From andrew.hutton@siemens-enterprise.com Thu Feb 9 07:26:37 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865BA21F86D1 for ; Thu, 9 Feb 2012 07:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY6Ab6weQLMY for ; Thu, 9 Feb 2012 07:26:36 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id C3C8D21F86B7 for ; Thu, 9 Feb 2012 07:26:36 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 518F11EB8406 for ; Thu, 9 Feb 2012 16:26:35 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 9 Feb 2012 16:26:35 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Thu, 9 Feb 2012 16:26:34 +0100 Thread-Topic: SRC, SRS feature tags in a REGISTER Thread-Index: AcznPzTjEEgzRg5VTjeI/5IE7UpA8w== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202DA2AF8@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] SRC, SRS feature tags in a REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 15:26:37 -0000 Hi All, What are the views of the group regarding including the "srs" and "src" fea= ture tags in a REGISTER request and what should be stated in the siprec pro= tocol draft? The current text in http://tools.ietf.org/html/draft-ietf-siprec-protocol-0= 2#section-5.1 & section 5.2 is a bit woolly only for example section 5.1. s= tates "a registrar could discover that a UA is an SRC based on the presence= of this feature tag in a registration" and there is similar text in 5.2. I am thinking that it is not necessarily always going to be useful to provi= de this information in REGISTER so some text such as "The SRC MAY include t= he "src" feature tag in a REGISTER request is probably what we want to say. Any comment? Regards Andy From trac+siprec@trac.tools.ietf.org Thu Feb 9 07:48:00 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510C121F86B6 for ; Thu, 9 Feb 2012 07:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr+F9VqlXfwM for ; Thu, 9 Feb 2012 07:47:59 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 89E3321F86B9 for ; Thu, 9 Feb 2012 07:47:59 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RvWDo-0002yJ-TM; Thu, 09 Feb 2012 10:47:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-siprec-protocol@tools.ietf.org, andrew.hutton@siemens-enterprise.com X-Trac-Project: siprec Date: Thu, 09 Feb 2012 15:47:44 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/83 Message-ID: <077.0021af1f6889a3d61f7d2f0642166001@trac.tools.ietf.org> X-Trac-Ticket-ID: 83 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-siprec-protocol@tools.ietf.org, andrew.hutton@siemens-enterprise.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120209154759.89E3321F86B9@ietfa.amsl.com> Resent-Date: Thu, 9 Feb 2012 07:47:59 -0800 (PST) Resent-From: trac+siprec@trac.tools.ietf.org Cc: siprec@ietf.org Subject: [siprec] #83: Need agreement on what to say about feature tags in REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 15:48:00 -0000 #83: Need agreement on what to say about feature tags in REGISTER -- -----------------------------+------------------------------------------ Reporter: andrew.hutton@… | Owner: draft-ietf-siprec-protocol@… Type: task | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: -----------------------------+------------------------------------------ Ticket URL: siprec From andrew.hutton@siemens-enterprise.com Thu Feb 9 09:04:35 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E5521E803D for ; Thu, 9 Feb 2012 09:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1dw2r4GcrP8 for ; Thu, 9 Feb 2012 09:04:35 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id C9A6E21E803B for ; Thu, 9 Feb 2012 09:04:34 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id F0C261EB8442 for ; Thu, 9 Feb 2012 18:04:33 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 9 Feb 2012 18:04:34 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Thu, 9 Feb 2012 18:04:32 +0100 Thread-Topic: Is SIPREC metadata mandatory to implement? Thread-Index: AcznTOSoydzMaYcFRNu/P4luqjLjsQ== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 17:04:35 -0000 Hi All, I am not sure we have ever addressed the question of whether a minimum SIPR= EC implementation could exist without any metadata being passed between the= SRC and SRS. =20 The way the protocol draft for example is written appears to make at least = some metadata mandatory for example section 6.1 states: "The SRC MUST provide a label attribute (a=3Dlabel), as per [RFC4574], on e= ach media stream in order to identify the recorded stream with the rest of = the metadata". Making it mandatory for the SRC to at least use the label attribute in SDP. I this what we want? Regards Andy (SIPREC co-chair). From pkyzivat@alum.mit.edu Thu Feb 9 12:34:46 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C06A11E8089 for ; Thu, 9 Feb 2012 12:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5tqI8Uia0BW for ; Thu, 9 Feb 2012 12:34:45 -0800 (PST) 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 67D5711E8073 for ; Thu, 9 Feb 2012 12:34:45 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id XvmZ1i0091c6gX85EwalPQ; Thu, 09 Feb 2012 20:34:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id Xwal1i01d07duvL3jwalc0; Thu, 09 Feb 2012 20:34:45 +0000 Message-ID: <4F342DE4.70306@alum.mit.edu> Date: Thu, 09 Feb 2012 15:34:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 20:34:46 -0000 On 2/9/12 12:04 PM, Hutton, Andrew wrote: > Hi All, > > I am not sure we have ever addressed the question of whether a minimum SIPREC implementation could exist without any metadata being passed between the SRC and SRS. > > The way the protocol draft for example is written appears to make at least some metadata mandatory for example section 6.1 states: > > "The SRC MUST provide a label attribute (a=label), as per [RFC4574], on each media stream in order to identify the recorded stream with the rest of the metadata". > > Making it mandatory for the SRC to at least use the label attribute in SDP. > > I this what we want? I think so. Its hard to imagine the utility of siprec without some metadata. The recorder can receive some media but has absolutely no context regarding what it means, other than perhaps From. The usage would be proprietary. Thanks, Paul From eckelcu@cisco.com Thu Feb 9 15:47:25 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB2611E808A for ; Thu, 9 Feb 2012 15:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaLYbPpt0SmZ for ; Thu, 9 Feb 2012 15:47:25 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2960511E8079 for ; Thu, 9 Feb 2012 15:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1365; q=dns/txt; s=iport; t=1328831245; x=1330040845; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=nBKSQ6nkwXGzWS0gz+nNDGbMMY5JVuSZPlLZ9VwyD8o=; b=Mj7IN3ma5iHp5LbyiE45h5Z78ma8C5DUaqydpFZyyn2rp6QuoYKInh8R c1Ic5b1y+WM1qkoyKJ4QJ76exUkuKtZrH1Ed9QZnlXtDZhHceWIqGa6i6 O2tdXU4qb+qYrPhiKjqA+JTiTjcK3Q30KdzBza6ZHpoRnEDBUISvP1zOA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAABaNE+rRDoI/2dsb2JhbABDr12BB4FyAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHY5l2AZ8Fi1ITAgMCAQcGNxoCBAIEB4MZAYEBAQIDBBSCYGMEiEifag X-IronPort-AV: E=Sophos;i="4.73,393,1325462400"; d="scan'208";a="27955852" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 09 Feb 2012 23:47:24 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q19NlO0T032493; Thu, 9 Feb 2012 23:47:24 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 15:47:24 -0800 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, 9 Feb 2012 15:47:22 -0800 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202DA2AF8@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SRC, SRS feature tags in a REGISTER Thread-Index: AcznPzTjEEgzRg5VTjeI/5IE7UpA8wARarzg References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2AF8@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , X-OriginalArrivalTime: 09 Feb 2012 23:47:24.0592 (UTC) FILETIME=[2C3F6300:01CCE785] Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2012 23:47:26 -0000 I'm somewhere between SHOULD and MUST for this. If we do not think it is really useful, then why define it in the first place? Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Thursday, February 09, 2012 3:27 PM > To: siprec@ietf.org > Subject: [siprec] SRC, SRS feature tags in a REGISTER >=20 > Hi All, >=20 > What are the views of the group regarding including the "srs" and "src" > feature tags in a REGISTER request and what should be stated in the > siprec protocol draft? >=20 > The current text in http://tools.ietf.org/html/draft-ietf-siprec- > protocol-02#section-5.1 & section 5.2 is a bit woolly only for example > section 5.1. states "a registrar could discover that a UA is an SRC > based on the presence of this feature tag in a registration" and there > is similar text in 5.2. >=20 > I am thinking that it is not necessarily always going to be useful to > provide this information in REGISTER so some text such as "The SRC MAY > include the "src" feature tag in a REGISTER request is probably what we > want to say. >=20 > Any comment? >=20 > Regards > Andy >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Feb 9 20:43:51 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1721F85D8 for ; Thu, 9 Feb 2012 20:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW08y-ldMwsG for ; Thu, 9 Feb 2012 20:43:50 -0800 (PST) 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 357F921F852F for ; Thu, 9 Feb 2012 20:43:48 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta12.westchester.pa.mail.comcast.net with comcast id Y4ih1i00317dt5G5C4joZr; Fri, 10 Feb 2012 04:43:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id Y4jo1i00Q07duvL3Z4jo0V; Fri, 10 Feb 2012 04:43:48 +0000 Message-ID: <4F34A081.9070408@alum.mit.edu> Date: Thu, 09 Feb 2012 23:43:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2AF8@MCHP058A.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 04:43:51 -0000 IMO MUST is appropriate here. Otherwise there will be interop issues. The presence of the SRC tag allows the same URI to be used to contact a UA as an SRS and for other purposes (e.g. as some other sort of media processor.) And the presence of the SRS tag allows the SRC to discover it has connected to an inappropriate server. Thanks, Paul On 2/9/12 6:47 PM, Charles Eckel (eckelcu) wrote: > I'm somewhere between SHOULD and MUST for this. If we do not think it is > really useful, then why define it in the first place? > > Cheers, > Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: Thursday, February 09, 2012 3:27 PM >> To: siprec@ietf.org >> Subject: [siprec] SRC, SRS feature tags in a REGISTER >> >> Hi All, >> >> What are the views of the group regarding including the "srs" and > "src" >> feature tags in a REGISTER request and what should be stated in the >> siprec protocol draft? >> >> The current text in http://tools.ietf.org/html/draft-ietf-siprec- >> protocol-02#section-5.1& section 5.2 is a bit woolly only for example >> section 5.1. states "a registrar could discover that a UA is an SRC >> based on the presence of this feature tag in a registration" and there >> is similar text in 5.2. >> >> I am thinking that it is not necessarily always going to be useful to >> provide this information in REGISTER so some text such as "The SRC MAY >> include the "src" feature tag in a REGISTER request is probably what > we >> want to say. >> >> Any comment? >> >> Regards >> Andy >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Fri Feb 10 07:02:49 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E4421F852E for ; Fri, 10 Feb 2012 07:02:49 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNR5xF4RbGsz for ; Fri, 10 Feb 2012 07:02:45 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E0A0721F86BE for ; Fri, 10 Feb 2012 07:02:44 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9D1C523F044B; Fri, 10 Feb 2012 16:02:38 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 10 Feb 2012 16:02:38 +0100 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Fri, 10 Feb 2012 16:02:36 +0100 Thread-Topic: [siprec] SRC, SRS feature tags in a REGISTER Thread-Index: AcznPzTjEEgzRg5VTjeI/5IE7UpA8wARarzgAB/e2aA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202DA31D3@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2AF8@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 15:02:49 -0000 The primary use of the feature tag's is used to identify the role of the UA= within the recording session it seems to me it is not so useful in the REG= ISTER but don't have a strong opinion. Maybe we should just make it a MUST = to reduce the options. Regards Andy=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 09 February 2012 23:47 > To: Hutton, Andrew; siprec@ietf.org > Subject: RE: [siprec] SRC, SRS feature tags in a REGISTER >=20 > I'm somewhere between SHOULD and MUST for this. If we do not think it > is > really useful, then why define it in the first place? >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Thursday, February 09, 2012 3:27 PM > > To: siprec@ietf.org > > Subject: [siprec] SRC, SRS feature tags in a REGISTER > > > > Hi All, > > > > What are the views of the group regarding including the "srs" and > "src" > > feature tags in a REGISTER request and what should be stated in the > > siprec protocol draft? > > > > The current text in http://tools.ietf.org/html/draft-ietf-siprec- > > protocol-02#section-5.1 & section 5.2 is a bit woolly only for > example > > section 5.1. states "a registrar could discover that a UA is an SRC > > based on the presence of this feature tag in a registration" and > there > > is similar text in 5.2. > > > > I am thinking that it is not necessarily always going to be useful to > > provide this information in REGISTER so some text such as "The SRC > MAY > > include the "src" feature tag in a REGISTER request is probably what > we > > want to say. > > > > Any comment? > > > > Regards > > Andy > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Fri Feb 10 07:10:31 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7A821F85AC for ; Fri, 10 Feb 2012 07:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVjeAyyMSHJj for ; Fri, 10 Feb 2012 07:10:29 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6C71021F859F for ; Fri, 10 Feb 2012 07:10:27 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id CDA3523F053F; Fri, 10 Feb 2012 16:10:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 10 Feb 2012 16:10:27 +0100 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Date: Fri, 10 Feb 2012 16:10:25 +0100 Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AcznakW3mp5OqB5WQW2RW5xqZlXR5AAmt4zg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202DA31EF@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <4F342DE4.70306@alum.mit.edu> In-Reply-To: <4F342DE4.70306@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] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 15:10:31 -0000 In the simplest case of a SIP endpoint (E.g. SIP Phone) acting as the SRC t= hen maybe all that is needed is the from header to identify the endpoint an= d the time which the SRS can get for itself. In this case the metadata body would not be needed and it would not make se= nse to include a label in the SDP. In anything more complex I agree metadata is needed. The question is whether this simplest case is within scope and I tend to th= ink it is but interested in hearing more opinions. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 09 February 2012 20:35 > To: siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >=20 > On 2/9/12 12:04 PM, Hutton, Andrew wrote: > > Hi All, > > > > I am not sure we have ever addressed the question of whether a > minimum SIPREC implementation could exist without any metadata being > passed between the SRC and SRS. > > > > The way the protocol draft for example is written appears to make at > least some metadata mandatory for example section 6.1 states: > > > > "The SRC MUST provide a label attribute (a=3Dlabel), as per [RFC4574], > on each media stream in order to identify the recorded stream with the > rest of the metadata". > > > > Making it mandatory for the SRC to at least use the label attribute > in SDP. > > > > I this what we want? >=20 > I think so. Its hard to imagine the utility of siprec without some > metadata. The recorder can receive some media but has absolutely no > context regarding what it means, other than perhaps From. The usage > would be proprietary. >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Fri Feb 10 07:48:39 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EA021F8605 for ; Fri, 10 Feb 2012 07:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrdfDTEe7ZiB for ; Fri, 10 Feb 2012 07:48:38 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7788221F8604 for ; Fri, 10 Feb 2012 07:48:38 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta10.westchester.pa.mail.comcast.net with comcast id YE3G1i0011ZXKqc5AFoeCm; Fri, 10 Feb 2012 15:48:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id YFoe1i00f07duvL3hFoe41; Fri, 10 Feb 2012 15:48:38 +0000 Message-ID: <4F353C55.50006@alum.mit.edu> Date: Fri, 10 Feb 2012 10:48:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hutton, Andrew" References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <4F342DE4.70306@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31202DA31EF@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202DA31EF@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 15:48:39 -0000 On 2/10/12 10:10 AM, Hutton, Andrew wrote: > In the simplest case of a SIP endpoint (E.g. SIP Phone) acting as the SRC then maybe all that is needed is the from header to identify the endpoint and the time which the SRS can get for itself. > > In this case the metadata body would not be needed and it would not make sense to include a label in the SDP. > > In anything more complex I agree metadata is needed. > > The question is whether this simplest case is within scope and I tend to think it is but interested in hearing more opinions. I think you are suggesting an SRS that gets a connection from an SRC without metadata should infer some default metadata based on other information in the message. If that is what we want, then we should say that, and spell out what inferences should be made. If we don't do that, then different SRSs are likely to make different inferences (or none), resulting in interop issues. Thanks, Paul > Regards > Andy > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 09 February 2012 20:35 >> To: siprec@ietf.org >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> On 2/9/12 12:04 PM, Hutton, Andrew wrote: >>> Hi All, >>> >>> I am not sure we have ever addressed the question of whether a >> minimum SIPREC implementation could exist without any metadata being >> passed between the SRC and SRS. >>> >>> The way the protocol draft for example is written appears to make at >> least some metadata mandatory for example section 6.1 states: >>> >>> "The SRC MUST provide a label attribute (a=label), as per [RFC4574], >> on each media stream in order to identify the recorded stream with the >> rest of the metadata". >>> >>> Making it mandatory for the SRC to at least use the label attribute >> in SDP. >>> >>> I this what we want? >> >> I think so. Its hard to imagine the utility of siprec without some >> metadata. The recorder can receive some media but has absolutely no >> context regarding what it means, other than perhaps From. The usage >> would be proprietary. >> >> Thanks, >> Paul >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Fri Feb 10 07:49:25 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155D611E8081 for ; Fri, 10 Feb 2012 07:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbyGYRHkR5sb for ; Fri, 10 Feb 2012 07:49:24 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 60A0421F8604 for ; Fri, 10 Feb 2012 07:49:23 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 478B21EB8439 for ; Fri, 10 Feb 2012 16:49:22 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 10 Feb 2012 16:49:22 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 10 Feb 2012 16:49:20 +0100 Thread-Topic: [siprec] SRC, SRS feature tags in a REGISTER Thread-Index: AcznPzTjEEgzRg5VTjeI/5IE7UpA8wARarzgAB/e2aAAAZuA4A== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202E31667@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2AF8@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E31202DA31D3@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202DA31D3@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 15:49:25 -0000 Hi All, Another related question. When include in an INVITE the 'src' and 'srs' feature tag's indicate that f= or this session the UA generating the request acts as either a SRC or a SRS= and therefore they are mutually exclusive. If included in a REGISTER requests then it just indicates a capability and = therefore I guess they are not mutually exclusive although it would be an u= nusual case for a UA to be able to act as both. We probably should also say= something about usage in OPTIONS. I don't have a huge opinion on this just think we need to clarify the proto= col draft. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: 10 February 2012 15:03 > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER >=20 > The primary use of the feature tag's is used to identify the role of > the UA within the recording session it seems to me it is not so useful > in the REGISTER but don't have a strong opinion. Maybe we should just > make it a MUST to reduce the options. >=20 > Regards > Andy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 09 February 2012 23:47 > > To: Hutton, Andrew; siprec@ietf.org > > Subject: RE: [siprec] SRC, SRS feature tags in a REGISTER > > > > I'm somewhere between SHOULD and MUST for this. If we do not think it > > is > > really useful, then why define it in the first place? > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: Thursday, February 09, 2012 3:27 PM > > > To: siprec@ietf.org > > > Subject: [siprec] SRC, SRS feature tags in a REGISTER > > > > > > Hi All, > > > > > > What are the views of the group regarding including the "srs" and > > "src" > > > feature tags in a REGISTER request and what should be stated in the > > > siprec protocol draft? > > > > > > The current text in http://tools.ietf.org/html/draft-ietf-siprec- > > > protocol-02#section-5.1 & section 5.2 is a bit woolly only for > > example > > > section 5.1. states "a registrar could discover that a UA is an SRC > > > based on the presence of this feature tag in a registration" and > > there > > > is similar text in 5.2. > > > > > > I am thinking that it is not necessarily always going to be useful > to > > > provide this information in REGISTER so some text such as "The SRC > > MAY > > > include the "src" feature tag in a REGISTER request is probably > what > > we > > > want to say. > > > > > > Any comment? > > > > > > Regards > > > Andy > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Fri Feb 10 09:57:17 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8542D21F87A4 for ; Fri, 10 Feb 2012 09:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxlMeGRKsIKr for ; Fri, 10 Feb 2012 09:57:15 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id D26A221F872F for ; Fri, 10 Feb 2012 09:57:14 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 16B651EB848E for ; Fri, 10 Feb 2012 18:57:14 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 10 Feb 2012 18:57:14 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 10 Feb 2012 18:57:13 +0100 Thread-Topic: Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5Q== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Feb 2012 17:57:18 -0000 Hi All, Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf-siprec-pro= tocol-02#section-6.1.1 describes how the SRC can add and remove media lines= during a recording session. However there is no corresponding section describing how the SRS can do the= same. I assume that that the SRS could for example terminate a stream duri= ng recording for example it might decide it no longer wants to record the v= ideo stream but will continue recording the audio.=20 We need to describe the use of offerless INVITE's by the SRS for example wh= en the SRS initiates the recording. Regards Andy From pravindran@sonusnet.com Sat Feb 11 07:05:34 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3717321F8527 for ; Sat, 11 Feb 2012 07:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 519K772CfGuN for ; Sat, 11 Feb 2012 07:05:33 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3320C21F8526 for ; Sat, 11 Feb 2012 07:05:32 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1BF6H89020521; Sat, 11 Feb 2012 10:06:17 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Feb 2012 10:05:09 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Feb 2012 20:35:16 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Sat, 11 Feb 2012 20:35:15 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AcznTOSoydzMaYcFRNu/P4luqjLjsf//3oYAgAE3uID//hQpMA== Date: Sat, 11 Feb 2012 15:05:14 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03F466@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <4F342DE4.70306@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31202DA31EF@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202DA31EF@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2012 15:05:16.0039 (UTC) FILETIME=[8FCD1170:01CCE8CE] Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 11 Feb 2012 15:05:34 -0000 Hi Andy, >From header in RS indicates SIP endpoint which acts as SRC but how to repre= sent the remote endpoint in this scenario because TO header indicates SRS.= =20 Also, your mail indicates the dependency on "Date" header in RS right? Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Friday, February 10, 2012 8:40 PM >To: Paul Kyzivat; siprec@ietf.org >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >In the simplest case of a SIP endpoint (E.g. SIP Phone) acting as the >SRC then maybe all that is needed is the from header to identify the >endpoint and the time which the SRS can get for itself. > >In this case the metadata body would not be needed and it would not make >sense to include a label in the SDP. > >In anything more complex I agree metadata is needed. > >The question is whether this simplest case is within scope and I tend to >think it is but interested in hearing more opinions. > >Regards >Andy > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 09 February 2012 20:35 >> To: siprec@ietf.org >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> On 2/9/12 12:04 PM, Hutton, Andrew wrote: >> > Hi All, >> > >> > I am not sure we have ever addressed the question of whether a >> minimum SIPREC implementation could exist without any metadata being >> passed between the SRC and SRS. >> > >> > The way the protocol draft for example is written appears to make at >> least some metadata mandatory for example section 6.1 states: >> > >> > "The SRC MUST provide a label attribute (a=3Dlabel), as per [RFC4574], >> on each media stream in order to identify the recorded stream with the >> rest of the metadata". >> > >> > Making it mandatory for the SRC to at least use the label attribute >> in SDP. >> > >> > I this what we want? >> >> I think so. Its hard to imagine the utility of siprec without some >> metadata. The recorder can receive some media but has absolutely no >> context regarding what it means, other than perhaps From. The usage >> would be proprietary. >> >> Thanks, >> Paul >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@genesyslab.com Mon Feb 13 07:57:59 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516CB21F856D for ; Mon, 13 Feb 2012 07:57:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RzNiHnJ76Ib for ; Mon, 13 Feb 2012 07:57:58 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id C8BE221F854B for ; Mon, 13 Feb 2012 07:57:58 -0800 (PST) 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 q1DFvwS1010732; Mon, 13 Feb 2012 07:57:58 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 07:57:58 -0800 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, 13 Feb 2012 07:57:37 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AcznTOSoydzMaYcFRNu/P4luqjLjsQDGsPTA References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> From: "Henry Lum" To: "Hutton, Andrew" , X-OriginalArrivalTime: 13 Feb 2012 15:57:58.0349 (UTC) FILETIME=[4182C7D0:01CCEA68] X-Mailman-Approved-At: Mon, 13 Feb 2012 09:36:37 -0800 Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 15:57:59 -0000 On a similar note, I am wondering if we can allow recording sessions that carry metadata only. Since it's a SIP dialog, we still need to negotiate an SDP offer/answer, but with no m=3D lines in the SDP. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: February-09-12 12:05 PM > To: siprec@ietf.org > Subject: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Hi All, >=20 > I am not sure we have ever addressed the question of whether a minimum > SIPREC implementation could exist without any metadata being passed > between the SRC and SRS. >=20 > The way the protocol draft for example is written appears to make at > least some metadata mandatory for example section 6.1 states: >=20 > "The SRC MUST provide a label attribute (a=3Dlabel), as per [RFC4574], on > each media stream in order to identify the recorded stream with the > rest of the metadata". >=20 > Making it mandatory for the SRC to at least use the label attribute in > SDP. >=20 > I this what we want? >=20 > Regards > Andy (SIPREC co-chair). > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Mon Feb 13 10:01:13 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA2921F86FC for ; Mon, 13 Feb 2012 10:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d07yCV9bKkr4 for ; Mon, 13 Feb 2012 10:01:12 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 453EC21F86FA for ; Mon, 13 Feb 2012 10:01:12 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id ZVy91i0020Fqzac5DW1Cb2; Mon, 13 Feb 2012 18:01:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta08.westchester.pa.mail.comcast.net with comcast id ZW1C1i00n07duvL3UW1Cbl; Mon, 13 Feb 2012 18:01:12 +0000 Message-ID: <4F394FE6.4000709@alum.mit.edu> Date: Mon, 13 Feb 2012 13:01:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 18:01:13 -0000 On 2/13/12 10:57 AM, Henry Lum wrote: > On a similar note, I am wondering if we can allow recording sessions > that carry metadata only. Since it's a SIP dialog, we still need to > negotiate an SDP offer/answer, but with no m= lines in the SDP. I don't see why not. I can certainly see that an RS might be *established* with metadata but no media, because there is at that time no media to record. But at some later time media might be added to it. The degenerate case is that there is never any media. That seems pretty uninteresting, but perhaps not forbidden. And I guess the flip side of that is an RS with (initially) no metadata. That might be sent later, but if it isn't, then I suppose the SRS needs to cope. As I mentioned before, we should try to say something about what the SRS should infer from other info in the dialog in the absence of metadata. Thanks, Paul > Henry > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: February-09-12 12:05 PM >> To: siprec@ietf.org >> Subject: [siprec] Is SIPREC metadata mandatory to implement? >> >> Hi All, >> >> I am not sure we have ever addressed the question of whether a minimum >> SIPREC implementation could exist without any metadata being passed >> between the SRC and SRS. >> >> The way the protocol draft for example is written appears to make at >> least some metadata mandatory for example section 6.1 states: >> >> "The SRC MUST provide a label attribute (a=label), as per [RFC4574], > on >> each media stream in order to identify the recorded stream with the >> rest of the metadata". >> >> Making it mandatory for the SRC to at least use the label attribute in >> SDP. >> >> I this what we want? >> >> Regards >> Andy (SIPREC co-chair). >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From eckelcu@cisco.com Mon Feb 13 12:34:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96FF21E802A for ; Mon, 13 Feb 2012 12:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.339 X-Spam-Level: X-Spam-Status: No, score=-8.339 tagged_above=-999 required=5 tests=[AWL=2.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX+DVZkuVeJH for ; Mon, 13 Feb 2012 12:34:40 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 294DC21E8029 for ; Mon, 13 Feb 2012 12:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4218; q=dns/txt; s=iport; t=1329165280; x=1330374880; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=TfSUWvaLok5X9TYaAQUDhtYqI/q0g0l/4pwntX586fk=; b=BEajpdghlmjtMtI3JFABr6ktkiupLqCC7gkmOTg6dOLsY8IazTrsnkKp cfQRlJC2P4KBJVWGHPvYhkACdtw227zWG69lSyPfWd5sUGJn9emu0p9M0 Pb0/99h7ODgCTLiLo17NVA3QMswIVIIypV71KxositAdQh50wOMWyp0KK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOdyOU+rRDoH/2dsb2JhbAA5BAawEIEHgXIBAQEEAQEBDwEdCjQXBAIBCBEEAQELBhcBBgEmHwkIAQEEARACCBqHY5pRAZ5miRULgkETAgMCAQcGNxoCBAIEgyABgQEBAgMEFIJgYwSISp9tHA X-IronPort-AV: E=Sophos;i="4.73,413,1325462400"; d="scan'208";a="30002145" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 13 Feb 2012 20:34:39 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1DKYdGm018300; Mon, 13 Feb 2012 20:34:39 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, 13 Feb 2012 12:34:39 -0800 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, 13 Feb 2012 12:34:38 -0800 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202E31667@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SRC, SRS feature tags in a REGISTER Thread-Index: AcznPzTjEEgzRg5VTjeI/5IE7UpA8wARarzgAB/e2aAAAZuA4ACgxs0g References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2AF8@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E31202DA31D3@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E31202E31667@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , X-OriginalArrivalTime: 13 Feb 2012 20:34:39.0826 (UTC) FILETIME=[E8C32320:01CCEA8E] Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2012 20:34:40 -0000 I agree that we should specify something.=20 For REGISTER, I think indicating both src and srs is valid. For INVITE and OPTIONS, I think indicating src vs. srs is driven by the request. If the request contains src, I would expect the response to indicate srs, and vice versa. If the request indicates neither src nor srs, I think responding with src is generally useful, whereas responding with srs or both src and srs is a bit odd but perhaps still legal. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Friday, February 10, 2012 7:49 AM > To: siprec@ietf.org > Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER >=20 > Hi All, >=20 > Another related question. >=20 > When include in an INVITE the 'src' and 'srs' feature tag's indicate > that for this session the UA generating the request acts as either a > SRC or a SRS and therefore they are mutually exclusive. >=20 > If included in a REGISTER requests then it just indicates a capability > and therefore I guess they are not mutually exclusive although it would > be an unusual case for a UA to be able to act as both. We probably > should also say something about usage in OPTIONS. >=20 > I don't have a huge opinion on this just think we need to clarify the > protocol draft. >=20 > Regards > Andy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: 10 February 2012 15:03 > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER > > > > The primary use of the feature tag's is used to identify the role of > > the UA within the recording session it seems to me it is not so > useful > > in the REGISTER but don't have a strong opinion. Maybe we should just > > make it a MUST to reduce the options. > > > > Regards > > Andy > > > > > > > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 09 February 2012 23:47 > > > To: Hutton, Andrew; siprec@ietf.org > > > Subject: RE: [siprec] SRC, SRS feature tags in a REGISTER > > > > > > I'm somewhere between SHOULD and MUST for this. If we do not think > it > > > is > > > really useful, then why define it in the first place? > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Hutton, Andrew > > > > Sent: Thursday, February 09, 2012 3:27 PM > > > > To: siprec@ietf.org > > > > Subject: [siprec] SRC, SRS feature tags in a REGISTER > > > > > > > > Hi All, > > > > > > > > What are the views of the group regarding including the "srs" and > > > "src" > > > > feature tags in a REGISTER request and what should be stated in > the > > > > siprec protocol draft? > > > > > > > > The current text in http://tools.ietf.org/html/draft-ietf-siprec- > > > > protocol-02#section-5.1 & section 5.2 is a bit woolly only for > > > example > > > > section 5.1. states "a registrar could discover that a UA is an > SRC > > > > based on the presence of this feature tag in a registration" and > > > there > > > > is similar text in 5.2. > > > > > > > > I am thinking that it is not necessarily always going to be > useful > > to > > > > provide this information in REGISTER so some text such as "The > SRC > > > MAY > > > > include the "src" feature tag in a REGISTER request is probably > > what > > > we > > > > want to say. > > > > > > > > Any comment? > > > > > > > > Regards > > > > Andy > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Mon Feb 13 23:21:49 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E2F21F86F3 for ; Mon, 13 Feb 2012 23:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BVWUoKYMhSf for ; Mon, 13 Feb 2012 23:21:48 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4767821F86F2 for ; Mon, 13 Feb 2012 23:21:48 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1E7MXfM024111; Tue, 14 Feb 2012 02:22:33 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 02:21:45 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 12:51:54 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Tue, 14 Feb 2012 12:51:53 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AcznTOSoydzMaYcFRNu/P4luqjLjsQDGsPTA///HagD//sYRkA== Date: Tue, 14 Feb 2012 07:21:53 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com> <4F394FE6.4000709@alum.mit.edu> In-Reply-To: <4F394FE6.4000709@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 07:21:54.0021 (UTC) FILETIME=[53BF0950:01CCEAE9] Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 07:21:49 -0000 Paul, I agree with you for RS with metadata but no media and also RS without meta= data initially. Hi All, In case there is no metadata from SRC, Some of the possible inferring detai= ls in SRS based on RS dialog are=20 1) originating participant (From header). 2) Date & Time (Date header) 3) Call-id (Unique-id) Even though the simple "no metadata" approach reduce the complexity in SRC,= The issue is that SRS MUST support both SIP headers (RS) based metadata as= well as XML based metadata. IMO, it is preferred not to have two ways to r= epresent the same metadata within RS. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Paul Kyzivat >Sent: Monday, February 13, 2012 11:31 PM >To: siprec@ietf.org >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >On 2/13/12 10:57 AM, Henry Lum wrote: >> On a similar note, I am wondering if we can allow recording sessions >> that carry metadata only. Since it's a SIP dialog, we still need to >> negotiate an SDP offer/answer, but with no m=3D lines in the SDP. > >I don't see why not. > >I can certainly see that an RS might be *established* with metadata but >no media, because there is at that time no media to record. But at some >later time media might be added to it. > >The degenerate case is that there is never any media. That seems pretty >uninteresting, but perhaps not forbidden. > >And I guess the flip side of that is an RS with (initially) no metadata. >That might be sent later, but if it isn't, then I suppose the SRS needs >to cope. As I mentioned before, we should try to say something about >what the SRS should infer from other info in the dialog in the absence >of metadata. > > Thanks, > Paul > >> Henry >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Hutton, Andrew >>> Sent: February-09-12 12:05 PM >>> To: siprec@ietf.org >>> Subject: [siprec] Is SIPREC metadata mandatory to implement? >>> >>> Hi All, >>> >>> I am not sure we have ever addressed the question of whether a >>> minimum SIPREC implementation could exist without any metadata being >>> passed between the SRC and SRS. >>> >>> The way the protocol draft for example is written appears to make at >>> least some metadata mandatory for example section 6.1 states: >>> >>> "The SRC MUST provide a label attribute (a=3Dlabel), as per [RFC4574], >> on >>> each media stream in order to identify the recorded stream with the >>> rest of the metadata". >>> >>> Making it mandatory for the SRC to at least use the label attribute >>> in SDP. >>> >>> I this what we want? >>> >>> Regards >>> Andy (SIPREC co-chair). >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Feb 14 02:10:45 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296E221F8775 for ; Tue, 14 Feb 2012 02:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 043eio74NuHi for ; Tue, 14 Feb 2012 02:10:42 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5114A21F876F for ; Tue, 14 Feb 2012 02:10:39 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 223FE1EB84C3; Tue, 14 Feb 2012 11:10:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 14 Feb 2012 11:10:37 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Paul Kyzivat , "siprec@ietf.org" Date: Tue, 14 Feb 2012 11:10:34 +0100 Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AcznTOSoydzMaYcFRNu/P4luqjLjsQDGsPTA///HagD//sYRkP/9XZTA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com> <4F394FE6.4000709@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 10:10:46 -0000 Hi All, Ok I can see there are times when we might have metadata but no media but w= e need to be careful about the use cases for this as long as this supports = some recording use cases in which there is an intention to record the media= we are probably ok but we must be careful not to start down the path of a = general purpose CTI type interface. Both the case of media without metadata and metadata without media need to = be clearly described in the architecture and protocol drafts. I am not convinced that we need to go down the path of stating what headers= in the RS can/should be used if there is no metadata. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: 14 February 2012 07:22 > To: Paul Kyzivat; siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Paul, >=20 > I agree with you for RS with metadata but no media and also RS without > metadata initially. >=20 > Hi All, >=20 > In case there is no metadata from SRC, Some of the possible inferring > details in SRS based on RS dialog are >=20 > 1) originating participant (From header). > 2) Date & Time (Date header) > 3) Call-id (Unique-id) >=20 > Even though the simple "no metadata" approach reduce the complexity in > SRC, The issue is that SRS MUST support both SIP headers (RS) based > metadata as well as XML based metadata. IMO, it is preferred not to > have two ways to represent the same metadata within RS. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Paul Kyzivat > >Sent: Monday, February 13, 2012 11:31 PM > >To: siprec@ietf.org > >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > >On 2/13/12 10:57 AM, Henry Lum wrote: > >> On a similar note, I am wondering if we can allow recording sessions > >> that carry metadata only. Since it's a SIP dialog, we still need to > >> negotiate an SDP offer/answer, but with no m=3D lines in the SDP. > > > >I don't see why not. > > > >I can certainly see that an RS might be *established* with metadata > but > >no media, because there is at that time no media to record. But at > some > >later time media might be added to it. > > > >The degenerate case is that there is never any media. That seems > pretty > >uninteresting, but perhaps not forbidden. > > > >And I guess the flip side of that is an RS with (initially) no > metadata. > >That might be sent later, but if it isn't, then I suppose the SRS > needs > >to cope. As I mentioned before, we should try to say something about > >what the SRS should infer from other info in the dialog in the absence > >of metadata. > > > > Thanks, > > Paul > > > >> Henry > >> > >>> -----Original Message----- > >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>> Behalf Of Hutton, Andrew > >>> Sent: February-09-12 12:05 PM > >>> To: siprec@ietf.org > >>> Subject: [siprec] Is SIPREC metadata mandatory to implement? > >>> > >>> Hi All, > >>> > >>> I am not sure we have ever addressed the question of whether a > >>> minimum SIPREC implementation could exist without any metadata > being > >>> passed between the SRC and SRS. > >>> > >>> The way the protocol draft for example is written appears to make > at > >>> least some metadata mandatory for example section 6.1 states: > >>> > >>> "The SRC MUST provide a label attribute (a=3Dlabel), as per > [RFC4574], > >> on > >>> each media stream in order to identify the recorded stream with the > >>> rest of the metadata". > >>> > >>> Making it mandatory for the SRC to at least use the label attribute > >>> in SDP. > >>> > >>> I this what we want? > >>> > >>> Regards > >>> Andy (SIPREC co-chair). > >>> _______________________________________________ > >>> siprec mailing list > >>> siprec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/siprec > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >> > > > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Feb 14 02:19:27 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6021F879F for ; Tue, 14 Feb 2012 02:19:27 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISfETX1DRfj0 for ; Tue, 14 Feb 2012 02:19:27 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id EC5A421F879B for ; Tue, 14 Feb 2012 02:19:26 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 5B0661EB8466; Tue, 14 Feb 2012 11:19:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 14 Feb 2012 11:19:26 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Paul Kyzivat , "siprec@ietf.org" Date: Tue, 14 Feb 2012 11:19:24 +0100 Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AcznTOSoydzMaYcFRNu/P4luqjLjsf//3oYAgAE3uID//hQpMP/3wP1Q Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202E32073@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <4F342DE4.70306@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31202DA31EF@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E03F466@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E03F466@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 10:19:27 -0000 See below. My thinking is that we don't need to say anything about the use of RS heade= rs as metadata. Regards Andy > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 11 February 2012 15:05 > To: Hutton, Andrew; Paul Kyzivat; siprec@ietf.org > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Hi Andy, >=20 > From header in RS indicates SIP endpoint which acts as SRC but how to > represent the remote endpoint in this scenario because TO header > indicates SRS. [AndyH] - I assume that if the application needed this then it would need t= o implement the metadata. >=20 > Also, your mail indicates the dependency on "Date" header in RS right? >=20 [AndyH] Not really but I agree it could be used.=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Hutton, Andrew > >Sent: Friday, February 10, 2012 8:40 PM > >To: Paul Kyzivat; siprec@ietf.org > >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > >In the simplest case of a SIP endpoint (E.g. SIP Phone) acting as the > >SRC then maybe all that is needed is the from header to identify the > >endpoint and the time which the SRS can get for itself. > > > >In this case the metadata body would not be needed and it would not > make > >sense to include a label in the SDP. > > > >In anything more complex I agree metadata is needed. > > > >The question is whether this simplest case is within scope and I tend > to > >think it is but interested in hearing more opinions. > > > >Regards > >Andy > > > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: 09 February 2012 20:35 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >> > >> On 2/9/12 12:04 PM, Hutton, Andrew wrote: > >> > Hi All, > >> > > >> > I am not sure we have ever addressed the question of whether a > >> minimum SIPREC implementation could exist without any metadata being > >> passed between the SRC and SRS. > >> > > >> > The way the protocol draft for example is written appears to make > at > >> least some metadata mandatory for example section 6.1 states: > >> > > >> > "The SRC MUST provide a label attribute (a=3Dlabel), as per > [RFC4574], > >> on each media stream in order to identify the recorded stream with > the > >> rest of the metadata". > >> > > >> > Making it mandatory for the SRC to at least use the label > attribute > >> in SDP. > >> > > >> > I this what we want? > >> > >> I think so. Its hard to imagine the utility of siprec without some > >> metadata. The recorder can receive some media but has absolutely no > >> context regarding what it means, other than perhaps From. The usage > >> would be proprietary. > >> > >> 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 Tue Feb 14 07:11:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15C121F87FD for ; Tue, 14 Feb 2012 07:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTq-K+JY1tJG for ; Tue, 14 Feb 2012 07:11:28 -0800 (PST) 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 0786E21F87E4 for ; Tue, 14 Feb 2012 07:11:27 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta14.westchester.pa.mail.comcast.net with comcast id Zr921i0031GhbT85ErBUmp; Tue, 14 Feb 2012 15:11:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id ZrBT1i00U07duvL3TrBUSV; Tue, 14 Feb 2012 15:11:28 +0000 Message-ID: <4F3A799E.9000508@alum.mit.edu> Date: Tue, 14 Feb 2012 10:11:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hutton, Andrew" References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com> <4F394FE6.4000709@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 15:11:28 -0000 On 2/14/12 5:10 AM, Hutton, Andrew wrote: > Hi All, > > Ok I can see there are times when we might have metadata but no media but we need to be careful about the use cases for this as long as this supports some recording use cases in which there is an intention to record the media we are probably ok but we must be careful not to start down the path of a general purpose CTI type interface. I agree with not wanting to turn this into CTI. > Both the case of media without metadata and metadata without media need to be clearly described in the architecture and protocol drafts. > I am not convinced that we need to go down the path of stating what headers in the RS can/should be used if there is no metadata. I guess it isn't *necessary* to specify that. But there are consequences to not doing so: An SRC may have been getting acceptable results not specifying metadata. Then the SRS gets replaced with a different one and results are no longer acceptable because the new one doesn't infer things the same way. Thanks, Paul From Leon.Portman@nice.com Tue Feb 14 08:21:16 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8698021F8581 for ; Tue, 14 Feb 2012 08:21:16 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2RmkA34Mi8y for ; Tue, 14 Feb 2012 08:21:11 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2D92E21F854D for ; Tue, 14 Feb 2012 08:21:11 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 14 Feb 2012 18:21:07 +0200 From: Leon Portman To: Paul Kyzivat , "Hutton, Andrew" Date: Tue, 14 Feb 2012 18:21:06 +0200 Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AczrKvJHPxTjChegR0OefnL1oLxKywACW8/w Message-ID: <07465C1D981ABC41A344374066AE1A2C39DA3AEA74@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com> <4F394FE6.4000709@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net> <4F3A799E.9000508@alum.mit.edu> In-Reply-To: <4F3A799E.9000508@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] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 16:21:16 -0000 Couple of comments. Today main use cases for CTI interface are two: 1. receive information about calls for reporting/billing/recording etc - I = think we cover it very well 2. third party call control - out of scope of SIPREC I agree that custom headers in RS is a bad idea. Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Tuesday, February 14, 2012 5:11 PM To: Hutton, Andrew Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? On 2/14/12 5:10 AM, Hutton, Andrew wrote: > Hi All, > > Ok I can see there are times when we might have metadata but no media but= we need to be careful about the use cases for this as long as this support= s some recording use cases in which there is an intention to record the med= ia we are probably ok but we must be careful not to start down the path of = a general purpose CTI type interface. I agree with not wanting to turn this into CTI. > Both the case of media without metadata and metadata without media need t= o be clearly described in the architecture and protocol drafts. > I am not convinced that we need to go down the path of stating what heade= rs in the RS can/should be used if there is no metadata. I guess it isn't *necessary* to specify that. But there are consequences to= not doing so: An SRC may have been getting acceptable results not specifying metadata.=20 Then the SRS gets replaced with a different one and results are no longer a= cceptable because the new one doesn't infer things the same way. Thanks, Paul _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Tue Feb 14 08:21:48 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E727521E800E for ; Tue, 14 Feb 2012 08:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4SRP6h7hjqk for ; Tue, 14 Feb 2012 08:21:43 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 632E221F8581 for ; Tue, 14 Feb 2012 08:21:41 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Tue, 14 Feb 2012 18:21:40 +0200 From: Leon Portman To: "Charles Eckel (eckelcu)" , "Hutton, Andrew" , "siprec@ietf.org" Date: Tue, 14 Feb 2012 18:21:38 +0200 Thread-Topic: [siprec] SRC, SRS feature tags in a REGISTER Thread-Index: AcznPzTjEEgzRg5VTjeI/5IE7UpA8wARarzgAB/e2aAAAZuA4ACgxs0gACm0tBA= Message-ID: <07465C1D981ABC41A344374066AE1A2C39DA3AEA76@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2AF8@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E31202DA31D3@MCHP058A.global-ad.net> <101C6067BEC68246B0C3F6843BCCC1E31202E31667@MCHP058A.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 16:21:48 -0000 Agree Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Monday, February 13, 2012 10:35 PM To: Hutton, Andrew; siprec@ietf.org Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER I agree that we should specify something.=20 For REGISTER, I think indicating both src and srs is valid. For INVITE and OPTIONS, I think indicating src vs. srs is driven by the req= uest. If the request contains src, I would expect the response to indicate = srs, and vice versa. If the request indicates neither src nor srs, I think = responding with src is generally useful, whereas responding with srs or bot= h src and srs is a bit odd but perhaps still legal. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Hutton, Andrew > Sent: Friday, February 10, 2012 7:49 AM > To: siprec@ietf.org > Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER >=20 > Hi All, >=20 > Another related question. >=20 > When include in an INVITE the 'src' and 'srs' feature tag's indicate=20 > that for this session the UA generating the request acts as either a=20 > SRC or a SRS and therefore they are mutually exclusive. >=20 > If included in a REGISTER requests then it just indicates a capability=20 > and therefore I guess they are not mutually exclusive although it would > be an unusual case for a UA to be able to act as both. We probably=20 > should also say something about usage in OPTIONS. >=20 > I don't have a huge opinion on this just think we need to clarify the=20 > protocol draft. >=20 > Regards > Andy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > > Behalf Of Hutton, Andrew > > Sent: 10 February 2012 15:03 > > To: Charles Eckel (eckelcu); siprec@ietf.org > > Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER > > > > The primary use of the feature tag's is used to identify the role of=20 > > the UA within the recording session it seems to me it is not so > useful > > in the REGISTER but don't have a strong opinion. Maybe we should just > > make it a MUST to reduce the options. > > > > Regards > > Andy > > > > > > > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > Sent: 09 February 2012 23:47 > > > To: Hutton, Andrew; siprec@ietf.org > > > Subject: RE: [siprec] SRC, SRS feature tags in a REGISTER > > > > > > I'm somewhere between SHOULD and MUST for this. If we do not think > it > > > is > > > really useful, then why define it in the first place? > > > > > > Cheers, > > > Charles > > > > > > > -----Original Message----- > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > > Behalf Of Hutton, Andrew > > > > Sent: Thursday, February 09, 2012 3:27 PM > > > > To: siprec@ietf.org > > > > Subject: [siprec] SRC, SRS feature tags in a REGISTER > > > > > > > > Hi All, > > > > > > > > What are the views of the group regarding including the "srs" and > > > "src" > > > > feature tags in a REGISTER request and what should be stated in > the > > > > siprec protocol draft? > > > > > > > > The current text in http://tools.ietf.org/html/draft-ietf-siprec- > > > > protocol-02#section-5.1 & section 5.2 is a bit woolly only for > > > example > > > > section 5.1. states "a registrar could discover that a UA is an > SRC > > > > based on the presence of this feature tag in a registration" and > > > there > > > > is similar text in 5.2. > > > > > > > > I am thinking that it is not necessarily always going to be > useful > > to > > > > provide this information in REGISTER so some text such as "The > SRC > > > MAY > > > > include the "src" feature tag in a REGISTER request is probably > > what > > > we > > > > want to say. > > > > > > > > Any comment? > > > > > > > > Regards > > > > Andy > > > > > > > > > > > > _______________________________________________ > > > > siprec mailing list > > > > siprec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Leon.Portman@nice.com Tue Feb 14 08:23:10 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFCB21F8557 for ; Tue, 14 Feb 2012 08:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH-gzEK0B8kz for ; Tue, 14 Feb 2012 08:23:05 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 89FFB21F865F for ; Tue, 14 Feb 2012 08:23:00 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Tue, 14 Feb 2012 18:22:59 +0200 From: Leon Portman To: "Hutton, Andrew" , "siprec@ietf.org" Date: Tue, 14 Feb 2012 18:22:58 +0200 Thread-Topic: Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2Xvg Message-ID: <07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net> 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] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 16:23:10 -0000 But today, if SRS does not want to record something, or pause recording , i= t will use media-inactive attribute. Do we want for SRS to be able remove m= -lines? Leon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Friday, February 10, 2012 7:57 PM To: siprec@ietf.org Subject: [siprec] Protocol draft - SRS SDP Procedures. Hi All, Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf-siprec-pro= tocol-02#section-6.1.1 describes how the SRC can add and remove media lines= during a recording session. However there is no corresponding section describing how the SRS can do the= same. I assume that that the SRS could for example terminate a stream duri= ng recording for example it might decide it no longer wants to record the v= ideo stream but will continue recording the audio.=20 We need to describe the use of offerless INVITE's by the SRS for example wh= en the SRS initiates the recording. Regards Andy _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Feb 14 09:56:41 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF9221E807E for ; Tue, 14 Feb 2012 09:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce7JpXLElD0L for ; Tue, 14 Feb 2012 09:56:40 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C621E8027 for ; Tue, 14 Feb 2012 09:56:40 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 329021EB843F; Tue, 14 Feb 2012 18:56:39 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 14 Feb 2012 18:56:39 +0100 From: "Hutton, Andrew" To: Leon Portman , "siprec@ietf.org" Date: Tue, 14 Feb 2012 18:56:37 +0100 Thread-Topic: Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2XvgAAM8pnA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 17:56:41 -0000 I assume the SRS can remove m-lines and we should say something about this = in the protocol draft. Regards Andy > -----Original Message----- > From: Leon Portman [mailto:Leon.Portman@nice.com] > Sent: 14 February 2012 16:23 > To: Hutton, Andrew; siprec@ietf.org > Subject: RE: Protocol draft - SRS SDP Procedures. >=20 > But today, if SRS does not want to record something, or pause recording > , it will use media-inactive attribute. Do we want for SRS to be able > remove m-lines? >=20 > Leon >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Friday, February 10, 2012 7:57 PM > To: siprec@ietf.org > Subject: [siprec] Protocol draft - SRS SDP Procedures. >=20 > Hi All, >=20 > Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf- > siprec-protocol-02#section-6.1.1 describes how the SRC can add and > remove media lines during a recording session. >=20 > However there is no corresponding section describing how the SRS can do > the same. I assume that that the SRS could for example terminate a > stream during recording for example it might decide it no longer wants > to record the video stream but will continue recording the audio. >=20 > We need to describe the use of offerless INVITE's by the SRS for > example when the SRS initiates the recording. >=20 > Regards > Andy >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Feb 14 09:59:36 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB04421E8092 for ; Tue, 14 Feb 2012 09:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLoPwoCsNk5m for ; Tue, 14 Feb 2012 09:59:36 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7019D21E808C for ; Tue, 14 Feb 2012 09:59:36 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 330F523F0405; Tue, 14 Feb 2012 18:59:35 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 14 Feb 2012 18:59:35 +0100 From: "Hutton, Andrew" To: Paul Kyzivat Date: Tue, 14 Feb 2012 18:59:33 +0100 Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AczrKu1lqNK7LUHLRUGHohODZXbiQQAFyf/A Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com> <4F394FE6.4000709@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net> <4F3A799E.9000508@alum.mit.edu> In-Reply-To: <4F3A799E.9000508@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] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 17:59:37 -0000 On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: >=20 > I guess it isn't *necessary* to specify that. But there are > consequences > to not doing so: >=20 > An SRC may have been getting acceptable results not specifying > metadata. > Then the SRS gets replaced with a different one and results are no > longer acceptable because the new one doesn't infer things the same > way. >=20 I think we can live with this if metadata is really important to a solution= then the SRC will need to generate SIPREC metadata. Regards Andy From eckelcu@cisco.com Tue Feb 14 10:46:20 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1D21E80B0 for ; Tue, 14 Feb 2012 10:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 tagged_above=-999 required=5 tests=[AWL=2.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvqyYjjWO6E7 for ; Tue, 14 Feb 2012 10:46:19 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E592D21E8087 for ; Tue, 14 Feb 2012 10:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2142; q=dns/txt; s=iport; t=1329245178; x=1330454778; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=OGlcln0JMW4r4Eg9sqZCVf4GbgJkFNAbYaVSOMvu8fg=; b=FPkjcji0/VodHO2+8ZSVRMSiChVDdN1gP4xNgpGTFWl2qY3XsgaABU6D 8Q4ZCRS/RaH665aynawrRPHvrmKjCKe8dtLZ98NF1253zPgJUjl4SrJTT BD/xu0TD43jNk+j0OF6dAIUByIGUp5vKoqQJk7ee3oSs+FGnPnLvr3wpL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMarOk+rRDoH/2dsb2JhbABDsE2BB4FyAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHY5ocAZ5fi2oMAgcTDlICgzkBA2UJCAcDCIJMYwSISp9t X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="30193262" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 14 Feb 2012 18:46:02 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1EIk2n3018980; Tue, 14 Feb 2012 18:46:02 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 10:46:02 -0800 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, 14 Feb 2012 10:46:01 -0800 Message-ID: In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2XvgAAM8pnAAAcOOoA== References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net> From: "Charles Eckel (eckelcu)" To: "Hutton, Andrew" , "Leon Portman" , X-OriginalArrivalTime: 14 Feb 2012 18:46:02.0458 (UTC) FILETIME=[E68573A0:01CCEB48] Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 18:46:20 -0000 I assume that by remove you mean set port=3D0, correct? Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Tuesday, February 14, 2012 9:57 AM > To: Leon Portman; siprec@ietf.org > Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >=20 > I assume the SRS can remove m-lines and we should say something about > this in the protocol draft. >=20 > Regards > Andy >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 14 February 2012 16:23 > > To: Hutton, Andrew; siprec@ietf.org > > Subject: RE: Protocol draft - SRS SDP Procedures. > > > > But today, if SRS does not want to record something, or pause > recording > > , it will use media-inactive attribute. Do we want for SRS to be able > > remove m-lines? > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Friday, February 10, 2012 7:57 PM > > To: siprec@ietf.org > > Subject: [siprec] Protocol draft - SRS SDP Procedures. > > > > Hi All, > > > > Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf- > > siprec-protocol-02#section-6.1.1 describes how the SRC can add and > > remove media lines during a recording session. > > > > However there is no corresponding section describing how the SRS can > do > > the same. I assume that that the SRS could for example terminate a > > stream during recording for example it might decide it no longer > wants > > to record the video stream but will continue recording the audio. > > > > We need to describe the use of offerless INVITE's by the SRS for > > example when the SRS initiates the recording. > > > > Regards > > Andy > > > > > > _______________________________________________ > > siprec mailing 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 Tue Feb 14 10:59:27 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2A21F877B for ; Tue, 14 Feb 2012 10:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6q9i7MJcAHg for ; Tue, 14 Feb 2012 10:59:27 -0800 (PST) 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 97AAE21F8778 for ; Tue, 14 Feb 2012 10:59:26 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta08.westchester.pa.mail.comcast.net with comcast id Zsco1i00727AodY58uzTnh; Tue, 14 Feb 2012 18:59:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id ZuzS1i01007duvL3fuzShm; Tue, 14 Feb 2012 18:59:27 +0000 Message-ID: <4F3AAF0D.1080108@alum.mit.edu> Date: Tue, 14 Feb 2012 13:59:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net> <07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 18:59:27 -0000 On 2/14/12 12:56 PM, Hutton, Andrew wrote: > I assume the SRS can remove m-lines and we should say something about this in the protocol draft. s/remove/refuse/ (by setting port to zero in the answer) Thanks, Paul > Regards > Andy > >> -----Original Message----- >> From: Leon Portman [mailto:Leon.Portman@nice.com] >> Sent: 14 February 2012 16:23 >> To: Hutton, Andrew; siprec@ietf.org >> Subject: RE: Protocol draft - SRS SDP Procedures. >> >> But today, if SRS does not want to record something, or pause recording >> , it will use media-inactive attribute. Do we want for SRS to be able >> remove m-lines? >> >> Leon >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: Friday, February 10, 2012 7:57 PM >> To: siprec@ietf.org >> Subject: [siprec] Protocol draft - SRS SDP Procedures. >> >> Hi All, >> >> Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf- >> siprec-protocol-02#section-6.1.1 describes how the SRC can add and >> remove media lines during a recording session. >> >> However there is no corresponding section describing how the SRS can do >> the same. I assume that that the SRS could for example terminate a >> stream during recording for example it might decide it no longer wants >> to record the video stream but will continue recording the audio. >> >> We need to describe the use of offerless INVITE's by the SRS for >> example when the SRS initiates the recording. >> >> Regards >> Andy >> >> >> _______________________________________________ >> siprec mailing 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 Tue Feb 14 11:06:14 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D5A21E80A7 for ; Tue, 14 Feb 2012 11:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFhHcZ1UAhku for ; Tue, 14 Feb 2012 11:06:13 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDD721E808D for ; Tue, 14 Feb 2012 11:06:13 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id ZsGZ1i0051ap0As5Av6Dpz; Tue, 14 Feb 2012 19:06:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id Zv6D1i02E07duvL3iv6DvZ; Tue, 14 Feb 2012 19:06:13 +0000 Message-ID: <4F3AB0A4.80309@alum.mit.edu> Date: Tue, 14 Feb 2012 14:06:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hutton, Andrew" References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com> <4F394FE6.4000709@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net> <4F3A799E.9000508@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 19:06:14 -0000 On 2/14/12 12:59 PM, Hutton, Andrew wrote: > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: >> >> I guess it isn't *necessary* to specify that. But there are >> consequences >> to not doing so: >> >> An SRC may have been getting acceptable results not specifying >> metadata. >> Then the SRS gets replaced with a different one and results are no >> longer acceptable because the new one doesn't infer things the same >> way. >> > > I think we can live with this if metadata is really important to a solution then the SRC will need to generate SIPREC metadata. Maybe. But there is a big hurdle between not supplied metadata and supplying it. If the metadata is optional, then its quite possible that you will have SRCs that just aren't capable of doing so. (Most likely for some simple cases like a UA that is its own SRC.) Then you might get locked in to an SRS that handles that case as you like. You will start having proprietary islands if SRCs and SRSs that can work together. Thanks, Paul From eckelcu@cisco.com Tue Feb 14 11:49:17 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF3821F8661 for ; Tue, 14 Feb 2012 11:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.506 X-Spam-Level: X-Spam-Status: No, score=-8.506 tagged_above=-999 required=5 tests=[AWL=2.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G1pfgbBeiYg for ; Tue, 14 Feb 2012 11:49:16 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id ACF9821F85F6 for ; Tue, 14 Feb 2012 11:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2273; q=dns/txt; s=iport; t=1329248956; x=1330458556; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=JZiCkTpkoVwFbQkFgLClvzgGGhBRYeHl4CgeMqzW2xo=; b=XsEo2x4/IbBZrJs09gbIWoWRfXRQxvknwLFcjeeU8RnxP+iX2Mlx0t9/ iHDGcU4xVoMREEWDJDSorOCz2QoX/2AgX+/xwuPHYGmVt6RM+3gWWsiJu 9UjiN0iIIWYsmZIpUKjCqHEa7PScXQkXaqH4liYyYgDAzPCmxAvH1AbXB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANa5Ok+rRDoJ/2dsb2JhbAA7CA6wRoEHgXIBAQEEAQEBDwEdCjQLDAQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEEwgTB4djniABlnUEiRmCPgoFAwIJDBQCClICgzkBA0gBEwkRBwMIgkxjBIhKnxVY X-IronPort-AV: E=Sophos;i="4.73,418,1325462400"; d="scan'208";a="30205282" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 14 Feb 2012 19:49:16 +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 q1EJnGWw003543; Tue, 14 Feb 2012 19:49:16 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, 14 Feb 2012 11:49:16 -0800 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, 14 Feb 2012 11:49:15 -0800 Message-ID: In-Reply-To: <4F3AB0A4.80309@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AczrS7uZoebXIzgDROyu2G5qssR0mwABJFNg References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net> <4F3AB0A4.80309@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , "Hutton, Andrew" X-OriginalArrivalTime: 14 Feb 2012 19:49:16.0061 (UTC) FILETIME=[BBAF54D0:01CCEB51] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2012 19:49:17 -0000 Exploring this a bit further, I think this would define a new option tag, e.g. siprec-metadata. An SRC/SRS would include it in a Supported vs. Required header. In the event metadata is not used between the SRC and SRS, a well documented set of SIP headers could be used to convey specific information about the recording. =20 I do see some value in this. If we go this route, the next question is, do you mandate support for this SIP headers AND avoid any overlap between them and the XML metadata? Or do we say that the XML metadata, if present, supersedes anything conveyed via the SIP headers? Seeing as XML metadata is a key part of SIPREC, I would suspect the latter, but I am interested to hear what others think. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Tuesday, February 14, 2012 11:06 AM > To: Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >=20 > On 2/14/12 12:59 PM, Hutton, Andrew wrote: > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: > >> > >> I guess it isn't *necessary* to specify that. But there are > >> consequences > >> to not doing so: > >> > >> An SRC may have been getting acceptable results not specifying > >> metadata. > >> Then the SRS gets replaced with a different one and results are no > >> longer acceptable because the new one doesn't infer things the same > >> way. > >> > > > > I think we can live with this if metadata is really important to a > solution then the SRC will need to generate SIPREC metadata. >=20 > Maybe. But there is a big hurdle between not supplied metadata and > supplying it. If the metadata is optional, then its quite possible that > you will have SRCs that just aren't capable of doing so. (Most likely > for some simple cases like a UA that is its own SRC.) >=20 > Then you might get locked in to an SRS that handles that case as you > like. You will start having proprietary islands if SRCs and SRSs that > can work together. >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@genesyslab.com Wed Feb 15 20:47:24 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293AE21E8047 for ; Wed, 15 Feb 2012 20:47:24 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af-sTcGhPTR9 for ; Wed, 15 Feb 2012 20:47:20 -0800 (PST) Received: from relay-out1.wc.genesyslab.com (relay-out1.wc.genesyslab.com [198.49.180.223]) by ietfa.amsl.com (Postfix) with ESMTP id 0695721E8011 for ; Wed, 15 Feb 2012 20:47:20 -0800 (PST) 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 q1G4lIlg003989; Wed, 15 Feb 2012 20:47:18 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 20:47:18 -0800 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, 15 Feb 2012 20:46:28 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF740825147D@NAHALD.us.int.genesyslab.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] SRC, SRS feature tags in a REGISTER Thread-Index: AcznPzTjEEgzRg5VTjeI/5IE7UpA8wARarzgAB/e2aAAAZuA4ACgxs0gAHXGiEA= References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2AF8@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E31202DA31D3@MCHP058A.global-ad.net><101C6067BEC68246B0C3F6843BCCC1E31202E31667@MCHP058A.global-ad.net> From: "Henry Lum" To: "Charles Eckel (eckelcu)" , "Hutton, Andrew" , X-OriginalArrivalTime: 16 Feb 2012 04:47:18.0764 (UTC) FILETIME=[1016A2C0:01CCEC66] Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 04:47:24 -0000 I don't suppose we would disallow those unusual but technically legal uses? I don't have a strong position here on whether we should use a MUST or SHOULD, but using MAY does seem a little too weak if we even mention it in those sections. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: February-13-12 3:35 PM > To: Hutton, Andrew; siprec@ietf.org > Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER >=20 > I agree that we should specify something. > For REGISTER, I think indicating both src and srs is valid. > For INVITE and OPTIONS, I think indicating src vs. srs is driven by the > request. If the request contains src, I would expect the response to > indicate srs, and vice versa. If the request indicates neither src nor > srs, I think responding with src is generally useful, whereas > responding > with srs or both src and srs is a bit odd but perhaps still legal. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Friday, February 10, 2012 7:49 AM > > To: siprec@ietf.org > > Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER > > > > Hi All, > > > > Another related question. > > > > When include in an INVITE the 'src' and 'srs' feature tag's indicate > > that for this session the UA generating the request acts as either a > > SRC or a SRS and therefore they are mutually exclusive. > > > > If included in a REGISTER requests then it just indicates a > capability > > and therefore I guess they are not mutually exclusive although it > would > > be an unusual case for a UA to be able to act as both. We probably > > should also say something about usage in OPTIONS. > > > > I don't have a huge opinion on this just think we need to clarify the > > protocol draft. > > > > Regards > > Andy > > > > > > > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Hutton, Andrew > > > Sent: 10 February 2012 15:03 > > > To: Charles Eckel (eckelcu); siprec@ietf.org > > > Subject: Re: [siprec] SRC, SRS feature tags in a REGISTER > > > > > > The primary use of the feature tag's is used to identify the role > of > > > the UA within the recording session it seems to me it is not so > > useful > > > in the REGISTER but don't have a strong opinion. Maybe we should > just > > > make it a MUST to reduce the options. > > > > > > Regards > > > Andy > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > > Sent: 09 February 2012 23:47 > > > > To: Hutton, Andrew; siprec@ietf.org > > > > Subject: RE: [siprec] SRC, SRS feature tags in a REGISTER > > > > > > > > I'm somewhere between SHOULD and MUST for this. If we do not > think > > it > > > > is > > > > really useful, then why define it in the first place? > > > > > > > > Cheers, > > > > Charles > > > > > > > > > -----Original Message----- > > > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > > > > > Behalf Of Hutton, Andrew > > > > > Sent: Thursday, February 09, 2012 3:27 PM > > > > > To: siprec@ietf.org > > > > > Subject: [siprec] SRC, SRS feature tags in a REGISTER > > > > > > > > > > Hi All, > > > > > > > > > > What are the views of the group regarding including the "srs" > and > > > > "src" > > > > > feature tags in a REGISTER request and what should be stated in > > the > > > > > siprec protocol draft? > > > > > > > > > > The current text in > http://tools.ietf.org/html/draft-ietf-siprec- > > > > > protocol-02#section-5.1 & section 5.2 is a bit woolly only for > > > > example > > > > > section 5.1. states "a registrar could discover that a UA is an > > SRC > > > > > based on the presence of this feature tag in a registration" > and > > > > there > > > > > is similar text in 5.2. > > > > > > > > > > I am thinking that it is not necessarily always going to be > > useful > > > to > > > > > provide this information in REGISTER so some text such as "The > > SRC > > > > MAY > > > > > include the "src" feature tag in a REGISTER request is probably > > > what > > > > we > > > > > want to say. > > > > > > > > > > Any comment? > > > > > > > > > > Regards > > > > > Andy > > > > > > > > > > > > > > > _______________________________________________ > > > > > siprec mailing list > > > > > siprec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/siprec > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@genesyslab.com Wed Feb 15 20:52:20 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D78021E8011 for ; Wed, 15 Feb 2012 20:52:20 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78HMUFS7uZn8 for ; Wed, 15 Feb 2012 20:52:16 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6221E803C for ; Wed, 15 Feb 2012 20:52:16 -0800 (PST) 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 q1G4qFXc011133; Wed, 15 Feb 2012 20:52:15 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 20:52:15 -0800 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, 15 Feb 2012 20:51:25 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2XvgAAM8pnAASRqZEA== References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net> From: "Henry Lum" To: "Hutton, Andrew" , "Leon Portman" , X-OriginalArrivalTime: 16 Feb 2012 04:52:15.0593 (UTC) FILETIME=[C1032590:01CCEC66] Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 04:52:20 -0000 You're right, the SRS should be allowed to remove media streams from the session for streams that the SRS does not want to record. Somehow I had the impression that the SRS need to BYE the session to do so, however, an SRS should not be able to add a media stream on its own. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: February-14-12 12:57 PM > To: Leon Portman; siprec@ietf.org > Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >=20 > I assume the SRS can remove m-lines and we should say something about > this in the protocol draft. >=20 > Regards > Andy >=20 > > -----Original Message----- > > From: Leon Portman [mailto:Leon.Portman@nice.com] > > Sent: 14 February 2012 16:23 > > To: Hutton, Andrew; siprec@ietf.org > > Subject: RE: Protocol draft - SRS SDP Procedures. > > > > But today, if SRS does not want to record something, or pause > recording > > , it will use media-inactive attribute. Do we want for SRS to be able > > remove m-lines? > > > > Leon > > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Hutton, Andrew > > Sent: Friday, February 10, 2012 7:57 PM > > To: siprec@ietf.org > > Subject: [siprec] Protocol draft - SRS SDP Procedures. > > > > Hi All, > > > > Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf- > > siprec-protocol-02#section-6.1.1 describes how the SRC can add and > > remove media lines during a recording session. > > > > However there is no corresponding section describing how the SRS can > do > > the same. I assume that that the SRS could for example terminate a > > stream during recording for example it might decide it no longer > wants > > to record the video stream but will continue recording the audio. > > > > We need to describe the use of offerless INVITE's by the SRS for > > example when the SRS initiates the recording. > > > > Regards > > Andy > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Wed Feb 15 22:02:37 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48CE21F84F3 for ; Wed, 15 Feb 2012 22:02:36 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJtjix-7SbI0 for ; Wed, 15 Feb 2012 22:02:32 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 235AD21E8010 for ; Wed, 15 Feb 2012 22:02:31 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1G63GEV004553; Thu, 16 Feb 2012 01:03:16 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 01:02:28 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 11:32:37 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 16 Feb 2012 11:32:37 +0530 From: "Ravindran, Parthasarathi" To: Henry Lum , "Hutton, Andrew" , Leon Portman , "siprec@ietf.org" Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2XvgAAM8pnAASRqZEAACclhQ Date: Thu, 16 Feb 2012 06:02:36 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com> <101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net> <059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2012 06:02:37.0911 (UTC) FILETIME=[95B5BE70:01CCEC70] Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 06:02:37 -0000 Henry & All, This question is coming around multiple times in the different form whether= SRS is allowed to send offer or not. In case SRS is allowed to initial the= offer, it is possible for SRS to add the stream. IIUC, it was decided not = to send offer during metadata request. Whether it is possible to say that S= RS MUST NOT initiate offer towards SRC? Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Henry Lum >Sent: Thursday, February 16, 2012 10:21 AM >To: Hutton, Andrew; Leon Portman; siprec@ietf.org >Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >You're right, the SRS should be allowed to remove media streams from the >session for streams that the SRS does not want to record. Somehow I had >the impression that the SRS need to BYE the session to do so, however, >an SRS should not be able to add a media stream on its own. > >Henry > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Hutton, Andrew >> Sent: February-14-12 12:57 PM >> To: Leon Portman; siprec@ietf.org >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >> >> I assume the SRS can remove m-lines and we should say something about >> this in the protocol draft. >> >> Regards >> Andy >> >> > -----Original Message----- >> > From: Leon Portman [mailto:Leon.Portman@nice.com] >> > Sent: 14 February 2012 16:23 >> > To: Hutton, Andrew; siprec@ietf.org >> > Subject: RE: Protocol draft - SRS SDP Procedures. >> > >> > But today, if SRS does not want to record something, or pause >> recording >> > , it will use media-inactive attribute. Do we want for SRS to be >able >> > remove m-lines? >> > >> > Leon >> > >> > -----Original Message----- >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> > Behalf Of Hutton, Andrew >> > Sent: Friday, February 10, 2012 7:57 PM >> > To: siprec@ietf.org >> > Subject: [siprec] Protocol draft - SRS SDP Procedures. >> > >> > Hi All, >> > >> > Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf- >> > siprec-protocol-02#section-6.1.1 describes how the SRC can add and >> > remove media lines during a recording session. >> > >> > However there is no corresponding section describing how the SRS can >> do >> > the same. I assume that that the SRS could for example terminate a >> > stream during recording for example it might decide it no longer >> wants >> > to record the video stream but will continue recording the audio. >> > >> > We need to describe the use of offerless INVITE's by the SRS for >> > example when the SRS initiates the recording. >> > >> > Regards >> > Andy >> > >> > >> > _______________________________________________ >> > siprec mailing list >> > siprec@ietf.org >> > https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing 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 Feb 15 22:22:08 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379C211E8073 for ; Wed, 15 Feb 2012 22:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=3.200, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL1yHcOWSXsp for ; Wed, 15 Feb 2012 22:22:04 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1E55811E8074 for ; Wed, 15 Feb 2012 22:22:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=3794; q=dns/txt; s=iport; t=1329373323; x=1330582923; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+kaCf6E1Lu6VTACZq/tDqxVhL7nYD9XNwHMplqkYlB0=; b=e4ZvBWBYBnS11mnv9W8/lMqek8sCCvKPuPZUIyX2+REbiJAvV+V3lxHi joKmQoaDKCtp15nhlxlg/8ZtB//VcDUCiakKG1pS8RINicTEKHYSjcv2n DAfsCneg5f4/xqXC9HJgUlWq3/omvfQvd5WhUNkDPvRpExz8bFlpILGZq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEACmgPE9Io8UY/2dsb2JhbAA7CA6xaIFyAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEAQoICBMHh2aebwGWXgSJGYIyCAEBAgQBAQkFCQQSBVmDcQsBFQIHEggCCoJNYwSIS58cPw X-IronPort-AV: E=Sophos;i="4.73,427,1325462400"; d="scan'208";a="5677312" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 16 Feb 2012 06:22:01 +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 q1G6Lw1n017044; Thu, 16 Feb 2012 06:22:01 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, 16 Feb 2012 11:51: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: Thu, 16 Feb 2012 11:51:45 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AczrS7uZoebXIzgDROyu2G5qssR0mwABJFNgAEU3qiA= References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Charles Eckel (eckelcu)" , "Paul Kyzivat" , "Hutton, Andrew" X-OriginalArrivalTime: 16 Feb 2012 06:21:46.0961 (UTC) FILETIME=[4298DC10:01CCEC73] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 06:22:08 -0000 I see some issues in going with this way: 1) We will end up in having two different metadata mechanisms - one XML and one headers based 2) The existing SIP headers may not be sufficient to carry even the basic metadata ( as partha mentioned in his previous e-mail) and if we are going to add new headers then it is redundant as XML metadata was just added for that purpose. 3) SRC/SRS needs to negotiate on whether they want to use XML based metadata (SIPREC metadata) or Header based metadata and this will lead to more issues some of which you already outlined in the below e-mail So, I feel it's better to stick with one metadata (XML SIPREC metadata) and make it mandatory. What we can add is some guidelines on how SRS has to behave for the calls where SRC is unable to send metadata or if SRS encounters an SRC that is not completely compliant with SIPREC standards(say does not implement metadata). Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Wednesday, February 15, 2012 1:19 AM > To: Paul Kyzivat; Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Exploring this a bit further, I think this would define a new option > tag, e.g. siprec-metadata. An SRC/SRS would include it in a Supported > vs. Required header. In the event metadata is not used between the SRC > and SRS, a well documented set of SIP headers could be used to convey > specific information about the recording. >=20 > I do see some value in this. If we go this route, the next question is, > do you mandate support for this SIP headers AND avoid any overlap > between them and the XML metadata? Or do we say that the XML metadata, > if present, supersedes anything conveyed via the SIP headers? Seeing as > XML metadata is a key part of SIPREC, I would suspect the latter, but I > am interested to hear what others think. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Tuesday, February 14, 2012 11:06 AM > > To: Hutton, Andrew > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: > > >> > > >> I guess it isn't *necessary* to specify that. But there are > > >> consequences > > >> to not doing so: > > >> > > >> An SRC may have been getting acceptable results not specifying > > >> metadata. > > >> Then the SRS gets replaced with a different one and results are no > > >> longer acceptable because the new one doesn't infer things the > same > > >> way. > > >> > > > > > > I think we can live with this if metadata is really important to a > > solution then the SRC will need to generate SIPREC metadata. > > > > Maybe. But there is a big hurdle between not supplied metadata and > > supplying it. If the metadata is optional, then its quite possible > that > > you will have SRCs that just aren't capable of doing so. (Most likely > > for some simple cases like a UA that is its own SRC.) > > > > Then you might get locked in to an SRS that handles that case as you > > like. You will start having proprietary islands if SRCs and SRSs that > > can work together. > > > > Thanks, > > Paul > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From john.r.elwell@gmail.com Thu Feb 16 01:40:02 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5421F8585 for ; Thu, 16 Feb 2012 01:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvtJcscGDVlE for ; Thu, 16 Feb 2012 01:39:58 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5A2621F86E8 for ; Thu, 16 Feb 2012 01:39:57 -0800 (PST) Received: by werg1 with SMTP id g1so308939wer.31 for ; Thu, 16 Feb 2012 01:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole; bh=87tKn4GaGG71pW0yCH73yn3fxG0ziNPAfnZ2kIrz/Dk=; b=wZdWPrGEM/hCmQhYJpqVPA7y2Y7cwxeQGq7W+lZJfJ6MwARdZJGGgyVXt+1ipIEGTP Gsor6HpMDXBX8pU3ipixoJrBO0OiLBC2/rlQV8m5lJUIPU7ku3ESo6L6arTgCvf8a1xd h3lgzYFzfl4ITcnmLKAzz8mMs5ZFHEFL3mqgA= Received: by 10.180.101.200 with SMTP id fi8mr2956734wib.20.1329385196838; Thu, 16 Feb 2012 01:39:56 -0800 (PST) Received: from Acer (cpc1-clif8-2-0-cust418.12-4.cable.virginmedia.com. [82.25.209.163]) by mx.google.com with ESMTPS id m8sm23782154wia.11.2012.02.16.01.39.55 (version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 01:39:55 -0800 (PST) Message-ID: <3FF56432D85141C8ACF379A5CD6069EE@Acer> From: "John Elwell" To: "Ram Mohan R \(rmohanr\)" , "Charles Eckel \(eckelcu\)" , "Paul Kyzivat" , "Hutton, Andrew" References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com> Date: Thu, 16 Feb 2012 09:39:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 09:40:02 -0000 I think that XML-based metadata is the essence of SIPREC - other protocol additions are peripheral in comparison. We should say that if you don't implement and use XML-based metadata you are not SIPREC-compliant. Trying to bend SIP header fields to achieve a poor-man's metadata does not make sense, particularly as we know that B2BUAs are all too prone to modifying SIP header fields. John -----Original Message----- From: Ram Mohan R (rmohanr) Sent: Thursday, February 16, 2012 6:21 AM To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? I see some issues in going with this way: 1) We will end up in having two different metadata mechanisms - one XML and one headers based 2) The existing SIP headers may not be sufficient to carry even the basic metadata ( as partha mentioned in his previous e-mail) and if we are going to add new headers then it is redundant as XML metadata was just added for that purpose. 3) SRC/SRS needs to negotiate on whether they want to use XML based metadata (SIPREC metadata) or Header based metadata and this will lead to more issues some of which you already outlined in the below e-mail So, I feel it's better to stick with one metadata (XML SIPREC metadata) and make it mandatory. What we can add is some guidelines on how SRS has to behave for the calls where SRC is unable to send metadata or if SRS encounters an SRC that is not completely compliant with SIPREC standards(say does not implement metadata). Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: Wednesday, February 15, 2012 1:19 AM > To: Paul Kyzivat; Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > Exploring this a bit further, I think this would define a new option > tag, e.g. siprec-metadata. An SRC/SRS would include it in a Supported > vs. Required header. In the event metadata is not used between the SRC > and SRS, a well documented set of SIP headers could be used to convey > specific information about the recording. > > I do see some value in this. If we go this route, the next question is, > do you mandate support for this SIP headers AND avoid any overlap > between them and the XML metadata? Or do we say that the XML metadata, > if present, supersedes anything conveyed via the SIP headers? Seeing as > XML metadata is a key part of SIPREC, I would suspect the latter, but I > am interested to hear what others think. > > Cheers, > Charles > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Tuesday, February 14, 2012 11:06 AM > > To: Hutton, Andrew > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: > > >> > > >> I guess it isn't *necessary* to specify that. But there are > > >> consequences > > >> to not doing so: > > >> > > >> An SRC may have been getting acceptable results not specifying > > >> metadata. > > >> Then the SRS gets replaced with a different one and results are no > > >> longer acceptable because the new one doesn't infer things the > same > > >> way. > > >> > > > > > > I think we can live with this if metadata is really important to a > > solution then the SRC will need to generate SIPREC metadata. > > > > Maybe. But there is a big hurdle between not supplied metadata and > > supplying it. If the metadata is optional, then its quite possible > that > > you will have SRCs that just aren't capable of doing so. (Most likely > > for some simple cases like a UA that is its own SRC.) > > > > Then you might get locked in to an SRS that handles that case as you > > like. You will start having proprietary islands if SRCs and SRSs that > > can work together. > > > > 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 eckelcu@cisco.com Thu Feb 16 08:41:53 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D4921F881F for ; Thu, 16 Feb 2012 08:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.581 X-Spam-Level: X-Spam-Status: No, score=-8.581 tagged_above=-999 required=5 tests=[AWL=2.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hiqUEwk9o+K for ; Thu, 16 Feb 2012 08:41:49 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 07AD621F8810 for ; Thu, 16 Feb 2012 08:41:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3945; q=dns/txt; s=iport; t=1329410509; x=1330620109; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1zCWmO1RREo8LF/sCHE3KoptIOuP1W6Gd7e+uUa3lmA=; b=k6P332m2sMlK+8SxK46ZV6NZaUO/6Zi/yE7UYrhonpEWGiOgF8l6SpCJ HGTFw0EmucYmjmuCF0p5QJNaRbAu0wxBsA+KdkixwaeUVHI+YUzql24e+ L3voOzVOycqFVjiRej9RC60Cml5s9rq8t3/aUdjEUpX/uoUSso2qNPjjy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHExPU+rRDoG/2dsb2JhbABDsGeBB4FyAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHZp8OAZZni2kLCAEDCQ0LPguDNAECWQkEBQ2CR2MEiE6fcg X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208";a="30782316" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 16 Feb 2012 16:41:48 +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 q1GGfm6H001422; Thu, 16 Feb 2012 16:41:48 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, 16 Feb 2012 08:41:40 -0800 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, 16 Feb 2012 08:41:39 -0800 Message-ID: In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2XvgAAM8pnAASRqZEAACclhQABZyLhA= References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> From: "Charles Eckel (eckelcu)" To: "Ravindran, Parthasarathi" , "Henry Lum" , "Hutton, Andrew" , "Leon Portman" , X-OriginalArrivalTime: 16 Feb 2012 16:41:40.0263 (UTC) FILETIME=[DB885B70:01CCECC9] Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 16:41:53 -0000 I do not see any need for such as a restriction. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: Wednesday, February 15, 2012 10:03 PM > To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org > Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >=20 > Henry & All, >=20 > This question is coming around multiple times in the different form > whether SRS is allowed to send offer or not. In case SRS is allowed to > initial the offer, it is possible for SRS to add the stream. IIUC, it > was decided not to send offer during metadata request. Whether it is > possible to say that SRS MUST NOT initiate offer towards SRC? >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Henry Lum > >Sent: Thursday, February 16, 2012 10:21 AM > >To: Hutton, Andrew; Leon Portman; siprec@ietf.org > >Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > > > >You're right, the SRS should be allowed to remove media streams from > the > >session for streams that the SRS does not want to record. Somehow I > had > >the impression that the SRS need to BYE the session to do so, however, > >an SRS should not be able to add a media stream on its own. > > > >Henry > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Hutton, Andrew > >> Sent: February-14-12 12:57 PM > >> To: Leon Portman; siprec@ietf.org > >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >> > >> I assume the SRS can remove m-lines and we should say something > about > >> this in the protocol draft. > >> > >> Regards > >> Andy > >> > >> > -----Original Message----- > >> > From: Leon Portman [mailto:Leon.Portman@nice.com] > >> > Sent: 14 February 2012 16:23 > >> > To: Hutton, Andrew; siprec@ietf.org > >> > Subject: RE: Protocol draft - SRS SDP Procedures. > >> > > >> > But today, if SRS does not want to record something, or pause > >> recording > >> > , it will use media-inactive attribute. Do we want for SRS to be > >able > >> > remove m-lines? > >> > > >> > Leon > >> > > >> > -----Original Message----- > >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> > Behalf Of Hutton, Andrew > >> > Sent: Friday, February 10, 2012 7:57 PM > >> > To: siprec@ietf.org > >> > Subject: [siprec] Protocol draft - SRS SDP Procedures. > >> > > >> > Hi All, > >> > > >> > Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf- > >> > siprec-protocol-02#section-6.1.1 describes how the SRC can add and > >> > remove media lines during a recording session. > >> > > >> > However there is no corresponding section describing how the SRS > can > >> do > >> > the same. I assume that that the SRS could for example terminate a > >> > stream during recording for example it might decide it no longer > >> wants > >> > to record the video stream but will continue recording the audio. > >> > > >> > We need to describe the use of offerless INVITE's by the SRS for > >> > example when the SRS initiates the recording. > >> > > >> > Regards > >> > Andy > >> > > >> > > >> > _______________________________________________ > >> > siprec mailing list > >> > siprec@ietf.org > >> > https://www.ietf.org/mailman/listinfo/siprec > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Thu Feb 16 09:27:02 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A90321F8816 for ; Thu, 16 Feb 2012 09:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhqtQN7+Rp40 for ; Thu, 16 Feb 2012 09:26:58 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 01C2B21F87FF for ; Thu, 16 Feb 2012 09:26:57 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1GHRfoG030455; Thu, 16 Feb 2012 12:27:41 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 12:26:53 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 22:57:03 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 16 Feb 2012 22:57:01 +0530 From: "Ravindran, Parthasarathi" To: "Charles Eckel (eckelcu)" , Henry Lum , "Hutton, Andrew" , Leon Portman , "siprec@ietf.org" Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2XvgAAM8pnAASRqZEAACclhQABZyLhAAAYdx0A== Date: Thu, 16 Feb 2012 17:27:00 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2012 17:27:03.0019 (UTC) FILETIME=[326BF3B0:01CCECD0] Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 17:27:02 -0000 Hi Charles, As a follow up query, whether SRS SHOULD be allowed to add the stream in it= s offer? As per your earlier statement, SRS should be allowed. Please corre= ct me in case I misunderstand your statement. Thanks Partha >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Thursday, February 16, 2012 10:12 PM >To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon Portman; >siprec@ietf.org >Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >I do not see any need for such as a restriction. > >Cheers, >Charles > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Ravindran, Parthasarathi >> Sent: Wednesday, February 15, 2012 10:03 PM >> To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >> >> Henry & All, >> >> This question is coming around multiple times in the different form >> whether SRS is allowed to send offer or not. In case SRS is allowed to >> initial the offer, it is possible for SRS to add the stream. IIUC, it >> was decided not to send offer during metadata request. Whether it is >> possible to say that SRS MUST NOT initiate offer towards SRC? >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >> >Of Henry Lum >> >Sent: Thursday, February 16, 2012 10:21 AM >> >To: Hutton, Andrew; Leon Portman; siprec@ietf.org >> >Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >> > >> >You're right, the SRS should be allowed to remove media streams from >> the >> >session for streams that the SRS does not want to record. Somehow I >> had >> >the impression that the SRS need to BYE the session to do so, >however, >> >an SRS should not be able to add a media stream on its own. >> > >> >Henry >> > >> >> -----Original Message----- >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> Behalf Of Hutton, Andrew >> >> Sent: February-14-12 12:57 PM >> >> To: Leon Portman; siprec@ietf.org >> >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >> >> >> >> I assume the SRS can remove m-lines and we should say something >> about >> >> this in the protocol draft. >> >> >> >> Regards >> >> Andy >> >> >> >> > -----Original Message----- >> >> > From: Leon Portman [mailto:Leon.Portman@nice.com] >> >> > Sent: 14 February 2012 16:23 >> >> > To: Hutton, Andrew; siprec@ietf.org >> >> > Subject: RE: Protocol draft - SRS SDP Procedures. >> >> > >> >> > But today, if SRS does not want to record something, or pause >> >> recording >> >> > , it will use media-inactive attribute. Do we want for SRS to be >> >able >> >> > remove m-lines? >> >> > >> >> > Leon >> >> > >> >> > -----Original Message----- >> >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> > Behalf Of Hutton, Andrew >> >> > Sent: Friday, February 10, 2012 7:57 PM >> >> > To: siprec@ietf.org >> >> > Subject: [siprec] Protocol draft - SRS SDP Procedures. >> >> > >> >> > Hi All, >> >> > >> >> > Currently section 6.1.1 of http://tools.ietf.org/html/draft-ietf- >> >> > siprec-protocol-02#section-6.1.1 describes how the SRC can add >and >> >> > remove media lines during a recording session. >> >> > >> >> > However there is no corresponding section describing how the SRS >> can >> >> do >> >> > the same. I assume that that the SRS could for example terminate >a >> >> > stream during recording for example it might decide it no longer >> >> wants >> >> > to record the video stream but will continue recording the audio. >> >> > >> >> > We need to describe the use of offerless INVITE's by the SRS for >> >> > example when the SRS initiates the recording. >> >> > >> >> > Regards >> >> > Andy >> >> > >> >> > >> >> > _______________________________________________ >> >> > siprec mailing list >> >> > siprec@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/siprec >> >> _______________________________________________ >> >> siprec mailing list >> >> siprec@ietf.org >> >> https://www.ietf.org/mailman/listinfo/siprec >> >_______________________________________________ >> >siprec mailing 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 Feb 16 09:36:25 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B025C21F87E9 for ; Thu, 16 Feb 2012 09:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.651 X-Spam-Level: X-Spam-Status: No, score=-8.651 tagged_above=-999 required=5 tests=[AWL=1.948, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDm8VnOLehfF for ; Thu, 16 Feb 2012 09:36:21 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4C09321F87E2 for ; Thu, 16 Feb 2012 09:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=5537; q=dns/txt; s=iport; t=1329413781; x=1330623381; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=VOkpc5LU3jRcLJfC4kSAM+oJRZPff619oLTizuDSWvs=; b=ZaGQnkDLqG07F9apMhiDpxNc9bXRa6KFdHviSqpYGxhDFOOETGj7GxOp ADvQ1j1CTLJJrcf1LRXg0frAh3Tu/L0Xl5CvgByczH6YYi6N4T9LfUAO7 y73gyqomLkipg0ViPTnIr7b8TYrwWagcR+LiX4Quv0ywKxde3Ti+Ap/Qb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFc+PU+rRDoG/2dsb2JhbABDsGiBB4FyAQEBBAEBAQ8BHQoyAhcEAgEIEQQBAQsGFwEGASYfCQgCBAESCBqHZp8PAZZji2kFDgEDFgs+gz8BAlkJBAUNgkdjBIhOn3I X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208";a="29147520" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 16 Feb 2012 17:36:20 +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 q1GHaL68000716; Thu, 16 Feb 2012 17:36:21 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 09:36:20 -0800 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, 16 Feb 2012 09:36:19 -0800 Message-ID: In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2XvgAAM8pnAASRqZEAACclhQABZyLhAAAYdx0AAATEmA References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com> From: "Charles Eckel (eckelcu)" To: "Ravindran, Parthasarathi" , "Henry Lum" , "Hutton, Andrew" , "Leon Portman" , X-OriginalArrivalTime: 16 Feb 2012 17:36:20.0801 (UTC) FILETIME=[7EE2BB10:01CCECD1] Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 17:36:25 -0000 Hi Partha, While I do not have a specific use case in mind that requires this, I do not see any benefit gained by explicitly not allowing it. I'd like to avoid placing unnecessary restrictions. If an SRS tries to add a media line and an SRC does not want to accept it, if can simply answer with port=3D0. That sounds fine to me. Cheers, Charles > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: Thursday, February 16, 2012 9:27 AM > To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon Portman; > siprec@ietf.org > Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >=20 > Hi Charles, >=20 > As a follow up query, whether SRS SHOULD be allowed to add the stream > in its offer? As per your earlier statement, SRS should be allowed. > Please correct me in case I misunderstand your statement. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >Sent: Thursday, February 16, 2012 10:12 PM > >To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon Portman; > >siprec@ietf.org > >Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > > > >I do not see any need for such as a restriction. > > > >Cheers, > >Charles > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Ravindran, Parthasarathi > >> Sent: Wednesday, February 15, 2012 10:03 PM > >> To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org > >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >> > >> Henry & All, > >> > >> This question is coming around multiple times in the different form > >> whether SRS is allowed to send offer or not. In case SRS is allowed > to > >> initial the offer, it is possible for SRS to add the stream. IIUC, > it > >> was decided not to send offer during metadata request. Whether it is > >> possible to say that SRS MUST NOT initiate offer towards SRC? > >> > >> Thanks > >> Partha > >> > >> >-----Original Message----- > >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf > >> >Of Henry Lum > >> >Sent: Thursday, February 16, 2012 10:21 AM > >> >To: Hutton, Andrew; Leon Portman; siprec@ietf.org > >> >Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >> > > >> >You're right, the SRS should be allowed to remove media streams > from > >> the > >> >session for streams that the SRS does not want to record. Somehow I > >> had > >> >the impression that the SRS need to BYE the session to do so, > >however, > >> >an SRS should not be able to add a media stream on its own. > >> > > >> >Henry > >> > > >> >> -----Original Message----- > >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> >> Behalf Of Hutton, Andrew > >> >> Sent: February-14-12 12:57 PM > >> >> To: Leon Portman; siprec@ietf.org > >> >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >> >> > >> >> I assume the SRS can remove m-lines and we should say something > >> about > >> >> this in the protocol draft. > >> >> > >> >> Regards > >> >> Andy > >> >> > >> >> > -----Original Message----- > >> >> > From: Leon Portman [mailto:Leon.Portman@nice.com] > >> >> > Sent: 14 February 2012 16:23 > >> >> > To: Hutton, Andrew; siprec@ietf.org > >> >> > Subject: RE: Protocol draft - SRS SDP Procedures. > >> >> > > >> >> > But today, if SRS does not want to record something, or pause > >> >> recording > >> >> > , it will use media-inactive attribute. Do we want for SRS to > be > >> >able > >> >> > remove m-lines? > >> >> > > >> >> > Leon > >> >> > > >> >> > -----Original Message----- > >> >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >> >> > Behalf Of Hutton, Andrew > >> >> > Sent: Friday, February 10, 2012 7:57 PM > >> >> > To: siprec@ietf.org > >> >> > Subject: [siprec] Protocol draft - SRS SDP Procedures. > >> >> > > >> >> > Hi All, > >> >> > > >> >> > Currently section 6.1.1 of http://tools.ietf.org/html/draft- > ietf- > >> >> > siprec-protocol-02#section-6.1.1 describes how the SRC can add > >and > >> >> > remove media lines during a recording session. > >> >> > > >> >> > However there is no corresponding section describing how the > SRS > >> can > >> >> do > >> >> > the same. I assume that that the SRS could for example > terminate > >a > >> >> > stream during recording for example it might decide it no > longer > >> >> wants > >> >> > to record the video stream but will continue recording the > audio. > >> >> > > >> >> > We need to describe the use of offerless INVITE's by the SRS > for > >> >> > example when the SRS initiates the recording. > >> >> > > >> >> > Regards > >> >> > Andy > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > siprec mailing list > >> >> > siprec@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/siprec > >> >> _______________________________________________ > >> >> siprec mailing list > >> >> siprec@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/siprec > >> >_______________________________________________ > >> >siprec mailing list > >> >siprec@ietf.org > >> >https://www.ietf.org/mailman/listinfo/siprec > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Thu Feb 16 09:45:15 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A65F21F8715 for ; Thu, 16 Feb 2012 09:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-wLcM70GpeK for ; Thu, 16 Feb 2012 09:45:11 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DA3C221F8877 for ; Thu, 16 Feb 2012 09:45:10 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1GHisNW009602; Thu, 16 Feb 2012 12:44:54 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 12:44:06 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 23:14:16 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 16 Feb 2012 23:14:15 +0530 From: "Ravindran, Parthasarathi" To: "Charles Eckel (eckelcu)" , Henry Lum , "Hutton, Andrew" , Leon Portman , "siprec@ietf.org" Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2XvgAAM8pnAASRqZEAACclhQABZyLhAAAYdx0AAATEmAAAAmdTA= Date: Thu, 16 Feb 2012 17:44:13 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04041C@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2012 17:44:16.0307 (UTC) FILETIME=[9A4F3030:01CCECD2] Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 17:45:15 -0000 Hi Charles, I agree with you as I don't see the strong reason to restrict. Let offer/an= swer exchange between SRC and SRS is same as offer/answer exchange between = any two SIP UA. The exception is required for metadata request scenario as = it creates cross wire scenario unnecessarily by SRS wherein SRS MUST NOT cr= eate offer till SRC sends offer. Thanks Partha >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Thursday, February 16, 2012 11:06 PM >To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon Portman; >siprec@ietf.org >Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >Hi Partha, > >While I do not have a specific use case in mind that requires this, I do >not see any benefit gained by explicitly not allowing it. I'd like to >avoid placing unnecessary restrictions. If an SRS tries to add a media >line and an SRC does not want to accept it, if can simply answer with >port=3D0. That sounds fine to me. > >Cheers, >Charles > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: Thursday, February 16, 2012 9:27 AM >> To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon Portman; >> siprec@ietf.org >> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >> >> Hi Charles, >> >> As a follow up query, whether SRS SHOULD be allowed to add the stream >> in its offer? As per your earlier statement, SRS should be allowed. >> Please correct me in case I misunderstand your statement. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> >Sent: Thursday, February 16, 2012 10:12 PM >> >To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon >Portman; >> >siprec@ietf.org >> >Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >> > >> >I do not see any need for such as a restriction. >> > >> >Cheers, >> >Charles >> > >> >> -----Original Message----- >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> Behalf Of Ravindran, Parthasarathi >> >> Sent: Wednesday, February 15, 2012 10:03 PM >> >> To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org >> >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >> >> >> >> Henry & All, >> >> >> >> This question is coming around multiple times in the different form >> >> whether SRS is allowed to send offer or not. In case SRS is allowed >> to >> >> initial the offer, it is possible for SRS to add the stream. IIUC, >> it >> >> was decided not to send offer during metadata request. Whether it >is >> >> possible to say that SRS MUST NOT initiate offer towards SRC? >> >> >> >> Thanks >> >> Partha >> >> >> >> >-----Original Message----- >> >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> Behalf >> >> >Of Henry Lum >> >> >Sent: Thursday, February 16, 2012 10:21 AM >> >> >To: Hutton, Andrew; Leon Portman; siprec@ietf.org >> >> >Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >> >> > >> >> >You're right, the SRS should be allowed to remove media streams >> from >> >> the >> >> >session for streams that the SRS does not want to record. Somehow >I >> >> had >> >> >the impression that the SRS need to BYE the session to do so, >> >however, >> >> >an SRS should not be able to add a media stream on its own. >> >> > >> >> >Henry >> >> > >> >> >> -----Original Message----- >> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >On >> >> >> Behalf Of Hutton, Andrew >> >> >> Sent: February-14-12 12:57 PM >> >> >> To: Leon Portman; siprec@ietf.org >> >> >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >> >> >> >> >> >> I assume the SRS can remove m-lines and we should say something >> >> about >> >> >> this in the protocol draft. >> >> >> >> >> >> Regards >> >> >> Andy >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: Leon Portman [mailto:Leon.Portman@nice.com] >> >> >> > Sent: 14 February 2012 16:23 >> >> >> > To: Hutton, Andrew; siprec@ietf.org >> >> >> > Subject: RE: Protocol draft - SRS SDP Procedures. >> >> >> > >> >> >> > But today, if SRS does not want to record something, or pause >> >> >> recording >> >> >> > , it will use media-inactive attribute. Do we want for SRS to >> be >> >> >able >> >> >> > remove m-lines? >> >> >> > >> >> >> > Leon >> >> >> > >> >> >> > -----Original Message----- >> >> >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >> >> >> > Behalf Of Hutton, Andrew >> >> >> > Sent: Friday, February 10, 2012 7:57 PM >> >> >> > To: siprec@ietf.org >> >> >> > Subject: [siprec] Protocol draft - SRS SDP Procedures. >> >> >> > >> >> >> > Hi All, >> >> >> > >> >> >> > Currently section 6.1.1 of http://tools.ietf.org/html/draft- >> ietf- >> >> >> > siprec-protocol-02#section-6.1.1 describes how the SRC can add >> >and >> >> >> > remove media lines during a recording session. >> >> >> > >> >> >> > However there is no corresponding section describing how the >> SRS >> >> can >> >> >> do >> >> >> > the same. I assume that that the SRS could for example >> terminate >> >a >> >> >> > stream during recording for example it might decide it no >> longer >> >> >> wants >> >> >> > to record the video stream but will continue recording the >> audio. >> >> >> > >> >> >> > We need to describe the use of offerless INVITE's by the SRS >> for >> >> >> > example when the SRS initiates the recording. >> >> >> > >> >> >> > Regards >> >> >> > Andy >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > siprec mailing list >> >> >> > siprec@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/siprec >> >> >> _______________________________________________ >> >> >> siprec mailing list >> >> >> siprec@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/siprec >> >> >_______________________________________________ >> >> >siprec mailing 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 Feb 16 09:57:06 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF3921F887E for ; Thu, 16 Feb 2012 09:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.716 X-Spam-Level: X-Spam-Status: No, score=-8.716 tagged_above=-999 required=5 tests=[AWL=1.883, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pJgWgMEGMvJ for ; Thu, 16 Feb 2012 09:57:01 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9602821F883A for ; Thu, 16 Feb 2012 09:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=7089; q=dns/txt; s=iport; t=1329415021; x=1330624621; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=d2qgF0HiJY2rUvVQR2mT0Oj/SdJn0ktaTaVb5/5Q9XU=; b=LKDfC/9YS+LeemypGymfNQ5AlkhBd+Lw1B1Zl5A297+RjdrzAoimJja5 ZQ1WjrcXIuItsMbC95DUgD7SHAuYsFhg/yaSuQ+2kt0J/I5AEhfRVUUZe idoZFhj1kg+UwL9wS9vbbISGksnvUfaBJ5DVovfXybTaFyxuHE0cU8doz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABZDPU+rRDoI/2dsb2JhbABEsGWBB4FyAQEBBAEBAQ8BHQoyAhcEAgEIEQQBAQsGFwEGASYfCQgCBAESCBqHZppLAZ5Li2kTAQMWCz6DPwECWQkEBQ2CR2MEiE6fcg X-IronPort-AV: E=Sophos;i="4.73,430,1325462400"; d="scan'208";a="30795631" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 16 Feb 2012 17:57:01 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1GHv1hh006461; Thu, 16 Feb 2012 17:57:01 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 09:57:01 -0800 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, 16 Feb 2012 09:57:00 -0800 Message-ID: In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E04041C@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: AczoHWrGl/zapk6RRI2dWngh8M3W5QDF2XvgAAM8pnAASRqZEAACclhQABZyLhAAAYdx0AAATEmAAAAmdTAAAK1iwA== References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04041C@inba-mail01.sonusnet.com> From: "Charles Eckel (eckelcu)" To: "Ravindran, Parthasarathi" , "Henry Lum" , "Hutton, Andrew" , "Leon Portman" , X-OriginalArrivalTime: 16 Feb 2012 17:57:01.0082 (UTC) FILETIME=[622697A0:01CCECD4] Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 17:57:06 -0000 Works for me. > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: Thursday, February 16, 2012 9:44 AM > To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon Portman; > siprec@ietf.org > Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >=20 > Hi Charles, >=20 > I agree with you as I don't see the strong reason to restrict. Let > offer/answer exchange between SRC and SRS is same as offer/answer > exchange between any two SIP UA. The exception is required for metadata > request scenario as it creates cross wire scenario unnecessarily by SRS > wherein SRS MUST NOT create offer till SRC sends offer. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >Sent: Thursday, February 16, 2012 11:06 PM > >To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon Portman; > >siprec@ietf.org > >Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > > > >Hi Partha, > > > >While I do not have a specific use case in mind that requires this, I > do > >not see any benefit gained by explicitly not allowing it. I'd like to > >avoid placing unnecessary restrictions. If an SRS tries to add a media > >line and an SRC does not want to accept it, if can simply answer with > >port=3D0. That sounds fine to me. > > > >Cheers, > >Charles > > > >> -----Original Message----- > >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >> Sent: Thursday, February 16, 2012 9:27 AM > >> To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon > Portman; > >> siprec@ietf.org > >> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >> > >> Hi Charles, > >> > >> As a follow up query, whether SRS SHOULD be allowed to add the > stream > >> in its offer? As per your earlier statement, SRS should be allowed. > >> Please correct me in case I misunderstand your statement. > >> > >> Thanks > >> Partha > >> > >> >-----Original Message----- > >> >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >> >Sent: Thursday, February 16, 2012 10:12 PM > >> >To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon > >Portman; > >> >siprec@ietf.org > >> >Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >> > > >> >I do not see any need for such as a restriction. > >> > > >> >Cheers, > >> >Charles > >> > > >> >> -----Original Message----- > >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> >> Behalf Of Ravindran, Parthasarathi > >> >> Sent: Wednesday, February 15, 2012 10:03 PM > >> >> To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org > >> >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >> >> > >> >> Henry & All, > >> >> > >> >> This question is coming around multiple times in the different > form > >> >> whether SRS is allowed to send offer or not. In case SRS is > allowed > >> to > >> >> initial the offer, it is possible for SRS to add the stream. > IIUC, > >> it > >> >> was decided not to send offer during metadata request. Whether it > >is > >> >> possible to say that SRS MUST NOT initiate offer towards SRC? > >> >> > >> >> Thanks > >> >> Partha > >> >> > >> >> >-----Original Message----- > >> >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >> >> Behalf > >> >> >Of Henry Lum > >> >> >Sent: Thursday, February 16, 2012 10:21 AM > >> >> >To: Hutton, Andrew; Leon Portman; siprec@ietf.org > >> >> >Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >> >> > > >> >> >You're right, the SRS should be allowed to remove media streams > >> from > >> >> the > >> >> >session for streams that the SRS does not want to record. > Somehow > >I > >> >> had > >> >> >the impression that the SRS need to BYE the session to do so, > >> >however, > >> >> >an SRS should not be able to add a media stream on its own. > >> >> > > >> >> >Henry > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > >On > >> >> >> Behalf Of Hutton, Andrew > >> >> >> Sent: February-14-12 12:57 PM > >> >> >> To: Leon Portman; siprec@ietf.org > >> >> >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >> >> >> > >> >> >> I assume the SRS can remove m-lines and we should say > something > >> >> about > >> >> >> this in the protocol draft. > >> >> >> > >> >> >> Regards > >> >> >> Andy > >> >> >> > >> >> >> > -----Original Message----- > >> >> >> > From: Leon Portman [mailto:Leon.Portman@nice.com] > >> >> >> > Sent: 14 February 2012 16:23 > >> >> >> > To: Hutton, Andrew; siprec@ietf.org > >> >> >> > Subject: RE: Protocol draft - SRS SDP Procedures. > >> >> >> > > >> >> >> > But today, if SRS does not want to record something, or > pause > >> >> >> recording > >> >> >> > , it will use media-inactive attribute. Do we want for SRS > to > >> be > >> >> >able > >> >> >> > remove m-lines? > >> >> >> > > >> >> >> > Leon > >> >> >> > > >> >> >> > -----Original Message----- > >> >> >> > From: siprec-bounces@ietf.org [mailto:siprec- > bounces@ietf.org] > >> On > >> >> >> > Behalf Of Hutton, Andrew > >> >> >> > Sent: Friday, February 10, 2012 7:57 PM > >> >> >> > To: siprec@ietf.org > >> >> >> > Subject: [siprec] Protocol draft - SRS SDP Procedures. > >> >> >> > > >> >> >> > Hi All, > >> >> >> > > >> >> >> > Currently section 6.1.1 of http://tools.ietf.org/html/draft- > >> ietf- > >> >> >> > siprec-protocol-02#section-6.1.1 describes how the SRC can > add > >> >and > >> >> >> > remove media lines during a recording session. > >> >> >> > > >> >> >> > However there is no corresponding section describing how the > >> SRS > >> >> can > >> >> >> do > >> >> >> > the same. I assume that that the SRS could for example > >> terminate > >> >a > >> >> >> > stream during recording for example it might decide it no > >> longer > >> >> >> wants > >> >> >> > to record the video stream but will continue recording the > >> audio. > >> >> >> > > >> >> >> > We need to describe the use of offerless INVITE's by the SRS > >> for > >> >> >> > example when the SRS initiates the recording. > >> >> >> > > >> >> >> > Regards > >> >> >> > Andy > >> >> >> > > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > siprec mailing list > >> >> >> > siprec@ietf.org > >> >> >> > https://www.ietf.org/mailman/listinfo/siprec > >> >> >> _______________________________________________ > >> >> >> siprec mailing list > >> >> >> siprec@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/siprec > >> >> >_______________________________________________ > >> >> >siprec mailing 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 Feb 16 10:01:13 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E806921F8889 for ; Thu, 16 Feb 2012 10:01:12 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmBIH5aBjy7S for ; Thu, 16 Feb 2012 10:01:00 -0800 (PST) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by ietfa.amsl.com (Postfix) with ESMTP id 62EAA21F883A for ; Thu, 16 Feb 2012 10:00:59 -0800 (PST) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta13.emeryville.ca.mail.comcast.net with comcast id adpf1i0031u4NiLADi0tZv; Thu, 16 Feb 2012 18:00:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([140.242.210.2]) by omta21.emeryville.ca.mail.comcast.net with comcast id ai0j1i00t03fLrQ8hi0mjv; Thu, 16 Feb 2012 18:00:51 +0000 Message-ID: <4F3D444B.1070905@alum.mit.edu> Date: Thu, 16 Feb 2012 13:00:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04041C@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E04041C@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 18:01:14 -0000 The problem with this is that the SRC is the one that knows what media it needs to send, and what media characteristics it needs to do so. If the SRS sends the offer, then the SRC has to decide if and how it can map what it needs to send onto that offer. It may or may not be able to do that. It certainly complicates the life of the SRC if it must be prepared to do that. It is somewhat easier for it to offer what it needs, and then cope with any refusals it gets. We can still allow this, but the outcomes may be somewhat unpredictable. Thanks, Paul On 2/16/12 12:44 PM, Ravindran, Parthasarathi wrote: > Hi Charles, > > I agree with you as I don't see the strong reason to restrict. Let offer/answer exchange between SRC and SRS is same as offer/answer exchange between any two SIP UA. The exception is required for metadata request scenario as it creates cross wire scenario unnecessarily by SRS wherein SRS MUST NOT create offer till SRC sends offer. > > Thanks > Partha > >> -----Original Message----- >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> Sent: Thursday, February 16, 2012 11:06 PM >> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon Portman; >> siprec@ietf.org >> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >> >> Hi Partha, >> >> While I do not have a specific use case in mind that requires this, I do >> not see any benefit gained by explicitly not allowing it. I'd like to >> avoid placing unnecessary restrictions. If an SRS tries to add a media >> line and an SRC does not want to accept it, if can simply answer with >> port=0. That sounds fine to me. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>> Sent: Thursday, February 16, 2012 9:27 AM >>> To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon Portman; >>> siprec@ietf.org >>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >>> >>> Hi Charles, >>> >>> As a follow up query, whether SRS SHOULD be allowed to add the stream >>> in its offer? As per your earlier statement, SRS should be allowed. >>> Please correct me in case I misunderstand your statement. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>> Sent: Thursday, February 16, 2012 10:12 PM >>>> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon >> Portman; >>>> siprec@ietf.org >>>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >>>> >>>> I do not see any need for such as a restriction. >>>> >>>> Cheers, >>>> Charles >>>> >>>>> -----Original Message----- >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf Of Ravindran, Parthasarathi >>>>> Sent: Wednesday, February 15, 2012 10:03 PM >>>>> To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org >>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >>>>> >>>>> Henry& All, >>>>> >>>>> This question is coming around multiple times in the different form >>>>> whether SRS is allowed to send offer or not. In case SRS is allowed >>> to >>>>> initial the offer, it is possible for SRS to add the stream. IIUC, >>> it >>>>> was decided not to send offer during metadata request. Whether it >> is >>>>> possible to say that SRS MUST NOT initiate offer towards SRC? >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>>> -----Original Message----- >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>> Behalf >>>>>> Of Henry Lum >>>>>> Sent: Thursday, February 16, 2012 10:21 AM >>>>>> To: Hutton, Andrew; Leon Portman; siprec@ietf.org >>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >>>>>> >>>>>> You're right, the SRS should be allowed to remove media streams >>> from >>>>> the >>>>>> session for streams that the SRS does not want to record. Somehow >> I >>>>> had >>>>>> the impression that the SRS need to BYE the session to do so, >>>> however, >>>>>> an SRS should not be able to add a media stream on its own. >>>>>> >>>>>> Henry >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >>>>>>> Behalf Of Hutton, Andrew >>>>>>> Sent: February-14-12 12:57 PM >>>>>>> To: Leon Portman; siprec@ietf.org >>>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >>>>>>> >>>>>>> I assume the SRS can remove m-lines and we should say something >>>>> about >>>>>>> this in the protocol draft. >>>>>>> >>>>>>> Regards >>>>>>> Andy >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>> Sent: 14 February 2012 16:23 >>>>>>>> To: Hutton, Andrew; siprec@ietf.org >>>>>>>> Subject: RE: Protocol draft - SRS SDP Procedures. >>>>>>>> >>>>>>>> But today, if SRS does not want to record something, or pause >>>>>>> recording >>>>>>>> , it will use media-inactive attribute. Do we want for SRS to >>> be >>>>>> able >>>>>>>> remove m-lines? >>>>>>>> >>>>>>>> Leon >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >>> On >>>>>>>> Behalf Of Hutton, Andrew >>>>>>>> Sent: Friday, February 10, 2012 7:57 PM >>>>>>>> To: siprec@ietf.org >>>>>>>> Subject: [siprec] Protocol draft - SRS SDP Procedures. >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Currently section 6.1.1 of http://tools.ietf.org/html/draft- >>> ietf- >>>>>>>> siprec-protocol-02#section-6.1.1 describes how the SRC can add >>>> and >>>>>>>> remove media lines during a recording session. >>>>>>>> >>>>>>>> However there is no corresponding section describing how the >>> SRS >>>>> can >>>>>>> do >>>>>>>> the same. I assume that that the SRS could for example >>> terminate >>>> a >>>>>>>> stream during recording for example it might decide it no >>> longer >>>>>>> wants >>>>>>>> to record the video stream but will continue recording the >>> audio. >>>>>>>> >>>>>>>> We need to describe the use of offerless INVITE's by the SRS >>> for >>>>>>>> example when the SRS initiates the recording. >>>>>>>> >>>>>>>> Regards >>>>>>>> Andy >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Thu Feb 16 12:31:05 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365DD11E8072 for ; Thu, 16 Feb 2012 12:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O37gF46ZvpaN for ; Thu, 16 Feb 2012 12:31:01 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 896B921F86E0 for ; Thu, 16 Feb 2012 12:31:00 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 45AD723F040A; Thu, 16 Feb 2012 21:30:59 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 16 Feb 2012 21:30:59 +0100 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Date: Thu, 16 Feb 2012 21:30:55 +0100 Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: Aczs1Pr6kJ9+99PRSWW7qWgt+jZaHgAE/Cjg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202EDA67A@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04041C@inba-mail01.sonusnet.com> <4F3D444B.1070905@alum.mit.edu> In-Reply-To: <4F3D444B.1070905@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] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 20:31:05 -0000 Is there a difference between the initial offer and subsequent offers to up= date SDP here? It seems difficult for an SRC to be able to handle an initial offer from th= e SRS or any offer which adds new media lines especially if we mandate meta= data and require the SRC to label each media line as a handle to the associ= ated metadata. However there is probably a need to allow the SRS to be able to terminate m= edia lines which would require the SRS to create an offer. Therefore could we say that the SRS can only create offer's to terminate me= dia lines (i.e. port=3D0). Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 16 February 2012 19:01 > To: siprec@ietf.org > Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >=20 > The problem with this is that the SRC is the one that knows what media > it needs to send, and what media characteristics it needs to do so. If > the SRS sends the offer, then the SRC has to decide if and how it can > map what it needs to send onto that offer. It may or may not be able to > do that. It certainly complicates the life of the SRC if it must be > prepared to do that. It is somewhat easier for it to offer what it > needs, and then cope with any refusals it gets. >=20 > We can still allow this, but the outcomes may be somewhat > unpredictable. >=20 > Thanks, > Paul >=20 > On 2/16/12 12:44 PM, Ravindran, Parthasarathi wrote: > > Hi Charles, > > > > I agree with you as I don't see the strong reason to restrict. Let > offer/answer exchange between SRC and SRS is same as offer/answer > exchange between any two SIP UA. The exception is required for metadata > request scenario as it creates cross wire scenario unnecessarily by SRS > wherein SRS MUST NOT create offer till SRC sends offer. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >> Sent: Thursday, February 16, 2012 11:06 PM > >> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon > Portman; > >> siprec@ietf.org > >> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >> > >> Hi Partha, > >> > >> While I do not have a specific use case in mind that requires this, > I do > >> not see any benefit gained by explicitly not allowing it. I'd like > to > >> avoid placing unnecessary restrictions. If an SRS tries to add a > media > >> line and an SRC does not want to accept it, if can simply answer > with > >> port=3D0. That sounds fine to me. > >> > >> Cheers, > >> Charles > >> > >>> -----Original Message----- > >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >>> Sent: Thursday, February 16, 2012 9:27 AM > >>> To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon > Portman; > >>> siprec@ietf.org > >>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >>> > >>> Hi Charles, > >>> > >>> As a follow up query, whether SRS SHOULD be allowed to add the > stream > >>> in its offer? As per your earlier statement, SRS should be allowed. > >>> Please correct me in case I misunderstand your statement. > >>> > >>> Thanks > >>> Partha > >>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>> Sent: Thursday, February 16, 2012 10:12 PM > >>>> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon > >> Portman; > >>>> siprec@ietf.org > >>>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >>>> > >>>> I do not see any need for such as a restriction. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Ravindran, Parthasarathi > >>>>> Sent: Wednesday, February 15, 2012 10:03 PM > >>>>> To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >>>>> > >>>>> Henry& All, > >>>>> > >>>>> This question is coming around multiple times in the different > form > >>>>> whether SRS is allowed to send offer or not. In case SRS is > allowed > >>> to > >>>>> initial the offer, it is possible for SRS to add the stream. > IIUC, > >>> it > >>>>> was decided not to send offer during metadata request. Whether it > >> is > >>>>> possible to say that SRS MUST NOT initiate offer towards SRC? > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >>>>> Behalf > >>>>>> Of Henry Lum > >>>>>> Sent: Thursday, February 16, 2012 10:21 AM > >>>>>> To: Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>> > >>>>>> You're right, the SRS should be allowed to remove media streams > >>> from > >>>>> the > >>>>>> session for streams that the SRS does not want to record. > Somehow > >> I > >>>>> had > >>>>>> the impression that the SRS need to BYE the session to do so, > >>>> however, > >>>>>> an SRS should not be able to add a media stream on its own. > >>>>>> > >>>>>> Henry > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > >> On > >>>>>>> Behalf Of Hutton, Andrew > >>>>>>> Sent: February-14-12 12:57 PM > >>>>>>> To: Leon Portman; siprec@ietf.org > >>>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>>> > >>>>>>> I assume the SRS can remove m-lines and we should say something > >>>>> about > >>>>>>> this in the protocol draft. > >>>>>>> > >>>>>>> Regards > >>>>>>> Andy > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>>>>>>> Sent: 14 February 2012 16:23 > >>>>>>>> To: Hutton, Andrew; siprec@ietf.org > >>>>>>>> Subject: RE: Protocol draft - SRS SDP Procedures. > >>>>>>>> > >>>>>>>> But today, if SRS does not want to record something, or pause > >>>>>>> recording > >>>>>>>> , it will use media-inactive attribute. Do we want for SRS to > >>> be > >>>>>> able > >>>>>>>> remove m-lines? > >>>>>>>> > >>>>>>>> Leon > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > >>> On > >>>>>>>> Behalf Of Hutton, Andrew > >>>>>>>> Sent: Friday, February 10, 2012 7:57 PM > >>>>>>>> To: siprec@ietf.org > >>>>>>>> Subject: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>>>> > >>>>>>>> Hi All, > >>>>>>>> > >>>>>>>> Currently section 6.1.1 of http://tools.ietf.org/html/draft- > >>> ietf- > >>>>>>>> siprec-protocol-02#section-6.1.1 describes how the SRC can add > >>>> and > >>>>>>>> remove media lines during a recording session. > >>>>>>>> > >>>>>>>> However there is no corresponding section describing how the > >>> SRS > >>>>> can > >>>>>>> do > >>>>>>>> the same. I assume that that the SRS could for example > >>> terminate > >>>> a > >>>>>>>> stream during recording for example it might decide it no > >>> longer > >>>>>>> wants > >>>>>>>> to record the video stream but will continue recording the > >>> audio. > >>>>>>>> > >>>>>>>> We need to describe the use of offerless INVITE's by the SRS > >>> for > >>>>>>>> example when the SRS initiates the recording. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> Andy > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> siprec mailing list > >>>>>>>> siprec@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>> _______________________________________________ > >>>>>>> siprec mailing list > >>>>>>> siprec@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>> _______________________________________________ > >>>>>> siprec mailing list > >>>>>> siprec@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>> _______________________________________________ > >>>>> siprec mailing list > >>>>> siprec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Feb 16 12:41:35 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EAB11E80AE for ; Thu, 16 Feb 2012 12:41:35 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1ijijsONhsE for ; Thu, 16 Feb 2012 12:41:31 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6693511E80AB for ; Thu, 16 Feb 2012 12:41:31 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id akMS1i0050Fqzac56khXqm; Thu, 16 Feb 2012 20:41:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([140.242.210.2]) by omta08.westchester.pa.mail.comcast.net with comcast id akhL1i00M03fLrQ3UkhNxS; Thu, 16 Feb 2012 20:41:29 +0000 Message-ID: <4F3D69EF.6090506@alum.mit.edu> Date: Thu, 16 Feb 2012 15:41:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hutton, Andrew" References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04041C@inba-mail01.sonusnet.com> <4F3D444B.1070905@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31202EDA67A@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31202EDA67A@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 20:41:35 -0000 On 2/16/12 3:30 PM, Hutton, Andrew wrote: > > Is there a difference between the initial offer and subsequent offers to update SDP here? > > It seems difficult for an SRC to be able to handle an initial offer from the SRS or any offer which adds new media lines especially if we mandate metadata and require the SRC to label each media line as a handle to the associated metadata. > > However there is probably a need to allow the SRS to be able to terminate media lines which would require the SRS to create an offer. > > Therefore could we say that the SRS can only create offer's to terminate media lines (i.e. port=0). This can be handled more easily by having the SRS send an offerless invite. Then the SRC will have to send an offer, and the SRS can refuse (port=0) the m-lines it doesn't want. Thanks, Paul > Regards > Andy > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 16 February 2012 19:01 >> To: siprec@ietf.org >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >> >> The problem with this is that the SRC is the one that knows what media >> it needs to send, and what media characteristics it needs to do so. If >> the SRS sends the offer, then the SRC has to decide if and how it can >> map what it needs to send onto that offer. It may or may not be able to >> do that. It certainly complicates the life of the SRC if it must be >> prepared to do that. It is somewhat easier for it to offer what it >> needs, and then cope with any refusals it gets. >> >> We can still allow this, but the outcomes may be somewhat >> unpredictable. >> >> Thanks, >> Paul >> >> On 2/16/12 12:44 PM, Ravindran, Parthasarathi wrote: >>> Hi Charles, >>> >>> I agree with you as I don't see the strong reason to restrict. Let >> offer/answer exchange between SRC and SRS is same as offer/answer >> exchange between any two SIP UA. The exception is required for metadata >> request scenario as it creates cross wire scenario unnecessarily by SRS >> wherein SRS MUST NOT create offer till SRC sends offer. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>> Sent: Thursday, February 16, 2012 11:06 PM >>>> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon >> Portman; >>>> siprec@ietf.org >>>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >>>> >>>> Hi Partha, >>>> >>>> While I do not have a specific use case in mind that requires this, >> I do >>>> not see any benefit gained by explicitly not allowing it. I'd like >> to >>>> avoid placing unnecessary restrictions. If an SRS tries to add a >> media >>>> line and an SRC does not want to accept it, if can simply answer >> with >>>> port=0. That sounds fine to me. >>>> >>>> Cheers, >>>> Charles >>>> >>>>> -----Original Message----- >>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>>> Sent: Thursday, February 16, 2012 9:27 AM >>>>> To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon >> Portman; >>>>> siprec@ietf.org >>>>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >>>>> >>>>> Hi Charles, >>>>> >>>>> As a follow up query, whether SRS SHOULD be allowed to add the >> stream >>>>> in its offer? As per your earlier statement, SRS should be allowed. >>>>> Please correct me in case I misunderstand your statement. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>>> Sent: Thursday, February 16, 2012 10:12 PM >>>>>> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon >>>> Portman; >>>>>> siprec@ietf.org >>>>>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. >>>>>> >>>>>> I do not see any need for such as a restriction. >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>>>>>> Behalf Of Ravindran, Parthasarathi >>>>>>> Sent: Wednesday, February 15, 2012 10:03 PM >>>>>>> To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org >>>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >>>>>>> >>>>>>> Henry& All, >>>>>>> >>>>>>> This question is coming around multiple times in the different >> form >>>>>>> whether SRS is allowed to send offer or not. In case SRS is >> allowed >>>>> to >>>>>>> initial the offer, it is possible for SRS to add the stream. >> IIUC, >>>>> it >>>>>>> was decided not to send offer during metadata request. Whether it >>>> is >>>>>>> possible to say that SRS MUST NOT initiate offer towards SRC? >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >>>>>>> Behalf >>>>>>>> Of Henry Lum >>>>>>>> Sent: Thursday, February 16, 2012 10:21 AM >>>>>>>> To: Hutton, Andrew; Leon Portman; siprec@ietf.org >>>>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >>>>>>>> >>>>>>>> You're right, the SRS should be allowed to remove media streams >>>>> from >>>>>>> the >>>>>>>> session for streams that the SRS does not want to record. >> Somehow >>>> I >>>>>>> had >>>>>>>> the impression that the SRS need to BYE the session to do so, >>>>>> however, >>>>>>>> an SRS should not be able to add a media stream on its own. >>>>>>>> >>>>>>>> Henry >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >>>> On >>>>>>>>> Behalf Of Hutton, Andrew >>>>>>>>> Sent: February-14-12 12:57 PM >>>>>>>>> To: Leon Portman; siprec@ietf.org >>>>>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >>>>>>>>> >>>>>>>>> I assume the SRS can remove m-lines and we should say something >>>>>>> about >>>>>>>>> this in the protocol draft. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Andy >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] >>>>>>>>>> Sent: 14 February 2012 16:23 >>>>>>>>>> To: Hutton, Andrew; siprec@ietf.org >>>>>>>>>> Subject: RE: Protocol draft - SRS SDP Procedures. >>>>>>>>>> >>>>>>>>>> But today, if SRS does not want to record something, or pause >>>>>>>>> recording >>>>>>>>>> , it will use media-inactive attribute. Do we want for SRS to >>>>> be >>>>>>>> able >>>>>>>>>> remove m-lines? >>>>>>>>>> >>>>>>>>>> Leon >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >>>>> On >>>>>>>>>> Behalf Of Hutton, Andrew >>>>>>>>>> Sent: Friday, February 10, 2012 7:57 PM >>>>>>>>>> To: siprec@ietf.org >>>>>>>>>> Subject: [siprec] Protocol draft - SRS SDP Procedures. >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Currently section 6.1.1 of http://tools.ietf.org/html/draft- >>>>> ietf- >>>>>>>>>> siprec-protocol-02#section-6.1.1 describes how the SRC can add >>>>>> and >>>>>>>>>> remove media lines during a recording session. >>>>>>>>>> >>>>>>>>>> However there is no corresponding section describing how the >>>>> SRS >>>>>>> can >>>>>>>>> do >>>>>>>>>> the same. I assume that that the SRS could for example >>>>> terminate >>>>>> a >>>>>>>>>> stream during recording for example it might decide it no >>>>> longer >>>>>>>>> wants >>>>>>>>>> to record the video stream but will continue recording the >>>>> audio. >>>>>>>>>> >>>>>>>>>> We need to describe the use of offerless INVITE's by the SRS >>>>> for >>>>>>>>>> example when the SRS initiates the recording. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Andy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> siprec mailing list >>>>>>>>>> siprec@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>>> _______________________________________________ >>>>>>>>> siprec mailing list >>>>>>>>> siprec@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>>> _______________________________________________ >>>>>>>> siprec mailing list >>>>>>>> siprec@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Thu Feb 16 12:48:09 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEE911E808E for ; Thu, 16 Feb 2012 12:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ5XfY-ajdrW for ; Thu, 16 Feb 2012 12:48:00 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 484D311E80B5 for ; Thu, 16 Feb 2012 12:48:00 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 7F8081EB8481; Thu, 16 Feb 2012 21:47:59 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 16 Feb 2012 21:47:59 +0100 From: "Hutton, Andrew" To: Paul Kyzivat Date: Thu, 16 Feb 2012 21:47:56 +0100 Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: Aczs612VM9r1UeUHRViqigAq1ZomGwAAIy6Q Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31202EDA68E@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04041C@inba-mail01.sonusnet.com> <4F3D444B.1070905@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E31202EDA67A@MCHP058A.global-ad.net> <4F3D69EF.6090506@alum.mit.edu> In-Reply-To: <4F3D69EF.6090506@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] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2012 20:48:09 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 16 February 2012 21:41 > To: Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >=20 > On 2/16/12 3:30 PM, Hutton, Andrew wrote: > > > > Is there a difference between the initial offer and subsequent offers > to update SDP here? > > > > It seems difficult for an SRC to be able to handle an initial offer > from the SRS or any offer which adds new media lines especially if we > mandate metadata and require the SRC to label each media line as a > handle to the associated metadata. > > > > However there is probably a need to allow the SRS to be able to > terminate media lines which would require the SRS to create an offer. > > > > Therefore could we say that the SRS can only create offer's to > terminate media lines (i.e. port=3D0). >=20 > This can be handled more easily by having the SRS send an offerless > invite. Then the SRC will have to send an offer, and the SRS can refuse > (port=3D0) the m-lines it doesn't want. [AndyH] Whether that is easier to implement or not I think we could debate = but I could also live with it as at least we would have simple rule that th= e SRC always creates the offer. >=20 > Thanks, > Paul >=20 > > Regards > > Andy > > > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: 16 February 2012 19:01 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >> > >> The problem with this is that the SRC is the one that knows what > media > >> it needs to send, and what media characteristics it needs to do so. > If > >> the SRS sends the offer, then the SRC has to decide if and how it > can > >> map what it needs to send onto that offer. It may or may not be able > to > >> do that. It certainly complicates the life of the SRC if it must be > >> prepared to do that. It is somewhat easier for it to offer what it > >> needs, and then cope with any refusals it gets. > >> > >> We can still allow this, but the outcomes may be somewhat > >> unpredictable. > >> > >> Thanks, > >> Paul > >> > >> On 2/16/12 12:44 PM, Ravindran, Parthasarathi wrote: > >>> Hi Charles, > >>> > >>> I agree with you as I don't see the strong reason to restrict. Let > >> offer/answer exchange between SRC and SRS is same as offer/answer > >> exchange between any two SIP UA. The exception is required for > metadata > >> request scenario as it creates cross wire scenario unnecessarily by > SRS > >> wherein SRS MUST NOT create offer till SRC sends offer. > >>> > >>> Thanks > >>> Partha > >>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>> Sent: Thursday, February 16, 2012 11:06 PM > >>>> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon > >> Portman; > >>>> siprec@ietf.org > >>>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >>>> > >>>> Hi Partha, > >>>> > >>>> While I do not have a specific use case in mind that requires > this, > >> I do > >>>> not see any benefit gained by explicitly not allowing it. I'd like > >> to > >>>> avoid placing unnecessary restrictions. If an SRS tries to add a > >> media > >>>> line and an SRC does not want to accept it, if can simply answer > >> with > >>>> port=3D0. That sounds fine to me. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >>>>> Sent: Thursday, February 16, 2012 9:27 AM > >>>>> To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon > >> Portman; > >>>>> siprec@ietf.org > >>>>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >>>>> > >>>>> Hi Charles, > >>>>> > >>>>> As a follow up query, whether SRS SHOULD be allowed to add the > >> stream > >>>>> in its offer? As per your earlier statement, SRS should be > allowed. > >>>>> Please correct me in case I misunderstand your statement. > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>>>> Sent: Thursday, February 16, 2012 10:12 PM > >>>>>> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon > >>>> Portman; > >>>>>> siprec@ietf.org > >>>>>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>> > >>>>>> I do not see any need for such as a restriction. > >>>>>> > >>>>>> Cheers, > >>>>>> Charles > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >>>>>>> Behalf Of Ravindran, Parthasarathi > >>>>>>> Sent: Wednesday, February 15, 2012 10:03 PM > >>>>>>> To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>>> > >>>>>>> Henry& All, > >>>>>>> > >>>>>>> This question is coming around multiple times in the different > >> form > >>>>>>> whether SRS is allowed to send offer or not. In case SRS is > >> allowed > >>>>> to > >>>>>>> initial the offer, it is possible for SRS to add the stream. > >> IIUC, > >>>>> it > >>>>>>> was decided not to send offer during metadata request. Whether > it > >>>> is > >>>>>>> possible to say that SRS MUST NOT initiate offer towards SRC? > >>>>>>> > >>>>>>> Thanks > >>>>>>> Partha > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > >> On > >>>>>>> Behalf > >>>>>>>> Of Henry Lum > >>>>>>>> Sent: Thursday, February 16, 2012 10:21 AM > >>>>>>>> To: Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>>>> > >>>>>>>> You're right, the SRS should be allowed to remove media > streams > >>>>> from > >>>>>>> the > >>>>>>>> session for streams that the SRS does not want to record. > >> Somehow > >>>> I > >>>>>>> had > >>>>>>>> the impression that the SRS need to BYE the session to do so, > >>>>>> however, > >>>>>>>> an SRS should not be able to add a media stream on its own. > >>>>>>>> > >>>>>>>> Henry > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec- > bounces@ietf.org] > >>>> On > >>>>>>>>> Behalf Of Hutton, Andrew > >>>>>>>>> Sent: February-14-12 12:57 PM > >>>>>>>>> To: Leon Portman; siprec@ietf.org > >>>>>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>>>>> > >>>>>>>>> I assume the SRS can remove m-lines and we should say > something > >>>>>>> about > >>>>>>>>> this in the protocol draft. > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> Andy > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>>>>>>>>> Sent: 14 February 2012 16:23 > >>>>>>>>>> To: Hutton, Andrew; siprec@ietf.org > >>>>>>>>>> Subject: RE: Protocol draft - SRS SDP Procedures. > >>>>>>>>>> > >>>>>>>>>> But today, if SRS does not want to record something, or > pause > >>>>>>>>> recording > >>>>>>>>>> , it will use media-inactive attribute. Do we want for SRS > to > >>>>> be > >>>>>>>> able > >>>>>>>>>> remove m-lines? > >>>>>>>>>> > >>>>>>>>>> Leon > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec- > bounces@ietf.org] > >>>>> On > >>>>>>>>>> Behalf Of Hutton, Andrew > >>>>>>>>>> Sent: Friday, February 10, 2012 7:57 PM > >>>>>>>>>> To: siprec@ietf.org > >>>>>>>>>> Subject: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>>>>>> > >>>>>>>>>> Hi All, > >>>>>>>>>> > >>>>>>>>>> Currently section 6.1.1 of http://tools.ietf.org/html/draft- > >>>>> ietf- > >>>>>>>>>> siprec-protocol-02#section-6.1.1 describes how the SRC can > add > >>>>>> and > >>>>>>>>>> remove media lines during a recording session. > >>>>>>>>>> > >>>>>>>>>> However there is no corresponding section describing how the > >>>>> SRS > >>>>>>> can > >>>>>>>>> do > >>>>>>>>>> the same. I assume that that the SRS could for example > >>>>> terminate > >>>>>> a > >>>>>>>>>> stream during recording for example it might decide it no > >>>>> longer > >>>>>>>>> wants > >>>>>>>>>> to record the video stream but will continue recording the > >>>>> audio. > >>>>>>>>>> > >>>>>>>>>> We need to describe the use of offerless INVITE's by the SRS > >>>>> for > >>>>>>>>>> example when the SRS initiates the recording. > >>>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> Andy > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> siprec mailing list > >>>>>>>>>> siprec@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>>> _______________________________________________ > >>>>>>>>> siprec mailing list > >>>>>>>>> siprec@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>>> _______________________________________________ > >>>>>>>> siprec mailing list > >>>>>>>> siprec@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>> _______________________________________________ > >>>>>>> siprec mailing list > >>>>>>> siprec@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>> _______________________________________________ > >>> siprec mailing 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 Feb 17 01:02:37 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FF721F8901 for ; Fri, 17 Feb 2012 01:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.739 X-Spam-Level: X-Spam-Status: No, score=-7.739 tagged_above=-999 required=5 tests=[AWL=2.860, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+yCGIhaTUQI for ; Fri, 17 Feb 2012 01:02:36 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 609DF21F88FA for ; Fri, 17 Feb 2012 01:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=8671; q=dns/txt; s=iport; t=1329469355; x=1330678955; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=h1tFu9iNlFAsX+nIMdG0hw6ZobzjtY1Ei8I1Fe/Ilf0=; b=M8JnEmkMgODTvCudvU1JNRQNAUzjkOT9/gHg7u+S/FX1KkpYiu0dT4Lc uvQPrFvINl/cFOytcB/3whduKnH0Gq8x+z/vpp/T6X+ChawT6Hmy8/OS4 XyPcrhaYnzAtONDFDBowNM/s3IYfPPyngUAxT7sqq1c7yTAm3nL+mS9j5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAPwWPk9Io8UY/2dsb2JhbABEDrFygXIBAQEEAQEBDwEdCjICFwQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEAQoICBEJh2aaRgGeVotkDQIIGQMGBoQDJQsHBgIDA4JIYwSITJ8cPw X-IronPort-AV: E=Sophos;i="4.73,435,1325462400"; d="scan'208";a="5789313" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 17 Feb 2012 09:02:33 +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 q1H92X4o013627; Fri, 17 Feb 2012 09:02:33 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, 17 Feb 2012 14:32: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: Fri, 17 Feb 2012 14:32:31 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD098AF486@XMB-BGL-417.cisco.com> In-Reply-To: <4F3D444B.1070905@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Protocol draft - SRS SDP Procedures. Thread-Index: Aczs1Rf/kokQSZfXSY6aYRQsH07DHwAfLo0w References: <101C6067BEC68246B0C3F6843BCCC1E31202E31756@MCHP058A.global-ad.net><07465C1D981ABC41A344374066AE1A2C39DA3AEA78@TLVMBX01.nice.com><101C6067BEC68246B0C3F6843BCCC1E31202E324FA@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF7408251480@NAHALD.us.int.genesyslab.com><387F9047F55E8C42850AD6B3A7A03C6C0E040011@inba-mail01.sonusnet.com><387F9047F55E8C42850AD6B3A7A03C6C0E0403E8@inba-mail01.sonusnet.com><387F9047F55E8C42850AD6B3A7A03C6C0E04041C@inba-mail01.sonusnet.com> <4F3D444B.1070905@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 17 Feb 2012 09:02:32.0662 (UTC) FILETIME=[E24BC760:01CCED52] Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 09:02:37 -0000 I agree with Paul that having SRS send offer may lead to complex scenarios for SRC. For e.g Assume we have a SRS send a INVITE/UPDATE mid call with a new offer and SRC does not support the codec, it would reject the offer. In this case should SRC stops forking the media ? or should it continue to record ? or Should SRS send another offer with previously negotiated codec ( or atleast with a codec it knows SRC can record) ? On the other hand if SRC has the capability to transcode from one codec to another it may very well accept the new offer from SRS. We will have document/define the behavior for all these cases if we are to support SRS generated offer.=20 Regards, Ram > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, February 16, 2012 11:31 PM > To: siprec@ietf.org > Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. >=20 > The problem with this is that the SRC is the one that knows what media > it needs to send, and what media characteristics it needs to do so. If > the SRS sends the offer, then the SRC has to decide if and how it can > map what it needs to send onto that offer. It may or may not be able to > do that. It certainly complicates the life of the SRC if it must be > prepared to do that. It is somewhat easier for it to offer what it > needs, and then cope with any refusals it gets. >=20 > We can still allow this, but the outcomes may be somewhat > unpredictable. >=20 > Thanks, > Paul >=20 > On 2/16/12 12:44 PM, Ravindran, Parthasarathi wrote: > > Hi Charles, > > > > I agree with you as I don't see the strong reason to restrict. Let > offer/answer exchange between SRC and SRS is same as offer/answer > exchange between any two SIP UA. The exception is required for metadata > request scenario as it creates cross wire scenario unnecessarily by SRS > wherein SRS MUST NOT create offer till SRC sends offer. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >> Sent: Thursday, February 16, 2012 11:06 PM > >> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon > Portman; > >> siprec@ietf.org > >> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >> > >> Hi Partha, > >> > >> While I do not have a specific use case in mind that requires this, > I do > >> not see any benefit gained by explicitly not allowing it. I'd like > to > >> avoid placing unnecessary restrictions. If an SRS tries to add a > media > >> line and an SRC does not want to accept it, if can simply answer > with > >> port=3D0. That sounds fine to me. > >> > >> Cheers, > >> Charles > >> > >>> -----Original Message----- > >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >>> Sent: Thursday, February 16, 2012 9:27 AM > >>> To: Charles Eckel (eckelcu); Henry Lum; Hutton, Andrew; Leon > Portman; > >>> siprec@ietf.org > >>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >>> > >>> Hi Charles, > >>> > >>> As a follow up query, whether SRS SHOULD be allowed to add the > stream > >>> in its offer? As per your earlier statement, SRS should be allowed. > >>> Please correct me in case I misunderstand your statement. > >>> > >>> Thanks > >>> Partha > >>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>> Sent: Thursday, February 16, 2012 10:12 PM > >>>> To: Ravindran, Parthasarathi; Henry Lum; Hutton, Andrew; Leon > >> Portman; > >>>> siprec@ietf.org > >>>> Subject: RE: [siprec] Protocol draft - SRS SDP Procedures. > >>>> > >>>> I do not see any need for such as a restriction. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >>>>> Behalf Of Ravindran, Parthasarathi > >>>>> Sent: Wednesday, February 15, 2012 10:03 PM > >>>>> To: Henry Lum; Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >>>>> > >>>>> Henry& All, > >>>>> > >>>>> This question is coming around multiple times in the different > form > >>>>> whether SRS is allowed to send offer or not. In case SRS is > allowed > >>> to > >>>>> initial the offer, it is possible for SRS to add the stream. > IIUC, > >>> it > >>>>> was decided not to send offer during metadata request. Whether it > >> is > >>>>> possible to say that SRS MUST NOT initiate offer towards SRC? > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >>>>> Behalf > >>>>>> Of Henry Lum > >>>>>> Sent: Thursday, February 16, 2012 10:21 AM > >>>>>> To: Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>> > >>>>>> You're right, the SRS should be allowed to remove media streams > >>> from > >>>>> the > >>>>>> session for streams that the SRS does not want to record. > Somehow > >> I > >>>>> had > >>>>>> the impression that the SRS need to BYE the session to do so, > >>>> however, > >>>>>> an SRS should not be able to add a media stream on its own. > >>>>>> > >>>>>> Henry > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > >> On > >>>>>>> Behalf Of Hutton, Andrew > >>>>>>> Sent: February-14-12 12:57 PM > >>>>>>> To: Leon Portman; siprec@ietf.org > >>>>>>> Subject: Re: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>>> > >>>>>>> I assume the SRS can remove m-lines and we should say something > >>>>> about > >>>>>>> this in the protocol draft. > >>>>>>> > >>>>>>> Regards > >>>>>>> Andy > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Leon Portman [mailto:Leon.Portman@nice.com] > >>>>>>>> Sent: 14 February 2012 16:23 > >>>>>>>> To: Hutton, Andrew; siprec@ietf.org > >>>>>>>> Subject: RE: Protocol draft - SRS SDP Procedures. > >>>>>>>> > >>>>>>>> But today, if SRS does not want to record something, or pause > >>>>>>> recording > >>>>>>>> , it will use media-inactive attribute. Do we want for SRS to > >>> be > >>>>>> able > >>>>>>>> remove m-lines? > >>>>>>>> > >>>>>>>> Leon > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > >>> On > >>>>>>>> Behalf Of Hutton, Andrew > >>>>>>>> Sent: Friday, February 10, 2012 7:57 PM > >>>>>>>> To: siprec@ietf.org > >>>>>>>> Subject: [siprec] Protocol draft - SRS SDP Procedures. > >>>>>>>> > >>>>>>>> Hi All, > >>>>>>>> > >>>>>>>> Currently section 6.1.1 of http://tools.ietf.org/html/draft- > >>> ietf- > >>>>>>>> siprec-protocol-02#section-6.1.1 describes how the SRC can add > >>>> and > >>>>>>>> remove media lines during a recording session. > >>>>>>>> > >>>>>>>> However there is no corresponding section describing how the > >>> SRS > >>>>> can > >>>>>>> do > >>>>>>>> the same. I assume that that the SRS could for example > >>> terminate > >>>> a > >>>>>>>> stream during recording for example it might decide it no > >>> longer > >>>>>>> wants > >>>>>>>> to record the video stream but will continue recording the > >>> audio. > >>>>>>>> > >>>>>>>> We need to describe the use of offerless INVITE's by the SRS > >>> for > >>>>>>>> example when the SRS initiates the recording. > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> Andy > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> siprec mailing list > >>>>>>>> siprec@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>>> _______________________________________________ > >>>>>>> siprec mailing list > >>>>>>> siprec@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>>> _______________________________________________ > >>>>>> siprec mailing list > >>>>>> siprec@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/siprec > >>>>> _______________________________________________ > >>>>> siprec mailing 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 eckelcu@cisco.com Fri Feb 17 08:38:05 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE67921F864E for ; Fri, 17 Feb 2012 08:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.176 X-Spam-Level: X-Spam-Status: No, score=-8.176 tagged_above=-999 required=5 tests=[AWL=1.223, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5E4Vf15R5vq for ; Fri, 17 Feb 2012 08:38:04 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id AB57521F85F6 for ; Fri, 17 Feb 2012 08:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=6424; q=dns/txt; s=iport; t=1329496684; x=1330706284; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=d4N/DGf2kv2DiSmdGkCWKilEd86nxGtFuZ9LcL3g6iM=; b=jTkI8yvdduIJpfcvb3oV2O5eNEtTdm8yNuaGXMehQG9cVUNcxTeprNeq Bntt3Petd2QWuxhhCR8nu7TMuq1Njf13LFq7X0aWkLSKHMYV4B/j0Kude /dZLdtrYcqcsX52blgsiHrYFdWQP8TfPAQAS4red/4p2BNAquTUyx9JMZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANSBPk+rRDoJ/2dsb2JhbAA8CA6weIEHgXUBAQEEAQEBDwEdCjQLDAQCAQgRBAEBAQoGFwEGASAGHwkIAQEEARIIEweHZ5oWAZ5pBIheXwOCNQMGAgIBCQ8DAwINg1c0FBQHBgiCSWMEiE6XfIceWIE7 X-IronPort-AV: E=Sophos;i="4.73,438,1325462400"; d="scan'208";a="30841614" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 17 Feb 2012 16:38:04 +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 q1HGc0fi015441; Fri, 17 Feb 2012 16:38:04 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, 17 Feb 2012 08:38:02 -0800 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, 17 Feb 2012 08:38:01 -0800 Message-ID: In-Reply-To: <3FF56432D85141C8ACF379A5CD6069EE@Acer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AczsjvLM3CPUN0yjSUqQazvbgKQ4lwA/vFsA References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com> <3FF56432D85141C8ACF379A5CD6069EE@Acer> From: "Charles Eckel (eckelcu)" To: "John Elwell" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat" , "Hutton, Andrew" X-OriginalArrivalTime: 17 Feb 2012 16:38:02.0475 (UTC) FILETIME=[84224BB0:01CCED92] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 16:38:05 -0000 Hi John, Good to hear from you, and thanks for keeping us honest on this one. The potential benefit I see in have the metadata be optional is with respect to the migration path from pre-SIPREC solutions to SIPREC solutions. In such cases, the SRCs and UAs within a deployment might add support for the SIP/SDP extensions and RTP/RTCP recommendations provided by SIPREC, but the SRC and/or SRS may support the XML metadata. What if we were to do the following? siprec option tag: add to existing definition that it means SIPREC metadata is supported sip.src and sip.srs feature tags: clarify that it does not imply support for SIPREC metadata In this case, the hybrid SRC that I described could still include the sip.src feature tag in its REGISTER and INVITE requests. It would not include the siprec option tag as it does not support SIPREC metadata. If a SIPREC SRS receives such an INVITE, it has the choice of rejecting the INVTIE or accepting it for the purpose of recording using whatever logic it used prior to SIPREC. If the SRC supports metadata but does not require it, it can include the siprec option tag in a Supported header rather than in a Require header. The same is true for the SRS. Cheers, Charles =20 > -----Original Message----- > From: John Elwell [mailto:john.r.elwell@gmail.com] > Sent: Thursday, February 16, 2012 1:40 AM > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul Kyzivat; > Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >=20 > I think that XML-based metadata is the essence of SIPREC - other > protocol > additions are peripheral in comparison. We should say that if you don't > implement and use XML-based metadata you are not SIPREC-compliant. > Trying to > bend SIP header fields to achieve a poor-man's metadata does not make > sense, > particularly as we know that B2BUAs are all too prone to modifying SIP > header fields. >=20 > John >=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Thursday, February 16, 2012 6:21 AM > To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >=20 > I see some issues in going with this way: >=20 > 1) We will end up in having two different metadata mechanisms - one XML > and one headers based >=20 > 2) The existing SIP headers may not be sufficient to carry even the > basic metadata ( as partha mentioned in his previous e-mail) and if we > are going to add new headers then it is redundant as XML metadata was > just added for that purpose. >=20 > 3) SRC/SRS needs to negotiate on whether they want to use XML based > metadata (SIPREC metadata) or Header based metadata and this will lead > to more issues some of which you already outlined in the below e-mail >=20 > So, I feel it's better to stick with one metadata (XML SIPREC metadata) > and make it mandatory. >=20 > What we can add is some guidelines on how SRS has to behave for the > calls where SRC is unable to send metadata or if SRS encounters an SRC > that is not completely compliant with SIPREC standards(say does not > implement metadata). >=20 > Regards, > Ram >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: Wednesday, February 15, 2012 1:19 AM > > To: Paul Kyzivat; Hutton, Andrew > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > > Exploring this a bit further, I think this would define a new option > > tag, e.g. siprec-metadata. An SRC/SRS would include it in a Supported > > vs. Required header. In the event metadata is not used between the > SRC > > and SRS, a well documented set of SIP headers could be used to convey > > specific information about the recording. > > > > I do see some value in this. If we go this route, the next question > is, > > do you mandate support for this SIP headers AND avoid any overlap > > between them and the XML metadata? Or do we say that the XML > metadata, > > if present, supersedes anything conveyed via the SIP headers? Seeing > as > > XML metadata is a key part of SIPREC, I would suspect the latter, but > I > > am interested to hear what others think. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat > > > Sent: Tuesday, February 14, 2012 11:06 AM > > > To: Hutton, Andrew > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > > > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: > > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: > > > >> > > > >> I guess it isn't *necessary* to specify that. But there are > > > >> consequences > > > >> to not doing so: > > > >> > > > >> An SRC may have been getting acceptable results not specifying > > > >> metadata. > > > >> Then the SRS gets replaced with a different one and results are > no > > > >> longer acceptable because the new one doesn't infer things the > > same > > > >> way. > > > >> > > > > > > > > I think we can live with this if metadata is really important to > a > > > solution then the SRC will need to generate SIPREC metadata. > > > > > > Maybe. But there is a big hurdle between not supplied metadata and > > > supplying it. If the metadata is optional, then its quite possible > > that > > > you will have SRCs that just aren't capable of doing so. (Most > likely > > > for some simple cases like a UA that is its own SRC.) > > > > > > Then you might get locked in to an SRS that handles that case as > you > > > like. You will start having proprietary islands if SRCs and SRSs > that > > > can work together. > > > > > > 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 pravindran@sonusnet.com Fri Feb 17 10:28:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1088D21F854B for ; Fri, 17 Feb 2012 10:28:28 -0800 (PST) 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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB5EaDmhggDU for ; Fri, 17 Feb 2012 10:28:27 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C1FBB21F8534 for ; Fri, 17 Feb 2012 10:28:03 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1HISlX7006132; Fri, 17 Feb 2012 13:28:47 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 13:27:59 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 23:58:09 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 17 Feb 2012 23:58:08 +0530 From: "Ravindran, Parthasarathi" To: "Charles Eckel (eckelcu)" , John Elwell , "Ram Mohan R (rmohanr)" , Paul Kyzivat , "Hutton, Andrew" Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AcznTOSoydzMaYcFRNu/P4luqjLjsQDGsPTA///HagD//sYRkP/9XZTAgAU/QwCAAC75gIAAEp8AgAAMB4CAAkMNgIAAN1mAgAIHK4D//4oXIA== Date: Fri, 17 Feb 2012 18:28:07 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu> <35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com> <3FF56432D85141C8ACF379A5CD6069EE@Acer> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Feb 2012 18:28:09.0762 (UTC) FILETIME=[E6624820:01CCEDA1] Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2012 18:28:28 -0000 Hi Charles, In case some of the SRS has done your proposed SIPREC migration without met= adata in the first phase, it will impact SRC SIPREC implementation as SRC i= s forced to support SRS proprietary metadata and it is one of the major iss= ue today in SIP recording. I wish that it will be solved by SIPREC. Also, I'm seeing with your argument that most of the existing SIP based pro= prietary recording are already compliant with SIPREC in case option tag onl= y is added because the option tag shall be added through SIP message config= uration in the device (no development required :-)). The requested flexibil= ity in SIPREC provides the opportunity for vendors to stick with pre-SIPREC= solution and also, the benefit of IETF SIPREC compliance. Could you please= look this issue from the "sake of compliance vendor" perspective. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Charles Eckel (eckelcu) >Sent: Friday, February 17, 2012 10:08 PM >To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, Andrew >Cc: siprec@ietf.org >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >Hi John, > >Good to hear from you, and thanks for keeping us honest on this one. The >potential benefit I see in have the metadata be optional is with respect >to the migration path from pre-SIPREC solutions to SIPREC solutions. In >such cases, the SRCs and UAs within a deployment might add support for >the SIP/SDP extensions and RTP/RTCP recommendations provided by SIPREC, >but the SRC and/or SRS may support the XML metadata. What if we were to >do the following? > >siprec option tag: add to existing definition that it means SIPREC >metadata is supported sip.src and sip.srs feature tags: clarify that it >does not imply support for SIPREC metadata > >In this case, the hybrid SRC that I described could still include the >sip.src feature tag in its REGISTER and INVITE requests. It would not >include the siprec option tag as it does not support SIPREC metadata. If >a SIPREC SRS receives such an INVITE, it has the choice of rejecting the >INVTIE or accepting it for the purpose of recording using whatever logic >it used prior to SIPREC. >If the SRC supports metadata but does not require it, it can include the >siprec option tag in a Supported header rather than in a Require header. >The same is true for the SRS. > >Cheers, >Charles > > >> -----Original Message----- >> From: John Elwell [mailto:john.r.elwell@gmail.com] >> Sent: Thursday, February 16, 2012 1:40 AM >> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul Kyzivat; >> Hutton, Andrew >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> I think that XML-based metadata is the essence of SIPREC - other >> protocol additions are peripheral in comparison. We should say that if >> you >don't >> implement and use XML-based metadata you are not SIPREC-compliant. >> Trying to >> bend SIP header fields to achieve a poor-man's metadata does not make >> sense, particularly as we know that B2BUAs are all too prone to >> modifying SIP header fields. >> >> John >> >> -----Original Message----- >> From: Ram Mohan R (rmohanr) >> Sent: Thursday, February 16, 2012 6:21 AM >> To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew >> Cc: siprec@ietf.org >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> I see some issues in going with this way: >> >> 1) We will end up in having two different metadata mechanisms - one >XML >> and one headers based >> >> 2) The existing SIP headers may not be sufficient to carry even the >> basic metadata ( as partha mentioned in his previous e-mail) and if we >> are going to add new headers then it is redundant as XML metadata was >> just added for that purpose. >> >> 3) SRC/SRS needs to negotiate on whether they want to use XML based >> metadata (SIPREC metadata) or Header based metadata and this will lead >> to more issues some of which you already outlined in the below e-mail >> >> So, I feel it's better to stick with one metadata (XML SIPREC >metadata) >> and make it mandatory. >> >> What we can add is some guidelines on how SRS has to behave for the >> calls where SRC is unable to send metadata or if SRS encounters an SRC >> that is not completely compliant with SIPREC standards(say does not >> implement metadata). >> >> Regards, >> Ram >> >> > -----Original Message----- >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> > Behalf Of Charles Eckel (eckelcu) >> > Sent: Wednesday, February 15, 2012 1:19 AM >> > To: Paul Kyzivat; Hutton, Andrew >> > Cc: siprec@ietf.org >> > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> > >> > Exploring this a bit further, I think this would define a new option >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in a >Supported >> > vs. Required header. In the event metadata is not used between the >> SRC >> > and SRS, a well documented set of SIP headers could be used to >convey >> > specific information about the recording. >> > >> > I do see some value in this. If we go this route, the next question >> is, >> > do you mandate support for this SIP headers AND avoid any overlap >> > between them and the XML metadata? Or do we say that the XML >> metadata, >> > if present, supersedes anything conveyed via the SIP headers? Seeing >> as >> > XML metadata is a key part of SIPREC, I would suspect the latter, >but >> I >> > am interested to hear what others think. >> > >> > Cheers, >> > Charles >> > >> > > -----Original Message----- >> > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> > > Behalf Of Paul Kyzivat >> > > Sent: Tuesday, February 14, 2012 11:06 AM >> > > To: Hutton, Andrew >> > > Cc: siprec@ietf.org >> > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> > > >> > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: >> > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: >> > > >> >> > > >> I guess it isn't *necessary* to specify that. But there are >> > > >> consequences to not doing so: >> > > >> >> > > >> An SRC may have been getting acceptable results not specifying >> > > >> metadata. >> > > >> Then the SRS gets replaced with a different one and results are >> no >> > > >> longer acceptable because the new one doesn't infer things the >> > same >> > > >> way. >> > > >> >> > > > >> > > > I think we can live with this if metadata is really important to >> a >> > > solution then the SRC will need to generate SIPREC metadata. >> > > >> > > Maybe. But there is a big hurdle between not supplied metadata and >> > > supplying it. If the metadata is optional, then its quite possible >> > that >> > > you will have SRCs that just aren't capable of doing so. (Most >> likely >> > > for some simple cases like a UA that is its own SRC.) >> > > >> > > Then you might get locked in to an SRS that handles that case as >> you >> > > like. You will start having proprietary islands if SRCs and SRSs >> that >> > > can work together. >> > > >> > > 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 > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Mon Feb 20 14:44:41 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAC321F85C5 for ; Mon, 20 Feb 2012 14:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.215 X-Spam-Level: X-Spam-Status: No, score=-8.215 tagged_above=-999 required=5 tests=[AWL=1.184, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmikublaD2xC for ; Mon, 20 Feb 2012 14:44:39 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E07EC21F85B7 for ; Mon, 20 Feb 2012 14:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=9231; q=dns/txt; s=iport; t=1329777879; x=1330987479; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mTKzNB06bLcqZJ9AknZfuvhMnfDoVyr97erUJhRXCnw=; b=hVHgHIkxdIDqTfmcUsRw/9G+x/x8CkumVTsWLR5ZzzICgiZ6aJ5wtJGg MYm4NupWXqpBaNfTitnNWBB4jPL1NgM/8bSUX6EswlqLJgbmgafgOAyOX kzziBveMR93en8bIo+IC5lUfZKELOUYXqctPT6MNLbUeNv3FPEodUJ5X/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOTLQk+rRDoJ/2dsb2JhbAA7CA6xb4EHgXMBAQEDAQEBAQ8BHQo0CwUHBAIBCBEEAQEBCgYXAQYBIAYfCQgCBAESCBMHh14JmhYBnnsEiGpgA4IyCAECAQEBDAQRg3UzGgwPCgaCSmMEiE6YAIcfWIE7 X-IronPort-AV: E=Sophos;i="4.73,453,1325462400"; d="scan'208";a="31419253" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 20 Feb 2012 22:44:39 +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 q1KMidpA026339; Mon, 20 Feb 2012 22:44:39 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 14:44:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: E5QK JLDU J1to M9Ii SZLJ TDqV cDsA l7N/ qqdr rTjE sl/U v2xR wuLL xT4F z/BV 2d5v; 5; YQBuAGQAcgBlAHcALgBoAHUAdAB0AG8AbgBAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBqAG8AaABuAC4AcgAuAGUAbAB3AGUAbABsAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBwAGsAeQB6AGkAdgBhAHQAQABhAGwAdQBtAC4AbQBpAHQALgBlAGQAdQA7AHAAcgBhAHYAaQBuAGQAcgBhAG4AQABzAG8AbgB1AHMAbgBlAHQALgBjAG8AbQA7AHMAaQBwAHIAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {B3E67D81-BB9D-419A-942E-DF1382F10588}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Mon, 20 Feb 2012 22:44:31 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABJAHMAIABTAEkAUABSAEUAQwAgAG0AZQB0AGEAZABhAHQAYQAgAG0AYQBuAGQAYQB0AG8AcgB5ACAAdABvACAAaQBtAHAAbABlAG0AZQBuAHQAPwA= MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {B3E67D81-BB9D-419A-942E-DF1382F10588} Content-class: urn:content-classes:message Date: Mon, 20 Feb 2012 14:44:31 -0800 Message-ID: In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AcznTOSoydzMaYcFRNu/P4luqjLjsQDGsPTA///HagD//sYRkP/9XZTAgAU/QwCAAC75gIAAEp8AgAAMB4CAAkMNgIAAN1mAgAIHK4D//4oXIP/6ElVQ References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> From: "Charles Eckel (eckelcu)" To: "Ravindran, Parthasarathi" , "John Elwell" , "Ram Mohan R (rmohanr)" , "Paul Kyzivat" , "Hutton, Andrew" X-OriginalArrivalTime: 20 Feb 2012 22:44:39.0751 (UTC) FILETIME=[3AC57D70:01CCF021] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Feb 2012 22:44:41 -0000 Hi Partha, Please see inline. > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: Friday, February 17, 2012 10:28 AM > To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R (rmohanr); Paul > Kyzivat; Hutton, Andrew > Cc: siprec@ietf.org > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Hi Charles, >=20 > In case some of the SRS has done your proposed SIPREC migration without > metadata in the first phase, it will impact SRC SIPREC implementation > as SRC is forced to support SRS proprietary metadata and it is one of > the major issue today in SIP recording. I wish that it will be solved > by SIPREC. >=20 > Also, I'm seeing with your argument that most of the existing SIP based > proprietary recording are already compliant with SIPREC in case option > tag only is added because the option tag shall be added through SIP > message configuration in the device (no development required :-)). The > requested flexibility in SIPREC provides the opportunity for vendors to > stick with pre-SIPREC solution and also, the benefit of IETF SIPREC > compliance. Could you please look this issue from the "sake of > compliance vendor" perspective. In my proposal, I included the following: siprec option tag: add to existing definition that it means SIPREC metadata is supported sip.src and sip.srs feature tags: clarify that it does not imply support for SIPREC metadata Therefore, including the "siprec" option tag means that the metadata is supported. I thought this would address your concern. If not, then perhaps I do not completely understand the issue you are highlighting. Cheers, Charles=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Charles Eckel (eckelcu) > >Sent: Friday, February 17, 2012 10:08 PM > >To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, Andrew > >Cc: siprec@ietf.org > >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > >Hi John, > > > >Good to hear from you, and thanks for keeping us honest on this one. > The > >potential benefit I see in have the metadata be optional is with > respect > >to the migration path from pre-SIPREC solutions to SIPREC solutions. > In > >such cases, the SRCs and UAs within a deployment might add support for > >the SIP/SDP extensions and RTP/RTCP recommendations provided by > SIPREC, > >but the SRC and/or SRS may support the XML metadata. What if we were > to > >do the following? > > > >siprec option tag: add to existing definition that it means SIPREC > >metadata is supported sip.src and sip.srs feature tags: clarify that > it > >does not imply support for SIPREC metadata > > > >In this case, the hybrid SRC that I described could still include the > >sip.src feature tag in its REGISTER and INVITE requests. It would not > >include the siprec option tag as it does not support SIPREC metadata. > If > >a SIPREC SRS receives such an INVITE, it has the choice of rejecting > the > >INVTIE or accepting it for the purpose of recording using whatever > logic > >it used prior to SIPREC. > >If the SRC supports metadata but does not require it, it can include > the > >siprec option tag in a Supported header rather than in a Require > header. > >The same is true for the SRS. > > > >Cheers, > >Charles > > > > > >> -----Original Message----- > >> From: John Elwell [mailto:john.r.elwell@gmail.com] > >> Sent: Thursday, February 16, 2012 1:40 AM > >> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul Kyzivat; > >> Hutton, Andrew > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >> > >> I think that XML-based metadata is the essence of SIPREC - other > >> protocol additions are peripheral in comparison. We should say that > if > >> you > >don't > >> implement and use XML-based metadata you are not SIPREC-compliant. > >> Trying to > >> bend SIP header fields to achieve a poor-man's metadata does not > make > >> sense, particularly as we know that B2BUAs are all too prone to > >> modifying SIP header fields. > >> > >> John > >> > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) > >> Sent: Thursday, February 16, 2012 6:21 AM > >> To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >> > >> I see some issues in going with this way: > >> > >> 1) We will end up in having two different metadata mechanisms - one > >XML > >> and one headers based > >> > >> 2) The existing SIP headers may not be sufficient to carry even the > >> basic metadata ( as partha mentioned in his previous e-mail) and if > we > >> are going to add new headers then it is redundant as XML metadata > was > >> just added for that purpose. > >> > >> 3) SRC/SRS needs to negotiate on whether they want to use XML based > >> metadata (SIPREC metadata) or Header based metadata and this will > lead > >> to more issues some of which you already outlined in the below e- > mail > >> > >> So, I feel it's better to stick with one metadata (XML SIPREC > >metadata) > >> and make it mandatory. > >> > >> What we can add is some guidelines on how SRS has to behave for the > >> calls where SRC is unable to send metadata or if SRS encounters an > SRC > >> that is not completely compliant with SIPREC standards(say does not > >> implement metadata). > >> > >> Regards, > >> Ram > >> > >> > -----Original Message----- > >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> > Behalf Of Charles Eckel (eckelcu) > >> > Sent: Wednesday, February 15, 2012 1:19 AM > >> > To: Paul Kyzivat; Hutton, Andrew > >> > Cc: siprec@ietf.org > >> > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >> > > >> > Exploring this a bit further, I think this would define a new > option > >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in a > >Supported > >> > vs. Required header. In the event metadata is not used between the > >> SRC > >> > and SRS, a well documented set of SIP headers could be used to > >convey > >> > specific information about the recording. > >> > > >> > I do see some value in this. If we go this route, the next > question > >> is, > >> > do you mandate support for this SIP headers AND avoid any overlap > >> > between them and the XML metadata? Or do we say that the XML > >> metadata, > >> > if present, supersedes anything conveyed via the SIP headers? > Seeing > >> as > >> > XML metadata is a key part of SIPREC, I would suspect the latter, > >but > >> I > >> > am interested to hear what others think. > >> > > >> > Cheers, > >> > Charles > >> > > >> > > -----Original Message----- > >> > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >> > > Behalf Of Paul Kyzivat > >> > > Sent: Tuesday, February 14, 2012 11:06 AM > >> > > To: Hutton, Andrew > >> > > Cc: siprec@ietf.org > >> > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >> > > > >> > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: > >> > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: > >> > > >> > >> > > >> I guess it isn't *necessary* to specify that. But there are > >> > > >> consequences to not doing so: > >> > > >> > >> > > >> An SRC may have been getting acceptable results not > specifying > >> > > >> metadata. > >> > > >> Then the SRS gets replaced with a different one and results > are > >> no > >> > > >> longer acceptable because the new one doesn't infer things > the > >> > same > >> > > >> way. > >> > > >> > >> > > > > >> > > > I think we can live with this if metadata is really important > to > >> a > >> > > solution then the SRC will need to generate SIPREC metadata. > >> > > > >> > > Maybe. But there is a big hurdle between not supplied metadata > and > >> > > supplying it. If the metadata is optional, then its quite > possible > >> > that > >> > > you will have SRCs that just aren't capable of doing so. (Most > >> likely > >> > > for some simple cases like a UA that is its own SRC.) > >> > > > >> > > Then you might get locked in to an SRS that handles that case as > >> you > >> > > like. You will start having proprietary islands if SRCs and SRSs > >> that > >> > > can work together. > >> > > > >> > > 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 > > > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Mon Feb 20 19:41:50 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC31421F856D for ; Mon, 20 Feb 2012 19:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9a-j8+bj9ZR for ; Mon, 20 Feb 2012 19:41:50 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id BB9CA21F856C for ; Mon, 20 Feb 2012 19:41:49 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1L3gXIZ011570; Mon, 20 Feb 2012 22:42:33 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 22:41:45 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 09:11:58 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 21 Feb 2012 09:11:57 +0530 From: "Ravindran, Parthasarathi" To: "Charles Eckel (eckelcu)" , John Elwell , "Ram Mohan R (rmohanr)" , Paul Kyzivat , "Hutton, Andrew" Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AcznTOSoydzMaYcFRNu/P4luqjLjsQDGsPTA///HagD//sYRkP/9XZTAgAU/QwCAAC75gIAAEp8AgAAMB4CAAkMNgIAAN1mAgAIHK4D//4oXIP/6ElVQ//PakuA= Date: Tue, 21 Feb 2012 03:41:56 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2012 03:41:58.0005 (UTC) FILETIME=[C3330A50:01CCF04A] Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2012 03:41:50 -0000 Hi Charles, In case we end up with sip.src contact parameter is the only mandatory for = SIPREC compliance, then I would say that Existing Sonus proprietary recordi= ng already met SIPREC compliance because adding contact header parameter is= a matter of configuration. I'm confident that smart product manager in oth= er companies push for the same level of compliance ;-) This will result in = SIPREC compliance with new proprietary headers/body for interop with each r= ecording vendor. I'm worried that those kind SIPREC compliance will not sol= ve the indented problem which we are working for. Thanks Partha >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Tuesday, February 21, 2012 4:15 AM >To: Ravindran, Parthasarathi; John Elwell; Ram Mohan R (rmohanr); Paul >Kyzivat; Hutton, Andrew >Cc: siprec@ietf.org >Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > >Hi Partha, > >Please see inline. > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: Friday, February 17, 2012 10:28 AM >> To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R (rmohanr); Paul >> Kyzivat; Hutton, Andrew >> Cc: siprec@ietf.org >> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >> >> Hi Charles, >> >> In case some of the SRS has done your proposed SIPREC migration >without >> metadata in the first phase, it will impact SRC SIPREC implementation >> as SRC is forced to support SRS proprietary metadata and it is one of >> the major issue today in SIP recording. I wish that it will be solved >> by SIPREC. >> >> Also, I'm seeing with your argument that most of the existing SIP >based >> proprietary recording are already compliant with SIPREC in case option >> tag only is added because the option tag shall be added through SIP >> message configuration in the device (no development required :-)). The >> requested flexibility in SIPREC provides the opportunity for vendors >to >> stick with pre-SIPREC solution and also, the benefit of IETF SIPREC >> compliance. Could you please look this issue from the "sake of >> compliance vendor" perspective. > >In my proposal, I included the following: > >siprec option tag: add to existing definition that it means SIPREC >metadata is supported > >sip.src and sip.srs feature tags: clarify that it does not imply support >for SIPREC metadata > >Therefore, including the "siprec" option tag means that the metadata is >supported. I thought this would address your concern. If not, then >perhaps I do not completely understand the issue you are highlighting. > >Cheers, >Charles > > >> Thanks >> Partha >> >> >-----Original Message----- >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >> >Of Charles Eckel (eckelcu) >> >Sent: Friday, February 17, 2012 10:08 PM >> >To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, Andrew >> >Cc: siprec@ietf.org >> >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> > >> >Hi John, >> > >> >Good to hear from you, and thanks for keeping us honest on this one. >> The >> >potential benefit I see in have the metadata be optional is with >> respect >> >to the migration path from pre-SIPREC solutions to SIPREC solutions. >> In >> >such cases, the SRCs and UAs within a deployment might add support >for >> >the SIP/SDP extensions and RTP/RTCP recommendations provided by >> SIPREC, >> >but the SRC and/or SRS may support the XML metadata. What if we were >> to >> >do the following? >> > >> >siprec option tag: add to existing definition that it means SIPREC >> >metadata is supported sip.src and sip.srs feature tags: clarify that >> it >> >does not imply support for SIPREC metadata >> > >> >In this case, the hybrid SRC that I described could still include the >> >sip.src feature tag in its REGISTER and INVITE requests. It would not >> >include the siprec option tag as it does not support SIPREC metadata. >> If >> >a SIPREC SRS receives such an INVITE, it has the choice of rejecting >> the >> >INVTIE or accepting it for the purpose of recording using whatever >> logic >> >it used prior to SIPREC. >> >If the SRC supports metadata but does not require it, it can include >> the >> >siprec option tag in a Supported header rather than in a Require >> header. >> >The same is true for the SRS. >> > >> >Cheers, >> >Charles >> > >> > >> >> -----Original Message----- >> >> From: John Elwell [mailto:john.r.elwell@gmail.com] >> >> Sent: Thursday, February 16, 2012 1:40 AM >> >> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul Kyzivat; >> >> Hutton, Andrew >> >> Cc: siprec@ietf.org >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> >> >> I think that XML-based metadata is the essence of SIPREC - other >> >> protocol additions are peripheral in comparison. We should say that >> if >> >> you >> >don't >> >> implement and use XML-based metadata you are not SIPREC-compliant. >> >> Trying to >> >> bend SIP header fields to achieve a poor-man's metadata does not >> make >> >> sense, particularly as we know that B2BUAs are all too prone to >> >> modifying SIP header fields. >> >> >> >> John >> >> >> >> -----Original Message----- >> >> From: Ram Mohan R (rmohanr) >> >> Sent: Thursday, February 16, 2012 6:21 AM >> >> To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew >> >> Cc: siprec@ietf.org >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> >> >> I see some issues in going with this way: >> >> >> >> 1) We will end up in having two different metadata mechanisms - one >> >XML >> >> and one headers based >> >> >> >> 2) The existing SIP headers may not be sufficient to carry even the >> >> basic metadata ( as partha mentioned in his previous e-mail) and if >> we >> >> are going to add new headers then it is redundant as XML metadata >> was >> >> just added for that purpose. >> >> >> >> 3) SRC/SRS needs to negotiate on whether they want to use XML based >> >> metadata (SIPREC metadata) or Header based metadata and this will >> lead >> >> to more issues some of which you already outlined in the below e- >> mail >> >> >> >> So, I feel it's better to stick with one metadata (XML SIPREC >> >metadata) >> >> and make it mandatory. >> >> >> >> What we can add is some guidelines on how SRS has to behave for the >> >> calls where SRC is unable to send metadata or if SRS encounters an >> SRC >> >> that is not completely compliant with SIPREC standards(say does not >> >> implement metadata). >> >> >> >> Regards, >> >> Ram >> >> >> >> > -----Original Message----- >> >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> > Behalf Of Charles Eckel (eckelcu) >> >> > Sent: Wednesday, February 15, 2012 1:19 AM >> >> > To: Paul Kyzivat; Hutton, Andrew >> >> > Cc: siprec@ietf.org >> >> > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> > >> >> > Exploring this a bit further, I think this would define a new >> option >> >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in a >> >Supported >> >> > vs. Required header. In the event metadata is not used between >the >> >> SRC >> >> > and SRS, a well documented set of SIP headers could be used to >> >convey >> >> > specific information about the recording. >> >> > >> >> > I do see some value in this. If we go this route, the next >> question >> >> is, >> >> > do you mandate support for this SIP headers AND avoid any overlap >> >> > between them and the XML metadata? Or do we say that the XML >> >> metadata, >> >> > if present, supersedes anything conveyed via the SIP headers? >> Seeing >> >> as >> >> > XML metadata is a key part of SIPREC, I would suspect the latter, >> >but >> >> I >> >> > am interested to hear what others think. >> >> > >> >> > Cheers, >> >> > Charles >> >> > >> >> > > -----Original Message----- >> >> > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >> >> > > Behalf Of Paul Kyzivat >> >> > > Sent: Tuesday, February 14, 2012 11:06 AM >> >> > > To: Hutton, Andrew >> >> > > Cc: siprec@ietf.org >> >> > > Subject: Re: [siprec] Is SIPREC metadata mandatory to >implement? >> >> > > >> >> > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: >> >> > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: >> >> > > >> >> >> > > >> I guess it isn't *necessary* to specify that. But there are >> >> > > >> consequences to not doing so: >> >> > > >> >> >> > > >> An SRC may have been getting acceptable results not >> specifying >> >> > > >> metadata. >> >> > > >> Then the SRS gets replaced with a different one and results >> are >> >> no >> >> > > >> longer acceptable because the new one doesn't infer things >> the >> >> > same >> >> > > >> way. >> >> > > >> >> >> > > > >> >> > > > I think we can live with this if metadata is really important >> to >> >> a >> >> > > solution then the SRC will need to generate SIPREC metadata. >> >> > > >> >> > > Maybe. But there is a big hurdle between not supplied metadata >> and >> >> > > supplying it. If the metadata is optional, then its quite >> possible >> >> > that >> >> > > you will have SRCs that just aren't capable of doing so. (Most >> >> likely >> >> > > for some simple cases like a UA that is its own SRC.) >> >> > > >> >> > > Then you might get locked in to an SRS that handles that case >as >> >> you >> >> > > like. You will start having proprietary islands if SRCs and >SRSs >> >> that >> >> > > can work together. >> >> > > >> >> > > 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 >> > >> >_______________________________________________ >> >siprec mailing list >> >siprec@ietf.org >> >https://www.ietf.org/mailman/listinfo/siprec From john.r.elwell@gmail.com Tue Feb 21 09:01:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80B721F8620 for ; Tue, 21 Feb 2012 09:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+Xm18SMwHU4 for ; Tue, 21 Feb 2012 09:01:24 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6F68221F879E for ; Tue, 21 Feb 2012 09:01:24 -0800 (PST) Received: by wgbgn7 with SMTP id gn7so4155008wgb.1 for ; Tue, 21 Feb 2012 09:01:23 -0800 (PST) Received-SPF: pass (google.com: domain of john.r.elwell@gmail.com designates 10.180.81.66 as permitted sender) client-ip=10.180.81.66; Authentication-Results: mr.google.com; spf=pass (google.com: domain of john.r.elwell@gmail.com designates 10.180.81.66 as permitted sender) smtp.mail=john.r.elwell@gmail.com; dkim=pass header.i=john.r.elwell@gmail.com Received: from mr.google.com ([10.180.81.66]) by 10.180.81.66 with SMTP id y2mr27210380wix.20.1329843683679 (num_hops = 1); Tue, 21 Feb 2012 09:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole; bh=P/cTZKiYWgNwltIYGXqq3zEeKsHsb4aCSytAEsKIGV8=; b=nzIxDLuBwPmaTz2bJNnAegweERAj2gRj/ciBy9XROiexwIbeibeu4yCwYPYazkJVns 3Y9Yx+42UaLmLTkxCljvN7GMorNvlcjU7WQTh9e8DG/cclIfHgTwJwua/Rk18kIUF2/b 23JazNKOcoRat4sBB0yIJW+UmWiUc1I9WteHU= Received: by 10.180.81.66 with SMTP id y2mr22668964wix.20.1329843683577; Tue, 21 Feb 2012 09:01:23 -0800 (PST) Received: from Acer (cpc1-clif8-2-0-cust418.12-4.cable.virginmedia.com. [82.25.209.163]) by mx.google.com with ESMTPS id gd8sm23720174wib.2.2012.02.21.09.01.21 (version=SSLv3 cipher=OTHER); Tue, 21 Feb 2012 09:01:22 -0800 (PST) Message-ID: From: "John Elwell" To: "Ravindran, Parthasarathi" , "Charles Eckel \(eckelcu\)" , "Ram Mohan R \(rmohanr\)" , "Paul Kyzivat" , "Hutton, Andrew" References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> Date: Tue, 21 Feb 2012 17:01:20 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2012 17:01:29 -0000 That is my concern. The proposed option tag would make the bar for SIPREC compliance so low that almost any implementation could easily be made to comply, and yet the degree of interoperability between such implementations would be rather poor. It would be rather like claiming to support SIP without supporting SDP. John -----Original Message----- From: Ravindran, Parthasarathi Sent: Tuesday, February 21, 2012 3:41 AM To: Charles Eckel (eckelcu) ; John Elwell ; Ram Mohan R (rmohanr) ; Paul Kyzivat ; Hutton, Andrew Cc: siprec@ietf.org Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? Hi Charles, In case we end up with sip.src contact parameter is the only mandatory for SIPREC compliance, then I would say that Existing Sonus proprietary recording already met SIPREC compliance because adding contact header parameter is a matter of configuration. I'm confident that smart product manager in other companies push for the same level of compliance ;-) This will result in SIPREC compliance with new proprietary headers/body for interop with each recording vendor. I'm worried that those kind SIPREC compliance will not solve the indented problem which we are working for. Thanks Partha >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Tuesday, February 21, 2012 4:15 AM >To: Ravindran, Parthasarathi; John Elwell; Ram Mohan R (rmohanr); Paul >Kyzivat; Hutton, Andrew >Cc: siprec@ietf.org >Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > >Hi Partha, > >Please see inline. > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: Friday, February 17, 2012 10:28 AM >> To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R (rmohanr); Paul >> Kyzivat; Hutton, Andrew >> Cc: siprec@ietf.org >> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >> >> Hi Charles, >> >> In case some of the SRS has done your proposed SIPREC migration >without >> metadata in the first phase, it will impact SRC SIPREC implementation >> as SRC is forced to support SRS proprietary metadata and it is one of >> the major issue today in SIP recording. I wish that it will be solved >> by SIPREC. >> >> Also, I'm seeing with your argument that most of the existing SIP >based >> proprietary recording are already compliant with SIPREC in case option >> tag only is added because the option tag shall be added through SIP >> message configuration in the device (no development required :-)). The >> requested flexibility in SIPREC provides the opportunity for vendors >to >> stick with pre-SIPREC solution and also, the benefit of IETF SIPREC >> compliance. Could you please look this issue from the "sake of >> compliance vendor" perspective. > >In my proposal, I included the following: > >siprec option tag: add to existing definition that it means SIPREC >metadata is supported > >sip.src and sip.srs feature tags: clarify that it does not imply support >for SIPREC metadata > >Therefore, including the "siprec" option tag means that the metadata is >supported. I thought this would address your concern. If not, then >perhaps I do not completely understand the issue you are highlighting. > >Cheers, >Charles > > >> Thanks >> Partha >> >> >-----Original Message----- >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >> >Of Charles Eckel (eckelcu) >> >Sent: Friday, February 17, 2012 10:08 PM >> >To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, Andrew >> >Cc: siprec@ietf.org >> >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> > >> >Hi John, >> > >> >Good to hear from you, and thanks for keeping us honest on this one. >> The >> >potential benefit I see in have the metadata be optional is with >> respect >> >to the migration path from pre-SIPREC solutions to SIPREC solutions. >> In >> >such cases, the SRCs and UAs within a deployment might add support >for >> >the SIP/SDP extensions and RTP/RTCP recommendations provided by >> SIPREC, >> >but the SRC and/or SRS may support the XML metadata. What if we were >> to >> >do the following? >> > >> >siprec option tag: add to existing definition that it means SIPREC >> >metadata is supported sip.src and sip.srs feature tags: clarify that >> it >> >does not imply support for SIPREC metadata >> > >> >In this case, the hybrid SRC that I described could still include the >> >sip.src feature tag in its REGISTER and INVITE requests. It would not >> >include the siprec option tag as it does not support SIPREC metadata. >> If >> >a SIPREC SRS receives such an INVITE, it has the choice of rejecting >> the >> >INVTIE or accepting it for the purpose of recording using whatever >> logic >> >it used prior to SIPREC. >> >If the SRC supports metadata but does not require it, it can include >> the >> >siprec option tag in a Supported header rather than in a Require >> header. >> >The same is true for the SRS. >> > >> >Cheers, >> >Charles >> > >> > >> >> -----Original Message----- >> >> From: John Elwell [mailto:john.r.elwell@gmail.com] >> >> Sent: Thursday, February 16, 2012 1:40 AM >> >> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul Kyzivat; >> >> Hutton, Andrew >> >> Cc: siprec@ietf.org >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> >> >> I think that XML-based metadata is the essence of SIPREC - other >> >> protocol additions are peripheral in comparison. We should say that >> if >> >> you >> >don't >> >> implement and use XML-based metadata you are not SIPREC-compliant. >> >> Trying to >> >> bend SIP header fields to achieve a poor-man's metadata does not >> make >> >> sense, particularly as we know that B2BUAs are all too prone to >> >> modifying SIP header fields. >> >> >> >> John >> >> >> >> -----Original Message----- >> >> From: Ram Mohan R (rmohanr) >> >> Sent: Thursday, February 16, 2012 6:21 AM >> >> To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew >> >> Cc: siprec@ietf.org >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> >> >> I see some issues in going with this way: >> >> >> >> 1) We will end up in having two different metadata mechanisms - one >> >XML >> >> and one headers based >> >> >> >> 2) The existing SIP headers may not be sufficient to carry even the >> >> basic metadata ( as partha mentioned in his previous e-mail) and if >> we >> >> are going to add new headers then it is redundant as XML metadata >> was >> >> just added for that purpose. >> >> >> >> 3) SRC/SRS needs to negotiate on whether they want to use XML based >> >> metadata (SIPREC metadata) or Header based metadata and this will >> lead >> >> to more issues some of which you already outlined in the below e- >> mail >> >> >> >> So, I feel it's better to stick with one metadata (XML SIPREC >> >metadata) >> >> and make it mandatory. >> >> >> >> What we can add is some guidelines on how SRS has to behave for the >> >> calls where SRC is unable to send metadata or if SRS encounters an >> SRC >> >> that is not completely compliant with SIPREC standards(say does not >> >> implement metadata). >> >> >> >> Regards, >> >> Ram >> >> >> >> > -----Original Message----- >> >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> > Behalf Of Charles Eckel (eckelcu) >> >> > Sent: Wednesday, February 15, 2012 1:19 AM >> >> > To: Paul Kyzivat; Hutton, Andrew >> >> > Cc: siprec@ietf.org >> >> > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> > >> >> > Exploring this a bit further, I think this would define a new >> option >> >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in a >> >Supported >> >> > vs. Required header. In the event metadata is not used between >the >> >> SRC >> >> > and SRS, a well documented set of SIP headers could be used to >> >convey >> >> > specific information about the recording. >> >> > >> >> > I do see some value in this. If we go this route, the next >> question >> >> is, >> >> > do you mandate support for this SIP headers AND avoid any overlap >> >> > between them and the XML metadata? Or do we say that the XML >> >> metadata, >> >> > if present, supersedes anything conveyed via the SIP headers? >> Seeing >> >> as >> >> > XML metadata is a key part of SIPREC, I would suspect the latter, >> >but >> >> I >> >> > am interested to hear what others think. >> >> > >> >> > Cheers, >> >> > Charles >> >> > >> >> > > -----Original Message----- >> >> > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> On >> >> > > Behalf Of Paul Kyzivat >> >> > > Sent: Tuesday, February 14, 2012 11:06 AM >> >> > > To: Hutton, Andrew >> >> > > Cc: siprec@ietf.org >> >> > > Subject: Re: [siprec] Is SIPREC metadata mandatory to >implement? >> >> > > >> >> > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: >> >> > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: >> >> > > >> >> >> > > >> I guess it isn't *necessary* to specify that. But there are >> >> > > >> consequences to not doing so: >> >> > > >> >> >> > > >> An SRC may have been getting acceptable results not >> specifying >> >> > > >> metadata. >> >> > > >> Then the SRS gets replaced with a different one and results >> are >> >> no >> >> > > >> longer acceptable because the new one doesn't infer things >> the >> >> > same >> >> > > >> way. >> >> > > >> >> >> > > > >> >> > > > I think we can live with this if metadata is really important >> to >> >> a >> >> > > solution then the SRC will need to generate SIPREC metadata. >> >> > > >> >> > > Maybe. But there is a big hurdle between not supplied metadata >> and >> >> > > supplying it. If the metadata is optional, then its quite >> possible >> >> > that >> >> > > you will have SRCs that just aren't capable of doing so. (Most >> >> likely >> >> > > for some simple cases like a UA that is its own SRC.) >> >> > > >> >> > > Then you might get locked in to an SRS that handles that case >as >> >> you >> >> > > like. You will start having proprietary islands if SRCs and >SRSs >> >> that >> >> > > can work together. >> >> > > >> >> > > 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 >> > >> >_______________________________________________ >> >siprec mailing list >> >siprec@ietf.org >> >https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Tue Feb 21 09:12:33 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A126721F887B for ; Tue, 21 Feb 2012 09:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsCqeRFnRsSp for ; Tue, 21 Feb 2012 09:12:29 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8025421F8887 for ; Tue, 21 Feb 2012 09:12:29 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id cgWn1i0081c6gX85DhCW5L; Tue, 21 Feb 2012 17:12:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id chCV1i00r07duvL3jhCVLy; Tue, 21 Feb 2012 17:12:30 +0000 Message-ID: <4F43D07C.5010204@alum.mit.edu> Date: Tue, 21 Feb 2012 12:12:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John Elwell References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 21 Feb 2012 17:12:33 -0000 On 2/21/12 12:01 PM, John Elwell wrote: > That is my concern. The proposed option tag would make the bar for > SIPREC compliance so low that almost any implementation could easily be > made to comply, and yet the degree of interoperability between such > implementations would be rather poor. It would be rather like claiming > to support SIP without supporting SDP. I agree. (But its actually reasonable to support SIP without supporting SDP. You only need support SDP if you support INVITE. A proxy, registrar, event server, or event client need not support SDP.) Thanks, Paul > John > > > -----Original Message----- From: Ravindran, Parthasarathi > Sent: Tuesday, February 21, 2012 3:41 AM > To: Charles Eckel (eckelcu) ; John Elwell ; Ram Mohan R (rmohanr) ; Paul > Kyzivat ; Hutton, Andrew > Cc: siprec@ietf.org > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > Hi Charles, > > In case we end up with sip.src contact parameter is the only mandatory > for SIPREC compliance, then I would say that Existing Sonus proprietary > recording already met SIPREC compliance because adding contact header > parameter is a matter of configuration. I'm confident that smart product > manager in other companies push for the same level of compliance ;-) > This will result in SIPREC compliance with new proprietary headers/body > for interop with each recording vendor. I'm worried that those kind > SIPREC compliance will not solve the indented problem which we are > working for. > > Thanks > Partha > >> -----Original Message----- >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> Sent: Tuesday, February 21, 2012 4:15 AM >> To: Ravindran, Parthasarathi; John Elwell; Ram Mohan R (rmohanr); Paul >> Kyzivat; Hutton, Andrew >> Cc: siprec@ietf.org >> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >> >> Hi Partha, >> >> Please see inline. >> >>> -----Original Message----- >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>> Sent: Friday, February 17, 2012 10:28 AM >>> To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R (rmohanr); Paul >>> Kyzivat; Hutton, Andrew >>> Cc: siprec@ietf.org >>> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >>> >>> Hi Charles, >>> >>> In case some of the SRS has done your proposed SIPREC migration >> without >>> metadata in the first phase, it will impact SRC SIPREC implementation >>> as SRC is forced to support SRS proprietary metadata and it is one of >>> the major issue today in SIP recording. I wish that it will be solved >>> by SIPREC. >>> >>> Also, I'm seeing with your argument that most of the existing SIP >> based >>> proprietary recording are already compliant with SIPREC in case option >>> tag only is added because the option tag shall be added through SIP >>> message configuration in the device (no development required :-)). The >>> requested flexibility in SIPREC provides the opportunity for vendors >> to >>> stick with pre-SIPREC solution and also, the benefit of IETF SIPREC >>> compliance. Could you please look this issue from the "sake of >>> compliance vendor" perspective. >> >> In my proposal, I included the following: >> >> siprec option tag: add to existing definition that it means SIPREC >> metadata is supported >> >> sip.src and sip.srs feature tags: clarify that it does not imply support >> for SIPREC metadata >> >> Therefore, including the "siprec" option tag means that the metadata is >> supported. I thought this would address your concern. If not, then >> perhaps I do not completely understand the issue you are highlighting. >> >> Cheers, >> Charles >> >> >>> Thanks >>> Partha >>> >>> >-----Original Message----- >>> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf >>> >Of Charles Eckel (eckelcu) >>> >Sent: Friday, February 17, 2012 10:08 PM >>> >To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, Andrew >>> >Cc: siprec@ietf.org >>> >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >>> > >>> >Hi John, >>> > >>> >Good to hear from you, and thanks for keeping us honest on this one. >>> The >>> >potential benefit I see in have the metadata be optional is with >>> respect >>> >to the migration path from pre-SIPREC solutions to SIPREC solutions. >>> In >>> >such cases, the SRCs and UAs within a deployment might add support >> for >>> >the SIP/SDP extensions and RTP/RTCP recommendations provided by >>> SIPREC, >>> >but the SRC and/or SRS may support the XML metadata. What if we were >>> to >>> >do the following? >>> > >>> >siprec option tag: add to existing definition that it means SIPREC >>> >metadata is supported sip.src and sip.srs feature tags: clarify that >>> it >>> >does not imply support for SIPREC metadata >>> > >>> >In this case, the hybrid SRC that I described could still include the >>> >sip.src feature tag in its REGISTER and INVITE requests. It would not >>> >include the siprec option tag as it does not support SIPREC metadata. >>> If >>> >a SIPREC SRS receives such an INVITE, it has the choice of rejecting >>> the >>> >INVTIE or accepting it for the purpose of recording using whatever >>> logic >>> >it used prior to SIPREC. >>> >If the SRC supports metadata but does not require it, it can include >>> the >>> >siprec option tag in a Supported header rather than in a Require >>> header. >>> >The same is true for the SRS. >>> > >>> >Cheers, >>> >Charles >>> > >>> > >>> >> -----Original Message----- >>> >> From: John Elwell [mailto:john.r.elwell@gmail.com] >>> >> Sent: Thursday, February 16, 2012 1:40 AM >>> >> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul Kyzivat; >>> >> Hutton, Andrew >>> >> Cc: siprec@ietf.org >>> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >>> >> >>> >> I think that XML-based metadata is the essence of SIPREC - other >>> >> protocol additions are peripheral in comparison. We should say that >>> if >>> >> you >>> >don't >>> >> implement and use XML-based metadata you are not SIPREC-compliant. >>> >> Trying to >>> >> bend SIP header fields to achieve a poor-man's metadata does not >>> make >>> >> sense, particularly as we know that B2BUAs are all too prone to >>> >> modifying SIP header fields. >>> >> >>> >> John >>> >> >>> >> -----Original Message----- >>> >> From: Ram Mohan R (rmohanr) >>> >> Sent: Thursday, February 16, 2012 6:21 AM >>> >> To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew >>> >> Cc: siprec@ietf.org >>> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >>> >> >>> >> I see some issues in going with this way: >>> >> >>> >> 1) We will end up in having two different metadata mechanisms - one >>> >XML >>> >> and one headers based >>> >> >>> >> 2) The existing SIP headers may not be sufficient to carry even the >>> >> basic metadata ( as partha mentioned in his previous e-mail) and if >>> we >>> >> are going to add new headers then it is redundant as XML metadata >>> was >>> >> just added for that purpose. >>> >> >>> >> 3) SRC/SRS needs to negotiate on whether they want to use XML based >>> >> metadata (SIPREC metadata) or Header based metadata and this will >>> lead >>> >> to more issues some of which you already outlined in the below e- >>> mail >>> >> >>> >> So, I feel it's better to stick with one metadata (XML SIPREC >>> >metadata) >>> >> and make it mandatory. >>> >> >>> >> What we can add is some guidelines on how SRS has to behave for the >>> >> calls where SRC is unable to send metadata or if SRS encounters an >>> SRC >>> >> that is not completely compliant with SIPREC standards(say does not >>> >> implement metadata). >>> >> >>> >> Regards, >>> >> Ram >>> >> >>> >> > -----Original Message----- >>> >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> >> > Behalf Of Charles Eckel (eckelcu) >>> >> > Sent: Wednesday, February 15, 2012 1:19 AM >>> >> > To: Paul Kyzivat; Hutton, Andrew >>> >> > Cc: siprec@ietf.org >>> >> > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >>> >> > >>> >> > Exploring this a bit further, I think this would define a new >>> option >>> >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in a >>> >Supported >>> >> > vs. Required header. In the event metadata is not used between >> the >>> >> SRC >>> >> > and SRS, a well documented set of SIP headers could be used to >>> >convey >>> >> > specific information about the recording. >>> >> > >>> >> > I do see some value in this. If we go this route, the next >>> question >>> >> is, >>> >> > do you mandate support for this SIP headers AND avoid any overlap >>> >> > between them and the XML metadata? Or do we say that the XML >>> >> metadata, >>> >> > if present, supersedes anything conveyed via the SIP headers? >>> Seeing >>> >> as >>> >> > XML metadata is a key part of SIPREC, I would suspect the latter, >>> >but >>> >> I >>> >> > am interested to hear what others think. >>> >> > >>> >> > Cheers, >>> >> > Charles >>> >> > >>> >> > > -----Original Message----- >>> >> > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >>> On >>> >> > > Behalf Of Paul Kyzivat >>> >> > > Sent: Tuesday, February 14, 2012 11:06 AM >>> >> > > To: Hutton, Andrew >>> >> > > Cc: siprec@ietf.org >>> >> > > Subject: Re: [siprec] Is SIPREC metadata mandatory to >> implement? >>> >> > > >>> >> > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: >>> >> > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: >>> >> > > >> >>> >> > > >> I guess it isn't *necessary* to specify that. But there are >>> >> > > >> consequences to not doing so: >>> >> > > >> >>> >> > > >> An SRC may have been getting acceptable results not >>> specifying >>> >> > > >> metadata. >>> >> > > >> Then the SRS gets replaced with a different one and results >>> are >>> >> no >>> >> > > >> longer acceptable because the new one doesn't infer things >>> the >>> >> > same >>> >> > > >> way. >>> >> > > >> >>> >> > > > >>> >> > > > I think we can live with this if metadata is really important >>> to >>> >> a >>> >> > > solution then the SRC will need to generate SIPREC metadata. >>> >> > > >>> >> > > Maybe. But there is a big hurdle between not supplied metadata >>> and >>> >> > > supplying it. If the metadata is optional, then its quite >>> possible >>> >> > that >>> >> > > you will have SRCs that just aren't capable of doing so. (Most >>> >> likely >>> >> > > for some simple cases like a UA that is its own SRC.) >>> >> > > >>> >> > > Then you might get locked in to an SRS that handles that case >> as >>> >> you >>> >> > > like. You will start having proprietary islands if SRCs and >> SRSs >>> >> that >>> >> > > can work together. >>> >> > > >>> >> > > 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 >>> > >>> >_______________________________________________ >>> >siprec mailing list >>> >siprec@ietf.org >>> >https://www.ietf.org/mailman/listinfo/siprec > > From rmohanr@cisco.com Tue Feb 21 19:10:32 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F8821F8697 for ; Tue, 21 Feb 2012 19:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.616 X-Spam-Level: X-Spam-Status: No, score=-7.616 tagged_above=-999 required=5 tests=[AWL=1.783, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+LsnRucsLGi for ; Tue, 21 Feb 2012 19:10:29 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F01CB21F864F for ; Tue, 21 Feb 2012 19:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=12503; q=dns/txt; s=iport; t=1329880226; x=1331089826; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iXyV5Q32Pj6DmhZsgP3uzMtjgAJ7EtJT9e7fZYLdDoo=; b=Wcprblth9Fgg1LEvO0EF3h4XEn+Mu2MdetQZodms4+/8tq6OSlTssJGA 0E1y5bSaS5l5kJdctZDhYuKmnFdSRrj/+960UMvld8E9rqb62ZcD/8hXl yTfnhyjZ+5kytx0J3ie13bNMJ6fAgJmyBv1jpFF1n7jGXOUvT3RUnXgCS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHhbRE+rRDoG/2dsb2JhbAA7CA6yTYEHgXMBAQEDAQEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEgBh8JCAEBBAEKCAgTB4deCZkJAZ8SBIh8ZQOCcAEBAQQCCgIOAwZChU0nGhIPgkpjBIhNmAKHHz+BVA X-IronPort-AV: E=Sophos;i="4.73,461,1325462400"; d="scan'208";a="31695166" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 22 Feb 2012 03:10:18 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1M3AGxw011992; Wed, 22 Feb 2012 03:10: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, 22 Feb 2012 08:40:16 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: Bpki GPZj GsdL IFue Iimr IzHR JmCC STr0 Twmp jf59 m5/B sThJ tbwV 6rYd 8FzI ABAc8A==; 6; YQBuAGQAcgBlAHcALgBoAHUAdAB0AG8AbgBAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBqAG8AaABuAC4AcgAuAGUAbAB3AGUAbABsAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBsAGUAbwBuAC4AcABvAHIAdABtAGEAbgBAAG4AaQBjAGUALgBjAG8AbQA7AHAAawB5AHoAaQB2AGEAdABAAGEAbAB1AG0ALgBtAGkAdAAuAGUAZAB1ADsAcAByAGEAdgBpAG4AZAByAGEAbgBAAHMAbwBuAHUAcwBuAGUAdAAuAGMAbwBtADsAcwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {4A506212-57ED-4BC0-A4F1-F413BDFCF9C4}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Wed, 22 Feb 2012 03:10:01 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABJAHMAIABTAEkAUABSAEUAQwAgAG0AZQB0AGEAZABhAHQAYQAgAG0AYQBuAGQAYQB0AG8AcgB5ACAAdABvACAAaQBtAHAAbABlAG0AZQBuAHQAPwA= MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {4A506212-57ED-4BC0-A4F1-F413BDFCF9C4} Content-class: urn:content-classes:message Date: Wed, 22 Feb 2012 08:40:01 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AczwunSIzmCYP9QIQXmR7ugN4sirlAAUtVQA References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> From: "Ram Mohan R (rmohanr)" To: "John Elwell" , "Ravindran, Parthasarathi" , "Charles Eckel (eckelcu)" , "Paul Kyzivat" , "Hutton, Andrew" , "Leon Portman" X-OriginalArrivalTime: 22 Feb 2012 03:10:16.0055 (UTC) FILETIME=[7FF64070:01CCF10F] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 03:10:32 -0000 +1 Yes. That is my concern too as I mentioned in one of the earlier e-mails also. I still prefer to make SIPREC XML metadata as mandatory. The moment we may it optional we will have all proprietary implementations ( for conveying metadata) creeping in and will eventually defeat the purpose of the work we are doing in this Group. Ram > -----Original Message----- > From: John Elwell [mailto:john.r.elwell@gmail.com] > Sent: Tuesday, February 21, 2012 10:31 PM > To: Ravindran, Parthasarathi; Charles Eckel (eckelcu); Ram Mohan R > (rmohanr); Paul Kyzivat; Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >=20 > That is my concern. The proposed option tag would make the bar for > SIPREC > compliance so low that almost any implementation could easily be made > to > comply, and yet the degree of interoperability between such > implementations > would be rather poor. It would be rather like claiming to support SIP > without supporting SDP. >=20 > John >=20 >=20 > -----Original Message----- > From: Ravindran, Parthasarathi > Sent: Tuesday, February 21, 2012 3:41 AM > To: Charles Eckel (eckelcu) ; John Elwell ; Ram Mohan R (rmohanr) ; > Paul > Kyzivat ; Hutton, Andrew > Cc: siprec@ietf.org > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Hi Charles, >=20 > In case we end up with sip.src contact parameter is the only mandatory > for > SIPREC compliance, then I would say that Existing Sonus proprietary > recording already met SIPREC compliance because adding contact header > parameter is a matter of configuration. I'm confident that smart > product > manager in other companies push for the same level of compliance ;-) > This > will result in SIPREC compliance with new proprietary headers/body for > interop with each recording vendor. I'm worried that those kind SIPREC > compliance will not solve the indented problem which we are working > for. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >Sent: Tuesday, February 21, 2012 4:15 AM > >To: Ravindran, Parthasarathi; John Elwell; Ram Mohan R (rmohanr); Paul > >Kyzivat; Hutton, Andrew > >Cc: siprec@ietf.org > >Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > >Hi Partha, > > > >Please see inline. > > > >> -----Original Message----- > >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >> Sent: Friday, February 17, 2012 10:28 AM > >> To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R (rmohanr); > Paul > >> Kyzivat; Hutton, Andrew > >> Cc: siprec@ietf.org > >> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > >> > >> Hi Charles, > >> > >> In case some of the SRS has done your proposed SIPREC migration > >without > >> metadata in the first phase, it will impact SRC SIPREC > implementation > >> as SRC is forced to support SRS proprietary metadata and it is one > of > >> the major issue today in SIP recording. I wish that it will be > solved > >> by SIPREC. > >> > >> Also, I'm seeing with your argument that most of the existing SIP > >based > >> proprietary recording are already compliant with SIPREC in case > option > >> tag only is added because the option tag shall be added through SIP > >> message configuration in the device (no development required :-)). > The > >> requested flexibility in SIPREC provides the opportunity for vendors > >to > >> stick with pre-SIPREC solution and also, the benefit of IETF SIPREC > >> compliance. Could you please look this issue from the "sake of > >> compliance vendor" perspective. > > > >In my proposal, I included the following: > > > >siprec option tag: add to existing definition that it means SIPREC > >metadata is supported > > > >sip.src and sip.srs feature tags: clarify that it does not imply > support > >for SIPREC metadata > > > >Therefore, including the "siprec" option tag means that the metadata > is > >supported. I thought this would address your concern. If not, then > >perhaps I do not completely understand the issue you are highlighting. > > > >Cheers, > >Charles > > > > > >> Thanks > >> Partha > >> > >> >-----Original Message----- > >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf > >> >Of Charles Eckel (eckelcu) > >> >Sent: Friday, February 17, 2012 10:08 PM > >> >To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, > Andrew > >> >Cc: siprec@ietf.org > >> >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >> > > >> >Hi John, > >> > > >> >Good to hear from you, and thanks for keeping us honest on this > one. > >> The > >> >potential benefit I see in have the metadata be optional is with > >> respect > >> >to the migration path from pre-SIPREC solutions to SIPREC > solutions. > >> In > >> >such cases, the SRCs and UAs within a deployment might add support > >for > >> >the SIP/SDP extensions and RTP/RTCP recommendations provided by > >> SIPREC, > >> >but the SRC and/or SRS may support the XML metadata. What if we > were > >> to > >> >do the following? > >> > > >> >siprec option tag: add to existing definition that it means SIPREC > >> >metadata is supported sip.src and sip.srs feature tags: clarify > that > >> it > >> >does not imply support for SIPREC metadata > >> > > >> >In this case, the hybrid SRC that I described could still include > the > >> >sip.src feature tag in its REGISTER and INVITE requests. It would > not > >> >include the siprec option tag as it does not support SIPREC > metadata. > >> If > >> >a SIPREC SRS receives such an INVITE, it has the choice of > rejecting > >> the > >> >INVTIE or accepting it for the purpose of recording using whatever > >> logic > >> >it used prior to SIPREC. > >> >If the SRC supports metadata but does not require it, it can > include > >> the > >> >siprec option tag in a Supported header rather than in a Require > >> header. > >> >The same is true for the SRS. > >> > > >> >Cheers, > >> >Charles > >> > > >> > > >> >> -----Original Message----- > >> >> From: John Elwell [mailto:john.r.elwell@gmail.com] > >> >> Sent: Thursday, February 16, 2012 1:40 AM > >> >> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul Kyzivat; > >> >> Hutton, Andrew > >> >> Cc: siprec@ietf.org > >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >> >> > >> >> I think that XML-based metadata is the essence of SIPREC - other > >> >> protocol additions are peripheral in comparison. We should say > that > >> if > >> >> you > >> >don't > >> >> implement and use XML-based metadata you are not SIPREC- > compliant. > >> >> Trying to > >> >> bend SIP header fields to achieve a poor-man's metadata does not > >> make > >> >> sense, particularly as we know that B2BUAs are all too prone to > >> >> modifying SIP header fields. > >> >> > >> >> John > >> >> > >> >> -----Original Message----- > >> >> From: Ram Mohan R (rmohanr) > >> >> Sent: Thursday, February 16, 2012 6:21 AM > >> >> To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew > >> >> Cc: siprec@ietf.org > >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >> >> > >> >> I see some issues in going with this way: > >> >> > >> >> 1) We will end up in having two different metadata mechanisms - > one > >> >XML > >> >> and one headers based > >> >> > >> >> 2) The existing SIP headers may not be sufficient to carry even > the > >> >> basic metadata ( as partha mentioned in his previous e-mail) and > if > >> we > >> >> are going to add new headers then it is redundant as XML metadata > >> was > >> >> just added for that purpose. > >> >> > >> >> 3) SRC/SRS needs to negotiate on whether they want to use XML > based > >> >> metadata (SIPREC metadata) or Header based metadata and this will > >> lead > >> >> to more issues some of which you already outlined in the below e- > >> mail > >> >> > >> >> So, I feel it's better to stick with one metadata (XML SIPREC > >> >metadata) > >> >> and make it mandatory. > >> >> > >> >> What we can add is some guidelines on how SRS has to behave for > the > >> >> calls where SRC is unable to send metadata or if SRS encounters > an > >> SRC > >> >> that is not completely compliant with SIPREC standards(say does > not > >> >> implement metadata). > >> >> > >> >> Regards, > >> >> Ram > >> >> > >> >> > -----Original Message----- > >> >> > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > >> >> > Behalf Of Charles Eckel (eckelcu) > >> >> > Sent: Wednesday, February 15, 2012 1:19 AM > >> >> > To: Paul Kyzivat; Hutton, Andrew > >> >> > Cc: siprec@ietf.org > >> >> > Subject: Re: [siprec] Is SIPREC metadata mandatory to > implement? > >> >> > > >> >> > Exploring this a bit further, I think this would define a new > >> option > >> >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in a > >> >Supported > >> >> > vs. Required header. In the event metadata is not used between > >the > >> >> SRC > >> >> > and SRS, a well documented set of SIP headers could be used to > >> >convey > >> >> > specific information about the recording. > >> >> > > >> >> > I do see some value in this. If we go this route, the next > >> question > >> >> is, > >> >> > do you mandate support for this SIP headers AND avoid any > overlap > >> >> > between them and the XML metadata? Or do we say that the XML > >> >> metadata, > >> >> > if present, supersedes anything conveyed via the SIP headers? > >> Seeing > >> >> as > >> >> > XML metadata is a key part of SIPREC, I would suspect the > latter, > >> >but > >> >> I > >> >> > am interested to hear what others think. > >> >> > > >> >> > Cheers, > >> >> > Charles > >> >> > > >> >> > > -----Original Message----- > >> >> > > From: siprec-bounces@ietf.org [mailto:siprec- > bounces@ietf.org] > >> On > >> >> > > Behalf Of Paul Kyzivat > >> >> > > Sent: Tuesday, February 14, 2012 11:06 AM > >> >> > > To: Hutton, Andrew > >> >> > > Cc: siprec@ietf.org > >> >> > > Subject: Re: [siprec] Is SIPREC metadata mandatory to > >implement? > >> >> > > > >> >> > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: > >> >> > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: > >> >> > > >> > >> >> > > >> I guess it isn't *necessary* to specify that. But there > are > >> >> > > >> consequences to not doing so: > >> >> > > >> > >> >> > > >> An SRC may have been getting acceptable results not > >> specifying > >> >> > > >> metadata. > >> >> > > >> Then the SRS gets replaced with a different one and > results > >> are > >> >> no > >> >> > > >> longer acceptable because the new one doesn't infer things > >> the > >> >> > same > >> >> > > >> way. > >> >> > > >> > >> >> > > > > >> >> > > > I think we can live with this if metadata is really > important > >> to > >> >> a > >> >> > > solution then the SRC will need to generate SIPREC metadata. > >> >> > > > >> >> > > Maybe. But there is a big hurdle between not supplied > metadata > >> and > >> >> > > supplying it. If the metadata is optional, then its quite > >> possible > >> >> > that > >> >> > > you will have SRCs that just aren't capable of doing so. > (Most > >> >> likely > >> >> > > for some simple cases like a UA that is its own SRC.) > >> >> > > > >> >> > > Then you might get locked in to an SRS that handles that case > >as > >> >> you > >> >> > > like. You will start having proprietary islands if SRCs and > >SRSs > >> >> that > >> >> > > can work together. > >> >> > > > >> >> > > 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 > >> > > >> >_______________________________________________ > >> >siprec mailing list > >> >siprec@ietf.org > >> >https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Wed Feb 22 06:55:01 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C15721F86D8 for ; Wed, 22 Feb 2012 06:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqbreoNUrLDf for ; Wed, 22 Feb 2012 06:55:01 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id DFEF521F8684 for ; Wed, 22 Feb 2012 06:55:00 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 7372D1EB84D7 for ; Wed, 22 Feb 2012 15:54:59 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 22 Feb 2012 15:54:59 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Wed, 22 Feb 2012 15:54:57 +0100 Thread-Topic: protocol draft - Media Stream Updates. Thread-Index: AczxcfHBCEE+74kKTHW0XoXSB3Ji3Q== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] protocol draft - Media Stream Updates. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 14:55:01 -0000 Hi, Section 6.1.1 of the protocol draft states: "To add a recorded stream to the recording session, the SRC sends a new SDP= offer by adding a new media stream description or by reusing an old media = stream which had been previously disabled, according to the procedures in [= RFC3264]". For clarity we probably should say something about the SDP labels that go i= nto the media lines. I assume that once a media line has its port set to zero then the SDP label= that was associated with it is no longer valid and should not be re-used. = When a previously disabled media line is re-used then a new label will be n= eeded. Regards Andy From pkyzivat@alum.mit.edu Wed Feb 22 07:20:22 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF90B21F861C for ; Wed, 22 Feb 2012 07:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1GLzMB19yYL for ; Wed, 22 Feb 2012 07:20:21 -0800 (PST) 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 8203E21F8627 for ; Wed, 22 Feb 2012 07:20:19 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta07.westchester.pa.mail.comcast.net with comcast id d03P1i0011wpRvQ573LKku; Wed, 22 Feb 2012 15:20:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id d3LK1i00A07duvL3e3LKJS; Wed, 22 Feb 2012 15:20:19 +0000 Message-ID: <4F4507B2.4080402@alum.mit.edu> Date: Wed, 22 Feb 2012 10:20:18 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] protocol draft - Media Stream Updates. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 15:20:22 -0000 On 2/22/12 9:54 AM, Hutton, Andrew wrote: > Hi, > > Section 6.1.1 of the protocol draft states: > > "To add a recorded stream to the recording session, the SRC sends a new SDP offer by adding a new media stream description or by reusing an old media stream which had been previously disabled, according to the procedures in [RFC3264]". > > For clarity we probably should say something about the SDP labels that go into the media lines. > > I assume that once a media line has its port set to zero then the SDP label that was associated with it is no longer valid and should not be re-used. When a previously disabled media line is re-used then a new label will be needed. I don't see any particular reason why that needs to be so. IMO the only purpose of the label is to allow a reference from the metadata in a message to an m-line *in the same message*. I see no need for the label to have any broader significance than that. Based on this assumption, it really doesn't matter if the labels are reused or not. Thanks, Paul From andrew.hutton@siemens-enterprise.com Wed Feb 22 08:17:50 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1862521F8827 for ; Wed, 22 Feb 2012 08:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYYMuPPRKGSS for ; Wed, 22 Feb 2012 08:17:45 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id DCEE821F8826 for ; Wed, 22 Feb 2012 08:17:44 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 217F91EB84C9; Wed, 22 Feb 2012 17:17:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 22 Feb 2012 17:17:44 +0100 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Date: Wed, 22 Feb 2012 17:17:43 +0100 Thread-Topic: [siprec] protocol draft - Media Stream Updates. Thread-Index: AczxdYGhCEjHIXdISRaAR6JJH7QieAAA1FFA Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3129422512C@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net> <4F4507B2.4080402@alum.mit.edu> In-Reply-To: <4F4507B2.4080402@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] protocol draft - Media Stream Updates. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 16:17:50 -0000 Is it really the intention that the scope of the label only applies to a si= ngle SIP message? This is not stated in the protocol draft or the metadata draft and the exam= ples in the metadata draft would tend to lead to a different conclusion. If this is the case then I guess that the label attribute in SDP would only= be mandatory in cases where there is relevant metadata to refer to. This i= s also not stated. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 22 February 2012 15:20 > To: siprec@ietf.org > Subject: Re: [siprec] protocol draft - Media Stream Updates. >=20 > On 2/22/12 9:54 AM, Hutton, Andrew wrote: > > Hi, > > > > Section 6.1.1 of the protocol draft states: > > > > "To add a recorded stream to the recording session, the SRC sends a > new SDP offer by adding a new media stream description or by reusing an > old media stream which had been previously disabled, according to the > procedures in [RFC3264]". > > > > For clarity we probably should say something about the SDP labels > that go into the media lines. > > > > I assume that once a media line has its port set to zero then the SDP > label that was associated with it is no longer valid and should not be > re-used. When a previously disabled media line is re-used then a new > label will be needed. >=20 > I don't see any particular reason why that needs to be so. > IMO the only purpose of the label is to allow a reference from the > metadata in a message to an m-line *in the same message*. > I see no need for the label to have any broader significance than that. >=20 > Based on this assumption, it really doesn't matter if the labels are > reused or not. >=20 > Thanks, > Paul > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Wed Feb 22 08:27:20 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9B321F8818 for ; Wed, 22 Feb 2012 08:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7TFSuy2H27i for ; Wed, 22 Feb 2012 08:27:16 -0800 (PST) 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 0F62C21F8805 for ; Wed, 22 Feb 2012 08:27:15 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id d45E1i00B1ap0As554TGx5; Wed, 22 Feb 2012 16:27:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id d4TF1i02Z07duvL3i4TGjG; Wed, 22 Feb 2012 16:27:16 +0000 Message-ID: <4F451762.7030105@alum.mit.edu> Date: Wed, 22 Feb 2012 11:27:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hutton, Andrew" References: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net> <4F4507B2.4080402@alum.mit.edu> <101C6067BEC68246B0C3F6843BCCC1E3129422512C@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E3129422512C@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] protocol draft - Media Stream Updates. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 16:27:20 -0000 On 2/22/12 11:17 AM, Hutton, Andrew wrote: > > Is it really the intention that the scope of the label only applies to a single SIP message? > > This is not stated in the protocol draft or the metadata draft and the examples in the metadata draft would tend to lead to a different conclusion. > > If this is the case then I guess that the label attribute in SDP would only be mandatory in cases where there is relevant metadata to refer to. This is also not stated. This was *my* concept of how it would work. Perhaps others don't see it that way. Lets see what others have to say. Thanks, Paul > Regards > Andy > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 22 February 2012 15:20 >> To: siprec@ietf.org >> Subject: Re: [siprec] protocol draft - Media Stream Updates. >> >> On 2/22/12 9:54 AM, Hutton, Andrew wrote: >>> Hi, >>> >>> Section 6.1.1 of the protocol draft states: >>> >>> "To add a recorded stream to the recording session, the SRC sends a >> new SDP offer by adding a new media stream description or by reusing an >> old media stream which had been previously disabled, according to the >> procedures in [RFC3264]". >>> >>> For clarity we probably should say something about the SDP labels >> that go into the media lines. >>> >>> I assume that once a media line has its port set to zero then the SDP >> label that was associated with it is no longer valid and should not be >> re-used. When a previously disabled media line is re-used then a new >> label will be needed. >> >> I don't see any particular reason why that needs to be so. >> IMO the only purpose of the label is to allow a reference from the >> metadata in a message to an m-line *in the same message*. >> I see no need for the label to have any broader significance than that. >> >> Based on this assumption, it really doesn't matter if the labels are >> reused or not. >> >> Thanks, >> Paul >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > From Henry.Lum@genesyslab.com Wed Feb 22 08:50:07 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B1021F8709 for ; Wed, 22 Feb 2012 08:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsyagyB8scH6 for ; Wed, 22 Feb 2012 08:50:04 -0800 (PST) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 0515A21F86B6 for ; Wed, 22 Feb 2012 08:50:03 -0800 (PST) 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 q1MGo0iZ029691; Wed, 22 Feb 2012 08:50:01 -0800 (PST) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 08:50:01 -0800 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, 22 Feb 2012 08:50:00 -0800 Message-ID: <059AF07365DC474393A19A3AF187DF74082E0E71@NAHALD.us.int.genesyslab.com> In-Reply-To: <4F451762.7030105@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] protocol draft - Media Stream Updates. Thread-Index: AczxfttfXixLobZpQgy3QRn6vQHd2gAAsqKg References: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net><4F4507B2.4080402@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E3129422512C@MCHP058A.global-ad.net> <4F451762.7030105@alum.mit.edu> From: "Henry Lum" To: "Paul Kyzivat" , "Hutton, Andrew" X-OriginalArrivalTime: 22 Feb 2012 16:50:01.0587 (UTC) FILETIME=[04D2D430:01CCF182] Cc: siprec@ietf.org Subject: Re: [siprec] protocol draft - Media Stream Updates. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 16:50:07 -0000 I don't see a reason why you cannot reuse the same label for future uses. As Paul mentioned, I see that the label is local to the metadata in the same SIP message.=20 Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: February-22-12 11:27 AM > To: Hutton, Andrew > Cc: siprec@ietf.org > Subject: Re: [siprec] protocol draft - Media Stream Updates. >=20 > On 2/22/12 11:17 AM, Hutton, Andrew wrote: > > > > Is it really the intention that the scope of the label only applies > to a single SIP message? > > > > This is not stated in the protocol draft or the metadata draft and > the examples in the metadata draft would tend to lead to a different > conclusion. > > > > If this is the case then I guess that the label attribute in SDP > would only be mandatory in cases where there is relevant metadata to > refer to. This is also not stated. >=20 > This was *my* concept of how it would work. > Perhaps others don't see it that way. > Lets see what others have to say. >=20 > Thanks, > Paul >=20 > > Regards > > Andy > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: 22 February 2012 15:20 > >> To: siprec@ietf.org > >> Subject: Re: [siprec] protocol draft - Media Stream Updates. > >> > >> On 2/22/12 9:54 AM, Hutton, Andrew wrote: > >>> Hi, > >>> > >>> Section 6.1.1 of the protocol draft states: > >>> > >>> "To add a recorded stream to the recording session, the SRC sends a > >> new SDP offer by adding a new media stream description or by reusing > an > >> old media stream which had been previously disabled, according to > the > >> procedures in [RFC3264]". > >>> > >>> For clarity we probably should say something about the SDP labels > >> that go into the media lines. > >>> > >>> I assume that once a media line has its port set to zero then the > SDP > >> label that was associated with it is no longer valid and should not > be > >> re-used. When a previously disabled media line is re-used then a new > >> label will be needed. > >> > >> I don't see any particular reason why that needs to be so. > >> IMO the only purpose of the label is to allow a reference from the > >> metadata in a message to an m-line *in the same message*. > >> I see no need for the label to have any broader significance than > that. > >> > >> Based on this assumption, it really doesn't matter if the labels are > >> reused or not. > >> > >> 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 From pravindran@sonusnet.com Wed Feb 22 09:07:36 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64CD21F862F for ; Wed, 22 Feb 2012 09:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDXn6U0KtbhW for ; Wed, 22 Feb 2012 09:07:32 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 917ED21F8619 for ; Wed, 22 Feb 2012 09:07:32 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1MH8H3G020578; Wed, 22 Feb 2012 12:08:17 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 12:07:28 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 22:37:42 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 22:37:42 +0530 From: "Ravindran, Parthasarathi" To: Henry Lum , Paul Kyzivat , "Hutton, Andrew" Thread-Topic: [siprec] protocol draft - Media Stream Updates. Thread-Index: AczxcfHBCEE+74kKTHW0XoXSB3Ji3f//quAAgAAQC4CAAAKpAIAABlwA//+gR6A= Date: Wed, 22 Feb 2012 17:07:41 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04172D@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net><4F4507B2.4080402@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E3129422512C@MCHP058A.global-ad.net> <4F451762.7030105@alum.mit.edu> <059AF07365DC474393A19A3AF187DF74082E0E71@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74082E0E71@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Feb 2012 17:07:42.0747 (UTC) FILETIME=[7D52FEB0:01CCF184] Cc: "siprec@ietf.org" Subject: Re: [siprec] protocol draft - Media Stream Updates. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 17:07:36 -0000 Andy, I agree with Paul that scope of SDP label is within the single SIP message = and it is as per RFC4574. It shall be reused but it is not required to same= . In fact, there is a long discussion initially whether SDP label shall be = used as stream unique id instead of extra URN UUID for stream. The idea of = using label attribute was not accepted because SDP label scope is within th= e given message. Please let us know in case you specific concern here. In case you wish to add the clarity text about label attribute usage, I'm w= ith you because it helps implementers. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Henry Lum >Sent: Wednesday, February 22, 2012 10:20 PM >To: Paul Kyzivat; Hutton, Andrew >Cc: siprec@ietf.org >Subject: Re: [siprec] protocol draft - Media Stream Updates. > >I don't see a reason why you cannot reuse the same label for future >uses. As Paul mentioned, I see that the label is local to the metadata >in the same SIP message. > >Henry > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: February-22-12 11:27 AM >> To: Hutton, Andrew >> Cc: siprec@ietf.org >> Subject: Re: [siprec] protocol draft - Media Stream Updates. >> >> On 2/22/12 11:17 AM, Hutton, Andrew wrote: >> > >> > Is it really the intention that the scope of the label only applies >> to a single SIP message? >> > >> > This is not stated in the protocol draft or the metadata draft and >> the examples in the metadata draft would tend to lead to a different >> conclusion. >> > >> > If this is the case then I guess that the label attribute in SDP >> would only be mandatory in cases where there is relevant metadata to >> refer to. This is also not stated. >> >> This was *my* concept of how it would work. >> Perhaps others don't see it that way. >> Lets see what others have to say. >> >> Thanks, >> Paul >> >> > Regards >> > Andy >> > >> > >> >> -----Original Message----- >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> Behalf Of Paul Kyzivat >> >> Sent: 22 February 2012 15:20 >> >> To: siprec@ietf.org >> >> Subject: Re: [siprec] protocol draft - Media Stream Updates. >> >> >> >> On 2/22/12 9:54 AM, Hutton, Andrew wrote: >> >>> Hi, >> >>> >> >>> Section 6.1.1 of the protocol draft states: >> >>> >> >>> "To add a recorded stream to the recording session, the SRC sends >a >> >> new SDP offer by adding a new media stream description or by >reusing >> an >> >> old media stream which had been previously disabled, according to >> the >> >> procedures in [RFC3264]". >> >>> >> >>> For clarity we probably should say something about the SDP labels >> >> that go into the media lines. >> >>> >> >>> I assume that once a media line has its port set to zero then the >> SDP >> >> label that was associated with it is no longer valid and should not >> be >> >> re-used. When a previously disabled media line is re-used then a >new >> >> label will be needed. >> >> >> >> I don't see any particular reason why that needs to be so. >> >> IMO the only purpose of the label is to allow a reference from the >> >> metadata in a message to an m-line *in the same message*. >> >> I see no need for the label to have any broader significance than >> that. >> >> >> >> Based on this assumption, it really doesn't matter if the labels >are >> >> reused or not. >> >> >> >> 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 eckelcu@cisco.com Wed Feb 22 12:50:35 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27FB21F863E for ; Wed, 22 Feb 2012 12:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.251 X-Spam-Level: X-Spam-Status: No, score=-8.251 tagged_above=-999 required=5 tests=[AWL=1.148, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k96KOeedAR1J for ; Wed, 22 Feb 2012 12:50:33 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8720F21E8014 for ; Wed, 22 Feb 2012 12:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=14911; q=dns/txt; s=iport; t=1329943833; x=1331153433; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+DVSTai+CCLVJAWhxULSXfLMxiDSn7a/kb4tt2kXbPY=; b=HFuEg2hf6W4wCfLBzXPMr4WSmsSTS7iFT5lze3DLPd5Ftxh+5Kw2E/Xi 5ftDOZlzyrP23hklwBKkYzszOmm5W8x/4xjuV4Q5LxxeRA4ObhAH2guji ZstSpSLlqFfKlqPNe3cJcA7E6oWgoV4M7+AVQ6W7JkPyrFqFF8Ds4aosJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPlTRU+rRDoJ/2dsb2JhbAA8CA6yPoEHgXMBAQEDAQEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEgBh8JCAEBBAESCBMHh18JmUQBnnoEiH9lA4JwAQEBBAIKAg4DBkeEZwFgJxoSD4JKYwSIT5gAhx9YgTs X-IronPort-AV: E=Sophos;i="4.73,466,1325462400"; d="scan'208";a="31712497" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 22 Feb 2012 20:50:33 +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 q1MKoWqC008162; Wed, 22 Feb 2012 20:50:32 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, 22 Feb 2012 12:50:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: B38k FA3g UpFu chrc dO/Z eWHZ iMlj jsqV j4Pa qKwj sWmV vNgN v25m 16RY 2+QO 4HWE; 6; YQBuAGQAcgBlAHcALgBoAHUAdAB0AG8AbgBAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBqAG8AaABuAC4AcgAuAGUAbAB3AGUAbABsAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBsAGUAbwBuAC4AcABvAHIAdABtAGEAbgBAAG4AaQBjAGUALgBjAG8AbQA7AHAAawB5AHoAaQB2AGEAdABAAGEAbAB1AG0ALgBtAGkAdAAuAGUAZAB1ADsAcAByAGEAdgBpAG4AZAByAGEAbgBAAHMAbwBuAHUAcwBuAGUAdAAuAGMAbwBtADsAcwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {3F1BAC8A-8AEF-4A11-8002-E2EC9142D02F}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Wed, 22 Feb 2012 20:50:24 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABJAHMAIABTAEkAUABSAEUAQwAgAG0AZQB0AGEAZABhAHQAYQAgAG0AYQBuAGQAYQB0AG8AcgB5ACAAdABvACAAaQBtAHAAbABlAG0AZQBuAHQAPwA= MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {3F1BAC8A-8AEF-4A11-8002-E2EC9142D02F} Content-class: urn:content-classes:message Date: Wed, 22 Feb 2012 12:50:24 -0800 Message-ID: In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AczwunSIzmCYP9QIQXmR7ugN4sirlAAUtVQAACTuBFA= References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><059AF07365DC474393A19A3AF187DF74081CDE3D@NAHALD.us.int.genesyslab.com><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisco .com> From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "John Elwell" , "Ravindran, Parthasarathi" , "Paul Kyzivat" , "Hutton, Andrew" , "Leon Portman" X-OriginalArrivalTime: 22 Feb 2012 20:50:32.0979 (UTC) FILETIME=[9E9A7E30:01CCF1A3] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 20:50:35 -0000 Based on the responses, either my proposal was not clear, or my understanding of the options and feature tags is incorrect, or both. Let me try again. My intention is not to lower the bar for SIPREC compliance. What I propose is: 1) clarify that the "siprec" option tag, in addition to what is already stated, indicates that the XML metadata is supposed. You cannot include the "siprec" option tag in a Supported/Require header unless you support the XML metadata, as it is the essence of SIPREC. 2) all other SIP/SDP extensions defined in the protocol draft (sip.src, sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. There are not tied directly to the "siprec" option tag and may be used without the "siprec" option tag. If an SRC or SRS supports SIPREC XML metadata, it may indicate that by including "siprec" in a Supported header. If an SRC or SRS requires SIPREC XML, it may indicate that by including "siprec" in a Require header. I do not see this as lowering the bar for SIPREC compliance. I do see it as providing benefit for implementations that have no intention of being a SIPREC compliant SRC or SRS. I also see it helping with interworking between SIPREC compliant and non SIPREC compliant entities. Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Tuesday, February 21, 2012 7:10 PM > To: John Elwell; Ravindran, Parthasarathi; Charles Eckel (eckelcu); > Paul Kyzivat; Hutton, Andrew; Leon Portman > Cc: siprec@ietf.org > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >=20 > +1 > Yes. That is my concern too as I mentioned in one of the earlier e- > mails also. > I still prefer to make SIPREC XML metadata as mandatory. The moment we > may it optional we will have all proprietary implementations ( for > conveying metadata) creeping in and will eventually defeat the purpose > of the work we are doing in this Group. >=20 > Ram >=20 > > -----Original Message----- > > From: John Elwell [mailto:john.r.elwell@gmail.com] > > Sent: Tuesday, February 21, 2012 10:31 PM > > To: Ravindran, Parthasarathi; Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); Paul Kyzivat; Hutton, Andrew > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > > That is my concern. The proposed option tag would make the bar for > > SIPREC > > compliance so low that almost any implementation could easily be made > > to > > comply, and yet the degree of interoperability between such > > implementations > > would be rather poor. It would be rather like claiming to support SIP > > without supporting SDP. > > > > John > > > > > > -----Original Message----- > > From: Ravindran, Parthasarathi > > Sent: Tuesday, February 21, 2012 3:41 AM > > To: Charles Eckel (eckelcu) ; John Elwell ; Ram Mohan R (rmohanr) ; > > Paul > > Kyzivat ; Hutton, Andrew > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > > Hi Charles, > > > > In case we end up with sip.src contact parameter is the only > mandatory > > for > > SIPREC compliance, then I would say that Existing Sonus proprietary > > recording already met SIPREC compliance because adding contact header > > parameter is a matter of configuration. I'm confident that smart > > product > > manager in other companies push for the same level of compliance ;-) > > This > > will result in SIPREC compliance with new proprietary headers/body > for > > interop with each recording vendor. I'm worried that those kind > SIPREC > > compliance will not solve the indented problem which we are working > > for. > > > > Thanks > > Partha > > > > >-----Original Message----- > > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > >Sent: Tuesday, February 21, 2012 4:15 AM > > >To: Ravindran, Parthasarathi; John Elwell; Ram Mohan R (rmohanr); > Paul > > >Kyzivat; Hutton, Andrew > > >Cc: siprec@ietf.org > > >Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > > > >Hi Partha, > > > > > >Please see inline. > > > > > >> -----Original Message----- > > >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > > >> Sent: Friday, February 17, 2012 10:28 AM > > >> To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R (rmohanr); > > Paul > > >> Kyzivat; Hutton, Andrew > > >> Cc: siprec@ietf.org > > >> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > >> > > >> Hi Charles, > > >> > > >> In case some of the SRS has done your proposed SIPREC migration > > >without > > >> metadata in the first phase, it will impact SRC SIPREC > > implementation > > >> as SRC is forced to support SRS proprietary metadata and it is one > > of > > >> the major issue today in SIP recording. I wish that it will be > > solved > > >> by SIPREC. > > >> > > >> Also, I'm seeing with your argument that most of the existing SIP > > >based > > >> proprietary recording are already compliant with SIPREC in case > > option > > >> tag only is added because the option tag shall be added through > SIP > > >> message configuration in the device (no development required :-)). > > The > > >> requested flexibility in SIPREC provides the opportunity for > vendors > > >to > > >> stick with pre-SIPREC solution and also, the benefit of IETF > SIPREC > > >> compliance. Could you please look this issue from the "sake of > > >> compliance vendor" perspective. > > > > > >In my proposal, I included the following: > > > > > >siprec option tag: add to existing definition that it means SIPREC > > >metadata is supported > > > > > >sip.src and sip.srs feature tags: clarify that it does not imply > > support > > >for SIPREC metadata > > > > > >Therefore, including the "siprec" option tag means that the metadata > > is > > >supported. I thought this would address your concern. If not, then > > >perhaps I do not completely understand the issue you are > highlighting. > > > > > >Cheers, > > >Charles > > > > > > > > >> Thanks > > >> Partha > > >> > > >> >-----Original Message----- > > >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > >> Behalf > > >> >Of Charles Eckel (eckelcu) > > >> >Sent: Friday, February 17, 2012 10:08 PM > > >> >To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, > > Andrew > > >> >Cc: siprec@ietf.org > > >> >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > >> > > > >> >Hi John, > > >> > > > >> >Good to hear from you, and thanks for keeping us honest on this > > one. > > >> The > > >> >potential benefit I see in have the metadata be optional is with > > >> respect > > >> >to the migration path from pre-SIPREC solutions to SIPREC > > solutions. > > >> In > > >> >such cases, the SRCs and UAs within a deployment might add > support > > >for > > >> >the SIP/SDP extensions and RTP/RTCP recommendations provided by > > >> SIPREC, > > >> >but the SRC and/or SRS may support the XML metadata. What if we > > were > > >> to > > >> >do the following? > > >> > > > >> >siprec option tag: add to existing definition that it means > SIPREC > > >> >metadata is supported sip.src and sip.srs feature tags: clarify > > that > > >> it > > >> >does not imply support for SIPREC metadata > > >> > > > >> >In this case, the hybrid SRC that I described could still include > > the > > >> >sip.src feature tag in its REGISTER and INVITE requests. It would > > not > > >> >include the siprec option tag as it does not support SIPREC > > metadata. > > >> If > > >> >a SIPREC SRS receives such an INVITE, it has the choice of > > rejecting > > >> the > > >> >INVTIE or accepting it for the purpose of recording using > whatever > > >> logic > > >> >it used prior to SIPREC. > > >> >If the SRC supports metadata but does not require it, it can > > include > > >> the > > >> >siprec option tag in a Supported header rather than in a Require > > >> header. > > >> >The same is true for the SRS. > > >> > > > >> >Cheers, > > >> >Charles > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: John Elwell [mailto:john.r.elwell@gmail.com] > > >> >> Sent: Thursday, February 16, 2012 1:40 AM > > >> >> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul > Kyzivat; > > >> >> Hutton, Andrew > > >> >> Cc: siprec@ietf.org > > >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to > implement? > > >> >> > > >> >> I think that XML-based metadata is the essence of SIPREC - > other > > >> >> protocol additions are peripheral in comparison. We should say > > that > > >> if > > >> >> you > > >> >don't > > >> >> implement and use XML-based metadata you are not SIPREC- > > compliant. > > >> >> Trying to > > >> >> bend SIP header fields to achieve a poor-man's metadata does > not > > >> make > > >> >> sense, particularly as we know that B2BUAs are all too prone to > > >> >> modifying SIP header fields. > > >> >> > > >> >> John > > >> >> > > >> >> -----Original Message----- > > >> >> From: Ram Mohan R (rmohanr) > > >> >> Sent: Thursday, February 16, 2012 6:21 AM > > >> >> To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew > > >> >> Cc: siprec@ietf.org > > >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to > implement? > > >> >> > > >> >> I see some issues in going with this way: > > >> >> > > >> >> 1) We will end up in having two different metadata mechanisms - > > one > > >> >XML > > >> >> and one headers based > > >> >> > > >> >> 2) The existing SIP headers may not be sufficient to carry even > > the > > >> >> basic metadata ( as partha mentioned in his previous e-mail) > and > > if > > >> we > > >> >> are going to add new headers then it is redundant as XML > metadata > > >> was > > >> >> just added for that purpose. > > >> >> > > >> >> 3) SRC/SRS needs to negotiate on whether they want to use XML > > based > > >> >> metadata (SIPREC metadata) or Header based metadata and this > will > > >> lead > > >> >> to more issues some of which you already outlined in the below > e- > > >> mail > > >> >> > > >> >> So, I feel it's better to stick with one metadata (XML SIPREC > > >> >metadata) > > >> >> and make it mandatory. > > >> >> > > >> >> What we can add is some guidelines on how SRS has to behave for > > the > > >> >> calls where SRC is unable to send metadata or if SRS encounters > > an > > >> SRC > > >> >> that is not completely compliant with SIPREC standards(say does > > not > > >> >> implement metadata). > > >> >> > > >> >> Regards, > > >> >> Ram > > >> >> > > >> >> > -----Original Message----- > > >> >> > From: siprec-bounces@ietf.org [mailto:siprec- > bounces@ietf.org] > > On > > >> >> > Behalf Of Charles Eckel (eckelcu) > > >> >> > Sent: Wednesday, February 15, 2012 1:19 AM > > >> >> > To: Paul Kyzivat; Hutton, Andrew > > >> >> > Cc: siprec@ietf.org > > >> >> > Subject: Re: [siprec] Is SIPREC metadata mandatory to > > implement? > > >> >> > > > >> >> > Exploring this a bit further, I think this would define a new > > >> option > > >> >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in a > > >> >Supported > > >> >> > vs. Required header. In the event metadata is not used > between > > >the > > >> >> SRC > > >> >> > and SRS, a well documented set of SIP headers could be used > to > > >> >convey > > >> >> > specific information about the recording. > > >> >> > > > >> >> > I do see some value in this. If we go this route, the next > > >> question > > >> >> is, > > >> >> > do you mandate support for this SIP headers AND avoid any > > overlap > > >> >> > between them and the XML metadata? Or do we say that the XML > > >> >> metadata, > > >> >> > if present, supersedes anything conveyed via the SIP headers? > > >> Seeing > > >> >> as > > >> >> > XML metadata is a key part of SIPREC, I would suspect the > > latter, > > >> >but > > >> >> I > > >> >> > am interested to hear what others think. > > >> >> > > > >> >> > Cheers, > > >> >> > Charles > > >> >> > > > >> >> > > -----Original Message----- > > >> >> > > From: siprec-bounces@ietf.org [mailto:siprec- > > bounces@ietf.org] > > >> On > > >> >> > > Behalf Of Paul Kyzivat > > >> >> > > Sent: Tuesday, February 14, 2012 11:06 AM > > >> >> > > To: Hutton, Andrew > > >> >> > > Cc: siprec@ietf.org > > >> >> > > Subject: Re: [siprec] Is SIPREC metadata mandatory to > > >implement? > > >> >> > > > > >> >> > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: > > >> >> > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: > > >> >> > > >> > > >> >> > > >> I guess it isn't *necessary* to specify that. But there > > are > > >> >> > > >> consequences to not doing so: > > >> >> > > >> > > >> >> > > >> An SRC may have been getting acceptable results not > > >> specifying > > >> >> > > >> metadata. > > >> >> > > >> Then the SRS gets replaced with a different one and > > results > > >> are > > >> >> no > > >> >> > > >> longer acceptable because the new one doesn't infer > things > > >> the > > >> >> > same > > >> >> > > >> way. > > >> >> > > >> > > >> >> > > > > > >> >> > > > I think we can live with this if metadata is really > > important > > >> to > > >> >> a > > >> >> > > solution then the SRC will need to generate SIPREC > metadata. > > >> >> > > > > >> >> > > Maybe. But there is a big hurdle between not supplied > > metadata > > >> and > > >> >> > > supplying it. If the metadata is optional, then its quite > > >> possible > > >> >> > that > > >> >> > > you will have SRCs that just aren't capable of doing so. > > (Most > > >> >> likely > > >> >> > > for some simple cases like a UA that is its own SRC.) > > >> >> > > > > >> >> > > Then you might get locked in to an SRS that handles that > case > > >as > > >> >> you > > >> >> > > like. You will start having proprietary islands if SRCs and > > >SRSs > > >> >> that > > >> >> > > can work together. > > >> >> > > > > >> >> > > 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 > > >> > > > >> >_______________________________________________ > > >> >siprec mailing list > > >> >siprec@ietf.org > > >> >https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Wed Feb 22 12:57:42 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5C021E8020 for ; Wed, 22 Feb 2012 12:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0KEjIQAecIP for ; Wed, 22 Feb 2012 12:57:41 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9450A21E800F for ; Wed, 22 Feb 2012 12:57:41 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id d67o1i0031wpRvQ5D8xirW; Wed, 22 Feb 2012 20:57:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id d8xh1i01N07duvL3e8xhQB; Wed, 22 Feb 2012 20:57:41 +0000 Message-ID: <4F4556C4.1070501@alum.mit.edu> Date: Wed, 22 Feb 2012 15:57:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 20:57:42 -0000 Charles, Do you see any case where it would be valid to use sip.src or sip.srs *without* supporting the siprec option tag? Below it sounds like you do, but I don't see how that makes sense. Thanks, Paul On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: > Based on the responses, either my proposal was not clear, or my > understanding of the options and feature tags is incorrect, or both. Let > me try again. > My intention is not to lower the bar for SIPREC compliance. What I > propose is: > > 1) clarify that the "siprec" option tag, in addition to what is already > stated, indicates that the XML metadata is supposed. You cannot include > the "siprec" option tag in a Supported/Require header unless you support > the XML metadata, as it is the essence of SIPREC. > > 2) all other SIP/SDP extensions defined in the protocol draft (sip.src, > sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. There > are not tied directly to the "siprec" option tag and may be used without > the "siprec" option tag. > > If an SRC or SRS supports SIPREC XML metadata, it may indicate that by > including "siprec" in a Supported header. > If an SRC or SRS requires SIPREC XML, it may indicate that by including > "siprec" in a Require header. > > I do not see this as lowering the bar for SIPREC compliance. > I do see it as providing benefit for implementations that have no > intention of being a SIPREC compliant SRC or SRS. > I also see it helping with interworking between SIPREC compliant and non > SIPREC compliant entities. > > Cheers, > Charles From eckelcu@cisco.com Wed Feb 22 13:15:06 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37621F8611 for ; Wed, 22 Feb 2012 13:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.584 X-Spam-Level: X-Spam-Status: No, score=-8.584 tagged_above=-999 required=5 tests=[AWL=1.415, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyHPWIocGc3K for ; Wed, 22 Feb 2012 13:15:05 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0D821F8531 for ; Wed, 22 Feb 2012 13:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2640; q=dns/txt; s=iport; t=1329945305; x=1331154905; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=N1MqZztd7Nsnc7ZKLHhk3mGagqcoauSrffnARkE3TIY=; b=nLD325t2QiqApD1lc4pG8y9zKfzJtnKZxllWdt6VmBNTgUWknfQ7dpLV cKEez3DDr7ztl328+zls2eNLtD9oXh61xT7sHkgL0VpmdA1viLBkyy+Mp /APMxBenU6pvyWndZzVTsHZLR7Ar8MJTclX1b+M1nW/blo2B6vKiAMTkd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMBZRU+rRDoH/2dsb2JhbABEDrJBgQeBcwEBAQQSAR0KPwwEAgEIDgMEAQEBCgYXAQYBRQkIAQEEEwgap1kBlxSMVxURBkcRCAKETAFgPhWCWWMEiE+fH1g X-IronPort-AV: E=Sophos;i="4.73,466,1325462400"; d="scan'208";a="31932350" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 22 Feb 2012 21:15:04 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1MLF4Am018828; Wed, 22 Feb 2012 21:15:04 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 13:15:04 -0800 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, 22 Feb 2012 13:15:03 -0800 Message-ID: In-Reply-To: <4F4556C4.1070501@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AczxpKDZGdY/DE/0S/u1xWrinUdSBwAAUQcw References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.1070501@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" X-OriginalArrivalTime: 22 Feb 2012 21:15:04.0432 (UTC) FILETIME=[0BA86700:01CCF1A7] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 21:15:06 -0000 Hi Paul, An SRC could use it when it registers itself with a call control server, or when it sends/receives a SIP INVITE to/from an UA/MCU to join a call. This way the UA/MCU knows it has the ability to request specific media streams within the SIP dialog between it and the SRC be recorded using the recording-pref attribute. How the SRC accomplishes this is likely not important to the UA/MCU. The SRC indicates that it is recording using the record attribute. The record-aware option tag could be leveraged her as well. Cheers, Charles =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, February 22, 2012 12:58 PM > To: Charles Eckel (eckelcu) > Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; > Hutton, Andrew; Leon Portman; siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Charles, >=20 > Do you see any case where it would be valid to use sip.src or sip.srs > *without* supporting the siprec option tag? >=20 > Below it sounds like you do, but I don't see how that makes sense. >=20 > Thanks, > Paul >=20 > On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: > > Based on the responses, either my proposal was not clear, or my > > understanding of the options and feature tags is incorrect, or both. > Let > > me try again. > > My intention is not to lower the bar for SIPREC compliance. What I > > propose is: > > > > 1) clarify that the "siprec" option tag, in addition to what is > already > > stated, indicates that the XML metadata is supposed. You cannot > include > > the "siprec" option tag in a Supported/Require header unless you > support > > the XML metadata, as it is the essence of SIPREC. > > > > 2) all other SIP/SDP extensions defined in the protocol draft > (sip.src, > > sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. > There > > are not tied directly to the "siprec" option tag and may be used > without > > the "siprec" option tag. > > > > If an SRC or SRS supports SIPREC XML metadata, it may indicate that > by > > including "siprec" in a Supported header. > > If an SRC or SRS requires SIPREC XML, it may indicate that by > including > > "siprec" in a Require header. > > > > I do not see this as lowering the bar for SIPREC compliance. > > I do see it as providing benefit for implementations that have no > > intention of being a SIPREC compliant SRC or SRS. > > I also see it helping with interworking between SIPREC compliant and > non > > SIPREC compliant entities. > > > > Cheers, > > Charles From andrew.hutton@siemens-enterprise.com Wed Feb 22 13:21:00 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD46221F8623 for ; Wed, 22 Feb 2012 13:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUrrOXDBGTZt for ; Wed, 22 Feb 2012 13:21:00 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 945C721F84EE for ; Wed, 22 Feb 2012 13:20:59 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id A0C7323F0483; Wed, 22 Feb 2012 22:20:58 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 22 Feb 2012 22:20:58 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Henry Lum , Paul Kyzivat Date: Wed, 22 Feb 2012 22:20:57 +0100 Thread-Topic: [siprec] protocol draft - Media Stream Updates. Thread-Index: AczxcfHBCEE+74kKTHW0XoXSB3Ji3f//quAAgAAQC4CAAAKpAIAABlwA//+gR6D//vkn8A== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312944813E6@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net><4F4507B2.4080402@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E3129422512C@MCHP058A.global-ad.net> <4F451762.7030105@alum.mit.edu> <059AF07365DC474393A19A3AF187DF74082E0E71@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04172D@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E04172D@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] protocol draft - Media Stream Updates. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 21:21:00 -0000 Ok I have no objections to the label scope being limited to the metadata ca= rried in the same SIP message as the SDP but we do need to make that very c= lear in I think both the protocol and metadata draft. At present it the scope does not seem clearly specified to me. Regards Andy > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 22 February 2012 17:08 > To: Henry Lum; Paul Kyzivat; Hutton, Andrew > Cc: siprec@ietf.org > Subject: RE: [siprec] protocol draft - Media Stream Updates. >=20 > Andy, >=20 > I agree with Paul that scope of SDP label is within the single SIP > message and it is as per RFC4574. It shall be reused but it is not > required to same. In fact, there is a long discussion initially whether > SDP label shall be used as stream unique id instead of extra URN UUID > for stream. The idea of using label attribute was not accepted because > SDP label scope is within the given message. Please let us know in case > you specific concern here. >=20 > In case you wish to add the clarity text about label attribute usage, > I'm with you because it helps implementers. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Henry Lum > >Sent: Wednesday, February 22, 2012 10:20 PM > >To: Paul Kyzivat; Hutton, Andrew > >Cc: siprec@ietf.org > >Subject: Re: [siprec] protocol draft - Media Stream Updates. > > > >I don't see a reason why you cannot reuse the same label for future > >uses. As Paul mentioned, I see that the label is local to the metadata > >in the same SIP message. > > > >Henry > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: February-22-12 11:27 AM > >> To: Hutton, Andrew > >> Cc: siprec@ietf.org > >> Subject: Re: [siprec] protocol draft - Media Stream Updates. > >> > >> On 2/22/12 11:17 AM, Hutton, Andrew wrote: > >> > > >> > Is it really the intention that the scope of the label only > applies > >> to a single SIP message? > >> > > >> > This is not stated in the protocol draft or the metadata draft and > >> the examples in the metadata draft would tend to lead to a different > >> conclusion. > >> > > >> > If this is the case then I guess that the label attribute in SDP > >> would only be mandatory in cases where there is relevant metadata to > >> refer to. This is also not stated. > >> > >> This was *my* concept of how it would work. > >> Perhaps others don't see it that way. > >> Lets see what others have to say. > >> > >> Thanks, > >> Paul > >> > >> > Regards > >> > Andy > >> > > >> > > >> >> -----Original Message----- > >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> >> Behalf Of Paul Kyzivat > >> >> Sent: 22 February 2012 15:20 > >> >> To: siprec@ietf.org > >> >> Subject: Re: [siprec] protocol draft - Media Stream Updates. > >> >> > >> >> On 2/22/12 9:54 AM, Hutton, Andrew wrote: > >> >>> Hi, > >> >>> > >> >>> Section 6.1.1 of the protocol draft states: > >> >>> > >> >>> "To add a recorded stream to the recording session, the SRC > sends > >a > >> >> new SDP offer by adding a new media stream description or by > >reusing > >> an > >> >> old media stream which had been previously disabled, according to > >> the > >> >> procedures in [RFC3264]". > >> >>> > >> >>> For clarity we probably should say something about the SDP > labels > >> >> that go into the media lines. > >> >>> > >> >>> I assume that once a media line has its port set to zero then > the > >> SDP > >> >> label that was associated with it is no longer valid and should > not > >> be > >> >> re-used. When a previously disabled media line is re-used then a > >new > >> >> label will be needed. > >> >> > >> >> I don't see any particular reason why that needs to be so. > >> >> IMO the only purpose of the label is to allow a reference from > the > >> >> metadata in a message to an m-line *in the same message*. > >> >> I see no need for the label to have any broader significance than > >> that. > >> >> > >> >> Based on this assumption, it really doesn't matter if the labels > >are > >> >> reused or not. > >> >> > >> >> 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 eckelcu@cisco.com Wed Feb 22 13:22:46 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9330B21E8018 for ; Wed, 22 Feb 2012 13:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.325 X-Spam-Level: X-Spam-Status: No, score=-8.325 tagged_above=-999 required=5 tests=[AWL=1.074, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cex1gryHVrhC for ; Wed, 22 Feb 2012 13:22:44 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D9E0121F8650 for ; Wed, 22 Feb 2012 13:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=378; q=dns/txt; s=iport; t=1329945764; x=1331155364; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=k0k2ppiSm3K/vQnMvuMUWnKqHHw9/FssZbdzVtm/kOg=; b=HY6sMdr03ZlVzNn4SrXz6V0u1NHergtC1hCrVnwiFpKZGVKFD99lJqVA L6eZxiFoRP4ciqXcJBauiRdlpzolO+xjFv16swvrT3FQaX+DBH6jAu3DV b+oRLP2B6iwjW+RT+gOOLrKZ//JJBMq8e6CHngeGtYu6PW8I7BvLDYOVG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGRcRU+rRDoG/2dsb2JhbABEsk+BB4F1AQQSAR0KUQEqBhgHVwEEGxqmNIEnAZcSjGgNDkcRAgECAQIChEwBgVGCO2MEiE+fdw X-IronPort-AV: E=Sophos;i="4.73,466,1325462400"; d="scan'208";a="31718243" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 22 Feb 2012 21:22:43 +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 q1MLMhUt021058 for ; Wed, 22 Feb 2012 21:22:43 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, 22 Feb 2012 13:22:43 -0800 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, 22 Feb 2012 13:22:42 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: recordpref and record SDP attributes Thread-Index: AczxqBzrXscnPkYrTqmPlfkBFrvdBA== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 22 Feb 2012 21:22:43.0826 (UTC) FILETIME=[1D7A5D20:01CCF1A8] Subject: [siprec] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 21:22:46 -0000 My assumption is that these SDP attributes, when used at the session or media level, apply to the media as stated by the media mode attribute, meaning that if the mode is "sendrecv", recordpref=3Don is a request to record both the media being sent to as well as the media being received by the requestor. Similarly for record=3Don. Is that correct? Thanks, Charles=20 From pkyzivat@alum.mit.edu Wed Feb 22 13:34:31 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2EB21F84F6 for ; Wed, 22 Feb 2012 13:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9zMa0AOo8Dy for ; Wed, 22 Feb 2012 13:34:30 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id AE16721F84F5 for ; Wed, 22 Feb 2012 13:34:30 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta15.westchester.pa.mail.comcast.net with comcast id d9FZ1i0010bG4ec5F9aXm8; Wed, 22 Feb 2012 21:34:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta03.westchester.pa.mail.comcast.net with comcast id d9aW1i00S07duvL3P9aWgm; Wed, 22 Feb 2012 21:34:31 +0000 Message-ID: <4F455F65.9050204@alum.mit.edu> Date: Wed, 22 Feb 2012 16:34:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.1070501@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] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2012 21:34:31 -0000 On 2/22/12 4:15 PM, Charles Eckel (eckelcu) wrote: > Hi Paul, > > An SRC could use it when it registers itself with a call control server, > or when it sends/receives a SIP INVITE to/from an UA/MCU to join a call. > This way the UA/MCU knows it has the ability to request specific media > streams within the SIP dialog between it and the SRC be recorded using > the recording-pref attribute. How the SRC accomplishes this is likely > not important to the UA/MCU. The SRC indicates that it is recording > using the record attribute. The record-aware option tag could be > leveraged her as well. OK, now I understand, and it does seem to make sense. Thanks, Paul > Cheers, > Charles > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Wednesday, February 22, 2012 12:58 PM >> To: Charles Eckel (eckelcu) >> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; >> Hutton, Andrew; Leon Portman; siprec@ietf.org >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> Charles, >> >> Do you see any case where it would be valid to use sip.src or sip.srs >> *without* supporting the siprec option tag? >> >> Below it sounds like you do, but I don't see how that makes sense. >> >> Thanks, >> Paul >> >> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: >>> Based on the responses, either my proposal was not clear, or my >>> understanding of the options and feature tags is incorrect, or both. >> Let >>> me try again. >>> My intention is not to lower the bar for SIPREC compliance. What I >>> propose is: >>> >>> 1) clarify that the "siprec" option tag, in addition to what is >> already >>> stated, indicates that the XML metadata is supposed. You cannot >> include >>> the "siprec" option tag in a Supported/Require header unless you >> support >>> the XML metadata, as it is the essence of SIPREC. >>> >>> 2) all other SIP/SDP extensions defined in the protocol draft >> (sip.src, >>> sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. >> There >>> are not tied directly to the "siprec" option tag and may be used >> without >>> the "siprec" option tag. >>> >>> If an SRC or SRS supports SIPREC XML metadata, it may indicate that >> by >>> including "siprec" in a Supported header. >>> If an SRC or SRS requires SIPREC XML, it may indicate that by >> including >>> "siprec" in a Require header. >>> >>> I do not see this as lowering the bar for SIPREC compliance. >>> I do see it as providing benefit for implementations that have no >>> intention of being a SIPREC compliant SRC or SRS. >>> I also see it helping with interworking between SIPREC compliant and >> non >>> SIPREC compliant entities. >>> >>> Cheers, >>> Charles > From pravindran@sonusnet.com Wed Feb 22 16:03:16 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8E321F8577 for ; Wed, 22 Feb 2012 16:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k06uRVZMh7p for ; Wed, 22 Feb 2012 16:03:15 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8B21F8575 for ; Wed, 22 Feb 2012 16:03:14 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1N03wHb000681; Wed, 22 Feb 2012 19:03:59 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 19:02:52 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 05:33:07 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 05:33:06 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Henry Lum , Paul Kyzivat Thread-Topic: [siprec] protocol draft - Media Stream Updates. Thread-Index: AczxcfHBCEE+74kKTHW0XoXSB3Ji3f//quAAgAAQC4CAAAKpAIAABlwA//+gR6D//vkn8P/9xS+A Date: Thu, 23 Feb 2012 00:03:05 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E041849@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net><4F4507B2.4080402@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E3129422512C@MCHP058A.global-ad.net> <4F451762.7030105@alum.mit.edu> <059AF07365DC474393A19A3AF187DF74082E0E71@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04172D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312944813E6@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312944813E6@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2012 00:03:07.0103 (UTC) FILETIME=[8565E6F0:01CCF1BE] Cc: "siprec@ietf.org" Subject: Re: [siprec] protocol draft - Media Stream Updates. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 00:03:16 -0000 Hi Andy, Thanks for the closure. We'll update metadata draft with the scope of label= attribute. Thanks Partha=20 >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Thursday, February 23, 2012 2:51 AM >To: Ravindran, Parthasarathi; Henry Lum; Paul Kyzivat >Cc: siprec@ietf.org >Subject: RE: [siprec] protocol draft - Media Stream Updates. > >Ok I have no objections to the label scope being limited to the metadata >carried in the same SIP message as the SDP but we do need to make that >very clear in I think both the protocol and metadata draft. > >At present it the scope does not seem clearly specified to me. > >Regards >Andy > > > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 22 February 2012 17:08 >> To: Henry Lum; Paul Kyzivat; Hutton, Andrew >> Cc: siprec@ietf.org >> Subject: RE: [siprec] protocol draft - Media Stream Updates. >> >> Andy, >> >> I agree with Paul that scope of SDP label is within the single SIP >> message and it is as per RFC4574. It shall be reused but it is not >> required to same. In fact, there is a long discussion initially >> whether SDP label shall be used as stream unique id instead of extra >> URN UUID for stream. The idea of using label attribute was not >> accepted because SDP label scope is within the given message. Please >> let us know in case you specific concern here. >> >> In case you wish to add the clarity text about label attribute usage, >> I'm with you because it helps implementers. >> >> Thanks >> Partha >> >> >-----Original Message----- >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >> >Of Henry Lum >> >Sent: Wednesday, February 22, 2012 10:20 PM >> >To: Paul Kyzivat; Hutton, Andrew >> >Cc: siprec@ietf.org >> >Subject: Re: [siprec] protocol draft - Media Stream Updates. >> > >> >I don't see a reason why you cannot reuse the same label for future >> >uses. As Paul mentioned, I see that the label is local to the >> >metadata in the same SIP message. >> > >> >Henry >> > >> >> -----Original Message----- >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> Behalf Of Paul Kyzivat >> >> Sent: February-22-12 11:27 AM >> >> To: Hutton, Andrew >> >> Cc: siprec@ietf.org >> >> Subject: Re: [siprec] protocol draft - Media Stream Updates. >> >> >> >> On 2/22/12 11:17 AM, Hutton, Andrew wrote: >> >> > >> >> > Is it really the intention that the scope of the label only >> applies >> >> to a single SIP message? >> >> > >> >> > This is not stated in the protocol draft or the metadata draft >> >> > and >> >> the examples in the metadata draft would tend to lead to a >> >> different conclusion. >> >> > >> >> > If this is the case then I guess that the label attribute in SDP >> >> would only be mandatory in cases where there is relevant metadata >> >> to refer to. This is also not stated. >> >> >> >> This was *my* concept of how it would work. >> >> Perhaps others don't see it that way. >> >> Lets see what others have to say. >> >> >> >> Thanks, >> >> Paul >> >> >> >> > Regards >> >> > Andy >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] >> >> >> On Behalf Of Paul Kyzivat >> >> >> Sent: 22 February 2012 15:20 >> >> >> To: siprec@ietf.org >> >> >> Subject: Re: [siprec] protocol draft - Media Stream Updates. >> >> >> >> >> >> On 2/22/12 9:54 AM, Hutton, Andrew wrote: >> >> >>> Hi, >> >> >>> >> >> >>> Section 6.1.1 of the protocol draft states: >> >> >>> >> >> >>> "To add a recorded stream to the recording session, the SRC >> sends >> >a >> >> >> new SDP offer by adding a new media stream description or by >> >reusing >> >> an >> >> >> old media stream which had been previously disabled, according >> >> >> to >> >> the >> >> >> procedures in [RFC3264]". >> >> >>> >> >> >>> For clarity we probably should say something about the SDP >> labels >> >> >> that go into the media lines. >> >> >>> >> >> >>> I assume that once a media line has its port set to zero then >> the >> >> SDP >> >> >> label that was associated with it is no longer valid and should >> not >> >> be >> >> >> re-used. When a previously disabled media line is re-used then a >> >new >> >> >> label will be needed. >> >> >> >> >> >> I don't see any particular reason why that needs to be so. >> >> >> IMO the only purpose of the label is to allow a reference from >> the >> >> >> metadata in a message to an m-line *in the same message*. >> >> >> I see no need for the label to have any broader significance >> >> >> than >> >> that. >> >> >> >> >> >> Based on this assumption, it really doesn't matter if the labels >> >are >> >> >> reused or not. >> >> >> >> >> >> 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 pravindran@sonusnet.com Wed Feb 22 17:09:15 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970DD21F84CE for ; Wed, 22 Feb 2012 17:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8Otmc4Z4oGl for ; Wed, 22 Feb 2012 17:09:15 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id EEA1121F84C4 for ; Wed, 22 Feb 2012 17:09:12 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1N19u51011089; Wed, 22 Feb 2012 20:09:56 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 20:09:08 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 06:39:22 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 06:39:21 +0530 From: "Ravindran, Parthasarathi" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Thread-Topic: recordpref and record SDP attributes Thread-Index: AczxqBzrXscnPkYrTqmPlfkBFrvdBAAHA5Lw Date: Thu, 23 Feb 2012 01:09:21 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E0418B0@inba-mail01.sonusnet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2012 01:09:22.0628 (UTC) FILETIME=[C6FEE040:01CCF1C7] Subject: Re: [siprec] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 01:09:15 -0000 Hi Charles, I got the same doubt by looking at your proposed usage in the another mail thread. Till now, I'm seeing recordpref attribute as an declarative=20 SDP attribute wherein SRC comes to know whether media stream has to be=20 recorded based on its policy. However, your proposal is to use this=20 attribute for negotiation (offer/answer). The topology in my mind is=20 UA1 ----B2BUA (SRC) ----UA2 IMO, Recordpref offer/answer combination in B2BUA with UA1 as offerer and=20 UA2 as answerer are as follows:=20 UA1 UA2 B2BUA/SRC On Off Off Off On Off Off Off Off On On On=20 Empty Off Off Empty On On On Empty On Off Empty Off Empty Empty On =20 The last row "On" indicates that both parties agrees for recording and it i= s upto SRC to decide whether recording has to be done or not. Empty indicates= the absence of this attribute in SDP. Please correct me in case I misunderstand= =20 about this SDP attribute. Thanks Partha =20 >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Charles Eckel (eckelcu) >Sent: Thursday, February 23, 2012 2:53 AM >To: siprec@ietf.org >Subject: [siprec] recordpref and record SDP attributes > >My assumption is that these SDP attributes, when used at the session or >media level, apply to the media as stated by the media mode attribute, >meaning that if the mode is "sendrecv", recordpref=3Don is a request to >record both the media being sent to as well as the media being received >by the requestor. Similarly for record=3Don. >Is that correct? > >Thanks, >Charles >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Wed Feb 22 17:57:39 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028FA21F8534 for ; Wed, 22 Feb 2012 17:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwBIS14N3s5U for ; Wed, 22 Feb 2012 17:57:38 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3256A21F8531 for ; Wed, 22 Feb 2012 17:57:38 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1N1wMlA010839; Wed, 22 Feb 2012 20:58:22 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 20:48:30 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 07:18:44 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 07:18:43 +0530 From: "Ravindran, Parthasarathi" To: "Charles Eckel (eckelcu)" , Paul Kyzivat Thread-Topic: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?] Thread-Index: AQHM8c1FGYhD9DGhCESahXQz/mAjlw== Date: Thu, 23 Feb 2012 01:48:42 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.1070501@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2012 01:48:44.0721 (UTC) FILETIME=[46E9AA10:01CCF1CD] Cc: "siprec@ietf.org" Subject: [siprec] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 01:57:39 -0000 Hi Charles, Thanks for the clarification. I understand that we are talking about two different stuff. So, I have changed the subject of the mail as "Is SIPREC metadata mandatory to implement in Recording Session(RS)".=20 Hi all, Till now, I have not seen anybody has objection for supporting SIRPEC=20 metadata in RS. Please correct me in case my understanding is wrong. Also, I propose to change the following normative statement from "SHOULD" To "MUST" in recording session: "An SRC SHOULD include the "siprec" option tag in the Require header when=20 initiating a Recording Session so that other types of user agents can=20 simply reject the INVITE request with a 420 Bad Extension." as "An SRC MUST include the "siprec" option tag in the Require header when=20 initiating a Recording Session so that other types of user agents can=20 simply reject the INVITE request with a 420 Bad Extension." Please let me know your opinion on the same. Thanks Partha >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Thursday, February 23, 2012 2:45 AM >To: Paul Kyzivat >Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; >Hutton, Andrew; Leon Portman; siprec@ietf.org >Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > >Hi Paul, > >An SRC could use it when it registers itself with a call control server, >or when it sends/receives a SIP INVITE to/from an UA/MCU to join a call. >This way the UA/MCU knows it has the ability to request specific media >streams within the SIP dialog between it and the SRC be recorded using >the recording-pref attribute. How the SRC accomplishes this is likely >not important to the UA/MCU. The SRC indicates that it is recording >using the record attribute. The record-aware option tag could be >leveraged her as well. > >Cheers, >Charles > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Wednesday, February 22, 2012 12:58 PM >> To: Charles Eckel (eckelcu) >> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; >> Hutton, Andrew; Leon Portman; siprec@ietf.org >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >> Charles, >> >> Do you see any case where it would be valid to use sip.src or sip.srs >> *without* supporting the siprec option tag? >> >> Below it sounds like you do, but I don't see how that makes sense. >> >> Thanks, >> Paul >> >> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: >> > Based on the responses, either my proposal was not clear, or my >> > understanding of the options and feature tags is incorrect, or both. >> Let >> > me try again. >> > My intention is not to lower the bar for SIPREC compliance. What I >> > propose is: >> > >> > 1) clarify that the "siprec" option tag, in addition to what is >> already >> > stated, indicates that the XML metadata is supposed. You cannot >> include >> > the "siprec" option tag in a Supported/Require header unless you >> support >> > the XML metadata, as it is the essence of SIPREC. >> > >> > 2) all other SIP/SDP extensions defined in the protocol draft >> (sip.src, >> > sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. >> There >> > are not tied directly to the "siprec" option tag and may be used >> without >> > the "siprec" option tag. >> > >> > If an SRC or SRS supports SIPREC XML metadata, it may indicate that >> by >> > including "siprec" in a Supported header. >> > If an SRC or SRS requires SIPREC XML, it may indicate that by >> including >> > "siprec" in a Require header. >> > >> > I do not see this as lowering the bar for SIPREC compliance. >> > I do see it as providing benefit for implementations that have no >> > intention of being a SIPREC compliant SRC or SRS. >> > I also see it helping with interworking between SIPREC compliant and >> non >> > SIPREC compliant entities. >> > >> > Cheers, >> > Charles From john.r.elwell@gmail.com Wed Feb 22 23:37:56 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8089D21E8027 for ; Wed, 22 Feb 2012 23:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE9I1oLB-mEU for ; Wed, 22 Feb 2012 23:37:55 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9C121E8016 for ; Wed, 22 Feb 2012 23:37:54 -0800 (PST) Received: by werg1 with SMTP id g1so695219wer.31 for ; Wed, 22 Feb 2012 23:37:53 -0800 (PST) Received-SPF: pass (google.com: domain of john.r.elwell@gmail.com designates 10.180.80.35 as permitted sender) client-ip=10.180.80.35; Authentication-Results: mr.google.com; spf=pass (google.com: domain of john.r.elwell@gmail.com designates 10.180.80.35 as permitted sender) smtp.mail=john.r.elwell@gmail.com; dkim=pass header.i=john.r.elwell@gmail.com Received: from mr.google.com ([10.180.80.35]) by 10.180.80.35 with SMTP id o3mr121283wix.5.1329982673894 (num_hops = 1); Wed, 22 Feb 2012 23:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole; bh=gqq6xNXjFghNabJaHWx6q/bc9KX7Ko+Nx56ATuqMD7w=; b=m2Re911epadxKh0zprxqZjesO8zjs0qxCy/jGThdEjS99eG/friI9vT+HXAqNd+VEn 7tZeMyARG52vasMSGwronxZi3ERFpM90zPCL/CS9s+RoOwGuDDlms/IIoWcynhvnO/lT Rrgx7bQlcVQfy19HlGpjzxDa+PzxCqLf/Ghpo= Received: by 10.180.80.35 with SMTP id o3mr95649wix.5.1329982673793; Wed, 22 Feb 2012 23:37:53 -0800 (PST) Received: from Acer (cpc1-clif8-2-0-cust418.12-4.cable.virginmedia.com. [82.25.209.163]) by mx.google.com with ESMTPS id fl2sm2817783wib.4.2012.02.22.23.37.51 (version=SSLv3 cipher=OTHER); Wed, 22 Feb 2012 23:37:52 -0800 (PST) Message-ID: <957AB983462E43BBBDAE5C77122D7E54@Acer> From: "John Elwell" To: "Charles Eckel \(eckelcu\)" , "Ram Mohan R \(rmohanr\)" , "Ravindran, Parthasarathi" , "Paul Kyzivat" , "Hutton, Andrew" , "Leon Portman" References: <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisco.com> In-Reply-To: Date: Thu, 23 Feb 2012 07:37:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MIMEOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 07:37:56 -0000 Charles, Thanks for the clarification. I don't see any harm in the option tag. My desire is that if you claim to support SIPREC (i.e., support the protocol RFC) you MUST also support XML metadata. John -----Original Message----- From: Charles Eckel (eckelcu) Sent: Wednesday, February 22, 2012 8:50 PM To: Ram Mohan R (rmohanr) ; John Elwell ; Ravindran, Parthasarathi ; Paul Kyzivat ; Hutton, Andrew ; Leon Portman Cc: siprec@ietf.org Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? Based on the responses, either my proposal was not clear, or my understanding of the options and feature tags is incorrect, or both. Let me try again. My intention is not to lower the bar for SIPREC compliance. What I propose is: 1) clarify that the "siprec" option tag, in addition to what is already stated, indicates that the XML metadata is supposed. You cannot include the "siprec" option tag in a Supported/Require header unless you support the XML metadata, as it is the essence of SIPREC. 2) all other SIP/SDP extensions defined in the protocol draft (sip.src, sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. There are not tied directly to the "siprec" option tag and may be used without the "siprec" option tag. If an SRC or SRS supports SIPREC XML metadata, it may indicate that by including "siprec" in a Supported header. If an SRC or SRS requires SIPREC XML, it may indicate that by including "siprec" in a Require header. I do not see this as lowering the bar for SIPREC compliance. I do see it as providing benefit for implementations that have no intention of being a SIPREC compliant SRC or SRS. I also see it helping with interworking between SIPREC compliant and non SIPREC compliant entities. Cheers, Charles > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Tuesday, February 21, 2012 7:10 PM > To: John Elwell; Ravindran, Parthasarathi; Charles Eckel (eckelcu); > Paul Kyzivat; Hutton, Andrew; Leon Portman > Cc: siprec@ietf.org > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > +1 > Yes. That is my concern too as I mentioned in one of the earlier e- > mails also. > I still prefer to make SIPREC XML metadata as mandatory. The moment we > may it optional we will have all proprietary implementations ( for > conveying metadata) creeping in and will eventually defeat the purpose > of the work we are doing in this Group. > > Ram > > > -----Original Message----- > > From: John Elwell [mailto:john.r.elwell@gmail.com] > > Sent: Tuesday, February 21, 2012 10:31 PM > > To: Ravindran, Parthasarathi; Charles Eckel (eckelcu); Ram Mohan R > > (rmohanr); Paul Kyzivat; Hutton, Andrew > > Cc: siprec@ietf.org > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > > That is my concern. The proposed option tag would make the bar for > > SIPREC > > compliance so low that almost any implementation could easily be made > > to > > comply, and yet the degree of interoperability between such > > implementations > > would be rather poor. It would be rather like claiming to support SIP > > without supporting SDP. > > > > John > > > > > > -----Original Message----- > > From: Ravindran, Parthasarathi > > Sent: Tuesday, February 21, 2012 3:41 AM > > To: Charles Eckel (eckelcu) ; John Elwell ; Ram Mohan R (rmohanr) ; > > Paul > > Kyzivat ; Hutton, Andrew > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > > Hi Charles, > > > > In case we end up with sip.src contact parameter is the only > mandatory > > for > > SIPREC compliance, then I would say that Existing Sonus proprietary > > recording already met SIPREC compliance because adding contact header > > parameter is a matter of configuration. I'm confident that smart > > product > > manager in other companies push for the same level of compliance ;-) > > This > > will result in SIPREC compliance with new proprietary headers/body > for > > interop with each recording vendor. I'm worried that those kind > SIPREC > > compliance will not solve the indented problem which we are working > > for. > > > > Thanks > > Partha > > > > >-----Original Message----- > > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > >Sent: Tuesday, February 21, 2012 4:15 AM > > >To: Ravindran, Parthasarathi; John Elwell; Ram Mohan R (rmohanr); > Paul > > >Kyzivat; Hutton, Andrew > > >Cc: siprec@ietf.org > > >Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > > > >Hi Partha, > > > > > >Please see inline. > > > > > >> -----Original Message----- > > >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > > >> Sent: Friday, February 17, 2012 10:28 AM > > >> To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R (rmohanr); > > Paul > > >> Kyzivat; Hutton, Andrew > > >> Cc: siprec@ietf.org > > >> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > >> > > >> Hi Charles, > > >> > > >> In case some of the SRS has done your proposed SIPREC migration > > >without > > >> metadata in the first phase, it will impact SRC SIPREC > > implementation > > >> as SRC is forced to support SRS proprietary metadata and it is one > > of > > >> the major issue today in SIP recording. I wish that it will be > > solved > > >> by SIPREC. > > >> > > >> Also, I'm seeing with your argument that most of the existing SIP > > >based > > >> proprietary recording are already compliant with SIPREC in case > > option > > >> tag only is added because the option tag shall be added through > SIP > > >> message configuration in the device (no development required :-)). > > The > > >> requested flexibility in SIPREC provides the opportunity for > vendors > > >to > > >> stick with pre-SIPREC solution and also, the benefit of IETF > SIPREC > > >> compliance. Could you please look this issue from the "sake of > > >> compliance vendor" perspective. > > > > > >In my proposal, I included the following: > > > > > >siprec option tag: add to existing definition that it means SIPREC > > >metadata is supported > > > > > >sip.src and sip.srs feature tags: clarify that it does not imply > > support > > >for SIPREC metadata > > > > > >Therefore, including the "siprec" option tag means that the metadata > > is > > >supported. I thought this would address your concern. If not, then > > >perhaps I do not completely understand the issue you are > highlighting. > > > > > >Cheers, > > >Charles > > > > > > > > >> Thanks > > >> Partha > > >> > > >> >-----Original Message----- > > >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > >> Behalf > > >> >Of Charles Eckel (eckelcu) > > >> >Sent: Friday, February 17, 2012 10:08 PM > > >> >To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, > > Andrew > > >> >Cc: siprec@ietf.org > > >> >Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > >> > > > >> >Hi John, > > >> > > > >> >Good to hear from you, and thanks for keeping us honest on this > > one. > > >> The > > >> >potential benefit I see in have the metadata be optional is with > > >> respect > > >> >to the migration path from pre-SIPREC solutions to SIPREC > > solutions. > > >> In > > >> >such cases, the SRCs and UAs within a deployment might add > support > > >for > > >> >the SIP/SDP extensions and RTP/RTCP recommendations provided by > > >> SIPREC, > > >> >but the SRC and/or SRS may support the XML metadata. What if we > > were > > >> to > > >> >do the following? > > >> > > > >> >siprec option tag: add to existing definition that it means > SIPREC > > >> >metadata is supported sip.src and sip.srs feature tags: clarify > > that > > >> it > > >> >does not imply support for SIPREC metadata > > >> > > > >> >In this case, the hybrid SRC that I described could still include > > the > > >> >sip.src feature tag in its REGISTER and INVITE requests. It would > > not > > >> >include the siprec option tag as it does not support SIPREC > > metadata. > > >> If > > >> >a SIPREC SRS receives such an INVITE, it has the choice of > > rejecting > > >> the > > >> >INVTIE or accepting it for the purpose of recording using > whatever > > >> logic > > >> >it used prior to SIPREC. > > >> >If the SRC supports metadata but does not require it, it can > > include > > >> the > > >> >siprec option tag in a Supported header rather than in a Require > > >> header. > > >> >The same is true for the SRS. > > >> > > > >> >Cheers, > > >> >Charles > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: John Elwell [mailto:john.r.elwell@gmail.com] > > >> >> Sent: Thursday, February 16, 2012 1:40 AM > > >> >> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul > Kyzivat; > > >> >> Hutton, Andrew > > >> >> Cc: siprec@ietf.org > > >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to > implement? > > >> >> > > >> >> I think that XML-based metadata is the essence of SIPREC - > other > > >> >> protocol additions are peripheral in comparison. We should say > > that > > >> if > > >> >> you > > >> >don't > > >> >> implement and use XML-based metadata you are not SIPREC- > > compliant. > > >> >> Trying to > > >> >> bend SIP header fields to achieve a poor-man's metadata does > not > > >> make > > >> >> sense, particularly as we know that B2BUAs are all too prone to > > >> >> modifying SIP header fields. > > >> >> > > >> >> John > > >> >> > > >> >> -----Original Message----- > > >> >> From: Ram Mohan R (rmohanr) > > >> >> Sent: Thursday, February 16, 2012 6:21 AM > > >> >> To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew > > >> >> Cc: siprec@ietf.org > > >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to > implement? > > >> >> > > >> >> I see some issues in going with this way: > > >> >> > > >> >> 1) We will end up in having two different metadata mechanisms - > > one > > >> >XML > > >> >> and one headers based > > >> >> > > >> >> 2) The existing SIP headers may not be sufficient to carry even > > the > > >> >> basic metadata ( as partha mentioned in his previous e-mail) > and > > if > > >> we > > >> >> are going to add new headers then it is redundant as XML > metadata > > >> was > > >> >> just added for that purpose. > > >> >> > > >> >> 3) SRC/SRS needs to negotiate on whether they want to use XML > > based > > >> >> metadata (SIPREC metadata) or Header based metadata and this > will > > >> lead > > >> >> to more issues some of which you already outlined in the below > e- > > >> mail > > >> >> > > >> >> So, I feel it's better to stick with one metadata (XML SIPREC > > >> >metadata) > > >> >> and make it mandatory. > > >> >> > > >> >> What we can add is some guidelines on how SRS has to behave for > > the > > >> >> calls where SRC is unable to send metadata or if SRS encounters > > an > > >> SRC > > >> >> that is not completely compliant with SIPREC standards(say does > > not > > >> >> implement metadata). > > >> >> > > >> >> Regards, > > >> >> Ram > > >> >> > > >> >> > -----Original Message----- > > >> >> > From: siprec-bounces@ietf.org [mailto:siprec- > bounces@ietf.org] > > On > > >> >> > Behalf Of Charles Eckel (eckelcu) > > >> >> > Sent: Wednesday, February 15, 2012 1:19 AM > > >> >> > To: Paul Kyzivat; Hutton, Andrew > > >> >> > Cc: siprec@ietf.org > > >> >> > Subject: Re: [siprec] Is SIPREC metadata mandatory to > > implement? > > >> >> > > > >> >> > Exploring this a bit further, I think this would define a new > > >> option > > >> >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in a > > >> >Supported > > >> >> > vs. Required header. In the event metadata is not used > between > > >the > > >> >> SRC > > >> >> > and SRS, a well documented set of SIP headers could be used > to > > >> >convey > > >> >> > specific information about the recording. > > >> >> > > > >> >> > I do see some value in this. If we go this route, the next > > >> question > > >> >> is, > > >> >> > do you mandate support for this SIP headers AND avoid any > > overlap > > >> >> > between them and the XML metadata? Or do we say that the XML > > >> >> metadata, > > >> >> > if present, supersedes anything conveyed via the SIP headers? > > >> Seeing > > >> >> as > > >> >> > XML metadata is a key part of SIPREC, I would suspect the > > latter, > > >> >but > > >> >> I > > >> >> > am interested to hear what others think. > > >> >> > > > >> >> > Cheers, > > >> >> > Charles > > >> >> > > > >> >> > > -----Original Message----- > > >> >> > > From: siprec-bounces@ietf.org [mailto:siprec- > > bounces@ietf.org] > > >> On > > >> >> > > Behalf Of Paul Kyzivat > > >> >> > > Sent: Tuesday, February 14, 2012 11:06 AM > > >> >> > > To: Hutton, Andrew > > >> >> > > Cc: siprec@ietf.org > > >> >> > > Subject: Re: [siprec] Is SIPREC metadata mandatory to > > >implement? > > >> >> > > > > >> >> > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: > > >> >> > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: > > >> >> > > >> > > >> >> > > >> I guess it isn't *necessary* to specify that. But there > > are > > >> >> > > >> consequences to not doing so: > > >> >> > > >> > > >> >> > > >> An SRC may have been getting acceptable results not > > >> specifying > > >> >> > > >> metadata. > > >> >> > > >> Then the SRS gets replaced with a different one and > > results > > >> are > > >> >> no > > >> >> > > >> longer acceptable because the new one doesn't infer > things > > >> the > > >> >> > same > > >> >> > > >> way. > > >> >> > > >> > > >> >> > > > > > >> >> > > > I think we can live with this if metadata is really > > important > > >> to > > >> >> a > > >> >> > > solution then the SRC will need to generate SIPREC > metadata. > > >> >> > > > > >> >> > > Maybe. But there is a big hurdle between not supplied > > metadata > > >> and > > >> >> > > supplying it. If the metadata is optional, then its quite > > >> possible > > >> >> > that > > >> >> > > you will have SRCs that just aren't capable of doing so. > > (Most > > >> >> likely > > >> >> > > for some simple cases like a UA that is its own SRC.) > > >> >> > > > > >> >> > > Then you might get locked in to an SRS that handles that > case > > >as > > >> >> you > > >> >> > > like. You will start having proprietary islands if SRCs and > > >SRSs > > >> >> that > > >> >> > > can work together. > > >> >> > > > > >> >> > > 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 > > >> > > > >> >_______________________________________________ > > >> >siprec mailing list > > >> >siprec@ietf.org > > >> >https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Thu Feb 23 00:33:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECEA21F8566 for ; Thu, 23 Feb 2012 00:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keNN6R5FTHJP for ; Thu, 23 Feb 2012 00:33:39 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id E5B6221F84B5 for ; Thu, 23 Feb 2012 00:33:38 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 7735D1EB8515; Thu, 23 Feb 2012 09:33:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 23 Feb 2012 09:33:37 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Henry Lum , Paul Kyzivat Date: Thu, 23 Feb 2012 09:33:35 +0100 Thread-Topic: [siprec] protocol draft - Media Stream Updates. Thread-Index: AczxcfHBCEE+74kKTHW0XoXSB3Ji3f//quAAgAAQC4CAAAKpAIAABlwA//+gR6D//vkn8P/9xS+A//r66qA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312944814E3@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31294225062@MCHP058A.global-ad.net><4F4507B2.4080402@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E3129422512C@MCHP058A.global-ad.net> <4F451762.7030105@alum.mit.edu> <059AF07365DC474393A19A3AF187DF74082E0E71@NAHALD.us.int.genesyslab.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04172D@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312944813E6@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E041849@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E041849@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] protocol draft - Media Stream Updates. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 08:33:40 -0000 Thanks. We also need to find some words for the protocol draft. Regards Andy > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 23 February 2012 00:03 > To: Hutton, Andrew; Henry Lum; Paul Kyzivat > Cc: siprec@ietf.org > Subject: RE: [siprec] protocol draft - Media Stream Updates. >=20 > Hi Andy, >=20 > Thanks for the closure. We'll update metadata draft with the scope of > label attribute. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > >Sent: Thursday, February 23, 2012 2:51 AM > >To: Ravindran, Parthasarathi; Henry Lum; Paul Kyzivat > >Cc: siprec@ietf.org > >Subject: RE: [siprec] protocol draft - Media Stream Updates. > > > >Ok I have no objections to the label scope being limited to the > metadata > >carried in the same SIP message as the SDP but we do need to make that > >very clear in I think both the protocol and metadata draft. > > > >At present it the scope does not seem clearly specified to me. > > > >Regards > >Andy > > > > > > > >> -----Original Message----- > >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >> Sent: 22 February 2012 17:08 > >> To: Henry Lum; Paul Kyzivat; Hutton, Andrew > >> Cc: siprec@ietf.org > >> Subject: RE: [siprec] protocol draft - Media Stream Updates. > >> > >> Andy, > >> > >> I agree with Paul that scope of SDP label is within the single SIP > >> message and it is as per RFC4574. It shall be reused but it is not > >> required to same. In fact, there is a long discussion initially > >> whether SDP label shall be used as stream unique id instead of extra > >> URN UUID for stream. The idea of using label attribute was not > >> accepted because SDP label scope is within the given message. Please > >> let us know in case you specific concern here. > >> > >> In case you wish to add the clarity text about label attribute > usage, > >> I'm with you because it helps implementers. > >> > >> Thanks > >> Partha > >> > >> >-----Original Message----- > >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf > >> >Of Henry Lum > >> >Sent: Wednesday, February 22, 2012 10:20 PM > >> >To: Paul Kyzivat; Hutton, Andrew > >> >Cc: siprec@ietf.org > >> >Subject: Re: [siprec] protocol draft - Media Stream Updates. > >> > > >> >I don't see a reason why you cannot reuse the same label for future > >> >uses. As Paul mentioned, I see that the label is local to the > >> >metadata in the same SIP message. > >> > > >> >Henry > >> > > >> >> -----Original Message----- > >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> >> Behalf Of Paul Kyzivat > >> >> Sent: February-22-12 11:27 AM > >> >> To: Hutton, Andrew > >> >> Cc: siprec@ietf.org > >> >> Subject: Re: [siprec] protocol draft - Media Stream Updates. > >> >> > >> >> On 2/22/12 11:17 AM, Hutton, Andrew wrote: > >> >> > > >> >> > Is it really the intention that the scope of the label only > >> applies > >> >> to a single SIP message? > >> >> > > >> >> > This is not stated in the protocol draft or the metadata draft > >> >> > and > >> >> the examples in the metadata draft would tend to lead to a > >> >> different conclusion. > >> >> > > >> >> > If this is the case then I guess that the label attribute in > SDP > >> >> would only be mandatory in cases where there is relevant metadata > >> >> to refer to. This is also not stated. > >> >> > >> >> This was *my* concept of how it would work. > >> >> Perhaps others don't see it that way. > >> >> Lets see what others have to say. > >> >> > >> >> Thanks, > >> >> Paul > >> >> > >> >> > Regards > >> >> > Andy > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > >> >> >> On Behalf Of Paul Kyzivat > >> >> >> Sent: 22 February 2012 15:20 > >> >> >> To: siprec@ietf.org > >> >> >> Subject: Re: [siprec] protocol draft - Media Stream Updates. > >> >> >> > >> >> >> On 2/22/12 9:54 AM, Hutton, Andrew wrote: > >> >> >>> Hi, > >> >> >>> > >> >> >>> Section 6.1.1 of the protocol draft states: > >> >> >>> > >> >> >>> "To add a recorded stream to the recording session, the SRC > >> sends > >> >a > >> >> >> new SDP offer by adding a new media stream description or by > >> >reusing > >> >> an > >> >> >> old media stream which had been previously disabled, according > >> >> >> to > >> >> the > >> >> >> procedures in [RFC3264]". > >> >> >>> > >> >> >>> For clarity we probably should say something about the SDP > >> labels > >> >> >> that go into the media lines. > >> >> >>> > >> >> >>> I assume that once a media line has its port set to zero then > >> the > >> >> SDP > >> >> >> label that was associated with it is no longer valid and > should > >> not > >> >> be > >> >> >> re-used. When a previously disabled media line is re-used then > a > >> >new > >> >> >> label will be needed. > >> >> >> > >> >> >> I don't see any particular reason why that needs to be so. > >> >> >> IMO the only purpose of the label is to allow a reference from > >> the > >> >> >> metadata in a message to an m-line *in the same message*. > >> >> >> I see no need for the label to have any broader significance > >> >> >> than > >> >> that. > >> >> >> > >> >> >> Based on this assumption, it really doesn't matter if the > labels > >> >are > >> >> >> reused or not. > >> >> >> > >> >> >> 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 andrew.hutton@siemens-enterprise.com Thu Feb 23 01:38:20 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94F421F8642 for ; Thu, 23 Feb 2012 01:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qYq03kADtjp for ; Thu, 23 Feb 2012 01:38:20 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id B93CA21F863F for ; Thu, 23 Feb 2012 01:38:19 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 650241EB84F2; Thu, 23 Feb 2012 10:38:18 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 23 Feb 2012 10:38:18 +0100 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , Paul Kyzivat Date: Thu, 23 Feb 2012 10:38:17 +0100 Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: AczxpKDZGdY/DE/0S/u1xWrinUdSBwAAUQcwABnqBzA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3129448154A@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.1070501@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 09:38:20 -0000 Hi Charles, The protocol draft currently states. "An SRC SHOULD include the "siprec" option tag in the Require header when i= nitiating a Recording Session so that other types of user agents can simply= reject the INVITE request with a 420 Bad Extension". There is a similar statement regarding the SRS. The purpose of this is to use the "siprec" option tag to identify the sessi= on as a recording session and I think we need this. Your proposal would bre= ak this so we would need to use a separate option tag to indicate metadata = support if we decide metadata is optional. Regards Andy > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 22 February 2012 21:15 > To: Paul Kyzivat > Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; > Hutton, Andrew; Leon Portman; siprec@ietf.org > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Hi Paul, >=20 > An SRC could use it when it registers itself with a call control > server, > or when it sends/receives a SIP INVITE to/from an UA/MCU to join a > call. > This way the UA/MCU knows it has the ability to request specific media > streams within the SIP dialog between it and the SRC be recorded using > the recording-pref attribute. How the SRC accomplishes this is likely > not important to the UA/MCU. The SRC indicates that it is recording > using the record attribute. The record-aware option tag could be > leveraged her as well. >=20 > Cheers, > Charles >=20 >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Wednesday, February 22, 2012 12:58 PM > > To: Charles Eckel (eckelcu) > > Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; > > Hutton, Andrew; Leon Portman; siprec@ietf.org > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > > Charles, > > > > Do you see any case where it would be valid to use sip.src or sip.srs > > *without* supporting the siprec option tag? > > > > Below it sounds like you do, but I don't see how that makes sense. > > > > Thanks, > > Paul > > > > On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: > > > Based on the responses, either my proposal was not clear, or my > > > understanding of the options and feature tags is incorrect, or > both. > > Let > > > me try again. > > > My intention is not to lower the bar for SIPREC compliance. What I > > > propose is: > > > > > > 1) clarify that the "siprec" option tag, in addition to what is > > already > > > stated, indicates that the XML metadata is supposed. You cannot > > include > > > the "siprec" option tag in a Supported/Require header unless you > > support > > > the XML metadata, as it is the essence of SIPREC. > > > > > > 2) all other SIP/SDP extensions defined in the protocol draft > > (sip.src, > > > sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. > > There > > > are not tied directly to the "siprec" option tag and may be used > > without > > > the "siprec" option tag. > > > > > > If an SRC or SRS supports SIPREC XML metadata, it may indicate that > > by > > > including "siprec" in a Supported header. > > > If an SRC or SRS requires SIPREC XML, it may indicate that by > > including > > > "siprec" in a Require header. > > > > > > I do not see this as lowering the bar for SIPREC compliance. > > > I do see it as providing benefit for implementations that have no > > > intention of being a SIPREC compliant SRC or SRS. > > > I also see it helping with interworking between SIPREC compliant > and > > non > > > SIPREC compliant entities. > > > > > > Cheers, > > > Charles From andrew.hutton@siemens-enterprise.com Thu Feb 23 01:53:48 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0CD21F861B for ; Thu, 23 Feb 2012 01:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UDSt+F8Lx9h for ; Thu, 23 Feb 2012 01:53:47 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id C417621F8602 for ; Thu, 23 Feb 2012 01:53:47 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9CA0223F053B; Thu, 23 Feb 2012 10:53:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 23 Feb 2012 10:53:46 +0100 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Thu, 23 Feb 2012 10:53:45 +0100 Thread-Topic: recordpref and record SDP attributes Thread-Index: AczxqBzrXscnPkYrTqmPlfkBFrvdBAAZ/mdw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31294481568@MCHP058A.global-ad.net> 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] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 09:53:48 -0000 Hi Charles, Actually the protocol draft states that these are media level attributes an= d says nothing about using them at the session level. I assume using them a= t the session level should be allowed so we would need to state this in the= protocol draft. My thinking is that your assumption is correct. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Charles Eckel (eckelcu) > Sent: 22 February 2012 21:23 > To: siprec@ietf.org > Subject: [siprec] recordpref and record SDP attributes >=20 > My assumption is that these SDP attributes, when used at the session or > media level, apply to the media as stated by the media mode attribute, > meaning that if the mode is "sendrecv", recordpref=3Don is a request to > record both the media being sent to as well as the media being received > by the requestor. Similarly for record=3Don. > Is that correct? >=20 > Thanks, > Charles > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Thu Feb 23 02:09:08 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF7F21F8646 for ; Thu, 23 Feb 2012 02:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSZw3foiv33C for ; Thu, 23 Feb 2012 02:09:06 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 669C121F8645 for ; Thu, 23 Feb 2012 02:09:06 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1NA9nQH006747; Thu, 23 Feb 2012 05:09:49 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 05:07:57 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 15:38:12 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 15:38:11 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "Charles Eckel (eckelcu)" , "siprec@ietf.org" Thread-Topic: recordpref and record SDP attributes Thread-Index: AczxqBzrXscnPkYrTqmPlfkBFrvdBAAZ/mdwAACRROA= Date: Thu, 23 Feb 2012 10:08:10 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E0419B9@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31294481568@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31294481568@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2012 10:08:12.0048 (UTC) FILETIME=[0CD4E100:01CCF213] Subject: Re: [siprec] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 10:09:08 -0000 Hi Andy, =20 Hope your mail is about only session level or media level recordpref query = and not about the below snip. recordpref=3Don is a=20 > request to record both the media being sent to as well as the media=20 > being received by the requestor. As per the above statement, offerer in the CS always decide whether the cal= l has to be recorded or not. Also, I could not think of the SDP parameter i= n the same line of understanding wherein controlling answerer using paramet= er. I have explained my understanding of the parameter at http://www.ietf.o= rg/mail-archive/web/siprec/current/msg03080.html. Please correct me where I= 'm going wrong. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Thursday, February 23, 2012 3:24 PM >To: Charles Eckel (eckelcu); siprec@ietf.org >Subject: Re: [siprec] recordpref and record SDP attributes > >Hi Charles, > >Actually the protocol draft states that these are media level attributes >and says nothing about using them at the session level. I assume using >them at the session level should be allowed so we would need to state >this in the protocol draft. > >My thinking is that your assumption is correct. > >Regards >Andy > > > > > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Charles Eckel (eckelcu) >> Sent: 22 February 2012 21:23 >> To: siprec@ietf.org >> Subject: [siprec] recordpref and record SDP attributes >> >> My assumption is that these SDP attributes, when used at the session >> or media level, apply to the media as stated by the media mode >> attribute, meaning that if the mode is "sendrecv", recordpref=3Don is a >> request to record both the media being sent to as well as the media >> being received by the requestor. Similarly for record=3Don. >> Is that correct? >> >> Thanks, >> Charles >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Thu Feb 23 02:23:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECB621F8665 for ; Thu, 23 Feb 2012 02:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqTYP7sJzZL5 for ; Thu, 23 Feb 2012 02:23:40 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id B4A4821F8664 for ; Thu, 23 Feb 2012 02:23:39 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 20D3C23F053B; Thu, 23 Feb 2012 11:23:39 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 23 Feb 2012 11:23:39 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Thu, 23 Feb 2012 11:23:37 +0100 Thread-Topic: recordpref and record SDP attributes Thread-Index: AczxqBzrXscnPkYrTqmPlfkBFrvdBAAZ/mdwAACRROAAAIhVcA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3129448159C@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31294481568@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E0419B9@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E0419B9@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 10:23:40 -0000 See below. Regards Andy > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 23 February 2012 10:08 > To: Hutton, Andrew; Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: recordpref and record SDP attributes >=20 > Hi Andy, >=20 > Hope your mail is about only session level or media level recordpref > query and not about the below snip. >=20 > > recordpref=3Don is a > > request to record both the media being sent to as well as the media > > being received by the requestor. > >=20 [AndyH] - I agree with this snip the recordpref=3Don is indicating a prefer= ence for the media to be recorded in both directions if it is a sendrecv st= ream. > As per the above statement, offerer in the CS always decide whether the > call has to be recorded or not.=20 [AndyH - I don't think this is true the offerer and answerer have equal rig= hts and in the end it is up to the SRC to decide depending on its local pol= icy and I don't think we should say very much about that policy. > Also, I could not think of the SDP > parameter in the same line of understanding wherein controlling > answerer using parameter. I have explained my understanding of the > parameter at http://www.ietf.org/mail- > archive/web/siprec/current/msg03080.html. Please correct me where I'm > going wrong. >=20 [AndyH] Will respond to this mail separately. > Thanks > Partha >=20 >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Hutton, Andrew > >Sent: Thursday, February 23, 2012 3:24 PM > >To: Charles Eckel (eckelcu); siprec@ietf.org > >Subject: Re: [siprec] recordpref and record SDP attributes > > > >Hi Charles, > > > >Actually the protocol draft states that these are media level > attributes > >and says nothing about using them at the session level. I assume using > >them at the session level should be allowed so we would need to state > >this in the protocol draft. > > > >My thinking is that your assumption is correct. > > > >Regards > >Andy > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > >> Behalf Of Charles Eckel (eckelcu) > >> Sent: 22 February 2012 21:23 > >> To: siprec@ietf.org > >> Subject: [siprec] recordpref and record SDP attributes > >> > >> My assumption is that these SDP attributes, when used at the session > >> or media level, apply to the media as stated by the media mode > >> attribute, meaning that if the mode is "sendrecv", recordpref=3Don is > a > >> request to record both the media being sent to as well as the media > >> being received by the requestor. Similarly for record=3Don. > >> Is that correct? > >> > >> Thanks, > >> Charles > >> _______________________________________________ > >> siprec mailing list > >> siprec@ietf.org > >> https://www.ietf.org/mailman/listinfo/siprec > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Thu Feb 23 03:22:08 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE2C21F86C6 for ; Thu, 23 Feb 2012 03:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKOShZLRtHM9 for ; Thu, 23 Feb 2012 03:22:08 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DA24621F86B7 for ; Thu, 23 Feb 2012 03:22:07 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1NBMqdB021970; Thu, 23 Feb 2012 06:22:52 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 06:12:15 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 16:42:29 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 16:42:28 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , "Charles Eckel (eckelcu)" , "siprec@ietf.org" Thread-Topic: recordpref and record SDP attributes Thread-Index: AczxqBzrXscnPkYrTqmPlfkBFrvdBAAZ/mdwAACRROAAAIhVcAABy8/Q Date: Thu, 23 Feb 2012 11:12:27 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E041A35@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31294481568@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E0419B9@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E3129448159C@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E3129448159C@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2012 11:12:29.0432 (UTC) FILETIME=[0802F780:01CCF21C] Subject: Re: [siprec] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 11:22:08 -0000 Hi Andy, Please read inline. Thanks Partha >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Thursday, February 23, 2012 3:54 PM >To: Ravindran, Parthasarathi; Charles Eckel (eckelcu); siprec@ietf.org >Subject: RE: recordpref and record SDP attributes > >See below. > >Regards >Andy > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 23 February 2012 10:08 >> To: Hutton, Andrew; Charles Eckel (eckelcu); siprec@ietf.org >> Subject: RE: recordpref and record SDP attributes >> >> Hi Andy, >> >> Hope your mail is about only session level or media level recordpref >> query and not about the below snip. >> >> >> recordpref=3Don is a >> > request to record both the media being sent to as well as the media >> > being received by the requestor. >> >> > >[AndyH] - I agree with this snip the recordpref=3Don is indicating a >preference for the media to be recorded in both directions if it is a >sendrecv stream. > > >> As per the above statement, offerer in the CS always decide whether >> the call has to be recorded or not. > >[AndyH - I don't think this is true the offerer and answerer have equal >rights and in the end it is up to the SRC to decide depending on its >local policy and I don't think we should say very much about that >policy. > I agree with SRC policy part. Assume, SRC has the policy to record and in case recordpref=3Don send by offerer and answerer mention as recordp= ref=3Doff, Please let me know the expected behavior. Also, I'll wait for your another= =20 Mail for below discussion > >> Also, I could not think of the SDP >> parameter in the same line of understanding wherein controlling >> answerer using parameter. I have explained my understanding of the >> parameter at http://www.ietf.org/mail- >> archive/web/siprec/current/msg03080.html. Please correct me where I'm >> going wrong. >> > >[AndyH] Will respond to this mail separately. > >> Thanks >> Partha >> >> >> >-----Original Message----- >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >> >Of Hutton, Andrew >> >Sent: Thursday, February 23, 2012 3:24 PM >> >To: Charles Eckel (eckelcu); siprec@ietf.org >> >Subject: Re: [siprec] recordpref and record SDP attributes >> > >> >Hi Charles, >> > >> >Actually the protocol draft states that these are media level >> attributes >> >and says nothing about using them at the session level. I assume >> >using them at the session level should be allowed so we would need to >> >state this in the protocol draft. >> > >> >My thinking is that your assumption is correct. >> > >> >Regards >> >Andy >> > >> > >> > >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> >> Behalf Of Charles Eckel (eckelcu) >> >> Sent: 22 February 2012 21:23 >> >> To: siprec@ietf.org >> >> Subject: [siprec] recordpref and record SDP attributes >> >> >> >> My assumption is that these SDP attributes, when used at the >> >> session or media level, apply to the media as stated by the media >> >> mode attribute, meaning that if the mode is "sendrecv", >> >> recordpref=3Don is >> a >> >> request to record both the media being sent to as well as the media >> >> being received by the requestor. Similarly for record=3Don. >> >> Is that correct? >> >> >> >> Thanks, >> >> Charles >> >> _______________________________________________ >> >> siprec mailing list >> >> siprec@ietf.org >> >> https://www.ietf.org/mailman/listinfo/siprec >> >_______________________________________________ >> >siprec mailing list >> >siprec@ietf.org >> >https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Feb 23 08:48:45 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD7221F884D for ; Thu, 23 Feb 2012 08:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2qLWIXGdNta for ; Thu, 23 Feb 2012 08:48:43 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9605821F884B for ; Thu, 23 Feb 2012 08:48:43 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id dUf81i00417dt5G5AUok3U; Thu, 23 Feb 2012 16:48:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id dUoj1i01V07duvL3ZUojJW; Thu, 23 Feb 2012 16:48:43 +0000 Message-ID: <4F466DEA.2010807@alum.mit.edu> Date: Thu, 23 Feb 2012 11:48:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E31294481568@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31294481568@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 16:48:45 -0000 IMO media level attributes should in general also be valid at session level, as a default for media that don't specify a value explicitly. But the way SDP is defined this needs to be specified explicitly for each newly defined attribute. So yes, language to this effect should be included. Thanks, Paul On 2/23/12 4:53 AM, Hutton, Andrew wrote: > Hi Charles, > > Actually the protocol draft states that these are media level attributes and says nothing about using them at the session level. I assume using them at the session level should be allowed so we would need to state this in the protocol draft. > > My thinking is that your assumption is correct. > > Regards > Andy > > > > > > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Charles Eckel (eckelcu) >> Sent: 22 February 2012 21:23 >> To: siprec@ietf.org >> Subject: [siprec] recordpref and record SDP attributes >> >> My assumption is that these SDP attributes, when used at the session or >> media level, apply to the media as stated by the media mode attribute, >> meaning that if the mode is "sendrecv", recordpref=on is a request to >> record both the media being sent to as well as the media being received >> by the requestor. Similarly for record=on. >> Is that correct? >> >> Thanks, >> Charles >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Thu Feb 23 09:09:43 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FD121F8709 for ; Thu, 23 Feb 2012 09:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_110=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OatGrZDYhJLx for ; Thu, 23 Feb 2012 09:09:42 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3AB21F86EA for ; Thu, 23 Feb 2012 09:09:42 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 994241EB8467; Thu, 23 Feb 2012 18:09:40 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 23 Feb 2012 18:09:40 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , "Charles Eckel (eckelcu)" , "siprec@ietf.org" Date: Thu, 23 Feb 2012 18:09:39 +0100 Thread-Topic: recordpref and record SDP attributes Thread-Index: AczxqBzrXscnPkYrTqmPlfkBFrvdBAAZ/mdwAACRROAAAIhVcAABy8/QAAxdjuA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31294481951@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31294481568@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E0419B9@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E3129448159C@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E041A35@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E041A35@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 17:09:43 -0000 On 23 February 2012 11:12 Ravindran, Parthasarathi stated: > I agree with SRC policy part. Assume, SRC has the policy to > record > and in case recordpref=3Don send by offerer and answerer mention as > recordpref=3Doff, > Please let me know the expected behavior. Also, I'll wait for your > another > Mail for below discussion >=20 The resulting behavior I believe depends on SRC policy which we don't defin= e.=20 This I think is what is implied in section 10.2.2 of the siprec-protocol dr= aft which states: "When the SRC receives the a=3Drecordpref SDP in an SDP offer or answer, th= e SRC MAY choose to honor such request to record the request based on local= policy on the SRC". Regards Andy From eckelcu@cisco.com Thu Feb 23 12:48:49 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F7A21F8895 for ; Thu, 23 Feb 2012 12:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.355 X-Spam-Level: X-Spam-Status: No, score=-8.355 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uN0RVlOpUCg for ; Thu, 23 Feb 2012 12:48:48 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1DF21F850D for ; Thu, 23 Feb 2012 12:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2610; q=dns/txt; s=iport; t=1330030128; x=1331239728; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Je9awyCqzZLfOHngIf3RqLEW2w/Z6m/ZSlelqYCiptA=; b=ZZ7mdhUnWYQdcVq6rekKrn8YaDlmOVzMelsSm1QYczajK8TTs+TF63Zi KcsCa8V9aky83gib8ajgfI3kF2tUxRUe09PH4YatjJUlUZAQJ+1Ys/wSV AOyKyurdsJ8ioLe9ZAK/E+CQRxfea+SdVt6vCITmDpnRKvwLBT6E2xqDP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJWlRk+rRDoG/2dsb2JhbABEslOBB4FzAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHaKATAZcABIlngxgFAQIOBAkORxEIAoRMAYEHGhIPgkpjBIhPn3eBOw X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="32072868" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 23 Feb 2012 20:48:48 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1NKmlTa032537; Thu, 23 Feb 2012 20:48:48 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, 23 Feb 2012 12:48:48 -0800 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 Feb 2012 12:48:48 -0800 Message-ID: In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E0418B0@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: recordpref and record SDP attributes Thread-Index: AczxqBzrXscnPkYrTqmPlfkBFrvdBAAHA5LwACoBPJA= References: <387F9047F55E8C42850AD6B3A7A03C6C0E0418B0@inba-mail01.sonusnet.com> From: "Charles Eckel (eckelcu)" To: "Ravindran, Parthasarathi" , X-OriginalArrivalTime: 23 Feb 2012 20:48:48.0206 (UTC) FILETIME=[8A9126E0:01CCF26C] Subject: Re: [siprec] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 20:48:49 -0000 Hi Partha, I understand both "record" and "recordpref" to be declarative attributes. The combinations you describe are what I consider to be policy decisions at the B2BUA/SRC. As such, I think there are just fine. Cheers, Charles > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: Wednesday, February 22, 2012 5:09 PM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: recordpref and record SDP attributes >=20 > Hi Charles, >=20 > I got the same doubt by looking at your proposed usage in the another > mail thread. Till now, I'm seeing recordpref attribute as an > declarative > SDP attribute wherein SRC comes to know whether media stream has to be > recorded based on its policy. However, your proposal is to use this > attribute for negotiation (offer/answer). The topology in my mind is >=20 > UA1 ----B2BUA (SRC) ----UA2 >=20 > IMO, Recordpref offer/answer combination in B2BUA with UA1 as offerer > and > UA2 as answerer are as follows: >=20 > UA1 UA2 B2BUA/SRC > On Off Off > Off On Off > Off Off Off > On On On > Empty Off Off > Empty On On > On Empty On > Off Empty Off > Empty Empty On >=20 > The last row "On" indicates that both parties agrees for recording and > it is > upto SRC to decide whether recording has to be done or not. Empty > indicates the > absence of this attribute in SDP. Please correct me in case I > misunderstand > about this SDP attribute. >=20 > Thanks > Partha >=20 >=20 > >-----Original Message----- > >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > >Of Charles Eckel (eckelcu) > >Sent: Thursday, February 23, 2012 2:53 AM > >To: siprec@ietf.org > >Subject: [siprec] recordpref and record SDP attributes > > > >My assumption is that these SDP attributes, when used at the session > or > >media level, apply to the media as stated by the media mode attribute, > >meaning that if the mode is "sendrecv", recordpref=3Don is a request = to > >record both the media being sent to as well as the media being > received > >by the requestor. Similarly for record=3Don. > >Is that correct? > > > >Thanks, > >Charles > >_______________________________________________ > >siprec mailing list > >siprec@ietf.org > >https://www.ietf.org/mailman/listinfo/siprec From eckelcu@cisco.com Thu Feb 23 12:55:43 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45B521F87A4 for ; Thu, 23 Feb 2012 12:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.683 X-Spam-Level: X-Spam-Status: No, score=-8.683 tagged_above=-999 required=5 tests=[AWL=1.316, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvOANYuUI2FM for ; Thu, 23 Feb 2012 12:55:42 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 59D6A21F85C6 for ; Thu, 23 Feb 2012 12:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4981; q=dns/txt; s=iport; t=1330030542; x=1331240142; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=xQEgdSkp4CNQHsQdaUdsEV8NJeQSnH15d6KBbntu/ps=; b=fw8/CX/Ueo5a3k1UihDFy7mtIXJbd27tuTbH/0xNv6qLR7HvRObZD0hF nDT0N3EOymHmJg3/WhSVA7HZBIyr3SIh7SMbSxM2Wk5aLYMmP7eN55Y4E ieXcJWZW5ef5nr+CR+dL6ueWH+tDiWHf1SR8dXdrq8ESurQN+/YzLZEmP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM6mRk+rRDoJ/2dsb2JhbABEDrJFgQeBcwEBAQQSAR0KPwwEAgEIEQQBAQEKBhMEAQYBRQkIAgQBEggap3wBlwSJZ4MdAQISEQZHEQqETAFgBAcDCQUCAR8VD4JKYwSIT58fWIE7 X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="32074334" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 Feb 2012 20:55:42 +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 q1NKtfa8008386; Thu, 23 Feb 2012 20:55: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); Thu, 23 Feb 2012 12:55:41 -0800 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 Feb 2012 12:55:41 -0800 Message-ID: In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?] Thread-Index: AQHM8c1FGYhD9DGhCESahXQz/mAjl5ZK9iOg References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> From: "Charles Eckel (eckelcu)" To: "Ravindran, Parthasarathi" , "Paul Kyzivat" X-OriginalArrivalTime: 23 Feb 2012 20:55:41.0822 (UTC) FILETIME=[8119F1E0:01CCF26D] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 20:55:43 -0000 Hi Partha, If the SRC requires the SRS support SIPREC XML metadata, it can indicate that by including "siprec" option tag in a Require header. However, the SRC may not require this, in which case including "siprec" option tag in Supported header is appropriate. Cheers, Charles > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: Wednesday, February 22, 2012 5:49 PM > To: Charles Eckel (eckelcu); Paul Kyzivat > Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon Portman; > siprec@ietf.org > Subject: Is SIPREC metadata mandatory to implement in RS [was RE: > [siprec] Is SIPREC metadata mandatory to implement?] >=20 > Hi Charles, >=20 > Thanks for the clarification. I understand that we are talking about > two > different stuff. So, I have changed the subject of the mail as > "Is SIPREC metadata mandatory to implement in Recording Session(RS)". >=20 > Hi all, >=20 > Till now, I have not seen anybody has objection for supporting SIRPEC > metadata in RS. Please correct me in case my understanding is wrong. >=20 > Also, I propose to change the following normative statement from > "SHOULD" > To "MUST" in recording session: >=20 > "An SRC SHOULD include the "siprec" option tag in the Require header > when > initiating a Recording Session so that other types of user agents can > simply reject the INVITE request with a 420 Bad Extension." >=20 > as >=20 > "An SRC MUST include the "siprec" option tag in the Require header when > initiating a Recording Session so that other types of user agents can > simply reject the INVITE request with a 420 Bad Extension." >=20 > Please let me know your opinion on the same. >=20 > Thanks > Partha > >-----Original Message----- > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >Sent: Thursday, February 23, 2012 2:45 AM > >To: Paul Kyzivat > >Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; > >Hutton, Andrew; Leon Portman; siprec@ietf.org > >Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > >Hi Paul, > > > >An SRC could use it when it registers itself with a call control > server, > >or when it sends/receives a SIP INVITE to/from an UA/MCU to join a > call. > >This way the UA/MCU knows it has the ability to request specific media > >streams within the SIP dialog between it and the SRC be recorded using > >the recording-pref attribute. How the SRC accomplishes this is likely > >not important to the UA/MCU. The SRC indicates that it is recording > >using the record attribute. The record-aware option tag could be > >leveraged her as well. > > > >Cheers, > >Charles > > > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Wednesday, February 22, 2012 12:58 PM > >> To: Charles Eckel (eckelcu) > >> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; > >> Hutton, Andrew; Leon Portman; siprec@ietf.org > >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >> > >> Charles, > >> > >> Do you see any case where it would be valid to use sip.src or > sip.srs > >> *without* supporting the siprec option tag? > >> > >> Below it sounds like you do, but I don't see how that makes sense. > >> > >> Thanks, > >> Paul > >> > >> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: > >> > Based on the responses, either my proposal was not clear, or my > >> > understanding of the options and feature tags is incorrect, or > both. > >> Let > >> > me try again. > >> > My intention is not to lower the bar for SIPREC compliance. What I > >> > propose is: > >> > > >> > 1) clarify that the "siprec" option tag, in addition to what is > >> already > >> > stated, indicates that the XML metadata is supposed. You cannot > >> include > >> > the "siprec" option tag in a Supported/Require header unless you > >> support > >> > the XML metadata, as it is the essence of SIPREC. > >> > > >> > 2) all other SIP/SDP extensions defined in the protocol draft > >> (sip.src, > >> > sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. > >> There > >> > are not tied directly to the "siprec" option tag and may be used > >> without > >> > the "siprec" option tag. > >> > > >> > If an SRC or SRS supports SIPREC XML metadata, it may indicate > that > >> by > >> > including "siprec" in a Supported header. > >> > If an SRC or SRS requires SIPREC XML, it may indicate that by > >> including > >> > "siprec" in a Require header. > >> > > >> > I do not see this as lowering the bar for SIPREC compliance. > >> > I do see it as providing benefit for implementations that have no > >> > intention of being a SIPREC compliant SRC or SRS. > >> > I also see it helping with interworking between SIPREC compliant > and > >> non > >> > SIPREC compliant entities. > >> > > >> > Cheers, > >> > Charles From eckelcu@cisco.com Thu Feb 23 12:57:28 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953CE21F88AE for ; Thu, 23 Feb 2012 12:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.417 X-Spam-Level: X-Spam-Status: No, score=-8.417 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjjeeB0wfC4X for ; Thu, 23 Feb 2012 12:57:26 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A7ED121F88A5 for ; Thu, 23 Feb 2012 12:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=16842; q=dns/txt; s=iport; t=1330030646; x=1331240246; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TaoKpYpJn6cIQcjykrE/yNJh23rX8P1ABPeQgEQP3+s=; b=CBINXQbaO6vX6xiNgeDKZQOgqodPf9HDHOOvCpSTPYO3NKPEEmfPo2b8 NGWIp6H3BTa3lluibhMBMqFcLGZoJtWCEf1XvcWc8+mty24VFzWp/6dl0 nISf/3fvmFGnCqWq1BzhR5xBP8ztqljaCndyw3grgxbVHJcp3RDpaq0gS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOynRk+rRDoJ/2dsb2JhbAA8CA6yRYEHgXMBAQEEAQEBDwEdCjQLDAQCAQgRBAEBAQoGFwEGASAGHwkIAQEEARIIEweHaKAdAZcABIh/ZQODHQEBAQQCDA4DBkeEZwFgJxoSD4JKYwSIT5gAhx9YgTs X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="32074767" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 Feb 2012 20:57:26 +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 q1NKvQuw009921; Thu, 23 Feb 2012 20:57: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); Thu, 23 Feb 2012 12:57:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: c50= DXLh FEl2 S2a3 Zpck dAJW eJkT htkM kD5U oa9e yfv/ 8NVS 9SwQ /oyd AAKAmQ== AArbzQ==; 6; YQBuAGQAcgBlAHcALgBoAHUAdAB0AG8AbgBAAHMAaQBlAG0AZQBuAHMALQBlAG4AdABlAHIAcAByAGkAcwBlAC4AYwBvAG0AOwBqAG8AaABuAC4AcgAuAGUAbAB3AGUAbABsAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBsAGUAbwBuAC4AcABvAHIAdABtAGEAbgBAAG4AaQBjAGUALgBjAG8AbQA7AHAAawB5AHoAaQB2AGEAdABAAGEAbAB1AG0ALgBtAGkAdAAuAGUAZAB1ADsAcAByAGEAdgBpAG4AZAByAGEAbgBAAHMAbwBuAHUAcwBuAGUAdAAuAGMAbwBtADsAcwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {F4507599-C4C6-41B5-9EE6-05D57F565C4A}; ZQBjAGsAZQBsAGMAdQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Thu, 23 Feb 2012 20:57:17 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABJAHMAIABTAEkAUABSAEUAQwAgAG0AZQB0AGEAZABhAHQAYQAgAG0AYQBuAGQAYQB0AG8AcgB5ACAAdABvACAAaQBtAHAAbABlAG0AZQBuAHQAPwA= MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {F4507599-C4C6-41B5-9EE6-05D57F565C4A} Content-class: urn:content-classes:message Date: Thu, 23 Feb 2012 12:57:17 -0800 Message-ID: In-Reply-To: <957AB983462E43BBBDAE5C77122D7E54@Acer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Is SIPREC metadata mandatory to implement? Thread-Index: Aczx/g/VgE9qdRUIQviaiYgDI4xEsgAb5psQ References: <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisco.com> <957AB983462E43BBBDAE5C77122D7E54@Acer> From: "Charles Eckel (eckelcu)" To: "John Elwell" , "Ram Mohan R (rmohanr)" , "Ravindran, Parthasarathi" , "Paul Kyzivat" , "Hutton, Andrew" , "Leon Portman" X-OriginalArrivalTime: 23 Feb 2012 20:57:26.0531 (UTC) FILETIME=[BF834530:01CCF26D] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2012 20:57:28 -0000 I agree. Cheers, Charles > -----Original Message----- > From: John Elwell [mailto:john.r.elwell@gmail.com] > Sent: Wednesday, February 22, 2012 11:38 PM > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Ravindran, > Parthasarathi; Paul Kyzivat; Hutton, Andrew; Leon Portman > Cc: siprec@ietf.org > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Charles, >=20 > Thanks for the clarification. I don't see any harm in the option tag. > My > desire is that if you claim to support SIPREC (i.e., support the > protocol > RFC) you MUST also support XML metadata. >=20 > John >=20 > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Wednesday, February 22, 2012 8:50 PM > To: Ram Mohan R (rmohanr) ; John Elwell ; Ravindran, Parthasarathi ; > Paul > Kyzivat ; Hutton, Andrew ; Leon Portman > Cc: siprec@ietf.org > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >=20 > Based on the responses, either my proposal was not clear, or my > understanding of the options and feature tags is incorrect, or both. > Let > me try again. > My intention is not to lower the bar for SIPREC compliance. What I > propose is: >=20 > 1) clarify that the "siprec" option tag, in addition to what is already > stated, indicates that the XML metadata is supposed. You cannot include > the "siprec" option tag in a Supported/Require header unless you > support > the XML metadata, as it is the essence of SIPREC. >=20 > 2) all other SIP/SDP extensions defined in the protocol draft (sip.src, > sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. > There > are not tied directly to the "siprec" option tag and may be used > without > the "siprec" option tag. >=20 > If an SRC or SRS supports SIPREC XML metadata, it may indicate that by > including "siprec" in a Supported header. > If an SRC or SRS requires SIPREC XML, it may indicate that by including > "siprec" in a Require header. >=20 > I do not see this as lowering the bar for SIPREC compliance. > I do see it as providing benefit for implementations that have no > intention of being a SIPREC compliant SRC or SRS. > I also see it helping with interworking between SIPREC compliant and > non > SIPREC compliant entities. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) > > Sent: Tuesday, February 21, 2012 7:10 PM > > To: John Elwell; Ravindran, Parthasarathi; Charles Eckel (eckelcu); > > Paul Kyzivat; Hutton, Andrew; Leon Portman > > Cc: siprec@ietf.org > > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > > +1 > > Yes. That is my concern too as I mentioned in one of the earlier e- > > mails also. > > I still prefer to make SIPREC XML metadata as mandatory. The moment > we > > may it optional we will have all proprietary implementations ( for > > conveying metadata) creeping in and will eventually defeat the > purpose > > of the work we are doing in this Group. > > > > Ram > > > > > -----Original Message----- > > > From: John Elwell [mailto:john.r.elwell@gmail.com] > > > Sent: Tuesday, February 21, 2012 10:31 PM > > > To: Ravindran, Parthasarathi; Charles Eckel (eckelcu); Ram Mohan R > > > (rmohanr); Paul Kyzivat; Hutton, Andrew > > > Cc: siprec@ietf.org > > > Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > > > > > That is my concern. The proposed option tag would make the bar for > > > SIPREC > > > compliance so low that almost any implementation could easily be > made > > > to > > > comply, and yet the degree of interoperability between such > > > implementations > > > would be rather poor. It would be rather like claiming to support > SIP > > > without supporting SDP. > > > > > > John > > > > > > > > > -----Original Message----- > > > From: Ravindran, Parthasarathi > > > Sent: Tuesday, February 21, 2012 3:41 AM > > > To: Charles Eckel (eckelcu) ; John Elwell ; Ram Mohan R (rmohanr) ; > > > Paul > > > Kyzivat ; Hutton, Andrew > > > Cc: siprec@ietf.org > > > Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > > > > Hi Charles, > > > > > > In case we end up with sip.src contact parameter is the only > > mandatory > > > for > > > SIPREC compliance, then I would say that Existing Sonus proprietary > > > recording already met SIPREC compliance because adding contact > header > > > parameter is a matter of configuration. I'm confident that smart > > > product > > > manager in other companies push for the same level of compliance ;- > ) > > > This > > > will result in SIPREC compliance with new proprietary headers/body > > for > > > interop with each recording vendor. I'm worried that those kind > > SIPREC > > > compliance will not solve the indented problem which we are working > > > for. > > > > > > Thanks > > > Partha > > > > > > >-----Original Message----- > > > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > > >Sent: Tuesday, February 21, 2012 4:15 AM > > > >To: Ravindran, Parthasarathi; John Elwell; Ram Mohan R (rmohanr); > > Paul > > > >Kyzivat; Hutton, Andrew > > > >Cc: siprec@ietf.org > > > >Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > > > > > >Hi Partha, > > > > > > > >Please see inline. > > > > > > > >> -----Original Message----- > > > >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > > > >> Sent: Friday, February 17, 2012 10:28 AM > > > >> To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R (rmohanr); > > > Paul > > > >> Kyzivat; Hutton, Andrew > > > >> Cc: siprec@ietf.org > > > >> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > >> > > > >> Hi Charles, > > > >> > > > >> In case some of the SRS has done your proposed SIPREC migration > > > >without > > > >> metadata in the first phase, it will impact SRC SIPREC > > > implementation > > > >> as SRC is forced to support SRS proprietary metadata and it is > one > > > of > > > >> the major issue today in SIP recording. I wish that it will be > > > solved > > > >> by SIPREC. > > > >> > > > >> Also, I'm seeing with your argument that most of the existing > SIP > > > >based > > > >> proprietary recording are already compliant with SIPREC in case > > > option > > > >> tag only is added because the option tag shall be added through > > SIP > > > >> message configuration in the device (no development required > :-)). > > > The > > > >> requested flexibility in SIPREC provides the opportunity for > > vendors > > > >to > > > >> stick with pre-SIPREC solution and also, the benefit of IETF > > SIPREC > > > >> compliance. Could you please look this issue from the "sake of > > > >> compliance vendor" perspective. > > > > > > > >In my proposal, I included the following: > > > > > > > >siprec option tag: add to existing definition that it means SIPREC > > > >metadata is supported > > > > > > > >sip.src and sip.srs feature tags: clarify that it does not imply > > > support > > > >for SIPREC metadata > > > > > > > >Therefore, including the "siprec" option tag means that the > metadata > > > is > > > >supported. I thought this would address your concern. If not, then > > > >perhaps I do not completely understand the issue you are > > highlighting. > > > > > > > >Cheers, > > > >Charles > > > > > > > > > > > >> Thanks > > > >> Partha > > > >> > > > >> >-----Original Message----- > > > >> >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] > On > > > >> Behalf > > > >> >Of Charles Eckel (eckelcu) > > > >> >Sent: Friday, February 17, 2012 10:08 PM > > > >> >To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, > > > Andrew > > > >> >Cc: siprec@ietf.org > > > >> >Subject: Re: [siprec] Is SIPREC metadata mandatory to > implement? > > > >> > > > > >> >Hi John, > > > >> > > > > >> >Good to hear from you, and thanks for keeping us honest on this > > > one. > > > >> The > > > >> >potential benefit I see in have the metadata be optional is > with > > > >> respect > > > >> >to the migration path from pre-SIPREC solutions to SIPREC > > > solutions. > > > >> In > > > >> >such cases, the SRCs and UAs within a deployment might add > > support > > > >for > > > >> >the SIP/SDP extensions and RTP/RTCP recommendations provided by > > > >> SIPREC, > > > >> >but the SRC and/or SRS may support the XML metadata. What if we > > > were > > > >> to > > > >> >do the following? > > > >> > > > > >> >siprec option tag: add to existing definition that it means > > SIPREC > > > >> >metadata is supported sip.src and sip.srs feature tags: clarify > > > that > > > >> it > > > >> >does not imply support for SIPREC metadata > > > >> > > > > >> >In this case, the hybrid SRC that I described could still > include > > > the > > > >> >sip.src feature tag in its REGISTER and INVITE requests. It > would > > > not > > > >> >include the siprec option tag as it does not support SIPREC > > > metadata. > > > >> If > > > >> >a SIPREC SRS receives such an INVITE, it has the choice of > > > rejecting > > > >> the > > > >> >INVTIE or accepting it for the purpose of recording using > > whatever > > > >> logic > > > >> >it used prior to SIPREC. > > > >> >If the SRC supports metadata but does not require it, it can > > > include > > > >> the > > > >> >siprec option tag in a Supported header rather than in a > Require > > > >> header. > > > >> >The same is true for the SRS. > > > >> > > > > >> >Cheers, > > > >> >Charles > > > >> > > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: John Elwell [mailto:john.r.elwell@gmail.com] > > > >> >> Sent: Thursday, February 16, 2012 1:40 AM > > > >> >> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul > > Kyzivat; > > > >> >> Hutton, Andrew > > > >> >> Cc: siprec@ietf.org > > > >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to > > implement? > > > >> >> > > > >> >> I think that XML-based metadata is the essence of SIPREC - > > other > > > >> >> protocol additions are peripheral in comparison. We should > say > > > that > > > >> if > > > >> >> you > > > >> >don't > > > >> >> implement and use XML-based metadata you are not SIPREC- > > > compliant. > > > >> >> Trying to > > > >> >> bend SIP header fields to achieve a poor-man's metadata does > > not > > > >> make > > > >> >> sense, particularly as we know that B2BUAs are all too prone > to > > > >> >> modifying SIP header fields. > > > >> >> > > > >> >> John > > > >> >> > > > >> >> -----Original Message----- > > > >> >> From: Ram Mohan R (rmohanr) > > > >> >> Sent: Thursday, February 16, 2012 6:21 AM > > > >> >> To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew > > > >> >> Cc: siprec@ietf.org > > > >> >> Subject: Re: [siprec] Is SIPREC metadata mandatory to > > implement? > > > >> >> > > > >> >> I see some issues in going with this way: > > > >> >> > > > >> >> 1) We will end up in having two different metadata mechanisms > - > > > one > > > >> >XML > > > >> >> and one headers based > > > >> >> > > > >> >> 2) The existing SIP headers may not be sufficient to carry > even > > > the > > > >> >> basic metadata ( as partha mentioned in his previous e-mail) > > and > > > if > > > >> we > > > >> >> are going to add new headers then it is redundant as XML > > metadata > > > >> was > > > >> >> just added for that purpose. > > > >> >> > > > >> >> 3) SRC/SRS needs to negotiate on whether they want to use XML > > > based > > > >> >> metadata (SIPREC metadata) or Header based metadata and this > > will > > > >> lead > > > >> >> to more issues some of which you already outlined in the > below > > e- > > > >> mail > > > >> >> > > > >> >> So, I feel it's better to stick with one metadata (XML SIPREC > > > >> >metadata) > > > >> >> and make it mandatory. > > > >> >> > > > >> >> What we can add is some guidelines on how SRS has to behave > for > > > the > > > >> >> calls where SRC is unable to send metadata or if SRS > encounters > > > an > > > >> SRC > > > >> >> that is not completely compliant with SIPREC standards(say > does > > > not > > > >> >> implement metadata). > > > >> >> > > > >> >> Regards, > > > >> >> Ram > > > >> >> > > > >> >> > -----Original Message----- > > > >> >> > From: siprec-bounces@ietf.org [mailto:siprec- > > bounces@ietf.org] > > > On > > > >> >> > Behalf Of Charles Eckel (eckelcu) > > > >> >> > Sent: Wednesday, February 15, 2012 1:19 AM > > > >> >> > To: Paul Kyzivat; Hutton, Andrew > > > >> >> > Cc: siprec@ietf.org > > > >> >> > Subject: Re: [siprec] Is SIPREC metadata mandatory to > > > implement? > > > >> >> > > > > >> >> > Exploring this a bit further, I think this would define a > new > > > >> option > > > >> >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in a > > > >> >Supported > > > >> >> > vs. Required header. In the event metadata is not used > > between > > > >the > > > >> >> SRC > > > >> >> > and SRS, a well documented set of SIP headers could be used > > to > > > >> >convey > > > >> >> > specific information about the recording. > > > >> >> > > > > >> >> > I do see some value in this. If we go this route, the next > > > >> question > > > >> >> is, > > > >> >> > do you mandate support for this SIP headers AND avoid any > > > overlap > > > >> >> > between them and the XML metadata? Or do we say that the > XML > > > >> >> metadata, > > > >> >> > if present, supersedes anything conveyed via the SIP > headers? > > > >> Seeing > > > >> >> as > > > >> >> > XML metadata is a key part of SIPREC, I would suspect the > > > latter, > > > >> >but > > > >> >> I > > > >> >> > am interested to hear what others think. > > > >> >> > > > > >> >> > Cheers, > > > >> >> > Charles > > > >> >> > > > > >> >> > > -----Original Message----- > > > >> >> > > From: siprec-bounces@ietf.org [mailto:siprec- > > > bounces@ietf.org] > > > >> On > > > >> >> > > Behalf Of Paul Kyzivat > > > >> >> > > Sent: Tuesday, February 14, 2012 11:06 AM > > > >> >> > > To: Hutton, Andrew > > > >> >> > > Cc: siprec@ietf.org > > > >> >> > > Subject: Re: [siprec] Is SIPREC metadata mandatory to > > > >implement? > > > >> >> > > > > > >> >> > > On 2/14/12 12:59 PM, Hutton, Andrew wrote: > > > >> >> > > > On 2/14/12 15:11 Paul, Kyzivat, Andrew wrote: > > > >> >> > > >> > > > >> >> > > >> I guess it isn't *necessary* to specify that. But > there > > > are > > > >> >> > > >> consequences to not doing so: > > > >> >> > > >> > > > >> >> > > >> An SRC may have been getting acceptable results not > > > >> specifying > > > >> >> > > >> metadata. > > > >> >> > > >> Then the SRS gets replaced with a different one and > > > results > > > >> are > > > >> >> no > > > >> >> > > >> longer acceptable because the new one doesn't infer > > things > > > >> the > > > >> >> > same > > > >> >> > > >> way. > > > >> >> > > >> > > > >> >> > > > > > > >> >> > > > I think we can live with this if metadata is really > > > important > > > >> to > > > >> >> a > > > >> >> > > solution then the SRC will need to generate SIPREC > > metadata. > > > >> >> > > > > > >> >> > > Maybe. But there is a big hurdle between not supplied > > > metadata > > > >> and > > > >> >> > > supplying it. If the metadata is optional, then its quite > > > >> possible > > > >> >> > that > > > >> >> > > you will have SRCs that just aren't capable of doing so. > > > (Most > > > >> >> likely > > > >> >> > > for some simple cases like a UA that is its own SRC.) > > > >> >> > > > > > >> >> > > Then you might get locked in to an SRS that handles that > > case > > > >as > > > >> >> you > > > >> >> > > like. You will start having proprietary islands if SRCs > and > > > >SRSs > > > >> >> that > > > >> >> > > can work together. > > > >> >> > > > > > >> >> > > 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 > > > >> > > > > >> >_______________________________________________ > > > >> >siprec mailing list > > > >> >siprec@ietf.org > > > >> >https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Fri Feb 24 08:26:50 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A869221F8882 for ; Fri, 24 Feb 2012 08:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxDCcd8gqbbi for ; Fri, 24 Feb 2012 08:26:50 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CB72D21F8810 for ; Fri, 24 Feb 2012 08:26:49 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 5C6BB1EB8485 for ; Fri, 24 Feb 2012 17:26:48 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 24 Feb 2012 17:26:48 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" Date: Fri, 24 Feb 2012 17:26:46 +0100 Thread-Topic: IETF83 SIPREC Meeting Scheduled. Thread-Index: AczzERo7cpSdT2UMTSe8J+wt6VET9A== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31294481EE4@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] IETF83 SIPREC Meeting Scheduled. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 16:26:51 -0000 Hi All, The SIPREC meeting at IETF83 has been scheduled this is still subject to ch= ange if conflicts need to be resolved. siprec Session 1 (2 hours) Friday, Morning Session I 0900-1100 Room Name: 243 --------------------------------------------- =20 Regards Andy From andrew.hutton@siemens-enterprise.com Fri Feb 24 08:30:40 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636E921F86B3 for ; Fri, 24 Feb 2012 08:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPrajGhOL7-m for ; Fri, 24 Feb 2012 08:30:39 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 17CAB21F8735 for ; Fri, 24 Feb 2012 08:30:38 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 694B41EB841B; Fri, 24 Feb 2012 17:30:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 24 Feb 2012 17:30:37 +0100 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , "Ravindran, Parthasarathi" , Paul Kyzivat Date: Fri, 24 Feb 2012 17:30:36 +0100 Thread-Topic: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?] Thread-Index: AQHM8c1FGYhD9DGhCESahXQz/mAjl5ZK9iOggAFJM6A= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><4F394FE6.4000709@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E03F8EA@inba-mail01.sonusnet.com><101C6067BEC68246B0C3F6843BCCC1E31202E3205F@MCHP058A.global-ad.net><4F3A799E.9000508@alum.mit.edu><101C6067BEC68246B0C3F6843BCCC1E31202E324FC@MCHP058A.global-ad.net><4F3AB0A4.80309@alum.mit.edu><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.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] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 16:30:40 -0000 I agree but would add that it also works in the opposite direction in that = the SRS can use the option tag in the same way to indicate whether it requi= res the SRC to support metadata. Regards Andy > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 23 February 2012 20:56 > To: Ravindran, Parthasarathi; Paul Kyzivat > Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon Portman; > siprec@ietf.org > Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: > [siprec] Is SIPREC metadata mandatory to implement?] >=20 > Hi Partha, >=20 > If the SRC requires the SRS support SIPREC XML metadata, it can > indicate > that by including "siprec" option tag in a Require header. > However, the SRC may not require this, in which case including "siprec" > option tag in Supported header is appropriate. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > > Sent: Wednesday, February 22, 2012 5:49 PM > > To: Charles Eckel (eckelcu); Paul Kyzivat > > Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon Portman; > > siprec@ietf.org > > Subject: Is SIPREC metadata mandatory to implement in RS [was RE: > > [siprec] Is SIPREC metadata mandatory to implement?] > > > > Hi Charles, > > > > Thanks for the clarification. I understand that we are talking about > > two > > different stuff. So, I have changed the subject of the mail as > > "Is SIPREC metadata mandatory to implement in Recording Session(RS)". > > > > Hi all, > > > > Till now, I have not seen anybody has objection for supporting SIRPEC > > metadata in RS. Please correct me in case my understanding is wrong. > > > > Also, I propose to change the following normative statement from > > "SHOULD" > > To "MUST" in recording session: > > > > "An SRC SHOULD include the "siprec" option tag in the Require header > > when > > initiating a Recording Session so that other types of user agents can > > simply reject the INVITE request with a 420 Bad Extension." > > > > as > > > > "An SRC MUST include the "siprec" option tag in the Require header > when > > initiating a Recording Session so that other types of user agents can > > simply reject the INVITE request with a 420 Bad Extension." > > > > Please let me know your opinion on the same. > > > > Thanks > > Partha > > >-----Original Message----- > > >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > >Sent: Thursday, February 23, 2012 2:45 AM > > >To: Paul Kyzivat > > >Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; > > >Hutton, Andrew; Leon Portman; siprec@ietf.org > > >Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > > > > > >Hi Paul, > > > > > >An SRC could use it when it registers itself with a call control > > server, > > >or when it sends/receives a SIP INVITE to/from an UA/MCU to join a > > call. > > >This way the UA/MCU knows it has the ability to request specific > media > > >streams within the SIP dialog between it and the SRC be recorded > using > > >the recording-pref attribute. How the SRC accomplishes this is > likely > > >not important to the UA/MCU. The SRC indicates that it is recording > > >using the record attribute. The record-aware option tag could be > > >leveraged her as well. > > > > > >Cheers, > > >Charles > > > > > > > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > >> Sent: Wednesday, February 22, 2012 12:58 PM > > >> To: Charles Eckel (eckelcu) > > >> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; > > >> Hutton, Andrew; Leon Portman; siprec@ietf.org > > >> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > > >> > > >> Charles, > > >> > > >> Do you see any case where it would be valid to use sip.src or > > sip.srs > > >> *without* supporting the siprec option tag? > > >> > > >> Below it sounds like you do, but I don't see how that makes sense. > > >> > > >> Thanks, > > >> Paul > > >> > > >> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: > > >> > Based on the responses, either my proposal was not clear, or my > > >> > understanding of the options and feature tags is incorrect, or > > both. > > >> Let > > >> > me try again. > > >> > My intention is not to lower the bar for SIPREC compliance. What > I > > >> > propose is: > > >> > > > >> > 1) clarify that the "siprec" option tag, in addition to what is > > >> already > > >> > stated, indicates that the XML metadata is supposed. You cannot > > >> include > > >> > the "siprec" option tag in a Supported/Require header unless you > > >> support > > >> > the XML metadata, as it is the essence of SIPREC. > > >> > > > >> > 2) all other SIP/SDP extensions defined in the protocol draft > > >> (sip.src, > > >> > sip.srs, recording-aware, etc.) are just that, SIP/SDP > extensions. > > >> There > > >> > are not tied directly to the "siprec" option tag and may be used > > >> without > > >> > the "siprec" option tag. > > >> > > > >> > If an SRC or SRS supports SIPREC XML metadata, it may indicate > > that > > >> by > > >> > including "siprec" in a Supported header. > > >> > If an SRC or SRS requires SIPREC XML, it may indicate that by > > >> including > > >> > "siprec" in a Require header. > > >> > > > >> > I do not see this as lowering the bar for SIPREC compliance. > > >> > I do see it as providing benefit for implementations that have > no > > >> > intention of being a SIPREC compliant SRC or SRS. > > >> > I also see it helping with interworking between SIPREC compliant > > and > > >> non > > >> > SIPREC compliant entities. > > >> > > > >> > Cheers, > > >> > Charles From pkyzivat@alum.mit.edu Fri Feb 24 09:02:25 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCB821F8860 for ; Fri, 24 Feb 2012 09:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuilyGdUwdm2 for ; Fri, 24 Feb 2012 09:02:24 -0800 (PST) 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 6B0DB21F883F for ; Fri, 24 Feb 2012 09:02:24 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id ds7G1i00127AodY53t2QWY; Fri, 24 Feb 2012 17:02:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id dt2Q1i00Q07duvL3ft2Qnh; Fri, 24 Feb 2012 17:02:24 +0000 Message-ID: <4F47C29F.1030307@alum.mit.edu> Date: Fri, 24 Feb 2012 12:02:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hutton, Andrew" References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 17:02:25 -0000 On 2/24/12 11:30 AM, Hutton, Andrew wrote: > I agree but would add that it also works in the opposite direction in that the SRS can use the option tag in the same way to indicate whether it requires the SRC to support metadata. If we agree that metadata support is required of both SRCs and SRSs, then signaling that you are an SRC or SRS should be sufficient, without separately indicating supprot for metadata. Thanks, Paul > Regards > Andy > >> -----Original Message----- >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> Sent: 23 February 2012 20:56 >> To: Ravindran, Parthasarathi; Paul Kyzivat >> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon Portman; >> siprec@ietf.org >> Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: >> [siprec] Is SIPREC metadata mandatory to implement?] >> >> Hi Partha, >> >> If the SRC requires the SRS support SIPREC XML metadata, it can >> indicate >> that by including "siprec" option tag in a Require header. >> However, the SRC may not require this, in which case including "siprec" >> option tag in Supported header is appropriate. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>> Sent: Wednesday, February 22, 2012 5:49 PM >>> To: Charles Eckel (eckelcu); Paul Kyzivat >>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon Portman; >>> siprec@ietf.org >>> Subject: Is SIPREC metadata mandatory to implement in RS [was RE: >>> [siprec] Is SIPREC metadata mandatory to implement?] >>> >>> Hi Charles, >>> >>> Thanks for the clarification. I understand that we are talking about >>> two >>> different stuff. So, I have changed the subject of the mail as >>> "Is SIPREC metadata mandatory to implement in Recording Session(RS)". >>> >>> Hi all, >>> >>> Till now, I have not seen anybody has objection for supporting SIRPEC >>> metadata in RS. Please correct me in case my understanding is wrong. >>> >>> Also, I propose to change the following normative statement from >>> "SHOULD" >>> To "MUST" in recording session: >>> >>> "An SRC SHOULD include the "siprec" option tag in the Require header >>> when >>> initiating a Recording Session so that other types of user agents can >>> simply reject the INVITE request with a 420 Bad Extension." >>> >>> as >>> >>> "An SRC MUST include the "siprec" option tag in the Require header >> when >>> initiating a Recording Session so that other types of user agents can >>> simply reject the INVITE request with a 420 Bad Extension." >>> >>> Please let me know your opinion on the same. >>> >>> Thanks >>> Partha >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>> Sent: Thursday, February 23, 2012 2:45 AM >>>> To: Paul Kyzivat >>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; >>>> Hutton, Andrew; Leon Portman; siprec@ietf.org >>>> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >>>> >>>> Hi Paul, >>>> >>>> An SRC could use it when it registers itself with a call control >>> server, >>>> or when it sends/receives a SIP INVITE to/from an UA/MCU to join a >>> call. >>>> This way the UA/MCU knows it has the ability to request specific >> media >>>> streams within the SIP dialog between it and the SRC be recorded >> using >>>> the recording-pref attribute. How the SRC accomplishes this is >> likely >>>> not important to the UA/MCU. The SRC indicates that it is recording >>>> using the record attribute. The record-aware option tag could be >>>> leveraged her as well. >>>> >>>> Cheers, >>>> Charles >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Wednesday, February 22, 2012 12:58 PM >>>>> To: Charles Eckel (eckelcu) >>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; >>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org >>>>> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >>>>> >>>>> Charles, >>>>> >>>>> Do you see any case where it would be valid to use sip.src or >>> sip.srs >>>>> *without* supporting the siprec option tag? >>>>> >>>>> Below it sounds like you do, but I don't see how that makes sense. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: >>>>>> Based on the responses, either my proposal was not clear, or my >>>>>> understanding of the options and feature tags is incorrect, or >>> both. >>>>> Let >>>>>> me try again. >>>>>> My intention is not to lower the bar for SIPREC compliance. What >> I >>>>>> propose is: >>>>>> >>>>>> 1) clarify that the "siprec" option tag, in addition to what is >>>>> already >>>>>> stated, indicates that the XML metadata is supposed. You cannot >>>>> include >>>>>> the "siprec" option tag in a Supported/Require header unless you >>>>> support >>>>>> the XML metadata, as it is the essence of SIPREC. >>>>>> >>>>>> 2) all other SIP/SDP extensions defined in the protocol draft >>>>> (sip.src, >>>>>> sip.srs, recording-aware, etc.) are just that, SIP/SDP >> extensions. >>>>> There >>>>>> are not tied directly to the "siprec" option tag and may be used >>>>> without >>>>>> the "siprec" option tag. >>>>>> >>>>>> If an SRC or SRS supports SIPREC XML metadata, it may indicate >>> that >>>>> by >>>>>> including "siprec" in a Supported header. >>>>>> If an SRC or SRS requires SIPREC XML, it may indicate that by >>>>> including >>>>>> "siprec" in a Require header. >>>>>> >>>>>> I do not see this as lowering the bar for SIPREC compliance. >>>>>> I do see it as providing benefit for implementations that have >> no >>>>>> intention of being a SIPREC compliant SRC or SRS. >>>>>> I also see it helping with interworking between SIPREC compliant >>> and >>>>> non >>>>>> SIPREC compliant entities. >>>>>> >>>>>> Cheers, >>>>>> Charles > From eckelcu@cisco.com Fri Feb 24 14:11:18 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E9721F85D3 for ; Fri, 24 Feb 2012 14:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.782 X-Spam-Level: X-Spam-Status: No, score=-8.782 tagged_above=-999 required=5 tests=[AWL=1.218, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDIE+jEObm1W for ; Fri, 24 Feb 2012 14:11:12 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D6AA621F8557 for ; Fri, 24 Feb 2012 14:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=8318; q=dns/txt; s=iport; t=1330121473; x=1331331073; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=lORuoio7g2M/Tz9DTkMt04mqCKMe5jMoLABgscbpcpQ=; b=bxcaWQpjgyLp9cLIHr98/lXV6zJUfctS3HGBxiIEp8GW4q8Gv0Pnnp61 YYK7QCDsEPjFGxqgQ4t2hiU/fQUri5kbOI62Zd36iWtlgTzlVxWKIp+Ip EmPQl/9/gKmuNi9ZPcHgJObATGL1yn3md4MSuxlBh1J09dmvVDt00d1EU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOMJSE+rRDoI/2dsb2JhbABDDrMTgQeBcwEBAQQSAR0KPwwEAgEIDgMEAQEBCgYTBAEGAUUJCAEBBBMIGodjAaA/AZZriXiDEwECEgMOBkeEZwFgBAcDCQUCAR8VD4JKYwSIT58kWIE7 X-IronPort-AV: E=Sophos;i="4.73,478,1325462400"; d="scan'208";a="32241298" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 24 Feb 2012 22:11:12 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1OMBCvl025148; Fri, 24 Feb 2012 22:11:12 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 14:11:12 -0800 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, 24 Feb 2012 14:11:11 -0800 Message-ID: In-Reply-To: <4F47C29F.1030307@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?] Thread-Index: AczzFhkniolzjbajSZKNX9CxfAcNEgAKKtTA References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> <4F47C29F.1030307@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , "Hutton, Andrew" X-OriginalArrivalTime: 24 Feb 2012 22:11:12.0626 (UTC) FILETIME=[38158520:01CCF341] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 22:11:18 -0000 I think SIPREC metadata is applicable to the RS between the SRC and SRS only, but I have been suggesting that it not be mandatory to support and use, in that an SRC or SRS could still use the sip.src or sip.srs feature tags despite not supporting or using the XML metadata within all RSs.=20 Andy raised a very good point, that this breaks the functionality of using the siprec option tag to indicate that an INVITE is for the necessary purpose of creating an RS, and should be rejected if the other side is not willing or capable of creating an RS. Consequently, we have a few choices: a) siprec option tag in a Supported/Require header means an RS is supported/required AND XML metadata is supported/required for this RS b) siprec option tag in a Supported/Require header means XML metadata is supported/required and another option tag is used to specify whether an RS is Supported/Required c) siprec option tag in a Supported/Require header means an RS is supported/required and another option tag is used to specify whether an RS is Supported/Required I believe Partha was advocating (a). Options (b) and (c) could be handled by replacing the single siprec options tag with two tags, siprec-rs for the RS, and siprec-metadata for the metadata. I am okay with (a), (b), or (c), so long as it is still possible to use the sip.src and sip.srs feature tags without necessarily having to support or use the XML metadata. Cheers, Charles > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, February 24, 2012 9:02 AM > To: Hutton, Andrew > Cc: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Ram Mohan R > (rmohanr); John Elwell; Leon Portman; siprec@ietf.org > Subject: Re: Is SIPREC metadata mandatory to implement in RS [was RE: > [siprec] Is SIPREC metadata mandatory to implement?] >=20 > On 2/24/12 11:30 AM, Hutton, Andrew wrote: > > I agree but would add that it also works in the opposite direction in > that the SRS can use the option tag in the same way to indicate whether > it requires the SRC to support metadata. >=20 > If we agree that metadata support is required of both SRCs and SRSs, > then signaling that you are an SRC or SRS should be sufficient, without > separately indicating supprot for metadata. >=20 > Thanks, > Paul >=20 > > Regards > > Andy > > > >> -----Original Message----- > >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >> Sent: 23 February 2012 20:56 > >> To: Ravindran, Parthasarathi; Paul Kyzivat > >> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon > Portman; > >> siprec@ietf.org > >> Subject: RE: Is SIPREC metadata mandatory to implement in RS [was > RE: > >> [siprec] Is SIPREC metadata mandatory to implement?] > >> > >> Hi Partha, > >> > >> If the SRC requires the SRS support SIPREC XML metadata, it can > >> indicate > >> that by including "siprec" option tag in a Require header. > >> However, the SRC may not require this, in which case including > "siprec" > >> option tag in Supported header is appropriate. > >> > >> Cheers, > >> Charles > >> > >>> -----Original Message----- > >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >>> Sent: Wednesday, February 22, 2012 5:49 PM > >>> To: Charles Eckel (eckelcu); Paul Kyzivat > >>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon > Portman; > >>> siprec@ietf.org > >>> Subject: Is SIPREC metadata mandatory to implement in RS [was RE: > >>> [siprec] Is SIPREC metadata mandatory to implement?] > >>> > >>> Hi Charles, > >>> > >>> Thanks for the clarification. I understand that we are talking > about > >>> two > >>> different stuff. So, I have changed the subject of the mail as > >>> "Is SIPREC metadata mandatory to implement in Recording > Session(RS)". > >>> > >>> Hi all, > >>> > >>> Till now, I have not seen anybody has objection for supporting > SIRPEC > >>> metadata in RS. Please correct me in case my understanding is > wrong. > >>> > >>> Also, I propose to change the following normative statement from > >>> "SHOULD" > >>> To "MUST" in recording session: > >>> > >>> "An SRC SHOULD include the "siprec" option tag in the Require > header > >>> when > >>> initiating a Recording Session so that other types of user agents > can > >>> simply reject the INVITE request with a 420 Bad Extension." > >>> > >>> as > >>> > >>> "An SRC MUST include the "siprec" option tag in the Require header > >> when > >>> initiating a Recording Session so that other types of user agents > can > >>> simply reject the INVITE request with a 420 Bad Extension." > >>> > >>> Please let me know your opinion on the same. > >>> > >>> Thanks > >>> Partha > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>> Sent: Thursday, February 23, 2012 2:45 AM > >>>> To: Paul Kyzivat > >>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; > >>>> Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > >>>> > >>>> Hi Paul, > >>>> > >>>> An SRC could use it when it registers itself with a call control > >>> server, > >>>> or when it sends/receives a SIP INVITE to/from an UA/MCU to join a > >>> call. > >>>> This way the UA/MCU knows it has the ability to request specific > >> media > >>>> streams within the SIP dialog between it and the SRC be recorded > >> using > >>>> the recording-pref attribute. How the SRC accomplishes this is > >> likely > >>>> not important to the UA/MCU. The SRC indicates that it is > recording > >>>> using the record attribute. The record-aware option tag could be > >>>> leveraged her as well. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>>>> Sent: Wednesday, February 22, 2012 12:58 PM > >>>>> To: Charles Eckel (eckelcu) > >>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; > >>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>>> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? > >>>>> > >>>>> Charles, > >>>>> > >>>>> Do you see any case where it would be valid to use sip.src or > >>> sip.srs > >>>>> *without* supporting the siprec option tag? > >>>>> > >>>>> Below it sounds like you do, but I don't see how that makes > sense. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: > >>>>>> Based on the responses, either my proposal was not clear, or my > >>>>>> understanding of the options and feature tags is incorrect, or > >>> both. > >>>>> Let > >>>>>> me try again. > >>>>>> My intention is not to lower the bar for SIPREC compliance. What > >> I > >>>>>> propose is: > >>>>>> > >>>>>> 1) clarify that the "siprec" option tag, in addition to what is > >>>>> already > >>>>>> stated, indicates that the XML metadata is supposed. You cannot > >>>>> include > >>>>>> the "siprec" option tag in a Supported/Require header unless you > >>>>> support > >>>>>> the XML metadata, as it is the essence of SIPREC. > >>>>>> > >>>>>> 2) all other SIP/SDP extensions defined in the protocol draft > >>>>> (sip.src, > >>>>>> sip.srs, recording-aware, etc.) are just that, SIP/SDP > >> extensions. > >>>>> There > >>>>>> are not tied directly to the "siprec" option tag and may be used > >>>>> without > >>>>>> the "siprec" option tag. > >>>>>> > >>>>>> If an SRC or SRS supports SIPREC XML metadata, it may indicate > >>> that > >>>>> by > >>>>>> including "siprec" in a Supported header. > >>>>>> If an SRC or SRS requires SIPREC XML, it may indicate that by > >>>>> including > >>>>>> "siprec" in a Require header. > >>>>>> > >>>>>> I do not see this as lowering the bar for SIPREC compliance. > >>>>>> I do see it as providing benefit for implementations that have > >> no > >>>>>> intention of being a SIPREC compliant SRC or SRS. > >>>>>> I also see it helping with interworking between SIPREC compliant > >>> and > >>>>> non > >>>>>> SIPREC compliant entities. > >>>>>> > >>>>>> Cheers, > >>>>>> Charles > > From eckelcu@cisco.com Fri Feb 24 14:18:46 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EAD21F8683 for ; Fri, 24 Feb 2012 14:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.511 X-Spam-Level: X-Spam-Status: No, score=-8.511 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JpZtWpmkKE3 for ; Fri, 24 Feb 2012 14:18:46 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5971021F8642 for ; Fri, 24 Feb 2012 14:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2207; q=dns/txt; s=iport; t=1330121926; x=1331331526; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=efNBJNMz1Hi8/KqDjUgUeTJ9Ma9CV0qOlWL+c3JOFIg=; b=erUlk7nHjVPsWS6/zxfDgWS7Ch3wSAPNXhJxYiM2pkhGypoi1WakAzyk cBNQ+aMVzIhj0npM7i54TaK3QZmxWP24Et7W7puEvyXNGD0bOOJx4xFw1 /pOTr1eSmopdjWslThv+z13n8DOy03GHNK1XfiozIlAWSp0zO0QGcwUOw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC8MSE+rRDoI/2dsb2JhbABEsyGBB4FzAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHYwELoDEBlmgEjRwNDkcRCAKETAGBBxoSDIJNYwSIT598 X-IronPort-AV: E=Sophos;i="4.73,478,1325462400"; d="scan'208";a="32375712" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 24 Feb 2012 22:18:46 +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 q1OMIkVe029731; Fri, 24 Feb 2012 22:18: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); Fri, 24 Feb 2012 14:18:46 -0800 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, 24 Feb 2012 14:18:45 -0800 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF74082E138A@NAHALD.us.int.genesyslab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] recordpref and record SDP attributes Thread-Index: AczxqBzrXscnPkYrTqmPlfkBFrvdBABaVgnAAAv3SJA= References: <059AF07365DC474393A19A3AF187DF74082E138A@NAHALD.us.int.genesyslab.com> From: "Charles Eckel (eckelcu)" To: "Henry Lum" , X-OriginalArrivalTime: 24 Feb 2012 22:18:46.0120 (UTC) FILETIME=[46633680:01CCF342] Subject: Re: [siprec] recordpref and record SDP attributes X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2012 22:18:47 -0000 Hi Henry, The record and recordpref attributes may be used in the CS and RS. I am not suggesting tying them together or requiring them to be related to each other in any particular fashion. What I was hoping to clarify is if when a UA adds a recordpref=3Don attribute to a sendrecv media stream, that means that UA prefers that both the media it is sending as well as the media it is receiving be recorded. What the SRC decides to do and it related to the media streams between the SRC and the SRS is up to the SRC. Cheers, Charles > -----Original Message----- > From: Henry Lum [mailto:Henry.Lum@genesyslab.com] > Sent: Friday, February 24, 2012 8:30 AM > To: Charles Eckel (eckelcu); siprec@ietf.org > Subject: RE: [siprec] recordpref and record SDP attributes >=20 > I realized my message was sent by wasn't posted for some reason - > reposting. >=20 > The attributes recordpref and record only declares whether you want to > record and whether recording is happening at the session or media > level. > The attributes do not indicate or imply the directionality of the > recording that is happening. The SRC may choose to mix multiple streams > in the session to record and I don't see an elegant way for the SRC to > present that level of detail. Is there a specific reason for needing > this level of detail? >=20 > Henry >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Charles Eckel (eckelcu) > > Sent: February-22-12 4:23 PM > > To: siprec@ietf.org > > Subject: [siprec] recordpref and record SDP attributes > > > > My assumption is that these SDP attributes, when used at the session > or > > media level, apply to the media as stated by the media mode > attribute, > > meaning that if the mode is "sendrecv", recordpref=3Don is a request to > > record both the media being sent to as well as the media being > received > > by the requestor. Similarly for record=3Don. > > Is that correct? > > > > Thanks, > > Charles > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From pravindran@sonusnet.com Sun Feb 26 22:32:15 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3868121F84DA for ; Sun, 26 Feb 2012 22:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ebyY6E8hhma for ; Sun, 26 Feb 2012 22:32:14 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 19EC121F8542 for ; Sun, 26 Feb 2012 22:32:14 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1R6WwVY008856; Mon, 27 Feb 2012 01:32:58 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 01:32:09 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 12:02:06 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 27 Feb 2012 12:02:05 +0530 From: "Ravindran, Parthasarathi" To: "Charles Eckel (eckelcu)" , Paul Kyzivat , "Hutton, Andrew" Thread-Topic: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?] Thread-Index: AQHM8c1FGYhD9DGhCESahXQz/mAjl5ZK9iOggAFJM6D//60DgIAAVkeAgAQImxA= Date: Mon, 27 Feb 2012 06:32:05 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04CDBE@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> <4F47C29F.1030307@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 06:32:06.0227 (UTC) FILETIME=[86409A30:01CCF519] Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2012 06:32:15 -0000 Hi Charles, Sorry in case my request for "siprec option tag MUST normative requirement"= request created some confusion here. IMO, siprec option tag in a Supported= /Require header means RS is supported/required. I have proposed "MUST" in s= iprec option as I didn't any reason for leniency to specify as "SHOULD".=20 Hi all, As far as the metadata is considered, I'm still look for the words to indic= ate "SRC and SRS MUST implement SIPREC metadata XML". It may be preferred t= o indicates that SRC MUST implement metadata XML encoding whereas SRS MUST = implement metadata XML decoding. Even though John indicated in his mail abo= ut metadata mandating, RFC 3261 does not have any explicit requirement to s= ay "application/sdp" MUST be supported in SIP UAC and UAS but instead, ther= e are requirement in INVITE, OPTIONS to send "application/sdp" message body= and UAS to assume "application/sdp" in accept header if nothing is mention= ed. It will be good to see the exact metadata requirement to convey this. Thanks Partha=20 >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Saturday, February 25, 2012 3:41 AM >To: Paul Kyzivat; Hutton, Andrew >Cc: Ravindran, Parthasarathi; Ram Mohan R (rmohanr); John Elwell; Leon >Portman; siprec@ietf.org >Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: >[siprec] Is SIPREC metadata mandatory to implement?] > >I think SIPREC metadata is applicable to the RS between the SRC and SRS >only, but I have been suggesting that it not be mandatory to support and >use, in that an SRC or SRS could still use the sip.src or sip.srs >feature tags despite not supporting or using the XML metadata within all >RSs. > >Andy raised a very good point, that this breaks the functionality of >using the siprec option tag to indicate that an INVITE is for the >necessary purpose of creating an RS, and should be rejected if the other >side is not willing or capable of creating an RS. Consequently, we have >a few choices: > >a) siprec option tag in a Supported/Require header means an RS is >supported/required AND XML metadata is supported/required for this RS >b) siprec option tag in a Supported/Require header means XML metadata is >supported/required and another option tag is used to specify whether an >RS is Supported/Required >c) siprec option tag in a Supported/Require header means an RS is >supported/required and another option tag is used to specify whether an >RS is Supported/Required > >I believe Partha was advocating (a). >Options (b) and (c) could be handled by replacing the single siprec >options tag with two tags, siprec-rs for the RS, and siprec-metadata for >the metadata. >I am okay with (a), (b), or (c), so long as it is still possible to use >the sip.src and sip.srs feature tags without necessarily having to >support or use the XML metadata. > >Cheers, >Charles > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, February 24, 2012 9:02 AM >> To: Hutton, Andrew >> Cc: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Ram Mohan R >> (rmohanr); John Elwell; Leon Portman; siprec@ietf.org >> Subject: Re: Is SIPREC metadata mandatory to implement in RS [was RE: >> [siprec] Is SIPREC metadata mandatory to implement?] >> >> On 2/24/12 11:30 AM, Hutton, Andrew wrote: >> > I agree but would add that it also works in the opposite direction >in >> that the SRS can use the option tag in the same way to indicate >whether >> it requires the SRC to support metadata. >> >> If we agree that metadata support is required of both SRCs and SRSs, >> then signaling that you are an SRC or SRS should be sufficient, >without >> separately indicating supprot for metadata. >> >> Thanks, >> Paul >> >> > Regards >> > Andy >> > >> >> -----Original Message----- >> >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> >> Sent: 23 February 2012 20:56 >> >> To: Ravindran, Parthasarathi; Paul Kyzivat >> >> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >> Portman; >> >> siprec@ietf.org >> >> Subject: RE: Is SIPREC metadata mandatory to implement in RS [was >> RE: >> >> [siprec] Is SIPREC metadata mandatory to implement?] >> >> >> >> Hi Partha, >> >> >> >> If the SRC requires the SRS support SIPREC XML metadata, it can >> >> indicate that by including "siprec" option tag in a Require header. >> >> However, the SRC may not require this, in which case including >> "siprec" >> >> option tag in Supported header is appropriate. >> >> >> >> Cheers, >> >> Charles >> >> >> >>> -----Original Message----- >> >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> >>> Sent: Wednesday, February 22, 2012 5:49 PM >> >>> To: Charles Eckel (eckelcu); Paul Kyzivat >> >>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >> Portman; >> >>> siprec@ietf.org >> >>> Subject: Is SIPREC metadata mandatory to implement in RS [was RE: >> >>> [siprec] Is SIPREC metadata mandatory to implement?] >> >>> >> >>> Hi Charles, >> >>> >> >>> Thanks for the clarification. I understand that we are talking >> about >> >>> two >> >>> different stuff. So, I have changed the subject of the mail as "Is >> >>> SIPREC metadata mandatory to implement in Recording >> Session(RS)". >> >>> >> >>> Hi all, >> >>> >> >>> Till now, I have not seen anybody has objection for supporting >> SIRPEC >> >>> metadata in RS. Please correct me in case my understanding is >> wrong. >> >>> >> >>> Also, I propose to change the following normative statement from >> >>> "SHOULD" >> >>> To "MUST" in recording session: >> >>> >> >>> "An SRC SHOULD include the "siprec" option tag in the Require >> header >> >>> when >> >>> initiating a Recording Session so that other types of user agents >> can >> >>> simply reject the INVITE request with a 420 Bad Extension." >> >>> >> >>> as >> >>> >> >>> "An SRC MUST include the "siprec" option tag in the Require header >> >> when >> >>> initiating a Recording Session so that other types of user agents >> can >> >>> simply reject the INVITE request with a 420 Bad Extension." >> >>> >> >>> Please let me know your opinion on the same. >> >>> >> >>> Thanks >> >>> Partha >> >>>> -----Original Message----- >> >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> >>>> Sent: Thursday, February 23, 2012 2:45 AM >> >>>> To: Paul Kyzivat >> >>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; >> >>>> Hutton, Andrew; Leon Portman; siprec@ietf.org >> >>>> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >> >>>> >> >>>> Hi Paul, >> >>>> >> >>>> An SRC could use it when it registers itself with a call control >> >>> server, >> >>>> or when it sends/receives a SIP INVITE to/from an UA/MCU to join >a >> >>> call. >> >>>> This way the UA/MCU knows it has the ability to request specific >> >> media >> >>>> streams within the SIP dialog between it and the SRC be recorded >> >> using >> >>>> the recording-pref attribute. How the SRC accomplishes this is >> >> likely >> >>>> not important to the UA/MCU. The SRC indicates that it is >> recording >> >>>> using the record attribute. The record-aware option tag could be >> >>>> leveraged her as well. >> >>>> >> >>>> Cheers, >> >>>> Charles >> >>>> >> >>>> >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> >>>>> Sent: Wednesday, February 22, 2012 12:58 PM >> >>>>> To: Charles Eckel (eckelcu) >> >>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, >Parthasarathi; >> >>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org >> >>>>> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >>>>> >> >>>>> Charles, >> >>>>> >> >>>>> Do you see any case where it would be valid to use sip.src or >> >>> sip.srs >> >>>>> *without* supporting the siprec option tag? >> >>>>> >> >>>>> Below it sounds like you do, but I don't see how that makes >> sense. >> >>>>> >> >>>>> Thanks, >> >>>>> Paul >> >>>>> >> >>>>> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: >> >>>>>> Based on the responses, either my proposal was not clear, or my >> >>>>>> understanding of the options and feature tags is incorrect, or >> >>> both. >> >>>>> Let >> >>>>>> me try again. >> >>>>>> My intention is not to lower the bar for SIPREC compliance. >What >> >> I >> >>>>>> propose is: >> >>>>>> >> >>>>>> 1) clarify that the "siprec" option tag, in addition to what is >> >>>>> already >> >>>>>> stated, indicates that the XML metadata is supposed. You cannot >> >>>>> include >> >>>>>> the "siprec" option tag in a Supported/Require header unless >you >> >>>>> support >> >>>>>> the XML metadata, as it is the essence of SIPREC. >> >>>>>> >> >>>>>> 2) all other SIP/SDP extensions defined in the protocol draft >> >>>>> (sip.src, >> >>>>>> sip.srs, recording-aware, etc.) are just that, SIP/SDP >> >> extensions. >> >>>>> There >> >>>>>> are not tied directly to the "siprec" option tag and may be >used >> >>>>> without >> >>>>>> the "siprec" option tag. >> >>>>>> >> >>>>>> If an SRC or SRS supports SIPREC XML metadata, it may indicate >> >>> that >> >>>>> by >> >>>>>> including "siprec" in a Supported header. >> >>>>>> If an SRC or SRS requires SIPREC XML, it may indicate that by >> >>>>> including >> >>>>>> "siprec" in a Require header. >> >>>>>> >> >>>>>> I do not see this as lowering the bar for SIPREC compliance. >> >>>>>> I do see it as providing benefit for implementations that have >> >> no >> >>>>>> intention of being a SIPREC compliant SRC or SRS. >> >>>>>> I also see it helping with interworking between SIPREC >compliant >> >>> and >> >>>>> non >> >>>>>> SIPREC compliant entities. >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Charles >> > From Leon.Portman@nice.com Mon Feb 27 04:38:01 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF3A21F86EE for ; Mon, 27 Feb 2012 04:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pqr60VmuQi4N for ; Mon, 27 Feb 2012 04:38:00 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF6C21F86F0 for ; Mon, 27 Feb 2012 04:38:00 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 27 Feb 2012 14:37:57 +0200 From: Leon Portman To: "Ravindran, Parthasarathi" , "Charles Eckel (eckelcu)" , Paul Kyzivat , "Hutton, Andrew" Date: Mon, 27 Feb 2012 14:37:56 +0200 Thread-Topic: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?] Thread-Index: AQHM8c1FGYhD9DGhCESahXQz/mAjl5ZK9iOggAFJM6D//60DgIAAVkeAgAQImxCAAGkU8A== Message-ID: <07465C1D981ABC41A344374066AE1A2C39DA4C6090@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> <4F47C29F.1030307@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E04CDBE@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E04CDBE@inba-mail01.sonusnet.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2012 12:38:01 -0000 Hello I am ok as well with all three options, however do we really want to compli= cate the protocol with different combinations (RS support and metadata supp= ort)? If SRC does not have/want to send any metadata, it can send empty XML= in the worst case. Leon=20 -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]=20 Sent: Monday, February 27, 2012 8:32 AM To: Charles Eckel (eckelcu); Paul Kyzivat; Hutton, Andrew Cc: Ram Mohan R (rmohanr); John Elwell; Leon Portman; siprec@ietf.org Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: [sipr= ec] Is SIPREC metadata mandatory to implement?] Hi Charles, Sorry in case my request for "siprec option tag MUST normative requirement"= request created some confusion here. IMO, siprec option tag in a Supported= /Require header means RS is supported/required. I have proposed "MUST" in s= iprec option as I didn't any reason for leniency to specify as "SHOULD".=20 Hi all, As far as the metadata is considered, I'm still look for the words to indic= ate "SRC and SRS MUST implement SIPREC metadata XML". It may be preferred t= o indicates that SRC MUST implement metadata XML encoding whereas SRS MUST = implement metadata XML decoding. Even though John indicated in his mail abo= ut metadata mandating, RFC 3261 does not have any explicit requirement to s= ay "application/sdp" MUST be supported in SIP UAC and UAS but instead, ther= e are requirement in INVITE, OPTIONS to send "application/sdp" message body= and UAS to assume "application/sdp" in accept header if nothing is mention= ed. It will be good to see the exact metadata requirement to convey this. Thanks Partha=20 >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Sent: Saturday, February 25, 2012 3:41 AM >To: Paul Kyzivat; Hutton, Andrew >Cc: Ravindran, Parthasarathi; Ram Mohan R (rmohanr); John Elwell; Leon=20 >Portman; siprec@ietf.org >Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: >[siprec] Is SIPREC metadata mandatory to implement?] > >I think SIPREC metadata is applicable to the RS between the SRC and SRS=20 >only, but I have been suggesting that it not be mandatory to support=20 >and use, in that an SRC or SRS could still use the sip.src or sip.srs=20 >feature tags despite not supporting or using the XML metadata within=20 >all RSs. > >Andy raised a very good point, that this breaks the functionality of=20 >using the siprec option tag to indicate that an INVITE is for the=20 >necessary purpose of creating an RS, and should be rejected if the=20 >other side is not willing or capable of creating an RS. Consequently,=20 >we have a few choices: > >a) siprec option tag in a Supported/Require header means an RS is=20 >supported/required AND XML metadata is supported/required for this RS >b) siprec option tag in a Supported/Require header means XML metadata=20 >is supported/required and another option tag is used to specify whether=20 >an RS is Supported/Required >c) siprec option tag in a Supported/Require header means an RS is=20 >supported/required and another option tag is used to specify whether an=20 >RS is Supported/Required > >I believe Partha was advocating (a). >Options (b) and (c) could be handled by replacing the single siprec=20 >options tag with two tags, siprec-rs for the RS, and siprec-metadata=20 >for the metadata. >I am okay with (a), (b), or (c), so long as it is still possible to use=20 >the sip.src and sip.srs feature tags without necessarily having to=20 >support or use the XML metadata. > >Cheers, >Charles > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, February 24, 2012 9:02 AM >> To: Hutton, Andrew >> Cc: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Ram Mohan R=20 >> (rmohanr); John Elwell; Leon Portman; siprec@ietf.org >> Subject: Re: Is SIPREC metadata mandatory to implement in RS [was RE: >> [siprec] Is SIPREC metadata mandatory to implement?] >> >> On 2/24/12 11:30 AM, Hutton, Andrew wrote: >> > I agree but would add that it also works in the opposite direction >in >> that the SRS can use the option tag in the same way to indicate >whether >> it requires the SRC to support metadata. >> >> If we agree that metadata support is required of both SRCs and SRSs,=20 >> then signaling that you are an SRC or SRS should be sufficient, >without >> separately indicating supprot for metadata. >> >> Thanks, >> Paul >> >> > Regards >> > Andy >> > >> >> -----Original Message----- >> >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> >> Sent: 23 February 2012 20:56 >> >> To: Ravindran, Parthasarathi; Paul Kyzivat >> >> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >> Portman; >> >> siprec@ietf.org >> >> Subject: RE: Is SIPREC metadata mandatory to implement in RS [was >> RE: >> >> [siprec] Is SIPREC metadata mandatory to implement?] >> >> >> >> Hi Partha, >> >> >> >> If the SRC requires the SRS support SIPREC XML metadata, it can=20 >> >> indicate that by including "siprec" option tag in a Require header. >> >> However, the SRC may not require this, in which case including >> "siprec" >> >> option tag in Supported header is appropriate. >> >> >> >> Cheers, >> >> Charles >> >> >> >>> -----Original Message----- >> >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> >>> Sent: Wednesday, February 22, 2012 5:49 PM >> >>> To: Charles Eckel (eckelcu); Paul Kyzivat >> >>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >> Portman; >> >>> siprec@ietf.org >> >>> Subject: Is SIPREC metadata mandatory to implement in RS [was RE: >> >>> [siprec] Is SIPREC metadata mandatory to implement?] >> >>> >> >>> Hi Charles, >> >>> >> >>> Thanks for the clarification. I understand that we are talking >> about >> >>> two >> >>> different stuff. So, I have changed the subject of the mail as=20 >> >>> "Is SIPREC metadata mandatory to implement in Recording >> Session(RS)". >> >>> >> >>> Hi all, >> >>> >> >>> Till now, I have not seen anybody has objection for supporting >> SIRPEC >> >>> metadata in RS. Please correct me in case my understanding is >> wrong. >> >>> >> >>> Also, I propose to change the following normative statement from=20 >> >>> "SHOULD" >> >>> To "MUST" in recording session: >> >>> >> >>> "An SRC SHOULD include the "siprec" option tag in the Require >> header >> >>> when >> >>> initiating a Recording Session so that other types of user agents >> can >> >>> simply reject the INVITE request with a 420 Bad Extension." >> >>> >> >>> as >> >>> >> >>> "An SRC MUST include the "siprec" option tag in the Require=20 >> >>> header >> >> when >> >>> initiating a Recording Session so that other types of user agents >> can >> >>> simply reject the INVITE request with a 420 Bad Extension." >> >>> >> >>> Please let me know your opinion on the same. >> >>> >> >>> Thanks >> >>> Partha >> >>>> -----Original Message----- >> >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> >>>> Sent: Thursday, February 23, 2012 2:45 AM >> >>>> To: Paul Kyzivat >> >>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran,=20 >> >>>> Parthasarathi; Hutton, Andrew; Leon Portman; siprec@ietf.org >> >>>> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >> >>>> >> >>>> Hi Paul, >> >>>> >> >>>> An SRC could use it when it registers itself with a call control >> >>> server, >> >>>> or when it sends/receives a SIP INVITE to/from an UA/MCU to join >a >> >>> call. >> >>>> This way the UA/MCU knows it has the ability to request specific >> >> media >> >>>> streams within the SIP dialog between it and the SRC be recorded >> >> using >> >>>> the recording-pref attribute. How the SRC accomplishes this is >> >> likely >> >>>> not important to the UA/MCU. The SRC indicates that it is >> recording >> >>>> using the record attribute. The record-aware option tag could be=20 >> >>>> leveraged her as well. >> >>>> >> >>>> Cheers, >> >>>> Charles >> >>>> >> >>>> >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> >>>>> Sent: Wednesday, February 22, 2012 12:58 PM >> >>>>> To: Charles Eckel (eckelcu) >> >>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, >Parthasarathi; >> >>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org >> >>>>> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >> >>>>> >> >>>>> Charles, >> >>>>> >> >>>>> Do you see any case where it would be valid to use sip.src or >> >>> sip.srs >> >>>>> *without* supporting the siprec option tag? >> >>>>> >> >>>>> Below it sounds like you do, but I don't see how that makes >> sense. >> >>>>> >> >>>>> Thanks, >> >>>>> Paul >> >>>>> >> >>>>> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: >> >>>>>> Based on the responses, either my proposal was not clear, or=20 >> >>>>>> my understanding of the options and feature tags is incorrect,=20 >> >>>>>> or >> >>> both. >> >>>>> Let >> >>>>>> me try again. >> >>>>>> My intention is not to lower the bar for SIPREC compliance. >What >> >> I >> >>>>>> propose is: >> >>>>>> >> >>>>>> 1) clarify that the "siprec" option tag, in addition to what=20 >> >>>>>> is >> >>>>> already >> >>>>>> stated, indicates that the XML metadata is supposed. You=20 >> >>>>>> cannot >> >>>>> include >> >>>>>> the "siprec" option tag in a Supported/Require header unless >you >> >>>>> support >> >>>>>> the XML metadata, as it is the essence of SIPREC. >> >>>>>> >> >>>>>> 2) all other SIP/SDP extensions defined in the protocol draft >> >>>>> (sip.src, >> >>>>>> sip.srs, recording-aware, etc.) are just that, SIP/SDP >> >> extensions. >> >>>>> There >> >>>>>> are not tied directly to the "siprec" option tag and may be >used >> >>>>> without >> >>>>>> the "siprec" option tag. >> >>>>>> >> >>>>>> If an SRC or SRS supports SIPREC XML metadata, it may indicate >> >>> that >> >>>>> by >> >>>>>> including "siprec" in a Supported header. >> >>>>>> If an SRC or SRS requires SIPREC XML, it may indicate that by >> >>>>> including >> >>>>>> "siprec" in a Require header. >> >>>>>> >> >>>>>> I do not see this as lowering the bar for SIPREC compliance. >> >>>>>> I do see it as providing benefit for implementations that have >> >> no >> >>>>>> intention of being a SIPREC compliant SRC or SRS. >> >>>>>> I also see it helping with interworking between SIPREC >compliant >> >>> and >> >>>>> non >> >>>>>> SIPREC compliant entities. >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Charles >> > From trac+siprec@trac.tools.ietf.org Mon Feb 27 04:42:59 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1D21F86F4 for ; Mon, 27 Feb 2012 04:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoK449OEdl-v for ; Mon, 27 Feb 2012 04:42:59 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 800D021F86F0 for ; Mon, 27 Feb 2012 04:42:54 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S1zul-0000lm-Fg; Mon, 27 Feb 2012 07:42:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: leonp@nice.com X-Trac-Project: siprec Date: Mon, 27 Feb 2012 12:42:51 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/84 Message-ID: <055.c8b9f781028eccb5f9b33ce1ede88fcf@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leonp@nice.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: [siprec] #84: State that label scope being limited to the metadata carried in the same SIP message as the SDP the label scope being limited to the > metadata > >carried in the same SIP message as the SDP X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 12:42:59 -0000 #84: State that label scope being limited to the metadata carried in the same SIP message as the SDP the label scope being limited to the > metadata > >carried in the same SIP message as the SDP As referenced in: http://www.ietf.org/mail-archive/web/siprec/current/msg03083.html -- -------------------------+--------------------- Reporter: leonp@… | Owner: leonp@… Type: enhancement | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -------------------------+--------------------- Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Mon Feb 27 04:43:26 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B5B21F86F3 for ; Mon, 27 Feb 2012 04:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx4KcG9Pt8Fy for ; Mon, 27 Feb 2012 04:43:26 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4D93821F86F1 for ; Mon, 27 Feb 2012 04:43:19 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S1zvD-0000nk-0T; Mon, 27 Feb 2012 07:43:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "siprec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: leonp@nice.com X-Trac-Project: siprec Date: Mon, 27 Feb 2012 12:43:18 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/84#comment:1 Message-ID: <070.1ef61e6bc63723b96f930d5065a9b988@trac.tools.ietf.org> References: <055.c8b9f781028eccb5f9b33ce1ede88fcf@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <055.c8b9f781028eccb5f9b33ce1ede88fcf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: leonp@nice.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #84: State that label scope being limited to the metadata carried in the same SIP message as the SDP (was: State that label scope being limited to the metadata carried in the same SIP message as the SDP the label scope being limited to the > metadata > >carried in the same SIP message as the SDP) X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 12:43:26 -0000 #84: State that label scope being limited to the metadata carried in the same SIP message as the SDP -- -------------------------+---------------------- Reporter: leonp@… | Owner: leonp@… Type: enhancement | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: Keywords: | -------------------------+---------------------- Ticket URL: siprec From pravindran@sonusnet.com Mon Feb 27 05:05:06 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2207221F86A2 for ; Mon, 27 Feb 2012 05:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC9s4pY76wFO for ; Mon, 27 Feb 2012 05:05:05 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DF63D21F8699 for ; Mon, 27 Feb 2012 05:05:04 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1RD40rQ003472; Mon, 27 Feb 2012 08:04:00 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 08:03:11 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 18:33:08 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 27 Feb 2012 18:33:07 +0530 From: "Ravindran, Parthasarathi" To: Leon Portman , "Charles Eckel (eckelcu)" , Paul Kyzivat , "Hutton, Andrew" Thread-Topic: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?] Thread-Index: AQHM8c1FGYhD9DGhCESahXQz/mAjl5ZK9iOggAFJM6D//60DgIAAVkeAgAQImxCAAGkU8IAABYeQ Date: Mon, 27 Feb 2012 13:03:07 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04EFE4@inba-mail01.sonusnet.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> <4F47C29F.1030307@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E04CDBE@inba-mail01.sonusnet.com> <07465C1D981ABC41A344374066AE1A2C39DA4C6090@TLVMBX01.nice.com> In-Reply-To: <07465C1D981ABC41A344374066AE1A2C39DA4C6090@TLVMBX01.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 13:03:08.0302 (UTC) FILETIME=[26BD22E0:01CCF550] Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2012 13:05:06 -0000 Leon, Even in the case of "Require:siprec", there is no need to mandate for sendi= ng metadata. Options tag "siprec" indicates that the dialog is RS. In case = of persistent scenario, it is perfectly fine to send the initial RS INVITE = with SDP, "Require:siprec" and without metadata. For option tag, there is a= need of text similar to below: Header field where proxy ACK BYE CAN INV OPT REG ------------------------------------------------------------------------ Supported:siprec R - o o - o o Require:siprec R - o - m o o The another open item how to mandate Metadata XML message body support in S= RC and SRS. Thanks Partha >-----Original Message----- >From: Leon Portman [mailto:Leon.Portman@nice.com] >Sent: Monday, February 27, 2012 6:08 PM >To: Ravindran, Parthasarathi; Charles Eckel (eckelcu); Paul Kyzivat; >Hutton, Andrew >Cc: Ram Mohan R (rmohanr); John Elwell; siprec@ietf.org >Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: >[siprec] Is SIPREC metadata mandatory to implement?] > >Hello > >I am ok as well with all three options, however do we really want to >complicate the protocol with different combinations (RS support and >metadata support)? If SRC does not have/want to send any metadata, it >can send empty XML in the worst case. > >Leon > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: Monday, February 27, 2012 8:32 AM >To: Charles Eckel (eckelcu); Paul Kyzivat; Hutton, Andrew >Cc: Ram Mohan R (rmohanr); John Elwell; Leon Portman; siprec@ietf.org >Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: >[siprec] Is SIPREC metadata mandatory to implement?] > >Hi Charles, > >Sorry in case my request for "siprec option tag MUST normative >requirement" request created some confusion here. IMO, siprec option tag >in a Supported/Require header means RS is supported/required. I have >proposed "MUST" in siprec option as I didn't any reason for leniency to >specify as "SHOULD". > >Hi all, > >As far as the metadata is considered, I'm still look for the words to >indicate "SRC and SRS MUST implement SIPREC metadata XML". It may be >preferred to indicates that SRC MUST implement metadata XML encoding >whereas SRS MUST implement metadata XML decoding. Even though John >indicated in his mail about metadata mandating, RFC 3261 does not have >any explicit requirement to say "application/sdp" MUST be supported in >SIP UAC and UAS but instead, there are requirement in INVITE, OPTIONS to >send "application/sdp" message body and UAS to assume "application/sdp" >in accept header if nothing is mentioned. It will be good to see the >exact metadata requirement to convey this. > >Thanks >Partha > >>-----Original Message----- >>From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>Sent: Saturday, February 25, 2012 3:41 AM >>To: Paul Kyzivat; Hutton, Andrew >>Cc: Ravindran, Parthasarathi; Ram Mohan R (rmohanr); John Elwell; Leon >>Portman; siprec@ietf.org >>Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: >>[siprec] Is SIPREC metadata mandatory to implement?] >> >>I think SIPREC metadata is applicable to the RS between the SRC and SRS >>only, but I have been suggesting that it not be mandatory to support >>and use, in that an SRC or SRS could still use the sip.src or sip.srs >>feature tags despite not supporting or using the XML metadata within >>all RSs. >> >>Andy raised a very good point, that this breaks the functionality of >>using the siprec option tag to indicate that an INVITE is for the >>necessary purpose of creating an RS, and should be rejected if the >>other side is not willing or capable of creating an RS. Consequently, >>we have a few choices: >> >>a) siprec option tag in a Supported/Require header means an RS is >>supported/required AND XML metadata is supported/required for this RS >>b) siprec option tag in a Supported/Require header means XML metadata >>is supported/required and another option tag is used to specify whether >>an RS is Supported/Required >>c) siprec option tag in a Supported/Require header means an RS is >>supported/required and another option tag is used to specify whether an >>RS is Supported/Required >> >>I believe Partha was advocating (a). >>Options (b) and (c) could be handled by replacing the single siprec >>options tag with two tags, siprec-rs for the RS, and siprec-metadata >>for the metadata. >>I am okay with (a), (b), or (c), so long as it is still possible to use >>the sip.src and sip.srs feature tags without necessarily having to >>support or use the XML metadata. >> >>Cheers, >>Charles >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Friday, February 24, 2012 9:02 AM >>> To: Hutton, Andrew >>> Cc: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Ram Mohan R >>> (rmohanr); John Elwell; Leon Portman; siprec@ietf.org >>> Subject: Re: Is SIPREC metadata mandatory to implement in RS [was RE: >>> [siprec] Is SIPREC metadata mandatory to implement?] >>> >>> On 2/24/12 11:30 AM, Hutton, Andrew wrote: >>> > I agree but would add that it also works in the opposite direction >>in >>> that the SRS can use the option tag in the same way to indicate >>whether >>> it requires the SRC to support metadata. >>> >>> If we agree that metadata support is required of both SRCs and SRSs, >>> then signaling that you are an SRC or SRS should be sufficient, >>without >>> separately indicating supprot for metadata. >>> >>> Thanks, >>> Paul >>> >>> > Regards >>> > Andy >>> > >>> >> -----Original Message----- >>> >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>> >> Sent: 23 February 2012 20:56 >>> >> To: Ravindran, Parthasarathi; Paul Kyzivat >>> >> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >>> Portman; >>> >> siprec@ietf.org >>> >> Subject: RE: Is SIPREC metadata mandatory to implement in RS [was >>> RE: >>> >> [siprec] Is SIPREC metadata mandatory to implement?] >>> >> >>> >> Hi Partha, >>> >> >>> >> If the SRC requires the SRS support SIPREC XML metadata, it can >>> >> indicate that by including "siprec" option tag in a Require >header. >>> >> However, the SRC may not require this, in which case including >>> "siprec" >>> >> option tag in Supported header is appropriate. >>> >> >>> >> Cheers, >>> >> Charles >>> >> >>> >>> -----Original Message----- >>> >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>> >>> Sent: Wednesday, February 22, 2012 5:49 PM >>> >>> To: Charles Eckel (eckelcu); Paul Kyzivat >>> >>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >>> Portman; >>> >>> siprec@ietf.org >>> >>> Subject: Is SIPREC metadata mandatory to implement in RS [was RE: >>> >>> [siprec] Is SIPREC metadata mandatory to implement?] >>> >>> >>> >>> Hi Charles, >>> >>> >>> >>> Thanks for the clarification. I understand that we are talking >>> about >>> >>> two >>> >>> different stuff. So, I have changed the subject of the mail as >>> >>> "Is SIPREC metadata mandatory to implement in Recording >>> Session(RS)". >>> >>> >>> >>> Hi all, >>> >>> >>> >>> Till now, I have not seen anybody has objection for supporting >>> SIRPEC >>> >>> metadata in RS. Please correct me in case my understanding is >>> wrong. >>> >>> >>> >>> Also, I propose to change the following normative statement from >>> >>> "SHOULD" >>> >>> To "MUST" in recording session: >>> >>> >>> >>> "An SRC SHOULD include the "siprec" option tag in the Require >>> header >>> >>> when >>> >>> initiating a Recording Session so that other types of user agents >>> can >>> >>> simply reject the INVITE request with a 420 Bad Extension." >>> >>> >>> >>> as >>> >>> >>> >>> "An SRC MUST include the "siprec" option tag in the Require >>> >>> header >>> >> when >>> >>> initiating a Recording Session so that other types of user agents >>> can >>> >>> simply reject the INVITE request with a 420 Bad Extension." >>> >>> >>> >>> Please let me know your opinion on the same. >>> >>> >>> >>> Thanks >>> >>> Partha >>> >>>> -----Original Message----- >>> >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>> >>>> Sent: Thursday, February 23, 2012 2:45 AM >>> >>>> To: Paul Kyzivat >>> >>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, >>> >>>> Parthasarathi; Hutton, Andrew; Leon Portman; siprec@ietf.org >>> >>>> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >>> >>>> >>> >>>> Hi Paul, >>> >>>> >>> >>>> An SRC could use it when it registers itself with a call control >>> >>> server, >>> >>>> or when it sends/receives a SIP INVITE to/from an UA/MCU to join >>a >>> >>> call. >>> >>>> This way the UA/MCU knows it has the ability to request specific >>> >> media >>> >>>> streams within the SIP dialog between it and the SRC be recorded >>> >> using >>> >>>> the recording-pref attribute. How the SRC accomplishes this is >>> >> likely >>> >>>> not important to the UA/MCU. The SRC indicates that it is >>> recording >>> >>>> using the record attribute. The record-aware option tag could be >>> >>>> leveraged her as well. >>> >>>> >>> >>>> Cheers, >>> >>>> Charles >>> >>>> >>> >>>> >>> >>>> >>> >>>>> -----Original Message----- >>> >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> >>>>> Sent: Wednesday, February 22, 2012 12:58 PM >>> >>>>> To: Charles Eckel (eckelcu) >>> >>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, >>Parthasarathi; >>> >>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org >>> >>>>> Subject: Re: [siprec] Is SIPREC metadata mandatory to >implement? >>> >>>>> >>> >>>>> Charles, >>> >>>>> >>> >>>>> Do you see any case where it would be valid to use sip.src or >>> >>> sip.srs >>> >>>>> *without* supporting the siprec option tag? >>> >>>>> >>> >>>>> Below it sounds like you do, but I don't see how that makes >>> sense. >>> >>>>> >>> >>>>> Thanks, >>> >>>>> Paul >>> >>>>> >>> >>>>> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: >>> >>>>>> Based on the responses, either my proposal was not clear, or >>> >>>>>> my understanding of the options and feature tags is incorrect, >>> >>>>>> or >>> >>> both. >>> >>>>> Let >>> >>>>>> me try again. >>> >>>>>> My intention is not to lower the bar for SIPREC compliance. >>What >>> >> I >>> >>>>>> propose is: >>> >>>>>> >>> >>>>>> 1) clarify that the "siprec" option tag, in addition to what >>> >>>>>> is >>> >>>>> already >>> >>>>>> stated, indicates that the XML metadata is supposed. You >>> >>>>>> cannot >>> >>>>> include >>> >>>>>> the "siprec" option tag in a Supported/Require header unless >>you >>> >>>>> support >>> >>>>>> the XML metadata, as it is the essence of SIPREC. >>> >>>>>> >>> >>>>>> 2) all other SIP/SDP extensions defined in the protocol draft >>> >>>>> (sip.src, >>> >>>>>> sip.srs, recording-aware, etc.) are just that, SIP/SDP >>> >> extensions. >>> >>>>> There >>> >>>>>> are not tied directly to the "siprec" option tag and may be >>used >>> >>>>> without >>> >>>>>> the "siprec" option tag. >>> >>>>>> >>> >>>>>> If an SRC or SRS supports SIPREC XML metadata, it may indicate >>> >>> that >>> >>>>> by >>> >>>>>> including "siprec" in a Supported header. >>> >>>>>> If an SRC or SRS requires SIPREC XML, it may indicate that by >>> >>>>> including >>> >>>>>> "siprec" in a Require header. >>> >>>>>> >>> >>>>>> I do not see this as lowering the bar for SIPREC compliance. >>> >>>>>> I do see it as providing benefit for implementations that have >>> >> no >>> >>>>>> intention of being a SIPREC compliant SRC or SRS. >>> >>>>>> I also see it helping with interworking between SIPREC >>compliant >>> >>> and >>> >>>>> non >>> >>>>>> SIPREC compliant entities. >>> >>>>>> >>> >>>>>> Cheers, >>> >>>>>> Charles >>> > From Leon.Portman@nice.com Mon Feb 27 07:48:02 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F387021F879B for ; Mon, 27 Feb 2012 07:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRsGQ2mllahf for ; Mon, 27 Feb 2012 07:48:01 -0800 (PST) Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by ietfa.amsl.com (Postfix) with ESMTP id 19A9421F879A for ; Mon, 27 Feb 2012 07:48:00 -0800 (PST) Received: from TLVMBX01.nice.com ([192.168.253.15]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Mon, 27 Feb 2012 17:47:58 +0200 From: Leon Portman To: "Ravindran, Parthasarathi" , "Charles Eckel (eckelcu)" , Paul Kyzivat , "Hutton, Andrew" Date: Mon, 27 Feb 2012 17:47:58 +0200 Thread-Topic: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?] Thread-Index: AQHM8c1FGYhD9DGhCESahXQz/mAjl5ZK9iOggAFJM6D//60DgIAAVkeAgAQImxCAAGkU8IAABYeQgAAw1mA= Message-ID: <07465C1D981ABC41A344374066AE1A2C39DA4C61D6@TLVMBX01.nice.com> References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><35BCE99A477D6A4986FB2216D8CF2CFD096E8B8C@XMB-BGL-417.cisco.com><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> <4F47C29F.1030307@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E04CDBE@inba-mail01.sonusnet.com> <07465C1D981ABC41A344374066AE1A2C39DA4C6090@TLVMBX01.nice.com> <387F9047F55E8C42850AD6B3A7A03C6C0E04EFE4@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E04EFE4@inba-mail01.sonusnet.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2012 15:48:02 -0000 Partha, thanks It is even more simple this way Leon -----Original Message----- From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com]=20 Sent: Monday, February 27, 2012 3:03 PM To: Leon Portman; Charles Eckel (eckelcu); Paul Kyzivat; Hutton, Andrew Cc: Ram Mohan R (rmohanr); John Elwell; siprec@ietf.org Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: [sipr= ec] Is SIPREC metadata mandatory to implement?] Leon, Even in the case of "Require:siprec", there is no need to mandate for sendi= ng metadata. Options tag "siprec" indicates that the dialog is RS. In case = of persistent scenario, it is perfectly fine to send the initial RS INVITE = with SDP, "Require:siprec" and without metadata. For option tag, there is a= need of text similar to below: Header field where proxy ACK BYE CAN INV OPT REG ------------------------------------------------------------------------ Supported:siprec R - o o - o o Require:siprec R - o - m o o The another open item how to mandate Metadata XML message body support in S= RC and SRS. Thanks Partha >-----Original Message----- >From: Leon Portman [mailto:Leon.Portman@nice.com] >Sent: Monday, February 27, 2012 6:08 PM >To: Ravindran, Parthasarathi; Charles Eckel (eckelcu); Paul Kyzivat;=20 >Hutton, Andrew >Cc: Ram Mohan R (rmohanr); John Elwell; siprec@ietf.org >Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: >[siprec] Is SIPREC metadata mandatory to implement?] > >Hello > >I am ok as well with all three options, however do we really want to=20 >complicate the protocol with different combinations (RS support and=20 >metadata support)? If SRC does not have/want to send any metadata, it=20 >can send empty XML in the worst case. > >Leon > >-----Original Message----- >From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >Sent: Monday, February 27, 2012 8:32 AM >To: Charles Eckel (eckelcu); Paul Kyzivat; Hutton, Andrew >Cc: Ram Mohan R (rmohanr); John Elwell; Leon Portman; siprec@ietf.org >Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: >[siprec] Is SIPREC metadata mandatory to implement?] > >Hi Charles, > >Sorry in case my request for "siprec option tag MUST normative=20 >requirement" request created some confusion here. IMO, siprec option=20 >tag in a Supported/Require header means RS is supported/required. I=20 >have proposed "MUST" in siprec option as I didn't any reason for=20 >leniency to specify as "SHOULD". > >Hi all, > >As far as the metadata is considered, I'm still look for the words to=20 >indicate "SRC and SRS MUST implement SIPREC metadata XML". It may be=20 >preferred to indicates that SRC MUST implement metadata XML encoding=20 >whereas SRS MUST implement metadata XML decoding. Even though John=20 >indicated in his mail about metadata mandating, RFC 3261 does not have=20 >any explicit requirement to say "application/sdp" MUST be supported in=20 >SIP UAC and UAS but instead, there are requirement in INVITE, OPTIONS=20 >to send "application/sdp" message body and UAS to assume "application/sdp" >in accept header if nothing is mentioned. It will be good to see the=20 >exact metadata requirement to convey this. > >Thanks >Partha > >>-----Original Message----- >>From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>Sent: Saturday, February 25, 2012 3:41 AM >>To: Paul Kyzivat; Hutton, Andrew >>Cc: Ravindran, Parthasarathi; Ram Mohan R (rmohanr); John Elwell; Leon=20 >>Portman; siprec@ietf.org >>Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: >>[siprec] Is SIPREC metadata mandatory to implement?] >> >>I think SIPREC metadata is applicable to the RS between the SRC and=20 >>SRS only, but I have been suggesting that it not be mandatory to=20 >>support and use, in that an SRC or SRS could still use the sip.src or=20 >>sip.srs feature tags despite not supporting or using the XML metadata=20 >>within all RSs. >> >>Andy raised a very good point, that this breaks the functionality of=20 >>using the siprec option tag to indicate that an INVITE is for the=20 >>necessary purpose of creating an RS, and should be rejected if the=20 >>other side is not willing or capable of creating an RS. Consequently,=20 >>we have a few choices: >> >>a) siprec option tag in a Supported/Require header means an RS is=20 >>supported/required AND XML metadata is supported/required for this RS >>b) siprec option tag in a Supported/Require header means XML metadata=20 >>is supported/required and another option tag is used to specify=20 >>whether an RS is Supported/Required >>c) siprec option tag in a Supported/Require header means an RS is=20 >>supported/required and another option tag is used to specify whether=20 >>an RS is Supported/Required >> >>I believe Partha was advocating (a). >>Options (b) and (c) could be handled by replacing the single siprec=20 >>options tag with two tags, siprec-rs for the RS, and siprec-metadata=20 >>for the metadata. >>I am okay with (a), (b), or (c), so long as it is still possible to=20 >>use the sip.src and sip.srs feature tags without necessarily having to=20 >>support or use the XML metadata. >> >>Cheers, >>Charles >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Friday, February 24, 2012 9:02 AM >>> To: Hutton, Andrew >>> Cc: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Ram Mohan R=20 >>> (rmohanr); John Elwell; Leon Portman; siprec@ietf.org >>> Subject: Re: Is SIPREC metadata mandatory to implement in RS [was RE: >>> [siprec] Is SIPREC metadata mandatory to implement?] >>> >>> On 2/24/12 11:30 AM, Hutton, Andrew wrote: >>> > I agree but would add that it also works in the opposite direction >>in >>> that the SRS can use the option tag in the same way to indicate >>whether >>> it requires the SRC to support metadata. >>> >>> If we agree that metadata support is required of both SRCs and SRSs,=20 >>> then signaling that you are an SRC or SRS should be sufficient, >>without >>> separately indicating supprot for metadata. >>> >>> Thanks, >>> Paul >>> >>> > Regards >>> > Andy >>> > >>> >> -----Original Message----- >>> >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>> >> Sent: 23 February 2012 20:56 >>> >> To: Ravindran, Parthasarathi; Paul Kyzivat >>> >> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >>> Portman; >>> >> siprec@ietf.org >>> >> Subject: RE: Is SIPREC metadata mandatory to implement in RS [was >>> RE: >>> >> [siprec] Is SIPREC metadata mandatory to implement?] >>> >> >>> >> Hi Partha, >>> >> >>> >> If the SRC requires the SRS support SIPREC XML metadata, it can=20 >>> >> indicate that by including "siprec" option tag in a Require >header. >>> >> However, the SRC may not require this, in which case including >>> "siprec" >>> >> option tag in Supported header is appropriate. >>> >> >>> >> Cheers, >>> >> Charles >>> >> >>> >>> -----Original Message----- >>> >>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>> >>> Sent: Wednesday, February 22, 2012 5:49 PM >>> >>> To: Charles Eckel (eckelcu); Paul Kyzivat >>> >>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >>> Portman; >>> >>> siprec@ietf.org >>> >>> Subject: Is SIPREC metadata mandatory to implement in RS [was RE: >>> >>> [siprec] Is SIPREC metadata mandatory to implement?] >>> >>> >>> >>> Hi Charles, >>> >>> >>> >>> Thanks for the clarification. I understand that we are talking >>> about >>> >>> two >>> >>> different stuff. So, I have changed the subject of the mail as=20 >>> >>> "Is SIPREC metadata mandatory to implement in Recording >>> Session(RS)". >>> >>> >>> >>> Hi all, >>> >>> >>> >>> Till now, I have not seen anybody has objection for supporting >>> SIRPEC >>> >>> metadata in RS. Please correct me in case my understanding is >>> wrong. >>> >>> >>> >>> Also, I propose to change the following normative statement from=20 >>> >>> "SHOULD" >>> >>> To "MUST" in recording session: >>> >>> >>> >>> "An SRC SHOULD include the "siprec" option tag in the Require >>> header >>> >>> when >>> >>> initiating a Recording Session so that other types of user=20 >>> >>> agents >>> can >>> >>> simply reject the INVITE request with a 420 Bad Extension." >>> >>> >>> >>> as >>> >>> >>> >>> "An SRC MUST include the "siprec" option tag in the Require=20 >>> >>> header >>> >> when >>> >>> initiating a Recording Session so that other types of user=20 >>> >>> agents >>> can >>> >>> simply reject the INVITE request with a 420 Bad Extension." >>> >>> >>> >>> Please let me know your opinion on the same. >>> >>> >>> >>> Thanks >>> >>> Partha >>> >>>> -----Original Message----- >>> >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>> >>>> Sent: Thursday, February 23, 2012 2:45 AM >>> >>>> To: Paul Kyzivat >>> >>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran,=20 >>> >>>> Parthasarathi; Hutton, Andrew; Leon Portman; siprec@ietf.org >>> >>>> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >>> >>>> >>> >>>> Hi Paul, >>> >>>> >>> >>>> An SRC could use it when it registers itself with a call=20 >>> >>>> control >>> >>> server, >>> >>>> or when it sends/receives a SIP INVITE to/from an UA/MCU to=20 >>> >>>> join >>a >>> >>> call. >>> >>>> This way the UA/MCU knows it has the ability to request=20 >>> >>>> specific >>> >> media >>> >>>> streams within the SIP dialog between it and the SRC be=20 >>> >>>> recorded >>> >> using >>> >>>> the recording-pref attribute. How the SRC accomplishes this is >>> >> likely >>> >>>> not important to the UA/MCU. The SRC indicates that it is >>> recording >>> >>>> using the record attribute. The record-aware option tag could=20 >>> >>>> be leveraged her as well. >>> >>>> >>> >>>> Cheers, >>> >>>> Charles >>> >>>> >>> >>>> >>> >>>> >>> >>>>> -----Original Message----- >>> >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> >>>>> Sent: Wednesday, February 22, 2012 12:58 PM >>> >>>>> To: Charles Eckel (eckelcu) >>> >>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, >>Parthasarathi; >>> >>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org >>> >>>>> Subject: Re: [siprec] Is SIPREC metadata mandatory to >implement? >>> >>>>> >>> >>>>> Charles, >>> >>>>> >>> >>>>> Do you see any case where it would be valid to use sip.src or >>> >>> sip.srs >>> >>>>> *without* supporting the siprec option tag? >>> >>>>> >>> >>>>> Below it sounds like you do, but I don't see how that makes >>> sense. >>> >>>>> >>> >>>>> Thanks, >>> >>>>> Paul >>> >>>>> >>> >>>>> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: >>> >>>>>> Based on the responses, either my proposal was not clear, or=20 >>> >>>>>> my understanding of the options and feature tags is=20 >>> >>>>>> incorrect, or >>> >>> both. >>> >>>>> Let >>> >>>>>> me try again. >>> >>>>>> My intention is not to lower the bar for SIPREC compliance. >>What >>> >> I >>> >>>>>> propose is: >>> >>>>>> >>> >>>>>> 1) clarify that the "siprec" option tag, in addition to what=20 >>> >>>>>> is >>> >>>>> already >>> >>>>>> stated, indicates that the XML metadata is supposed. You=20 >>> >>>>>> cannot >>> >>>>> include >>> >>>>>> the "siprec" option tag in a Supported/Require header unless >>you >>> >>>>> support >>> >>>>>> the XML metadata, as it is the essence of SIPREC. >>> >>>>>> >>> >>>>>> 2) all other SIP/SDP extensions defined in the protocol draft >>> >>>>> (sip.src, >>> >>>>>> sip.srs, recording-aware, etc.) are just that, SIP/SDP >>> >> extensions. >>> >>>>> There >>> >>>>>> are not tied directly to the "siprec" option tag and may be >>used >>> >>>>> without >>> >>>>>> the "siprec" option tag. >>> >>>>>> >>> >>>>>> If an SRC or SRS supports SIPREC XML metadata, it may=20 >>> >>>>>> indicate >>> >>> that >>> >>>>> by >>> >>>>>> including "siprec" in a Supported header. >>> >>>>>> If an SRC or SRS requires SIPREC XML, it may indicate that by >>> >>>>> including >>> >>>>>> "siprec" in a Require header. >>> >>>>>> >>> >>>>>> I do not see this as lowering the bar for SIPREC compliance. >>> >>>>>> I do see it as providing benefit for implementations that=20 >>> >>>>>> have >>> >> no >>> >>>>>> intention of being a SIPREC compliant SRC or SRS. >>> >>>>>> I also see it helping with interworking between SIPREC >>compliant >>> >>> and >>> >>>>> non >>> >>>>>> SIPREC compliant entities. >>> >>>>>> >>> >>>>>> Cheers, >>> >>>>>> Charles >>> > From pkyzivat@alum.mit.edu Mon Feb 27 12:20:55 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BC421F8857 for ; Mon, 27 Feb 2012 12:20:55 -0800 (PST) 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_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXOxYReNdK6o for ; Mon, 27 Feb 2012 12:20:55 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id E437E21F8849 for ; Mon, 27 Feb 2012 12:20:54 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA11.westchester.pa.mail.comcast.net with comcast id f7XQ1i00A27AodY5B8LvyK; Mon, 27 Feb 2012 20:20:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id f8Lu1i00j07duvL3f8LvEY; Mon, 27 Feb 2012 20:20:55 +0000 Message-ID: <4F4BE5A5.2030602@alum.mit.edu> Date: Mon, 27 Feb 2012 15:20:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> <4F47C29F.1030307@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] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2012 20:20:56 -0000 I support (a) below. Frankly ISTM that what siprec is all about is the metadata. Without the metadata you don't need siprec at all. While we certainly have in mind that the SRS is recording the media it receives, I doubt there is any way that we can actually enforce that. So without metadata support, siprec simply becomes SIP support. Thanks, Paul On 2/24/12 5:11 PM, Charles Eckel (eckelcu) wrote: > I think SIPREC metadata is applicable to the RS between the SRC and SRS > only, but I have been suggesting that it not be mandatory to support and > use, in that an SRC or SRS could still use the sip.src or sip.srs > feature tags despite not supporting or using the XML metadata within all > RSs. > > Andy raised a very good point, that this breaks the functionality of > using the siprec option tag to indicate that an INVITE is for the > necessary purpose of creating an RS, and should be rejected if the other > side is not willing or capable of creating an RS. Consequently, we have > a few choices: > > a) siprec option tag in a Supported/Require header means an RS is > supported/required AND XML metadata is supported/required for this RS > b) siprec option tag in a Supported/Require header means XML metadata is > supported/required and another option tag is used to specify whether an > RS is Supported/Required > c) siprec option tag in a Supported/Require header means an RS is > supported/required and another option tag is used to specify whether an > RS is Supported/Required > > I believe Partha was advocating (a). > Options (b) and (c) could be handled by replacing the single siprec > options tag with two tags, siprec-rs for the RS, and siprec-metadata for > the metadata. > I am okay with (a), (b), or (c), so long as it is still possible to use > the sip.src and sip.srs feature tags without necessarily having to > support or use the XML metadata. > > Cheers, > Charles > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, February 24, 2012 9:02 AM >> To: Hutton, Andrew >> Cc: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Ram Mohan R >> (rmohanr); John Elwell; Leon Portman; siprec@ietf.org >> Subject: Re: Is SIPREC metadata mandatory to implement in RS [was RE: >> [siprec] Is SIPREC metadata mandatory to implement?] >> >> On 2/24/12 11:30 AM, Hutton, Andrew wrote: >>> I agree but would add that it also works in the opposite direction > in >> that the SRS can use the option tag in the same way to indicate > whether >> it requires the SRC to support metadata. >> >> If we agree that metadata support is required of both SRCs and SRSs, >> then signaling that you are an SRC or SRS should be sufficient, > without >> separately indicating supprot for metadata. >> >> Thanks, >> Paul >> >>> Regards >>> Andy >>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>> Sent: 23 February 2012 20:56 >>>> To: Ravindran, Parthasarathi; Paul Kyzivat >>>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >> Portman; >>>> siprec@ietf.org >>>> Subject: RE: Is SIPREC metadata mandatory to implement in RS [was >> RE: >>>> [siprec] Is SIPREC metadata mandatory to implement?] >>>> >>>> Hi Partha, >>>> >>>> If the SRC requires the SRS support SIPREC XML metadata, it can >>>> indicate >>>> that by including "siprec" option tag in a Require header. >>>> However, the SRC may not require this, in which case including >> "siprec" >>>> option tag in Supported header is appropriate. >>>> >>>> Cheers, >>>> Charles >>>> >>>>> -----Original Message----- >>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >>>>> Sent: Wednesday, February 22, 2012 5:49 PM >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat >>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon >> Portman; >>>>> siprec@ietf.org >>>>> Subject: Is SIPREC metadata mandatory to implement in RS [was RE: >>>>> [siprec] Is SIPREC metadata mandatory to implement?] >>>>> >>>>> Hi Charles, >>>>> >>>>> Thanks for the clarification. I understand that we are talking >> about >>>>> two >>>>> different stuff. So, I have changed the subject of the mail as >>>>> "Is SIPREC metadata mandatory to implement in Recording >> Session(RS)". >>>>> >>>>> Hi all, >>>>> >>>>> Till now, I have not seen anybody has objection for supporting >> SIRPEC >>>>> metadata in RS. Please correct me in case my understanding is >> wrong. >>>>> >>>>> Also, I propose to change the following normative statement from >>>>> "SHOULD" >>>>> To "MUST" in recording session: >>>>> >>>>> "An SRC SHOULD include the "siprec" option tag in the Require >> header >>>>> when >>>>> initiating a Recording Session so that other types of user agents >> can >>>>> simply reject the INVITE request with a 420 Bad Extension." >>>>> >>>>> as >>>>> >>>>> "An SRC MUST include the "siprec" option tag in the Require header >>>> when >>>>> initiating a Recording Session so that other types of user agents >> can >>>>> simply reject the INVITE request with a 420 Bad Extension." >>>>> >>>>> Please let me know your opinion on the same. >>>>> >>>>> Thanks >>>>> Partha >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>>>> Sent: Thursday, February 23, 2012 2:45 AM >>>>>> To: Paul Kyzivat >>>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi; >>>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org >>>>>> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? >>>>>> >>>>>> Hi Paul, >>>>>> >>>>>> An SRC could use it when it registers itself with a call control >>>>> server, >>>>>> or when it sends/receives a SIP INVITE to/from an UA/MCU to join > a >>>>> call. >>>>>> This way the UA/MCU knows it has the ability to request specific >>>> media >>>>>> streams within the SIP dialog between it and the SRC be recorded >>>> using >>>>>> the recording-pref attribute. How the SRC accomplishes this is >>>> likely >>>>>> not important to the UA/MCU. The SRC indicates that it is >> recording >>>>>> using the record attribute. The record-aware option tag could be >>>>>> leveraged her as well. >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>> Sent: Wednesday, February 22, 2012 12:58 PM >>>>>>> To: Charles Eckel (eckelcu) >>>>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, > Parthasarathi; >>>>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org >>>>>>> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement? >>>>>>> >>>>>>> Charles, >>>>>>> >>>>>>> Do you see any case where it would be valid to use sip.src or >>>>> sip.srs >>>>>>> *without* supporting the siprec option tag? >>>>>>> >>>>>>> Below it sounds like you do, but I don't see how that makes >> sense. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: >>>>>>>> Based on the responses, either my proposal was not clear, or my >>>>>>>> understanding of the options and feature tags is incorrect, or >>>>> both. >>>>>>> Let >>>>>>>> me try again. >>>>>>>> My intention is not to lower the bar for SIPREC compliance. > What >>>> I >>>>>>>> propose is: >>>>>>>> >>>>>>>> 1) clarify that the "siprec" option tag, in addition to what is >>>>>>> already >>>>>>>> stated, indicates that the XML metadata is supposed. You cannot >>>>>>> include >>>>>>>> the "siprec" option tag in a Supported/Require header unless > you >>>>>>> support >>>>>>>> the XML metadata, as it is the essence of SIPREC. >>>>>>>> >>>>>>>> 2) all other SIP/SDP extensions defined in the protocol draft >>>>>>> (sip.src, >>>>>>>> sip.srs, recording-aware, etc.) are just that, SIP/SDP >>>> extensions. >>>>>>> There >>>>>>>> are not tied directly to the "siprec" option tag and may be > used >>>>>>> without >>>>>>>> the "siprec" option tag. >>>>>>>> >>>>>>>> If an SRC or SRS supports SIPREC XML metadata, it may indicate >>>>> that >>>>>>> by >>>>>>>> including "siprec" in a Supported header. >>>>>>>> If an SRC or SRS requires SIPREC XML, it may indicate that by >>>>>>> including >>>>>>>> "siprec" in a Require header. >>>>>>>> >>>>>>>> I do not see this as lowering the bar for SIPREC compliance. >>>>>>>> I do see it as providing benefit for implementations that have >>>> no >>>>>>>> intention of being a SIPREC compliant SRC or SRS. >>>>>>>> I also see it helping with interworking between SIPREC > compliant >>>>> and >>>>>>> non >>>>>>>> SIPREC compliant entities. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Charles >>> > > From rmohanr@cisco.com Mon Feb 27 19:19:18 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BEA21E802F for ; Mon, 27 Feb 2012 19:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.17 X-Spam-Level: X-Spam-Status: No, score=-8.17 tagged_above=-999 required=5 tests=[AWL=1.829, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Y1f-F41jHHT for ; Mon, 27 Feb 2012 19:19:17 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9423421E8029 for ; Mon, 27 Feb 2012 19:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=9855; q=dns/txt; s=iport; t=1330399156; x=1331608756; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DT/5CWu6BPNIkezkTeoL7un6FdMtpsUq9lFUKr9ejdM=; b=IzdMw+07RviaQmE3KU5H1OipQRIRYy2Oou9hLZRUIlDZVPMpWdBZ02P9 ChWpZhjYjo23WynQKx8GTN1Rgp5NXbco6qgfj6XAAItyhkUis+THRfa4t IftnkDO3Jyk0yJxCyV9sYcsHTL0Xb3haG4CTS7bBLHXnjlbum082Bya3o 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EABNHTE9Io8UY/2dsb2JhbABCDrR9gXMBAQEEEgEdCj8MBAIBCA4DBAEBAQoGEwQBBgFFCQgBAQQBCggIGodkoRUBly+JeYJ4CAIOCgIBBAcDAkAVhRgDCwYRBwEKDgyCZ2MEiE2fJz+BVQ X-IronPort-AV: E=Sophos;i="4.73,494,1325462400"; d="scan'208";a="6516164" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 28 Feb 2012 03:19: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 q1S3JDZD005967; Tue, 28 Feb 2012 03:19:13 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, 28 Feb 2012 08:49:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2012 08:49:12 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD09A2F8AC@XMB-BGL-417.cisco.com> In-Reply-To: <4F4BE5A5.2030602@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?] Thread-Index: Acz1jVLUKg0hvpheTBSpaYPske4u7QAOkmng References: <101C6067BEC68246B0C3F6843BCCC1E31202DA2BEB@MCHP058A.global-ad.net><3FF56432D85141C8ACF379A5CD6069EE@Acer> <387F9047F55E8C42850AD6B3A7A03C6C0E040858@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E040F84@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD098AFE12@XMB-BGL-417.cisc! o.com> < 4F4556C4.107 0501@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E0418CB@inba-mail01.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E31294481EED@MCHP058A.global-ad.net> <4F47C29F.1030307@alum.mit.edu> <4F4B E5A5.203 0602@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: "Paul Kyzivat" , "Charles Eckel (eckelcu)" X-OriginalArrivalTime: 28 Feb 2012 03:19:13.0770 (UTC) FILETIME=[BEF18CA0:01CCF5C7] Cc: siprec@ietf.org Subject: Re: [siprec] Is SIPREC metadata mandatory to implement in RS [was RE: Is SIPREC metadata mandatory to implement?] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 03:19:18 -0000 +1. Even I support (a) below.=20 Ram > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, February 28, 2012 1:51 AM > To: Charles Eckel (eckelcu) > Cc: Hutton, Andrew; Ravindran, Parthasarathi; Ram Mohan R (rmohanr); > John Elwell; Leon Portman; siprec@ietf.org > Subject: Re: Is SIPREC metadata mandatory to implement in RS [was RE: > [siprec] Is SIPREC metadata mandatory to implement?] >=20 > I support (a) below. Frankly ISTM that what siprec is all about is the > metadata. Without the metadata you don't need siprec at all. While we > certainly have in mind that the SRS is recording the media it receives, > I doubt there is any way that we can actually enforce that. So without > metadata support, siprec simply becomes SIP support. >=20 > Thanks, > Paul >=20 > On 2/24/12 5:11 PM, Charles Eckel (eckelcu) wrote: > > I think SIPREC metadata is applicable to the RS between the SRC and > SRS > > only, but I have been suggesting that it not be mandatory to support > and > > use, in that an SRC or SRS could still use the sip.src or sip.srs > > feature tags despite not supporting or using the XML metadata within > all > > RSs. > > > > Andy raised a very good point, that this breaks the functionality of > > using the siprec option tag to indicate that an INVITE is for the > > necessary purpose of creating an RS, and should be rejected if the > other > > side is not willing or capable of creating an RS. Consequently, we > have > > a few choices: > > > > a) siprec option tag in a Supported/Require header means an RS is > > supported/required AND XML metadata is supported/required for this RS > > b) siprec option tag in a Supported/Require header means XML metadata > is > > supported/required and another option tag is used to specify whether > an > > RS is Supported/Required > > c) siprec option tag in a Supported/Require header means an RS is > > supported/required and another option tag is used to specify whether > an > > RS is Supported/Required > > > > I believe Partha was advocating (a). > > Options (b) and (c) could be handled by replacing the single siprec > > options tag with two tags, siprec-rs for the RS, and siprec-metadata > for > > the metadata. > > I am okay with (a), (b), or (c), so long as it is still possible to > use > > the sip.src and sip.srs feature tags without necessarily having to > > support or use the XML metadata. > > > > Cheers, > > Charles > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Friday, February 24, 2012 9:02 AM > >> To: Hutton, Andrew > >> Cc: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Ram Mohan R > >> (rmohanr); John Elwell; Leon Portman; siprec@ietf.org > >> Subject: Re: Is SIPREC metadata mandatory to implement in RS [was > RE: > >> [siprec] Is SIPREC metadata mandatory to implement?] > >> > >> On 2/24/12 11:30 AM, Hutton, Andrew wrote: > >>> I agree but would add that it also works in the opposite direction > > in > >> that the SRS can use the option tag in the same way to indicate > > whether > >> it requires the SRC to support metadata. > >> > >> If we agree that metadata support is required of both SRCs and SRSs, > >> then signaling that you are an SRC or SRS should be sufficient, > > without > >> separately indicating supprot for metadata. > >> > >> Thanks, > >> Paul > >> > >>> Regards > >>> Andy > >>> > >>>> -----Original Message----- > >>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>> Sent: 23 February 2012 20:56 > >>>> To: Ravindran, Parthasarathi; Paul Kyzivat > >>>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon > >> Portman; > >>>> siprec@ietf.org > >>>> Subject: RE: Is SIPREC metadata mandatory to implement in RS [was > >> RE: > >>>> [siprec] Is SIPREC metadata mandatory to implement?] > >>>> > >>>> Hi Partha, > >>>> > >>>> If the SRC requires the SRS support SIPREC XML metadata, it can > >>>> indicate > >>>> that by including "siprec" option tag in a Require header. > >>>> However, the SRC may not require this, in which case including > >> "siprec" > >>>> option tag in Supported header is appropriate. > >>>> > >>>> Cheers, > >>>> Charles > >>>> > >>>>> -----Original Message----- > >>>>> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > >>>>> Sent: Wednesday, February 22, 2012 5:49 PM > >>>>> To: Charles Eckel (eckelcu); Paul Kyzivat > >>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon > >> Portman; > >>>>> siprec@ietf.org > >>>>> Subject: Is SIPREC metadata mandatory to implement in RS [was RE: > >>>>> [siprec] Is SIPREC metadata mandatory to implement?] > >>>>> > >>>>> Hi Charles, > >>>>> > >>>>> Thanks for the clarification. I understand that we are talking > >> about > >>>>> two > >>>>> different stuff. So, I have changed the subject of the mail as > >>>>> "Is SIPREC metadata mandatory to implement in Recording > >> Session(RS)". > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Till now, I have not seen anybody has objection for supporting > >> SIRPEC > >>>>> metadata in RS. Please correct me in case my understanding is > >> wrong. > >>>>> > >>>>> Also, I propose to change the following normative statement from > >>>>> "SHOULD" > >>>>> To "MUST" in recording session: > >>>>> > >>>>> "An SRC SHOULD include the "siprec" option tag in the Require > >> header > >>>>> when > >>>>> initiating a Recording Session so that other types of user agents > >> can > >>>>> simply reject the INVITE request with a 420 Bad Extension." > >>>>> > >>>>> as > >>>>> > >>>>> "An SRC MUST include the "siprec" option tag in the Require > header > >>>> when > >>>>> initiating a Recording Session so that other types of user agents > >> can > >>>>> simply reject the INVITE request with a 420 Bad Extension." > >>>>> > >>>>> Please let me know your opinion on the same. > >>>>> > >>>>> Thanks > >>>>> Partha > >>>>>> -----Original Message----- > >>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > >>>>>> Sent: Thursday, February 23, 2012 2:45 AM > >>>>>> To: Paul Kyzivat > >>>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, > Parthasarathi; > >>>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>>>> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement? > >>>>>> > >>>>>> Hi Paul, > >>>>>> > >>>>>> An SRC could use it when it registers itself with a call control > >>>>> server, > >>>>>> or when it sends/receives a SIP INVITE to/from an UA/MCU to join > > a > >>>>> call. > >>>>>> This way the UA/MCU knows it has the ability to request specific > >>>> media > >>>>>> streams within the SIP dialog between it and the SRC be recorded > >>>> using > >>>>>> the recording-pref attribute. How the SRC accomplishes this is > >>>> likely > >>>>>> not important to the UA/MCU. The SRC indicates that it is > >> recording > >>>>>> using the record attribute. The record-aware option tag could be > >>>>>> leveraged her as well. > >>>>>> > >>>>>> Cheers, > >>>>>> Charles > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>>>>>> Sent: Wednesday, February 22, 2012 12:58 PM > >>>>>>> To: Charles Eckel (eckelcu) > >>>>>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, > > Parthasarathi; > >>>>>>> Hutton, Andrew; Leon Portman; siprec@ietf.org > >>>>>>> Subject: Re: [siprec] Is SIPREC metadata mandatory to > implement? > >>>>>>> > >>>>>>> Charles, > >>>>>>> > >>>>>>> Do you see any case where it would be valid to use sip.src or > >>>>> sip.srs > >>>>>>> *without* supporting the siprec option tag? > >>>>>>> > >>>>>>> Below it sounds like you do, but I don't see how that makes > >> sense. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> > >>>>>>> On 2/22/12 3:50 PM, Charles Eckel (eckelcu) wrote: > >>>>>>>> Based on the responses, either my proposal was not clear, or > my > >>>>>>>> understanding of the options and feature tags is incorrect, or > >>>>> both. > >>>>>>> Let > >>>>>>>> me try again. > >>>>>>>> My intention is not to lower the bar for SIPREC compliance. > > What > >>>> I > >>>>>>>> propose is: > >>>>>>>> > >>>>>>>> 1) clarify that the "siprec" option tag, in addition to what > is > >>>>>>> already > >>>>>>>> stated, indicates that the XML metadata is supposed. You > cannot > >>>>>>> include > >>>>>>>> the "siprec" option tag in a Supported/Require header unless > > you > >>>>>>> support > >>>>>>>> the XML metadata, as it is the essence of SIPREC. > >>>>>>>> > >>>>>>>> 2) all other SIP/SDP extensions defined in the protocol draft > >>>>>>> (sip.src, > >>>>>>>> sip.srs, recording-aware, etc.) are just that, SIP/SDP > >>>> extensions. > >>>>>>> There > >>>>>>>> are not tied directly to the "siprec" option tag and may be > > used > >>>>>>> without > >>>>>>>> the "siprec" option tag. > >>>>>>>> > >>>>>>>> If an SRC or SRS supports SIPREC XML metadata, it may indicate > >>>>> that > >>>>>>> by > >>>>>>>> including "siprec" in a Supported header. > >>>>>>>> If an SRC or SRS requires SIPREC XML, it may indicate that by > >>>>>>> including > >>>>>>>> "siprec" in a Require header. > >>>>>>>> > >>>>>>>> I do not see this as lowering the bar for SIPREC compliance. > >>>>>>>> I do see it as providing benefit for implementations that have > >>>> no > >>>>>>>> intention of being a SIPREC compliant SRC or SRS. > >>>>>>>> I also see it helping with interworking between SIPREC > > compliant > >>>>> and > >>>>>>> non > >>>>>>>> SIPREC compliant entities. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Charles > >>> > > > > From john.2.stafford@bt.com Tue Feb 28 00:09:58 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3032B21F871C for ; Tue, 28 Feb 2012 00:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq0hSXRui9BV for ; Tue, 28 Feb 2012 00:09:57 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5834721F8718 for ; Tue, 28 Feb 2012 00:09:56 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 28 Feb 2012 08:09:56 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.172]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Tue, 28 Feb 2012 08:09:54 +0000 From: To: Date: Tue, 28 Feb 2012 08:09:54 +0000 Thread-Topic: How to specify in metadata that a participants stream is being recorded in multtiple m line streams Thread-Index: AQHM8x7AXahTJKcSv0iMEMvfuWkzx5ZQ5wAQgAEOW6w= Message-ID: References: , <96B3D51234119144AE22BA9E1E3E0F81192A44EF95@EMV03-UKBR.domain1.systemhost.net> In-Reply-To: <96B3D51234119144AE22BA9E1E3E0F81192A44EF95@EMV03-UKBR.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_BBA98B7742309546A60F3AE3B4E975A72886E2288DEMV64UKRDdoma_" MIME-Version: 1.0 Cc: TuanHoang.Nguyen@verint.com, Mark.Goodall@verint.com, Marc.Calahan@verint.com Subject: [siprec] How to specify in metadata that a participants stream is being recorded in multtiple m line streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 08:09:58 -0000 --_000_BBA98B7742309546A60F3AE3B4E975A72886E2288DEMV64UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Guys, We have a somewhat unusual requirement for recording from our turret. The turret is a Recording Aware UA that supports multiple simultaneous call= s. The turret supports two handsets and many speaker channels. We are going to have a configuration where there will be multiple recording= streams sent from the turret to the recorder, for simplicity I'll describ= e when we have one record stream for handset 1 calls, and another record st= ream for handset 2 calls. Each record stream records a call as a single mixed stream. At registration, the turret sets up a single persistent RS containing two m= lines in the INVITES sdp, the first m-line will be used for recording calls on handset 1, and is labe= lled HS1_stream the 2nd m line will be used for recording calls on handset 2. and is labell= ed HS2_stream When we have a call on handset 1, the call is recorded in a single mixed st= ream to the recorder so metadata describing the handset1 record stream would be: RamMohan R i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D Paul Kyzivat 8zc6e0lYTlWIINA6GR+3ag=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D 2010-12-16T23:41:07Z Now the 2nd handset is barge conferenced into the same call ! (sometime a t= rader gives 2nd handset to another trader to join in same call) You might expect the metadata describing the handset1 record stream would c= hange to: RamMohan R i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D aBzzAkhhlbcSHAxxkcdj=3D=3D Paul Kyzivat 8zc6e0lYTlWIINA6GR+3ag=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D aBzzAkhhlbcSHAxxkcdj=3D=3D 2010-12-16T23:41:07Z John Stafford aBzzAkhhlbcSHAxxkcdj=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D 2010-12-16T27:12:07Z However, this is not correct, as the conference is also getting recorded in= the handset 2 m line stream. How can we convey this information to the recorder ? I would like to be able to put multiple labels on the streams, but the sipr= ec schema does not allow it, ie: Is there any reason why the schema limits stream to having a single label ? Rgds John Stafford | Solution Architect 1 | BT Global Services --_000_BBA98B7742309546A60F3AE3B4E975A72886E2288DEMV64UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Guys,

 

 

We have a somewhat unusual requirement for re= cording from our turret.

The turret is a Recordi= ng Aware UA that supports multiple simultaneous calls.

 

The turret supports two handsets and many spe= aker channels.

 

We are going to have a configuration where th= ere will be multiple recording streams sent from the turret to the recorder= ,  for simplicity I'll describe when we have one record st= ream for handset 1 calls, and another record stream for handset 2 calls.

Each record stream records a call as a single= mixed stream.

 

At registration, the turret sets up a single = persistent RS containing two m lines in the INVITES sdp,

the first m-line will be used for recording c= alls on handset 1, and is labelled HS1_stream

the 2nd m line will be used for recording cal= ls on handset 2. and is labelled HS2_stream

 

 

 

When we have a call on handset 1, the call is= recorded in a single mixed stream to the recorder

so metadata describing the handset1 record st= ream would be:

 

 

       &nb= sp;     <session id=3D"hVpd7YQgRW2nD22h7q60JQ= =3D=3D">
             &l= t;/session>

 

       &nb= sp;     <participant
            &nb= sp;   id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"
            &nb= sp;   session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">
            &nb= sp;   <nameID aor=3Dsip:ram@blr.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">RamMohan R&l= t;/name>
            &nb= sp;            =     </nameID>
            &nb= sp;   <send>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</send>             &nb= sp;   <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv>              &l= t;/participant>

 

       &nb= sp;     <participant
            &nb= sp;    id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <nameID aor=3Dsip:paul@box.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">Paul Kyzivat= </name>
            &nb= sp;            =     </nameID>
            &nb= sp;    <send>8zc6e0lYTlWIINA6GR+3ag=3D=3D</send= >
            &nb= sp;    <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv= >
            &nb= sp;    <associate-time>2010-12-16T23:41:07Z</associ= ate-time>
             &l= t;/participant>

 

       &nb= sp;     <stream id=3D"i1Pz3to5hGk8fuXl+PbwC= w=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>

       &nb= sp;     <stream id=3D"8zc6e0lYTlWIINA6GR+3a= g=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>

 

 

 

Now the 2nd handset is barge conferenced into= the same call ! (sometime a trader gives 2nd handset to another trader to = join in same call)

 

 

You might expect the metadata describing the = handset1 record stream would change to:

 

       &nb= sp;     <session id=3D"hVpd7YQgRW2nD22h7q60JQ= =3D=3D">
             &l= t;/session>

 

       &nb= sp;     <participant
            &nb= sp;   id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"
            &nb= sp;   session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">
            &nb= sp;   <nameID aor=3Dsip:ram@blr.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">RamMohan R&l= t;/name>
            &nb= sp;            =     </nameID>
            &nb= sp;   <send>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</send>             &nb= sp;   <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv>             &nb= sp;    <recv>aBzzAkhhlbcSHAxxkcdj=3D=3D</recv>              &l= t;/participant>

 

       &nb= sp;     <participant
            &nb= sp;    id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <nameID aor=3Dsip:paul@box.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">Paul Kyzivat= </name>
            &nb= sp;            =     </nameID>
            &nb= sp;    <send>8zc6e0lYTlWIINA6GR+3ag=3D=3D</send= >
            &nb= sp;    <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv= >
            &nb= sp;    <recv>aBzzAkhhlbcSHAxxkcdj=3D=3D</recv>             &nb= sp;    <associate-time>2010-12-16T23:41:07Z</associ= ate-time>
             &l= t;/participant>

 

       &nb= sp;     <participant     &n= bsp;
            &nb= sp;    id=3D"zSfPoSvdSDCmU3A3TxACDeh=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <nameID aor=3Dsip:John@box.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">John Staffor= d</name>
            &nb= sp;            =     </nameID>
            &nb= sp;    <send>aBzzAkhhlbcSHAxxkcdj=3D=3D</send>             &nb= sp;    <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv= >
            &nb= sp;    <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv= >
            &nb= sp; <associate-time>2010-12-16T27:12:07Z</associate-time>
             &l= t;/participant>

 

 

       &nb= sp;     <stream id=3D"i1Pz3to5hGk8fuXl+PbwC= w=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>

       &nb= sp;     <stream id=3D"8zc6e0lYTlWIINA6GR+3a= g=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>
             &l= t;stream id=3D"aBzzAkhhlbcSHAxxkcdj=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>

 

However, this is not correct, as the conferen= ce is also getting recorded in the handset 2 m line stream.

 

How can we convey this information to the rec= order ?

 

I would like to be able to put multiple label= s on the streams, but the siprec schema does not allow it,  ie:=

       &nb= sp;     <stream id=3D"i1Pz3to5hGk8fuXl+PbwC= w=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
            &nb= sp;    <label>HS2_stream</label>
             &l= t;/stream>

       &nb= sp;     <stream id=3D"8zc6e0lYTlWIINA6GR+3a= g=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
            &nb= sp;    <label>HS2_stream</label>
             &l= t;/stream>
             &l= t;stream id=3D"aBzzAkhhlbcSHAxxkcdj=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
            &nb= sp;    <label>HS2_stream</label>
             &l= t;/stream>

Is there any reason why the schema limits str= eam to having a single label ?

 

 

Rgds

John Stafford |&= nbsp;Solution Architect 1 | BT Global Services

--_000_BBA98B7742309546A60F3AE3B4E975A72886E2288DEMV64UKRDdoma_-- From gonzalo.camarillo@ericsson.com Tue Feb 28 03:20:27 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B5921F8589 for ; Tue, 28 Feb 2012 03:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.247 X-Spam-Level: X-Spam-Status: No, score=-110.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04TimE0X4obe for ; Tue, 28 Feb 2012 03:20:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F1C7B21F85F4 for ; Tue, 28 Feb 2012 03:20:26 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-e1-4f4cb8789f7f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EE.96.27041.878BC4F4; Tue, 28 Feb 2012 12:20:24 +0100 (CET) Received: from [131.160.36.141] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012 12:20:23 +0100 Message-ID: <4F4CB877.9070205@ericsson.com> Date: Tue, 28 Feb 2012 13:20:23 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <4F4CB861.4090805@ericsson.com> In-Reply-To: <4F4CB861.4090805@ericsson.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <4F4CB861.4090805@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [siprec] Fwd: How to exchange metadata about the media streams established with a SIP session X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 11:20:28 -0000 FYI. -------- Original Message -------- Subject: How to exchange metadata about the media streams established with a SIP session Date: Tue, 28 Feb 2012 13:20:01 +0200 From: Gonzalo Camarillo To: rai@ietf.org Folks, I am sending this email to the RAI list because it is about an architectural issue that affects more than one WG. Both the CLUE and SIPREC WGs have identified the need to exchange metadata about media streams that have been established using SIP. Both groups need to transport such metadata between SIP UAs. In CLUE, they are studying how to transport their metadata, as documented in: http://tools.ietf.org/html/draft-wenger-clue-transport-01 In SIPREC, they are planning to piggyback the metadata in SIP UPDATEs as an XML-encoded body part. When they need to send a request for full state (as opposed to partial state), they use an UPDATE request with a particular body type, as documented in: http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 The best way to exchange metadata within a SIP session depends on the type of metadata and on how the UAs need to interact with each other (e.g., a UA simply pushing information to the other UA or a more complicated protocol). Given that SIPREC and CLUE have different metadata and interactions, it may well be that we decide to use a different mechanism in each group. Nevertheless, I think both groups would benefit from architecturally-inclined RAI people having a look at their work. Please, continue this discussion focusing on their specific requirements on either the CLUE list or the SIPREC list. Somewhat related to this issue, the RTCWeb group discussed the use of SCTP over UDP as a reliable NAT-friendly way to exchange data between endpoints. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Tue Feb 28 03:42:18 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE88F21F8613 for ; Tue, 28 Feb 2012 03:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.252 X-Spam-Level: X-Spam-Status: No, score=-110.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18dNrVmak6AI for ; Tue, 28 Feb 2012 03:42:18 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 243DD21F8615 for ; Tue, 28 Feb 2012 03:42:17 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-ca-4f4cbd99a713 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.B2.01970.99DBC4F4; Tue, 28 Feb 2012 12:42:17 +0100 (CET) Received: from [131.160.36.141] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012 12:42:16 +0100 Message-ID: <4F4CBD98.9010801@ericsson.com> Date: Tue, 28 Feb 2012 13:42:16 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [siprec] Comments on draft-ietf-siprec-architecture-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: Tue, 28 Feb 2012 11:42:19 -0000 Hi, some comments on the architecture draft: http://tools.ietf.org/html/draft-ietf-siprec-architecture-03 All acronyms need to be expanded on their first use. Also, the use of acronyms need to be consistent throughout the document. For example, in Section 3.1.1 in some cases the acronym appears without its expansion, in other cases the expansion appears without the acronym, and in other cases both appear together. In Section 2 (Definitions), there is a definition of a Recording aware UA. For completeness, the text should talk about recording unaware UAs as well, either as part of the same definition of as a new term. Also in that definition: s/notify the SIP UA/notify the Recording aware UA/ s/all the SIP UA/all the Recording aware UAs/ The definition of Replicated Media needs to explain its relation with the Recording Session (RS). Section 3.1.1, 4th paragraph: s/will need to contain/contains/ Section 3.1.2, 3rd paragraph. The text could touch upon how a RS can know about an endpoint and about the fact that the endpoint will establish a session that needs to be recorded at some point. Something brief would be enough. Section 3.1.4 talks about the RTCWeb control protocol. The text needs to be more explicit because it is not clear what protocol that sentence refers to. Section 3.2.1, 3rd bullet. The bullet talks about two possible mechanisms. The text should be more clear on that, given that they are not just two possible mechanisms out of many. They are the only two mechanisms defined in the protocol document, one of which is mandatory (i.e., at a MUST level). Section 3.2.2 misses a first bullet like the one in Section 3.2.1, about how the URI of the SRC is provisioned. Section 3.2.2, 3rd bullet. Why does it say "Possibly"? The document could include a bit more text explaining what the protocol document defines so that it is easier for readers to understand what exactly they will find there. Cheers, Gonzalo From pravindran@sonusnet.com Tue Feb 28 03:59:54 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98F821F8619 for ; Tue, 28 Feb 2012 03:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PLcr018oydQ for ; Tue, 28 Feb 2012 03:59:53 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCAD21F8615 for ; Tue, 28 Feb 2012 03:59:52 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1SC0YTm029270; Tue, 28 Feb 2012 07:00:35 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 06:59:45 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 17:29:42 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 28 Feb 2012 17:29:41 +0530 From: "Ravindran, Parthasarathi" To: "john.2.stafford@bt.com" , "siprec@ietf.org" Thread-Topic: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams Thread-Index: AQHM9hB0g8XPqQaJKkuVv0j4mMsWkg== Date: Tue, 28 Feb 2012 11:59:42 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E051086@inba-mail01.sonusnet.com> References: , <96B3D51234119144AE22BA9E1E3E0F81192A44EF95@EMV03-UKBR.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E051086inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 11:59:42.0364 (UTC) FILETIME=[74A2D5C0:01CCF610] Cc: "TuanHoang.Nguyen@verint.com" , "Marc.Calahan@verint.com" , "Mark.Goodall@verint.com" Subject: Re: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 11:59:55 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E051086inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, I need clarification whether the barge-call leads to the mixed stream towar= ds recorder or un-mixed stream towards recorder. Your example with multiple= label indicates that it is un-mixed stream whereas the initial call is mix= ed. Could you please clarify on this point for providing the appropriate me= tadata. In case of un-mixed stream, it is possible to create multiple stream with s= ingle label and participants points to multiple stream. In case of mixed st= ream, there is no concept of multiple label. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= john.2.stafford@bt.com Sent: Tuesday, February 28, 2012 1:40 PM To: siprec@ietf.org Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; Marc.Calahan@veri= nt.com Subject: [siprec] How to specify in metadata that a participants stream is = being recorded in multtiple m line streams Guys, We have a somewhat unusual requirement for recording from our turret. The turret is a Recording Aware UA that supports multiple simultaneous call= s. The turret supports two handsets and many speaker channels. We are going to have a configuration where there will be multiple recording= streams sent from the turret to the recorder, for simplicity I'll describ= e when we have one record stream for handset 1 calls, and another record st= ream for handset 2 calls. Each record stream records a call as a single mixed stream. At registration, the turret sets up a single persistent RS containing two m= lines in the INVITES sdp, the first m-line will be used for recording calls on handset 1, and is labe= lled HS1_stream the 2nd m line will be used for recording calls on handset 2. and is labell= ed HS2_stream When we have a call on handset 1, the call is recorded in a single mixed st= ream to the recorder so metadata describing the handset1 record stream would be: RamMohan R i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D Paul Kyzivat 8zc6e0lYTlWIINA6GR+3ag=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D 2010-12-16T23:41:07Z Now the 2nd handset is barge conferenced into the same call ! (sometime a t= rader gives 2nd handset to another trader to join in same call) You might expect the metadata describing the handset1 record stream would c= hange to: RamMohan R i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D aBzzAkhhlbcSHAxxkcdj=3D=3D Paul Kyzivat 8zc6e0lYTlWIINA6GR+3ag=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D aBzzAkhhlbcSHAxxkcdj=3D=3D 2010-12-16T23:41:07Z John Stafford aBzzAkhhlbcSHAxxkcdj=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D 2010-12-16T27:12:07Z However, this is not correct, as the conference is also getting recorded in= the handset 2 m line stream. How can we convey this information to the recorder ? I would like to be able to put multiple labels on the streams, but the sipr= ec schema does not allow it, ie: Is there any reason why the schema limits stream to having a single label ? Rgds John Stafford | Solution Architect 1 | BT Global Services --_000_387F9047F55E8C42850AD6B3A7A03C6C0E051086inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 <= /p>

I need clarification whet= her the barge-call leads to the mixed stream towards recorder or un-mixed s= tream towards recorder. Your example with multiple label indicates that it is un-mixed stream whereas the initial call is mixed. Co= uld you please clarify on this point for providing the appropriate metadata= .

 <= /p>

In case of un-mixed strea= m, it is possible to create multiple stream with single label and participa= nts points to multiple stream. In case of mixed stream, there is no concept of multiple label.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: siprec-b= ounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of john.2.stafford@bt.com
Sent: Tuesday, February 28, 2012 1:40 PM
To: siprec@ietf.org
Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; Marc.Calah= an@verint.com
Subject: [siprec] How to specify in metadata that a participants str= eam is being recorded in multtiple m line streams

 

Guys,

 

 

We have a som= ewhat unusual requirement for recording from our turret.

The turret is= a Recording Aware UA that supports multiple simultaneous calls.

 

The turret su= pports two handsets and many speaker channels.

 

We are going = to have a configuration where there will be multiple recording streams sent= from the turret to the recorder,  for simplicity I'll describe when we have one record stream for handset 1 calls, and another record str= eam for handset 2 calls.<= o:p>

Each record s= tream records a call as a single mixed stream.

 

At registrati= on, the turret sets up a single persistent RS containing two m li= nes in the INVITES sdp,

the first m-l= ine will be used for recording calls on handset 1, and is labelled HS1_stre= am

the 2nd m lin= e will be used for recording calls on handset 2. and is labelled HS2_stream=

 

 

 

When we have = a call on handset 1, the call is recorded in a single mixed stream to the r= ecorder=

so metadata d= escribing the handset1 record stream would be:

 

 

  &= nbsp;          <session id= =3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">
             &l= t;/session>=

 

  &= nbsp;          <participant=
            &nb= sp;   id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"
            &nb= sp;   session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">
            &nb= sp;   <nameID aor=3Dsip:ram@blr.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">RamMohan R&l= t;/name>
            &nb= sp;            =     </nameID>
            &nb= sp;   <send>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</send>             &nb= sp;   <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv>              &l= t;/participant>

 

  &= nbsp;          <participant=
            &nb= sp;    id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <nameID aor=3Dsip:paul@box.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">Paul Kyzivat= </name>
            &nb= sp;            =     </nameID>
            &nb= sp;    <send>8zc6e0lYTlWIINA6GR+3ag=3D=3D</send= >
            &nb= sp;    <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv= >
            &nb= sp;    <associate-time>2010-12-16T23:41:07Z</associ= ate-time>
             &l= t;/participant>

 

  &= nbsp;          <stream id= =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream><= /span>

  &= nbsp;          <stream id= =3D"8zc6e0lYTlWIINA6GR+3ag=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream><= /span>

 

 

 

Now the 2nd h= andset is barge conferenced into the same call ! (sometime a trader gives 2= nd handset to another trader to join in same call)

 

 

You might exp= ect the metadata describing the handset1 record stream would change to:

 

  &= nbsp;          <session id= =3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">
             &l= t;/session>=

 

  &= nbsp;          <participant=
            &nb= sp;   id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"
            &nb= sp;   session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">
            &nb= sp;   <nameID aor=3Dsip:ram@blr.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">RamMohan R&l= t;/name>
            &nb= sp;            =     </nameID>
            &nb= sp;   <send>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</send>             &nb= sp;   <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv>             &nb= sp;    <recv>aBzzAkhhlbcSHAxxkcdj=3D=3D</recv>              &l= t;/participant>

 

  &= nbsp;          <participant=
            &nb= sp;    id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <nameID aor=3Dsip:paul@box.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">Paul Kyzivat= </name>
            &nb= sp;            =     </nameID>
            &nb= sp;    <send>8zc6e0lYTlWIINA6GR+3ag=3D=3D</send= >
            &nb= sp;    <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv= >
            &nb= sp;    <recv>aBzzAkhhlbcSHAxxkcdj=3D=3D</recv>             &nb= sp;    <associate-time>2010-12-16T23:41:07Z</associ= ate-time>
             &l= t;/participant>

 

  &= nbsp;          <participant=       
            &nb= sp;    id=3D"zSfPoSvdSDCmU3A3TxACDeh=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <nameID aor=3Dsip:John@box.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">John Staffor= d</name>
            &nb= sp;            =     </nameID>
            &nb= sp;    <send>aBzzAkhhlbcSHAxxkcdj=3D=3D</send>             &nb= sp;    <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv= >
            &nb= sp;    <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv= >
            &nb= sp; <associate-time>2010-12-16T27:12:07Z</associate-time>
             &l= t;/participant>

 

 

  &= nbsp;          <stream id= =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream><= /span>

  &= nbsp;          <stream id= =3D"8zc6e0lYTlWIINA6GR+3ag=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>
             &l= t;stream id=3D"aBzzAkhhlbcSHAxxkcdj=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream><= /span>

 

However, this= is not correct, as the conference is also getting recorded in the handset = 2 m line stream.

 

How can we co= nvey this information to the recorder ?

 

I would like = to be able to put multiple labels on the streams, but the siprec schema doe= s not allow it,  ie:=

  &= nbsp;          <stream id= =3D"i1Pz3to5hGk8fuXl+PbwCw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
            &nb= sp;    <label>HS2_stream</label>
             &l= t;/stream><= /span>

  &= nbsp;          <stream id= =3D"8zc6e0lYTlWIINA6GR+3ag=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
            &nb= sp;    <label>HS2_stream</label>
             &l= t;/stream>
             &l= t;stream id=3D"aBzzAkhhlbcSHAxxkcdj=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
            &nb= sp;    <label>HS2_stream</label>
             &l= t;/stream><= /span>

Is there any = reason why the schema limits stream to having a single label ?

 

 

Rgds<= /span>

John Stafford | Solution Architect 1 | BT Global Se= rvices

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E051086inbamail01sonus_-- From gonzalo.camarillo@ericsson.com Tue Feb 28 04:54:49 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F52721F85B6 for ; Tue, 28 Feb 2012 04:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.808 X-Spam-Level: X-Spam-Status: No, score=-108.808 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaNFX9pGYlhF for ; Tue, 28 Feb 2012 04:54:47 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 68AED21F8565 for ; Tue, 28 Feb 2012 04:54:46 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-74-4f4cce94cea1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 45.B3.01970.49ECC4F4; Tue, 28 Feb 2012 13:54:45 +0100 (CET) Received: from [131.160.36.141] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012 13:54:44 +0100 Message-ID: <4F4CCE94.7080808@ericsson.com> Date: Tue, 28 Feb 2012 14:54:44 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [siprec] Comments on draft-ietf-siprec-protocol-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 12:54:50 -0000 Hi, some comments on the protocol draft: http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 Section 4.1: s/the SRC wants record/the SRC wants to record/ That section talks about using a single recording session to record several communication sessions. Can a single recording session be used to record several communication sessions that take place at the same time (i.e., in parallel), or the communication sessions need to happen one after another (i.e., sequentially)? Section 5.1, 1st paragraph: That paragraph includes two MUSTs. However, the important advice in the paragraph seems to be the last sentence. Do we need those two MUSTs or specifying what the last sentence says would be enough? Section 5.2, 2nd paragraph: The text talks about an SRS registering. Is it expected that SRSes register in general? Section 6.1, 2nd paragraph: s/a recorded stream is different than a CS stream/a recorded stream can be different than a CS stream/ Section 6.2 What happens if the server becomes "not ready" while the stream is inactive (because the client set it as inactive before)? The sever will not be able to set the stream as inactive because it already is inactive. Then, the client will not know about the server not being ready and, consequently, will not look for alternative servers, which would be ready. Section 8.1. When the draft is ready, remember that the definition of new media types need to be reviewed by ietf-types@ietf.org. Section 8.2 Fix this sentence: The metadata snapshot request is contained the content with the disposition type "recording-session". Section 10.2.2 OLD: When the SRC receives the a=recordpref SDP in an SDP offer or answer, the SRC MAY choose to honor such request to record the request based on local policy on the SRC. NEW: When the SRC receives the a=recordpref SDP in an SDP offer or answer, the SRC chooses to honor such request to record based on local policy on the SRC. Cheers, Gonzalo From john.2.stafford@bt.com Tue Feb 28 05:14:34 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3475521F854E for ; Tue, 28 Feb 2012 05:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKW64u0+HyCV for ; Tue, 28 Feb 2012 05:14:32 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id AE43021F854A for ; Tue, 28 Feb 2012 05:14:30 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 28 Feb 2012 13:14:31 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.172]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 28 Feb 2012 13:14:29 +0000 From: To: , Date: Tue, 28 Feb 2012 13:14:29 +0000 Thread-Topic: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams Thread-Index: AQHM9hB0g8XPqQaJKkuVv0j4mMsWkpZSRxft Message-ID: References: , <96B3D51234119144AE22BA9E1E3E0F81192A44EF95@EMV03-UKBR.domain1.systemhost.net> , <387F9047F55E8C42850AD6B3A7A03C6C0E051086@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E051086@inba-mail01.sonusnet.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_BBA98B7742309546A60F3AE3B4E975A72886E2288FEMV64UKRDdoma_" MIME-Version: 1.0 Cc: TuanHoang.Nguyen@verint.com, Marc.Calahan@verint.com, Mark.Goodall@verint.com Subject: Re: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 13:14:34 -0000 --_000_BBA98B7742309546A60F3AE3B4E975A72886E2288FEMV64UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Partha After registration we have two RS streams from the turret, but becuase ther= e are is no call on iether handset, the streams are sending silence. When the call is made on handset 1, then the RS stream associated with that= handset records a mix of both the participants on the call. When the 2nd handset is barged into the call, the handset 1 stream records = a mix of all three oparticipants. BUT also RS stream assocaiated with the 2nd handset also records a mix of = all three oparticipants. So after barge the two streams of the persistent RS are both recording the = same mix of the 3 participants. So each participants stream is being recorded in two streams of the same RS= . Rgds John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932= 773504 | E: john.2.stafford@bt.com | ww= w.bt.com/globalservices ________________________________ From: Ravindran, Parthasarathi [pravindran@sonusnet.com] Sent: 28 February 2012 11:59 To: Stafford,J,John,JRJ3X C; siprec@ietf.org Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; Marc.Calahan@veri= nt.com Subject: RE: [siprec] How to specify in metadata that a participants stream= is being recorded in multiple m line streams John, I need clarification whether the barge-call leads to the mixed stream towar= ds recorder or un-mixed stream towards recorder. Your example with multiple= label indicates that it is un-mixed stream whereas the initial call is mix= ed. Could you please clarify on this point for providing the appropriate me= tadata. In case of un-mixed stream, it is possible to create multiple stream with s= ingle label and participants points to multiple stream. In case of mixed st= ream, there is no concept of multiple label. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= john.2.stafford@bt.com Sent: Tuesday, February 28, 2012 1:40 PM To: siprec@ietf.org Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; Marc.Calahan@veri= nt.com Subject: [siprec] How to specify in metadata that a participants stream is = being recorded in multtiple m line streams Guys, We have a somewhat unusual requirement for recording from our turret. The turret is a Recording Aware UA that supports multiple simultaneous call= s. The turret supports two handsets and many speaker channels. We are going to have a configuration where there will be multiple recording= streams sent from the turret to the recorder, for simplicity I'll describ= e when we have one record stream for handset 1 calls, and another record st= ream for handset 2 calls. Each record stream records a call as a single mixed stream. At registration, the turret sets up a single persistent RS containing two m= lines in the INVITES sdp, the first m-line will be used for recording calls on handset 1, and is labe= lled HS1_stream the 2nd m line will be used for recording calls on handset 2. and is labell= ed HS2_stream When we have a call on handset 1, the call is recorded in a single mixed st= ream to the recorder so metadata describing the handset1 record stream would be: RamMohan R i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D Paul Kyzivat 8zc6e0lYTlWIINA6GR+3ag=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D 2010-12-16T23:41:07Z Now the 2nd handset is barge conferenced into the same call ! (sometime a t= rader gives 2nd handset to another trader to join in same call) You might expect the metadata describing the handset1 record stream would c= hange to: RamMohan R i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D aBzzAkhhlbcSHAxxkcdj=3D=3D Paul Kyzivat 8zc6e0lYTlWIINA6GR+3ag=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D aBzzAkhhlbcSHAxxkcdj=3D=3D 2010-12-16T23:41:07Z John Stafford aBzzAkhhlbcSHAxxkcdj=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D 8zc6e0lYTlWIINA6GR+3ag=3D=3D 2010-12-16T27:12:07Z However, this is not correct, as the conference is also getting recorded in= the handset 2 m line stream. How can we convey this information to the recorder ? I would like to be able to put multiple labels on the streams, but the sipr= ec schema does not allow it, ie: Is there any reason why the schema limits stream to having a single label ? Rgds John Stafford | Solution Architect 1 | BT Global Services --_000_BBA98B7742309546A60F3AE3B4E975A72886E2288FEMV64UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Partha
 
After registration we have two RS streams from t= he turret, but becuase there are is no call on iether handset, the streams = are sending silence.
 
When the call is made on handset 1, then the RS = stream associated with that handset records a mix of both the participants = on the call.
 
When the 2nd handset is barged into the call, th= e handset 1 stream records a mix of all three oparticipants.
 
BUT also RS stream assocaiated with the  2n= d handset also records a mix of all three oparticipants.
 
So after barge the two streams of the persi= stent RS are both recording the same mix of the 3 participants.
 
So each participants stream is being recorded in= two streams of the same RS.
 
 
Rgds
John Stafford | Solution Architect 1 | BT Global = Services | Tel:+44 (0)1932 773504   | E: john.2.stafford@bt.co= m  |  www.bt.com/globals= ervices=
 
=  
From: Ravindran, = Parthasarathi [pravindran@sonusnet.com]
Sent: 28 February 2012 11:59
To: Stafford,J,John,JRJ3X C; siprec@ietf.org
Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; Marc.Calah= an@verint.com
Subject: RE: [siprec] How to specify in metadata that a participants= stream is being recorded in multiple m line streams

John,

 

I need clarification whether the barge-cal= l leads to the mixed stream towards recorder or un-mixed stream towards rec= order. Your example with multiple label indicates that it is un-mixed stream whereas the initial call is mixed. Co= uld you please clarify on this point for providing the appropriate metadata= .

 

In case of un-mixed stream, it is possible= to create multiple stream with single label and participants points to mul= tiple stream. In case of mixed stream, there is no concept of multiple label.

 

Thanks

Partha

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces= @ietf.org] On Behalf Of john.2.stafford@bt.com
Sent: Tuesday, February 28, 2012 1:40 PM
To: siprec@ietf.org
Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; Marc.Calah= an@verint.com
Subject: [siprec] How to specify in metadata that a participants str= eam is being recorded in multtiple m line streams

 

Guys,

&= nbsp;

&= nbsp;

We have a somewhat unusual req= uirement for recording from our turret.

The turret is a Recording Awar= e UA that supports multiple simultaneous calls.

&= nbsp;

The turret supports two handse= ts and many speaker channels.

&= nbsp;

We are going to have a configu= ration where there will be multiple recording streams sent from the turret = to the recorder,  for simplicity I'll describe when we have one record stream for handset 1 calls, and another r= ecord stream for handset 2 calls.

Each record stream records a c= all as a single mixed stream.

&= nbsp;

At registration, the turret se= ts up a single persistent RS containing two m lines in the INVITE= S sdp,

the first m-line will be used = for recording calls on handset 1, and is labelled HS1_stream

the 2nd m line will be used fo= r recording calls on handset 2. and is labelled HS2_stream

&= nbsp;

&= nbsp;

&= nbsp;

When we have a call on handset= 1, the call is recorded in a single mixed stream to the recorder

so metadata describing the han= dset1 record stream would be:

&= nbsp;

&= nbsp;

     =         <session id=3D"hVpd7YQgR= W2nD22h7q60JQ=3D=3D">
             &l= t;/session>

&= nbsp;

     =         <participant
            &nb= sp;   id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"
            &nb= sp;   session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">
            &nb= sp;   <nameID aor=3Dsip:ram@blr.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">RamMohan R&l= t;/name>
            &nb= sp;            =     </nameID>
            &nb= sp;   <send>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</send>             &nb= sp;   <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv>              &l= t;/participant>

&= nbsp;

     =         <participant
            &nb= sp;    id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <nameID aor=3Dsip:paul@box.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">Paul Kyzivat= </name>
            &nb= sp;            =     </nameID>
            &nb= sp;    <send>8zc6e0lYTlWIINA6GR+3ag=3D=3D</send= >
            &nb= sp;    <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv= >
            &nb= sp;    <associate-time>2010-12-16T23:41:07Z</associ= ate-time>
             &l= t;/participant>

&= nbsp;

     =         <stream id=3D"i1Pz3to5hG= k8fuXl+PbwCw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>

     =         <stream id=3D"8zc6e0lYTl= WIINA6GR+3ag=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>

&= nbsp;

&= nbsp;

&= nbsp;

Now the 2nd handset is barge c= onferenced into the same call ! (sometime a trader gives 2nd handset to ano= ther trader to join in same call)

&= nbsp;

&= nbsp;

You might expect the metadata = describing the handset1 record stream would change to:

&= nbsp;

     =         <session id=3D"hVpd7YQgR= W2nD22h7q60JQ=3D=3D">
             &l= t;/session>

&= nbsp;

     =         <participant
            &nb= sp;   id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D"
            &nb= sp;   session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">
            &nb= sp;   <nameID aor=3Dsip:ram@blr.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">RamMohan R&l= t;/name>
            &nb= sp;            =     </nameID>
            &nb= sp;   <send>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</send>             &nb= sp;   <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv>             &nb= sp;    <recv>aBzzAkhhlbcSHAxxkcdj=3D=3D</recv>              &l= t;/participant>

&= nbsp;

     =         <participant
            &nb= sp;    id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <nameID aor=3Dsip:paul@box.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">Paul Kyzivat= </name>
            &nb= sp;            =     </nameID>
            &nb= sp;    <send>8zc6e0lYTlWIINA6GR+3ag=3D=3D</send= >
            &nb= sp;    <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv= >
            &nb= sp;    <recv>aBzzAkhhlbcSHAxxkcdj=3D=3D</recv>             &nb= sp;    <associate-time>2010-12-16T23:41:07Z</associ= ate-time>
             &l= t;/participant>

&= nbsp;

     =         <participant   = ;   
            &nb= sp;    id=3D"zSfPoSvdSDCmU3A3TxACDeh=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <nameID aor=3Dsip:John@box.cisco.com>
            &nb= sp;            =      <name xml:lang=3D"it">John Staffor= d</name>
            &nb= sp;            =     </nameID>
            &nb= sp;    <send>aBzzAkhhlbcSHAxxkcdj=3D=3D</send>             &nb= sp;    <recv>i1Pz3to5hGk8fuXl+PbwCw=3D=3D</recv= >
            &nb= sp;    <recv>8zc6e0lYTlWIINA6GR+3ag=3D=3D</recv= >
            &nb= sp; <associate-time>2010-12-16T27:12:07Z</associate-time>
             &l= t;/participant>

&= nbsp;

&= nbsp;

     =         <stream id=3D"i1Pz3to5hG= k8fuXl+PbwCw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>

     =         <stream id=3D"8zc6e0lYTl= WIINA6GR+3ag=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>
             &l= t;stream id=3D"aBzzAkhhlbcSHAxxkcdj=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
             &l= t;/stream>

&= nbsp;

However, this is not correct, = as the conference is also getting recorded in the handset 2 m line stream.<= /span>

&= nbsp;

How can we convey this informa= tion to the recorder ?

&= nbsp;

I would like to be able to put= multiple labels on the streams, but the siprec schema does not allow it, &= nbsp;ie:

     =         <stream id=3D"i1Pz3to5hG= k8fuXl+PbwCw=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
            &nb= sp;    <label>HS2_stream</label>
             &l= t;/stream>

     =         <stream id=3D"8zc6e0lYTl= WIINA6GR+3ag=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
            &nb= sp;    <label>HS2_stream</label>
             &l= t;/stream>
             &l= t;stream id=3D"aBzzAkhhlbcSHAxxkcdj=3D=3D"
            &nb= sp;    session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D">= ;
            &nb= sp;    <label>HS1_stream</label>
            &nb= sp;    <label>HS2_stream</label>
             &l= t;/stream>

Is there any reason why the sc= hema limits stream to having a single label ?

&= nbsp;

&= nbsp;

Rgds

John S= tafford | Solution Architect 1 | BT Global Services

--_000_BBA98B7742309546A60F3AE3B4E975A72886E2288FEMV64UKRDdoma_-- From pkyzivat@alum.mit.edu Tue Feb 28 05:39:47 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FDC21F8505 for ; Tue, 28 Feb 2012 05:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UglCo8bUyeqW for ; Tue, 28 Feb 2012 05:39:46 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 4298121F8503 for ; Tue, 28 Feb 2012 05:39:44 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta15.westchester.pa.mail.comcast.net with comcast id fRQf1i0010SCNGk5FRflEz; Tue, 28 Feb 2012 13:39:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta09.westchester.pa.mail.comcast.net with comcast id fRfk1i01L07duvL3VRfkin; Tue, 28 Feb 2012 13:39:45 +0000 Message-ID: <4F4CD91F.9090801@alum.mit.edu> Date: Tue, 28 Feb 2012 08:39:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: , <96B3D51234119144AE22BA9E1E3E0F81192A44EF95@EMV03-UKBR.domain1.systemhost.net> , <387F9047F55E8C42850AD6B3A7A03C6C0E051086@inba-mail01.sonusnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 13:39:47 -0000 On 2/28/12 8:14 AM, john.2.stafford@bt.com wrote: > Partha > After registration we have two RS streams from the turret, but becuase > there are is no call on iether handset, the streams are sending silence. > When the call is made on handset 1, then the RS stream associated with > that handset records a mix of both the participants on the call. > When the 2nd handset is barged into the call, the handset 1 stream > records a mix of all three oparticipants. > BUT also RS stream assocaiated with the 2nd handset also records a mix > of all three oparticipants. > So after barge the two streams of the persistent RS are both recording > the same mix of the 3 participants. > So each participants stream is being recorded in two streams of the same RS. > Rgds So you are sending mixed media for the 3-party call twice? Why would you do that? Is it for redundance? Or just that you are incapable of *not* doing so? What do you want the recorder to do about it? Do you want the recorder to record the call twice? Or do you want it to ignore one of the streams? Thanks, Paul > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 > (0)1932 773504| E: john.2.stafford@bt.com > |_www.bt.com/globalservices > _ > ------------------------------------------------------------------------ > *From:* Ravindran, Parthasarathi [pravindran@sonusnet.com] > *Sent:* 28 February 2012 11:59 > *To:* Stafford,J,John,JRJ3X C; siprec@ietf.org > *Cc:* TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > Marc.Calahan@verint.com > *Subject:* RE: [siprec] How to specify in metadata that a participants > stream is being recorded in multiple m line streams > > John, > > I need clarification whether the barge-call leads to the mixed stream > towards recorder or un-mixed stream towards recorder. Your example with > multiple label indicates that it is un-mixed stream whereas the initial > call is mixed. Could you please clarify on this point for providing the > appropriate metadata. > > In case of un-mixed stream, it is possible to create multiple stream > with single label and participants points to multiple stream. In case of > mixed stream, there is no concept of multiple label. > > Thanks > > Partha > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *john.2.stafford@bt.com > *Sent:* Tuesday, February 28, 2012 1:40 PM > *To:* siprec@ietf.org > *Cc:* TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > Marc.Calahan@verint.com > *Subject:* [siprec] How to specify in metadata that a participants > stream is being recorded in multtiple m line streams > > Guys, > > We have a somewhat unusual requirement for recording from our turret. > > The turret is a Recording Aware UA that supports multiple simultaneous > calls. > > The turret supports two handsets and many speaker channels. > > We are going to have a configuration where there will be multiple > recording streams sent from the turret to the recorder, for simplicity > I'll describe when we have one record stream for handset 1 calls, and > another record stream for handset 2 calls. > > Each record stream records a call as a single mixed stream. > > At registration, the turret sets up a single persistent RS containing > two m lines in the INVITES sdp, > > the first m-line will be used for recording calls on handset 1, and is > labelled HS1_stream > > the 2nd m line will be used for recording calls on handset 2. and is > labelled HS2_stream > > When we have a call on handset 1, the call is recorded in a single mixed > stream to the recorder > > so metadata describing the handset1 record stream would be: > > > > > id="srfBElmCRp2QB23b7Mpk0w==" > session="hVpd7YQgRW2nD22h7q60JQ=="> > > RamMohan R > > i1Pz3to5hGk8fuXl+PbwCw== > 8zc6e0lYTlWIINA6GR+3ag== > > > id="zSfPoSvdSDCmU3A3TRDxAw==" > session="hVpd7YQgRW2nD22h7q60JQ=="> > > Paul Kyzivat > > 8zc6e0lYTlWIINA6GR+3ag== > i1Pz3to5hGk8fuXl+PbwCw== > 2010-12-16T23:41:07Z > > > session="hVpd7YQgRW2nD22h7q60JQ=="> > > > > session="hVpd7YQgRW2nD22h7q60JQ=="> > > > > Now the 2nd handset is barge conferenced into the same call ! (sometime > a trader gives 2nd handset to another trader to join in same call) > > You might expect the metadata describing the handset1 record stream > would change to: > > > > > id="srfBElmCRp2QB23b7Mpk0w==" > session="hVpd7YQgRW2nD22h7q60JQ=="> > > RamMohan R > > i1Pz3to5hGk8fuXl+PbwCw== > 8zc6e0lYTlWIINA6GR+3ag== > aBzzAkhhlbcSHAxxkcdj== > > > id="zSfPoSvdSDCmU3A3TRDxAw==" > session="hVpd7YQgRW2nD22h7q60JQ=="> > > Paul Kyzivat > > 8zc6e0lYTlWIINA6GR+3ag== > i1Pz3to5hGk8fuXl+PbwCw== > aBzzAkhhlbcSHAxxkcdj== > 2010-12-16T23:41:07Z > > > id="zSfPoSvdSDCmU3A3TxACDeh==" > session="hVpd7YQgRW2nD22h7q60JQ=="> > > John Stafford > > aBzzAkhhlbcSHAxxkcdj== > i1Pz3to5hGk8fuXl+PbwCw== > 8zc6e0lYTlWIINA6GR+3ag== > 2010-12-16T27:12:07Z > > > session="hVpd7YQgRW2nD22h7q60JQ=="> > > > > session="hVpd7YQgRW2nD22h7q60JQ=="> > > > session="hVpd7YQgRW2nD22h7q60JQ=="> > > > > However, this is not correct, as the conference is also getting recorded > in the handset 2 m line stream. > > How can we convey this information to the recorder ? > > I would like to be able to put multiple labels on the streams, but the > siprec schema does not allow it, ie: > > session="hVpd7YQgRW2nD22h7q60JQ=="> > > > > > session="hVpd7YQgRW2nD22h7q60JQ=="> > > > > session="hVpd7YQgRW2nD22h7q60JQ=="> > > > > > Is there any reason why the schema limits stream to having a single label ? > > Rgds > > John Stafford | Solution Architect 1 | BT Global Services > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Tue Feb 28 06:04:57 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF06B21F85C5 for ; Tue, 28 Feb 2012 06:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.155 X-Spam-Level: X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[AWL=-1.456, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, MANGLED_LIST=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQONiPj5VuHn for ; Tue, 28 Feb 2012 06:04:57 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8DC21F84E7 for ; Tue, 28 Feb 2012 06:04:57 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id fS4m1i0020Fqzac56S4xng; Tue, 28 Feb 2012 14:04:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta08.westchester.pa.mail.comcast.net with comcast id fS4x1i00507duvL3US4xWf; Tue, 28 Feb 2012 14:04:57 +0000 Message-ID: <4F4CDF06.3070909@alum.mit.edu> Date: Tue, 28 Feb 2012 09:04:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: siprec@ietf.org References: <4F4CCE94.7080808@ericsson.com> In-Reply-To: <4F4CCE94.7080808@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-02 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 14:04:58 -0000 Hi Gonzalo. Thanks for the review. I've commented inline of a few points. Paul On 2/28/12 7:54 AM, Gonzalo Camarillo wrote: > Hi, > > some comments on the protocol draft: > http://tools.ietf.org/html/draft-ietf-siprec-protocol-02 > > Section 4.1: > s/the SRC wants record/the SRC wants to record/ > That section talks about using a single recording session to record > several communication sessions. Can a single recording session be used > to record several communication sessions that take place at the same > time (i.e., in parallel), or the communication sessions need to happen > one after another (i.e., sequentially)? Yes. (to both) > Section 5.1, 1st paragraph: > That paragraph includes two MUSTs. However, the important advice in the > paragraph seems to be the last sentence. Do we need those two MUSTs or > specifying what the last sentence says would be enough? > > Section 5.2, 2nd paragraph: > The text talks about an SRS registering. Is it expected that SRSes > register in general? AFAIK we take no position on that. But its certainly possible that they could, to facilitate SRCs accessing them. > Section 6.1, 2nd paragraph: > s/a recorded stream is different than a CS stream/a recorded stream > can be different than a CS stream/ I guess you must understand this differently than I do. As I conceive it, this statement is true as written. Perhaps it could be changed as: s/different/distinct/ > Section 6.2 > What happens if the server becomes "not ready" while the stream is > inactive (because the client set it as inactive before)? The sever will > not be able to set the stream as inactive because it already is > inactive. Then, the client will not know about the server not being > ready and, consequently, will not look for alternative servers, which > would be ready. I don't understand your point. You are concerned with the SRS crashing - no longer able to handle sip signaling? And you are worried about an inability to detect a crashed server while not recording anything? How is this different from any sip call on hold? If the stream is inactive, then there will still be a need to exchange RTCP from time to time, and if that fails it would be a hint. If that isn't sufficient, the SRC and/or the SRS can exchange some signaling from time to time just to test the otherwise idle connection. Session Timer can be used to drive this, though I usually state that UAs don't need Session Timer because they can do signaling whenever they wish. In any case this is basic UA behavior - nothing that needs to be specified as special for siprec. > Section 8.1. > When the draft is ready, remember that the definition of new media types > need to be reviewed by ietf-types@ietf.org. > > Section 8.2 > Fix this sentence: > The metadata snapshot request is > contained the content with the disposition type "recording-session". > > Section 10.2.2 > OLD: > When the SRC receives the a=recordpref SDP in an SDP offer or answer, > the SRC MAY choose to honor such request to record the request based > on local policy on the SRC. > > NEW: > When the SRC receives the a=recordpref SDP in an SDP offer or answer, > the SRC chooses to honor such request to record based on local > policy on the SRC. > > Cheers, > > Gonzalo > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Tue Feb 28 09:14:21 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ED221F84F1 for ; Tue, 28 Feb 2012 09:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8GXrd8ecwF3 for ; Tue, 28 Feb 2012 09:14:20 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id AF7F821F86FA for ; Tue, 28 Feb 2012 09:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=9151; q=dns/txt; s=iport; t=1330449259; x=1331658859; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=hDHzkWbupTQCAx3Q/8q504L9cmgnImFCfJAOFeNKOSA=; b=Et2mhUrFuKEdhFhux47MyazPz80Pf6GKsHU41r7BEer7awnuulMzMEm9 BbexaHSDikQ6Lyl0Myi2JbaBnAn2OUVVXde9T6TvjSVdD29qrDjHhr5xt 4UDzYxjim5zzpdfVOAAm355wKdXP0iYbkTiVMisTm/bD2r7Ah0X3i0c88 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAL4KTU9Io8UY/2dsb2JhbAA9BrRrgXcBAQEDAQEBAQ8BHQouBhcEAgEIEQQBAQEKBhMEAQYBJh8JCAEBBAsICBMHh2EFC6B5AZcvig2CbgUBCggLAgYIAkAVhRgDCgEBAwEFBAEBAQEDAQEDAgMDBQEBAQQIAQYEAgQBBAkLAYJJYwSITZgOh1w X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="6581975" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 28 Feb 2012 17:14:17 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1SHEHo6018998 for ; Tue, 28 Feb 2012 17:14:17 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 22:44:16 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AFFx Aa+T B1S+ Dudg EAgX EIWL FX6v F51e Guzu G2PI IFv/ JIhP JWpp KYB6 LLwP MLJ5; 1; cwBpAHAAcgBlAGMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {6E5C9269-A3D9-45E6-94F5-7449AC3EBEAB}; cgBtAG8AaABhAG4AcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 28 Feb 2012 17:14:03 GMT; UgBFADoAIABbAHMAaQBwAHIAZQBjAF0AIABIAG8AdwAgAHQAbwAgAHMAcABlAGMAaQBmAHkAIABpAG4AIABtAGUAdABhAGQAYQB0AGEAIAB0AGgAYQB0ACAAYQAgAHAAYQByAHQAaQBjAGkAcABhAG4AdABzACAAcwB0AHIAZQBhAG0AIABpAHMAIABiAGUAaQBuAGcAIAByAGUAYwBvAHIAZABlAGQAIABpAG4AIABtAHUAbAB0AGkAcABsAGUAIABtACAAbABpAG4AZQAgAHMAdAByAGUAYQBtAHMA MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {6E5C9269-A3D9-45E6-94F5-7449AC3EBEAB} Content-class: urn:content-classes:message Date: Tue, 28 Feb 2012 22:44:02 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD09A2FC02@XMB-BGL-417.cisco.com> In-Reply-To: <4F4CD91F.9090801@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams Thread-Index: Acz2HnbUuPSGkmK3S3yWZqKJo/oupwAHSVdA References: , <96B3D51234119144AE22BA9E1E3E0F81192A44EF95@EMV03-UKBR.domain1.systemhost.net>, <387F9047F55E8C42850AD6B3A7A03C6C0E051086@inba-mail01.sonusnet.com> <4F4CD91F.9090801@alum.mit.edu> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 28 Feb 2012 17:14:16.0722 (UTC) FILETIME=[66A14F20:01CCF63C] Subject: Re: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 17:14:21 -0000 Hi Paul, Please see inline > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Tuesday, February 28, 2012 7:10 PM > To: siprec@ietf.org > Subject: Re: [siprec] How to specify in metadata that a participants > stream is being recorded in multiple m line streams >=20 > On 2/28/12 8:14 AM, john.2.stafford@bt.com wrote: > > Partha > > After registration we have two RS streams from the turret, but > becuase > > there are is no call on iether handset, the streams are sending > silence. > > When the call is made on handset 1, then the RS stream associated > with > > that handset records a mix of both the participants on the call. > > When the 2nd handset is barged into the call, the handset 1 stream > > records a mix of all three oparticipants. > > BUT also RS stream assocaiated with the 2nd handset also records a > mix > > of all three oparticipants. > > So after barge the two streams of the persistent RS are both > recording > > the same mix of the 3 participants. > > So each participants stream is being recorded in two streams of the > same RS. > > Rgds >=20 > So you are sending mixed media for the 3-party call twice? > Why would you do that? Is it for redundance? Or just that you are > incapable of *not* doing so? I will let John give his views. But I have seen use-cases (especially with banks call centres) where they mandate=20 Redundant recording of a same CS to at least two recorders (sometimes more) located at different geo-graphical locations. I also heard this(redundant recording at different locations) is regulatory for some countries. Ram >=20 > What do you want the recorder to do about it? Do you want the recorder > to record the call twice? Or do you want it to ignore one of the > streams? >=20 > Thanks, > Paul >=20 > > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 > > (0)1932 773504| E: john.2.stafford@bt.com > > |_www.bt.com/globalservices > > _ > > --------------------------------------------------------------------- > --- > > *From:* Ravindran, Parthasarathi [pravindran@sonusnet.com] > > *Sent:* 28 February 2012 11:59 > > *To:* Stafford,J,John,JRJ3X C; siprec@ietf.org > > *Cc:* TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > > Marc.Calahan@verint.com > > *Subject:* RE: [siprec] How to specify in metadata that a > participants > > stream is being recorded in multiple m line streams > > > > John, > > > > I need clarification whether the barge-call leads to the mixed stream > > towards recorder or un-mixed stream towards recorder. Your example > with > > multiple label indicates that it is un-mixed stream whereas the > initial > > call is mixed. Could you please clarify on this point for providing > the > > appropriate metadata. > > > > In case of un-mixed stream, it is possible to create multiple stream > > with single label and participants points to multiple stream. In case > of > > mixed stream, there is no concept of multiple label. > > > > Thanks > > > > Partha > > > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > > Behalf Of *john.2.stafford@bt.com > > *Sent:* Tuesday, February 28, 2012 1:40 PM > > *To:* siprec@ietf.org > > *Cc:* TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > > Marc.Calahan@verint.com > > *Subject:* [siprec] How to specify in metadata that a participants > > stream is being recorded in multtiple m line streams > > > > Guys, > > > > We have a somewhat unusual requirement for recording from our turret. > > > > The turret is a Recording Aware UA that supports multiple > simultaneous > > calls. > > > > The turret supports two handsets and many speaker channels. > > > > We are going to have a configuration where there will be multiple > > recording streams sent from the turret to the recorder, for > simplicity > > I'll describe when we have one record stream for handset 1 calls, and > > another record stream for handset 2 calls. > > > > Each record stream records a call as a single mixed stream. > > > > At registration, the turret sets up a single persistent RS containing > > two m lines in the INVITES sdp, > > > > the first m-line will be used for recording calls on handset 1, and > is > > labelled HS1_stream > > > > the 2nd m line will be used for recording calls on handset 2. and is > > labelled HS2_stream > > > > When we have a call on handset 1, the call is recorded in a single > mixed > > stream to the recorder > > > > so metadata describing the handset1 record stream would be: > > > > > > > > > > > id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > RamMohan R > > > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > > > > > > id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > Paul Kyzivat > > > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > 2010-12-16T23:41:07Z > > > > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > > > > Now the 2nd handset is barge conferenced into the same call ! > (sometime > > a trader gives 2nd handset to another trader to join in same call) > > > > You might expect the metadata describing the handset1 record stream > > would change to: > > > > > > > > > > > id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > RamMohan R > > > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > aBzzAkhhlbcSHAxxkcdj=3D=3D > > > > > > > id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > Paul Kyzivat > > > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > aBzzAkhhlbcSHAxxkcdj=3D=3D > > 2010-12-16T23:41:07Z > > > > > > > id=3D"zSfPoSvdSDCmU3A3TxACDeh=3D=3D" > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > John Stafford > > > > aBzzAkhhlbcSHAxxkcdj=3D=3D > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > 2010-12-16T27:12:07Z > > > > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > > > > However, this is not correct, as the conference is also getting > recorded > > in the handset 2 m line stream. > > > > How can we convey this information to the recorder ? > > > > I would like to be able to put multiple labels on the streams, but > the > > siprec schema does not allow it, ie: > > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > > > > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > > > > > > Is there any reason why the schema limits stream to having a single > label ? > > > > Rgds > > > > John Stafford | Solution Architect 1 | BT Global Services > > > > > > > > _______________________________________________ > > 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 Tue Feb 28 09:21:45 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ED321F8562 for ; Tue, 28 Feb 2012 09:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.077 X-Spam-Level: X-Spam-Status: No, score=-8.077 tagged_above=-999 required=5 tests=[AWL=0.922, BAYES_00=-2.599, J_BACKHAIR_14=1, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoaobSlxuNJX for ; Tue, 28 Feb 2012 09:21:44 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id E536021F855E for ; Tue, 28 Feb 2012 09:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=13197; q=dns/txt; s=iport; t=1330449703; x=1331659303; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=8izR/I65A0tuZGKcDobzZ/obE43y0m8+Jb26IzGBwek=; b=Wb1/fauu1vP+Agdn1Qqvg/Aa+zpy0DBdI2pS7k6MeMMEYFcCKLgzW4co DfB2jkPUaYXrO9HM8UdRLWoZ7SvVQRdYQWfR5yy+HHhN3oxuP0YcP8rdw u1DvQIIBoCC5cVeIOwYyiz+AVN+ebW5HGaqUyAuDVqOurRZC8cd3qOZ4E c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAAoMTU9Io8UY/2dsb2JhbAA9BrRrgXcBAQEDARIBFAkZHxEFCwIBCBEEAQELBhMEAQYBRQkIAgQLCAgTB4dhBaEGAZctig2CbgUBEgoBCAgCQBWFGAMKAQEDAQUEAQEBAQMBAQMCAwgBAQUIAQYGBQQJC4JKYwSIHDGYDodc X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="6582281" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 28 Feb 2012 17:21:41 +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 q1SHLfR3009030; Tue, 28 Feb 2012 17:21:41 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 22:51: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2012 22:51:39 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD09A2FC07@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD09A2FBFB@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams Thread-Index: AQHM9hB0g8XPqQaJKkuVv0j4mMsWkpZSRxftgABCKiCAAAAdUA== References: <35BCE99A477D6A4986FB2216D8CF2CFD09A2FBFB@XMB-BGL-417.cisco.com> From: "Ram Mohan R (rmohanr)" To: X-OriginalArrivalTime: 28 Feb 2012 17:21:40.0852 (UTC) FILETIME=[6F5A2B40:01CCF63D] Cc: siprec@ietf.org, Mark.Goodall@verint.com, Marc.Calahan@verint.com, TuanHoang.Nguyen@verint.com Subject: Re: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 17:21:45 -0000 Hello John, Let me see If I understand your use-case properly. IIUC this is what = you are talking about: 1) First you setup two persistent RS from handset 1 and handset 2 to a = recorder. 2)Call comes on the first handset ( say call from A to B). Handset 1 = (say of user B) records the call (sends mixed stream) to recorder. 3) Now a user (say C) with Handset 2 barges in. Handset records the = mixed conversation (of A, B and C) to recorder. CS1 User A<---->User B RS1 (mixed stream A+B) [Handset 1]<-------------------------> Recorder | | CS2=20 | User C RS2(mixed stream A+B+C) [Handset 2]<-------------------------> Recorder Am I right here ?. Ram =20 > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of john.2.stafford@bt.com > Sent: Tuesday, February 28, 2012 6:44 PM > To: pravindran@sonusnet.com; siprec@ietf.org > Cc: TuanHoang.Nguyen@verint.com; Marc.Calahan@verint.com; > Mark.Goodall@verint.com > Subject: Re: [siprec] How to specify in metadata that a participants > stream is being recorded in multiple m line streams >=20 > Partha >=20 > After registration we have two RS streams from the turret, but becuase > there are is no call on iether handset, the streams are sending > silence. >=20 > When the call is made on handset 1, then the RS stream associated with > that handset records a mix of both the participants on the=A0call. >=20 > When the 2nd handset is barged into the call, the handset 1 stream > records a mix of all three oparticipants. >=20 > BUT also RS stream assocaiated with the=A0 2nd handset also records a = mix > of all three oparticipants. >=20 > So after barge=A0the two streams of the persistent RS are both = recording > the same mix of the 3 participants. >=20 > So each participants stream is being recorded in two streams of the > same RS. >=20 >=20 > Rgds > John Stafford=A0|=A0Solution Architect 1=A0| BT Global Services | = Tel:+44 > (0)1932=A0773504=A0=A0 | E: john.2.stafford@bt.com=A0 | > www.bt.com/globalservices >=20 >=20 > ________________________________________ > From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > Sent: 28 February 2012 11:59 > To: Stafford,J,John,JRJ3X C; siprec@ietf.org > Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > Marc.Calahan@verint.com > Subject: RE: [siprec] How to specify in metadata that a participants > stream is being recorded in multiple m line streams John, >=20 > I need clarification whether the barge-call leads to the mixed stream > towards recorder or un-mixed stream towards recorder. Your example = with > multiple label indicates that it is un-mixed stream whereas the = initial > call is mixed. Could you please clarify on this point for providing = the > appropriate metadata. >=20 > In case of un-mixed stream, it is possible to create multiple stream > with single label and participants points to multiple stream. In case > of mixed stream, there is no concept of multiple label. >=20 > Thanks > Partha >=20 > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of john.2.stafford@bt.com > Sent: Tuesday, February 28, 2012 1:40 PM > To: siprec@ietf.org > Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > Marc.Calahan@verint.com > Subject: [siprec] How to specify in metadata that a participants = stream > is being recorded in multtiple m line streams >=20 > Guys, >=20 >=20 > We have a somewhat unusual requirement for recording from our turret. > The turret is a Recording Aware UA that supports multiple simultaneous > calls. >=20 > The turret supports two handsets and many speaker channels. >=20 > We are going to have a configuration where there will be multiple > recording streams sent from the turret to the recorder, =A0for = simplicity > I'll describe when we have one record stream for handset 1 calls, and > another record stream for handset 2 calls. > Each record stream records a call as a single mixed stream. >=20 > At registration, the turret sets up a single persistent = RS=A0containing > two=A0m lines in the INVITES sdp, the first m-line will be used for > recording calls on handset 1, and is labelled HS1_stream the 2nd m = line > will be used for recording calls on handset 2. and is labelled > HS2_stream >=20 >=20 >=20 > When we have a call on handset 1, the call is recorded in a single > mixed stream to the recorder so metadata describing the handset1 = record > stream would be: >=20 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 RamMohan R > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = i1Pz3to5hGk8fuXl+PbwCw=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 8zc6e0lYTlWIINA6GR+3ag=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Paul Kyzivat > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 8zc6e0lYTlWIINA6GR+3ag=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = i1Pz3to5hGk8fuXl+PbwCw=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 2010-12-16T23:41:07Z > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 >=20 >=20 > Now the 2nd handset is barge conferenced into the same call ! = (sometime > a trader gives 2nd handset to another trader to join in same call) >=20 >=20 > You might expect the metadata describing the handset1 record stream > would change to: >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 RamMohan R > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = i1Pz3to5hGk8fuXl+PbwCw=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 8zc6e0lYTlWIINA6GR+3ag=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = aBzzAkhhlbcSHAxxkcdj=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Paul Kyzivat > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 8zc6e0lYTlWIINA6GR+3ag=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = i1Pz3to5hGk8fuXl+PbwCw=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = aBzzAkhhlbcSHAxxkcdj=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 2010-12-16T23:41:07Z > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = id=3D"zSfPoSvdSDCmU3A3TxACDeh=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 John Stafford > = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = aBzzAkhhlbcSHAxxkcdj=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = i1Pz3to5hGk8fuXl+PbwCw=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 8zc6e0lYTlWIINA6GR+3ag=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 2010-12-16T27:12:07Z > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > However, this is not correct, as the conference is also getting > recorded in the handset 2 m line stream. >=20 > How can we convey this information to the recorder ? >=20 > I would like to be able to put multiple labels on the streams, but the > siprec schema does not allow it, =A0ie: > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > Is there any reason why the schema limits stream to having a single > label ? >=20 >=20 > Rgds > John Stafford=A0|=A0Solution Architect 1=A0| BT Global Services From andrew.hutton@siemens-enterprise.com Tue Feb 28 11:33:50 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8891021F8713 for ; Tue, 28 Feb 2012 11:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cqo9bPGsDiO4 for ; Tue, 28 Feb 2012 11:33:50 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id D336E21F870F for ; Tue, 28 Feb 2012 11:33:49 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id DA8A01EB8550; Tue, 28 Feb 2012 20:33:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 28 Feb 2012 20:33:45 +0100 From: "Hutton, Andrew" To: "siprec@ietf.org" , "brian.rosen@gmail.com" Date: Tue, 28 Feb 2012 20:33:41 +0100 Thread-Topic: IETF83 SIPREC - Deadlines etc. Thread-Index: Acz2T+BRjN4osCHNSOiRk4OnjpBKJA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3129455FC4C@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] IETF83 SIPREC - Deadlines etc. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2012 19:33:50 -0000 Hi All, As already mentioned a 2 hour SIPREC session has been scheduled for IETF83 = in Paris. The draft deadlines are as follows: March 5th, 17:00 Pacific: -00 drafts (Next Monday!!! - I am not aware of = any new draft proposals). March 12th, 17:00 Pacific: -01+ drafts (One week from this coming Monday!!!= ) A preliminary agenda needs to be published no later than March 14th.=20 Please notify the chairs if you would like an agenda slot no later than Mar= ch 7th, 2012. Regards Andy (SIPREC Co-Chair). From john.2.stafford@bt.com Wed Feb 29 00:23:42 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD62921E8077 for ; Wed, 29 Feb 2012 00:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDAj9RJvf-QR for ; Wed, 29 Feb 2012 00:23:41 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9B821E8057 for ; Wed, 29 Feb 2012 00:23:41 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 29 Feb 2012 08:23:39 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.172]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 29 Feb 2012 08:23:39 +0000 From: To: Date: Wed, 29 Feb 2012 08:23:39 +0000 Thread-Topic: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams Thread-Index: Acz2HnJo6zgTLH+8QSix7E3y3FDdHQADOoSSAAngFrQAGeqR3w== Message-ID: References: , <96B3D51234119144AE22BA9E1E3E0F81192A44EF95@EMV03-UKBR.domain1.systemhost.net> , <387F9047F55E8C42850AD6B3A7A03C6C0E051086@inba-mail01.sonusnet.com> , <4F4CD91F.9090801@alum.mit.edu>, , <67DAF295CD01EB44AE6EA8A51F6ABF0A408B441D6D@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <67DAF295CD01EB44AE6EA8A51F6ABF0A408B441D6D@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 08:23:42 -0000 Paul, yes you are correct, under this scanrio we end up recording the same call t= wice. It is a side effect of recording each handsets calls in a separate RS strea= m. I suppose we could inhibit recording the call in the 2nd handsets RS stream= . But then if handset 1 hangs up, the call will continue and we would have = to switch to recording it in the handset 2 stream, so a meatadata update wo= uld show that handset 1 participant has left the CS, and that all the strea= ms of the CS are now labelled as being recorded on the other RS stream. But thats an extra complication that the turret would have to deal with, an= d also in our architecture although the turret initiates the RS session and= controls SDP, it is our central server that is generating the metadata As this scenario will happen relatively infrequently we see the saving in r= ecorder storage does not justify the increased complexity needed to avoid i= t. Also it is possible that we could in the future want to generate two RS str= eams recording the same call for redundancy. We would expect the recorder to record both streams. Rgds John Stafford | Solution Architect 1 | BT Global Services=20 ________________________________________ From: siprec-bounces@ietf.org [siprec-bounces@ietf.org] On Behalf Of Paul K= yzivat [pkyzivat@alum.mit.edu] Sent: 28 February 2012 13:39 To: siprec@ietf.org Subject: Re: [siprec] How to specify in metadata that a participants stream= is being recorded in multiple m line streams On 2/28/12 8:14 AM, john.2.stafford@bt.com wrote: > Partha > After registration we have two RS streams from the turret, but becuase > there are is no call on iether handset, the streams are sending silence. > When the call is made on handset 1, then the RS stream associated with > that handset records a mix of both the participants on the call. > When the 2nd handset is barged into the call, the handset 1 stream > records a mix of all three oparticipants. > BUT also RS stream assocaiated with the 2nd handset also records a mix > of all three oparticipants. > So after barge the two streams of the persistent RS are both recording > the same mix of the 3 participants. > So each participants stream is being recorded in two streams of the same = RS. > Rgds So you are sending mixed media for the 3-party call twice? Why would you do that? Is it for redundance? Or just that you are incapable of *not* doing so? What do you want the recorder to do about it? Do you want the recorder to record the call twice? Or do you want it to ignore one of the streams? Thanks, Paul > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 > (0)1932 773504| E: john.2.stafford@bt.com > |_www.bt.com/globalservices > _ > ------------------------------------------------------------------------ > *From:* Ravindran, Parthasarathi [pravindran@sonusnet.com] > *Sent:* 28 February 2012 11:59 > *To:* Stafford,J,John,JRJ3X C; siprec@ietf.org > *Cc:* TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > Marc.Calahan@verint.com > *Subject:* RE: [siprec] How to specify in metadata that a participants > stream is being recorded in multiple m line streams > > John, > > I need clarification whether the barge-call leads to the mixed stream > towards recorder or un-mixed stream towards recorder. Your example with > multiple label indicates that it is un-mixed stream whereas the initial > call is mixed. Could you please clarify on this point for providing the > appropriate metadata. > > In case of un-mixed stream, it is possible to create multiple stream > with single label and participants points to multiple stream. In case of > mixed stream, there is no concept of multiple label. > > Thanks > > Partha > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *john.2.stafford@bt.com > *Sent:* Tuesday, February 28, 2012 1:40 PM > *To:* siprec@ietf.org > *Cc:* TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > Marc.Calahan@verint.com > *Subject:* [siprec] How to specify in metadata that a participants > stream is being recorded in multtiple m line streams > > Guys, > > We have a somewhat unusual requirement for recording from our turret. > > The turret is a Recording Aware UA that supports multiple simultaneous > calls. > > The turret supports two handsets and many speaker channels. > > We are going to have a configuration where there will be multiple > recording streams sent from the turret to the recorder, for simplicity > I'll describe when we have one record stream for handset 1 calls, and > another record stream for handset 2 calls. > > Each record stream records a call as a single mixed stream. > > At registration, the turret sets up a single persistent RS containing > two m lines in the INVITES sdp, > > the first m-line will be used for recording calls on handset 1, and is > labelled HS1_stream > > the 2nd m line will be used for recording calls on handset 2. and is > labelled HS2_stream > > When we have a call on handset 1, the call is recorded in a single mixed > stream to the recorder > > so metadata describing the handset1 record stream would be: > > > > > id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > RamMohan R > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > > id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > Paul Kyzivat > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 2010-12-16T23:41:07Z > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > Now the 2nd handset is barge conferenced into the same call ! (sometime > a trader gives 2nd handset to another trader to join in same call) > > You might expect the metadata describing the handset1 record stream > would change to: > > > > > id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > RamMohan R > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > aBzzAkhhlbcSHAxxkcdj=3D=3D > > > id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > Paul Kyzivat > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > aBzzAkhhlbcSHAxxkcdj=3D=3D > 2010-12-16T23:41:07Z > > > id=3D"zSfPoSvdSDCmU3A3TxACDeh=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > John Stafford > > aBzzAkhhlbcSHAxxkcdj=3D=3D > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > 2010-12-16T27:12:07Z > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > However, this is not correct, as the conference is also getting recorded > in the handset 2 m line stream. > > How can we convey this information to the recorder ? > > I would like to be able to put multiple labels on the streams, but the > siprec schema does not allow it, ie: > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > Is there any reason why the schema limits stream to having a single label= ? > > Rgds > > John Stafford | Solution Architect 1 | BT Global Services > > > > _______________________________________________ > siprec mailing 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.2.stafford@bt.com Wed Feb 29 01:15:33 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6D21F87BA for ; Wed, 29 Feb 2012 01:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_BACKHAIR_14=1, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8oEmo-vXMua for ; Wed, 29 Feb 2012 01:15:32 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6F61A21F87B9 for ; Wed, 29 Feb 2012 01:15:31 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 29 Feb 2012 09:15:30 +0000 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.172]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 29 Feb 2012 09:15:29 +0000 From: To: Date: Wed, 29 Feb 2012 09:15:29 +0000 Thread-Topic: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams Thread-Index: AQHM9hB0g8XPqQaJKkuVv0j4mMsWkpZSRxftgABCKiCAAAAdUIABAXE3 Message-ID: References: <35BCE99A477D6A4986FB2216D8CF2CFD09A2FBFB@XMB-BGL-417.cisco.com>, <35BCE99A477D6A4986FB2216D8CF2CFD09A2FC07@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD09A2FC07@XMB-BGL-417.cisco.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: TuanHoang.Nguyen@verint.com, Mark.Goodall@verint.com, Marc.Calahan@verint.com Subject: Re: [siprec] How to specify in metadata that a participants stream is being recorded in multiple m line streams X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 09:15:34 -0000 Ram At registration we set up ONE persistent RS but it has 2 m lines. (handset = 1 and handset 2 are on the same physical device.) After the barge there is still only one CS, ie just one comference call. Al= so both handset record streams are A+B+C CS1 User A<---->User B RS1 m line a=3Dlabel:hs1 (mixed stream A+B+C) [Handset 1]<-------------------------> Recorder | | | User C RS1 m line a=3Dlabel:hs2 (mixed stream = A+B+C) [Handset 2]<-------------------------> Recorder You might wonder why we are setting up just a single persistent RS, as if w= e had two RS's the multiple label problem in the metadata wouldn't occur. Its because although the example we are discussing involves only two stream= s, our turret device actually handles up to 26 separate simultaneous calls,= and could in theory record each of those calls separately. By having all t= he streams setup in a single RS reduces the handling overhead for both us = and the voice recorder. Rgds John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932= 773504 | E: john.2.stafford@bt.com | www.bt.com/globalservices ________________________________________ From: Ram Mohan R (rmohanr) [rmohanr@cisco.com] Sent: 28 February 2012 17:21 To: Stafford,J,John,JRJ3X C Cc: siprec@ietf.org; TuanHoang.Nguyen@verint.com; Marc.Calahan@verint.com; = Mark.Goodall@verint.com Subject: RE: [siprec] How to specify in metadata that a participants stream= is being recorded in multiple m line streams Hello John, Let me see If I understand your use-case properly. IIUC this is what you a= re talking about: 1) First you setup two persistent RS from handset 1 and handset 2 to a reco= rder. 2)Call comes on the first handset ( say call from A to B). Handset 1 (say = of user B) records the call (sends mixed stream) to recorder. 3) Now a user (say C) with Handset 2 barges in. Handset records the mixed c= onversation (of A, B and C) to recorder. CS1 User A<---->User B RS1 (mixed stream A+B) [Handset 1]<-------------------------> Recorder | | CS2 | User C RS2(mixed stream A+B+C) [Handset 2]<-------------------------> Recorder Am I right here ?. Ram > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of john.2.stafford@bt.com > Sent: Tuesday, February 28, 2012 6:44 PM > To: pravindran@sonusnet.com; siprec@ietf.org > Cc: TuanHoang.Nguyen@verint.com; Marc.Calahan@verint.com; > Mark.Goodall@verint.com > Subject: Re: [siprec] How to specify in metadata that a participants > stream is being recorded in multiple m line streams > > Partha > > After registration we have two RS streams from the turret, but becuase > there are is no call on iether handset, the streams are sending > silence. > > When the call is made on handset 1, then the RS stream associated with > that handset records a mix of both the participants on the call. > > When the 2nd handset is barged into the call, the handset 1 stream > records a mix of all three oparticipants. > > BUT also RS stream assocaiated with the 2nd handset also records a mix > of all three oparticipants. > > So after barge the two streams of the persistent RS are both recording > the same mix of the 3 participants. > > So each participants stream is being recorded in two streams of the > same RS. > > > Rgds > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 > (0)1932 773504 | E: john.2.stafford@bt.com | > www.bt.com/globalservices > > > ________________________________________ > From: Ravindran, Parthasarathi [pravindran@sonusnet.com] > Sent: 28 February 2012 11:59 > To: Stafford,J,John,JRJ3X C; siprec@ietf.org > Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > Marc.Calahan@verint.com > Subject: RE: [siprec] How to specify in metadata that a participants > stream is being recorded in multiple m line streams John, > > I need clarification whether the barge-call leads to the mixed stream > towards recorder or un-mixed stream towards recorder. Your example with > multiple label indicates that it is un-mixed stream whereas the initial > call is mixed. Could you please clarify on this point for providing the > appropriate metadata. > > In case of un-mixed stream, it is possible to create multiple stream > with single label and participants points to multiple stream. In case > of mixed stream, there is no concept of multiple label. > > Thanks > Partha > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of john.2.stafford@bt.com > Sent: Tuesday, February 28, 2012 1:40 PM > To: siprec@ietf.org > Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > Marc.Calahan@verint.com > Subject: [siprec] How to specify in metadata that a participants stream > is being recorded in multtiple m line streams > > Guys, > > > We have a somewhat unusual requirement for recording from our turret. > The turret is a Recording Aware UA that supports multiple simultaneous > calls. > > The turret supports two handsets and many speaker channels. > > We are going to have a configuration where there will be multiple > recording streams sent from the turret to the recorder, for simplicity > I'll describe when we have one record stream for handset 1 calls, and > another record stream for handset 2 calls. > Each record stream records a call as a single mixed stream. > > At registration, the turret sets up a single persistent RS containing > two m lines in the INVITES sdp, the first m-line will be used for > recording calls on handset 1, and is labelled HS1_stream the 2nd m line > will be used for recording calls on handset 2. and is labelled > HS2_stream > > > > When we have a call on handset 1, the call is recorded in a single > mixed stream to the recorder so metadata describing the handset1 record > stream would be: > > > > > > id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > RamMohan R > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > > > id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > Paul Kyzivat > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 2010-12-16T23:41:07Z > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > > > Now the 2nd handset is barge conferenced into the same call ! (sometime > a trader gives 2nd handset to another trader to join in same call) > > > You might expect the metadata describing the handset1 record stream > would change to: > > > > > id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > RamMohan R > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > aBzzAkhhlbcSHAxxkcdj=3D=3D > > > id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > Paul Kyzivat > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > aBzzAkhhlbcSHAxxkcdj=3D=3D > 2010-12-16T23:41:07Z > > > id=3D"zSfPoSvdSDCmU3A3TxACDeh=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > John Stafford > > aBzzAkhhlbcSHAxxkcdj=3D=3D > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > 2010-12-16T27:12:07Z > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > However, this is not correct, as the conference is also getting > recorded in the handset 2 m line stream. > > How can we convey this information to the recorder ? > > I would like to be able to put multiple labels on the streams, but the > siprec schema does not allow it, ie: > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > > Is there any reason why the schema limits stream to having a single > label ? > > > Rgds > John Stafford | Solution Architect 1 | BT Global Services= From andrew.hutton@siemens-enterprise.com Wed Feb 29 02:31:51 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C012621F8667 for ; Wed, 29 Feb 2012 02:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9GpudF5mhWY for ; Wed, 29 Feb 2012 02:31:51 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 51FA421F865F for ; Wed, 29 Feb 2012 02:31:50 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E27011EB8488; Wed, 29 Feb 2012 11:31:48 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 29 Feb 2012 11:31:48 +0100 From: "Hutton, Andrew" To: "john.2.stafford@bt.com" , "siprec@ietf.org" Date: Wed, 29 Feb 2012 11:31:47 +0100 Thread-Topic: How to specify in metadata - Mixed Streams. Thread-Index: AQHM8x7AXahTJKcSv0iMEMvfuWkzx5ZQ5wAQgAEOW6yAAbrUIA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3129455FE6B@MCHP058A.global-ad.net> References: , <96B3D51234119144AE22BA9E1E3E0F81192A44EF95@EMV03-UKBR.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TuanHoang.Nguyen@verint.com" , "Marc.Calahan@verint.com" , "Mark.Goodall@verint.com" Subject: [siprec] How to specify in metadata - Mixed Streams. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 10:31:51 -0000 Hi John, I changed the subject for a side discussion on metadata for mixed streams w= hich I wanted to clarify before moving on to your more complex scenario. Th= e metadata draft does not have examples of how mixed streams are represente= d but my interpretation is different to your example. I would like the view= s of our metadata experts on the list. You indicated that for the basic two party call using handset one the strea= m is mixed and the metadata looks like this. >=20 > > >=20 > id=3D"srfBElmCRp2QB23b7Mpk0w=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > RamMohan R > > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > >=20 > id=3D"zSfPoSvdSDCmU3A3TRDxAw=3D=3D" > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > Paul Kyzivat > > 8zc6e0lYTlWIINA6GR+3ag=3D=3D > i1Pz3to5hGk8fuXl+PbwCw=3D=3D > 2010-12-16T23:41:07Z > >=20 > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > session=3D"hVpd7YQgRW2nD22h7q60JQ=3D=3D"> > > > However my understanding is that since there is a single mixed stream that = the metadata would have only a single stream with the two participants send= ing and receiving on that single stream. =20 RamMohan R i1Pz3to5hGk8fuXl+PbwCw=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D =20 Paul Kyzivat i1Pz3to5hGk8fuXl+PbwCw=3D=3D i1Pz3to5hGk8fuXl+PbwCw=3D=3D 2010-12-16T23:41:07Z =20 Regards Andy (SIPREC Co-chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of john.2.stafford@bt.com > Sent: 28 February 2012 08:10 > To: siprec@ietf.org > Cc: TuanHoang.Nguyen@verint.com; Mark.Goodall@verint.com; > Marc.Calahan@verint.com > Subject: [siprec] How to specify in metadata that a participants stream > is being recorded in multtiple m line streams >=20 > Guys, >=20 >=20 > We have a somewhat unusual requirement for recording from our turret. > The turret is a Recording Aware UA that supports multiple simultaneous > calls. >=20 > The turret supports two handsets and many speaker channels. >=20 > We are going to have a configuration where there will be multiple > recording streams sent from the turret to the recorder, =A0for simplicity > I'll describe when we have one record stream for handset 1 calls, and > another record stream for handset 2 calls. > Each record stream records a call as a single mixed stream. >=20 > At registration, the turret sets up a single persistent RS=A0containing > two=A0m lines in the INVITES sdp, > the first m-line will be used for recording calls on handset 1, and is > labelled HS1_stream > the 2nd m line will be used for recording calls on handset 2. and is > labelled HS2_stream >=20 >=20 >=20 > When we have a call on handset 1, the call is recorded in a single > mixed stream to the recorder > so metadata describing the handset1 record stream would be: >=20 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 id=3D"srfBElmCRp2QB23b7Mpk0= w=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD22h= 7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 RamMohan R > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 i1Pz3to5hGk8fuXl+PbwC= w=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8zc6e0lYTlWIINA6GR+3a= g=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 id=3D"zSfPoSvdSDCmU3A3TR= DxAw=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Paul Kyzivat > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8zc6e0lYTlWIINA6GR= +3ag=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 i1Pz3to5hGk8fuXl+P= bwCw=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2010-12-= 16T23:41:07Z > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 >=20 >=20 > Now the 2nd handset is barge conferenced into the same call ! (sometime > a trader gives 2nd handset to another trader to join in same call) >=20 >=20 > You might expect the metadata describing the handset1 record stream > would change to: >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 id=3D"srfBElmCRp2QB23b7Mpk0= w=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD22h= 7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 RamMohan R > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 i1Pz3to5hGk8fuXl+PbwC= w=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8zc6e0lYTlWIINA6GR+3a= g=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 aBzzAkhhlbcSHAxxkc= dj=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 id=3D"zSfPoSvdSDCmU3A3TR= DxAw=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Paul Kyzivat > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8zc6e0lYTlWIINA6GR= +3ag=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 i1Pz3to5hGk8fuXl+P= bwCw=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 aBzzAkhhlbcSHAxxkc= dj=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2010-12-= 16T23:41:07Z > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 id=3D"zSfPoSvdSDCmU3A3Tx= ACDeh=3D=3D" > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 John Stafford > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 aBzzAkhhlbcSHAxxkc= dj=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 i1Pz3to5hGk8fuXl+P= bwCw=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 8zc6e0lYTlWIINA6GR= +3ag=3D=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2010-12-16T27:12:= 07Z > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 >=20 > However, this is not correct, as the conference is also getting > recorded in the handset 2 m line stream. >=20 > How can we convey this information to the recorder ? >=20 > I would like to be able to put multiple labels on the streams, but the > siprec schema does not allow it, =A0ie: > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 session=3D"hVpd7YQgRW2nD= 22h7q60JQ=3D=3D"> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > Is there any reason why the schema limits stream to having a single > label ? >=20 >=20 > Rgds > John Stafford=A0|=A0Solution Architect 1=A0| BT Global Services From rmohanr@cisco.com Wed Feb 29 03:01:43 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EC121F861F for ; Wed, 29 Feb 2012 03:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.969 X-Spam-Level: X-Spam-Status: No, score=-8.969 tagged_above=-999 required=5 tests=[AWL=1.630, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gvpiiu+9yiM for ; Wed, 29 Feb 2012 03:01:40 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id ACCC821F85A5 for ; Wed, 29 Feb 2012 03:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=15758; q=dns/txt; s=iport; t=1330513300; x=1331722900; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CV2P/78RtmWf5gCKNFw4twUZAnogB6PxDzOMT+vLMVw=; b=B06RQbkMADOZcU7vuTBpfp35brHWX0Q5m7Ic8WmMyJY6ulgLkzXoXJ9M 7tzUFsBG7Reen5oz+4yfVHDxwRSPd2lPAvwiQG6LJYtIVgos+p7CPeD5T /dXlKmfqliLw5bNM6i1i97R7pBZrEIPwyY0h7gHKkFoHcvHw7rOc/TvC7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIsETk+rRDoJ/2dsb2JhbAA9BrNvgQeBdwEBAQQBAQEPAR04AwMLDAQCAQgRBAEBCwYXAQYBJh8JCAIEAQoICBMHh2UBC6BkAZcsBIoMgnQSCwIOAkAVhU4BGAIEARgBgkljBIgcMZ9r X-IronPort-AV: E=Sophos;i="4.73,501,1325462400"; d="scan'208";a="33203391" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 29 Feb 2012 11:01:40 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1TB1WgR027296; Wed, 29 Feb 2012 11:01: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); Wed, 29 Feb 2012 16:31:38 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 16:31:35 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD09A2FF1D@XMB-BGL-417.cisco.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E3129455FE6B@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] How to specify in metadata - Mixed Streams. Thread-Index: AQHM8x7AXahTJKcSv0iMEMvfuWkzx5ZQ5wAQgAEOW6yAAbrUIIAACyFA References: , <96B3D51234119144AE22BA9E1E3E0F81192A44EF95@EMV03-UKBR.domain1.systemhost.net> <101C6067BEC68246B0C3F6843BCCC1E3129455FE6B@MCHP058A.global-ad.net> From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , , X-OriginalArrivalTime: 29 Feb 2012 11:01:38.0578 (UTC) FILETIME=[828D0720:01CCF6D1] Cc: TuanHoang.Nguyen@verint.com, Mark.Goodall@verint.com, Marc.Calahan@verint.com Subject: Re: [siprec] How to specify in metadata - Mixed Streams. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 11:01:44 -0000 Andy, Thanks for sending the correct metadata. Yes you are right. In case of mixed stream there will be single stream = and multiple participants have pointer ( or ) to it. IIUC John has an additional requirement too- In this use-case there are two copies of the same stream ( represented = by two m-lines in SDP) and forked to recorder. The question is: Should we just treat this as two different streams ( with two different = IDs) and have all the participant point ( or ) to both of = them ? OR Should we have one element and have two