From andrew.hutton@siemens-enterprise.com Mon Oct 1 05:49:29 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 0287D11E8124 for ; Mon, 1 Oct 2012 05:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYYJMOzXRIck for ; Mon, 1 Oct 2012 05:49:28 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9E91B11E8122 for ; Mon, 1 Oct 2012 05:49:27 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 354E823F0472; Mon, 1 Oct 2012 14:49:26 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.209]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 14:49:25 +0200 From: "Hutton, Andrew" To: "Jain, Rajnish" , "siprec@ietf.org" Thread-Topic: Comments on draft-ietf-siprec-protocol-06 Thread-Index: Ac2c5du5ZV1cJo+ySHq3n5ELyh8mhAC2bzqQ Date: Mon, 1 Oct 2012 12:49:25 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net> References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 12:49:29 -0000 Hi Raj, See below. Regards Andy (SIPREC Co-Chair) > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Jain, Rajnish > Sent: 27 September 2012 20:24 > To: siprec@ietf.org > Subject: [siprec] Comments on draft-ietf-siprec-protocol-06 >=20 > Pls. find below some of my questions and comments on the draft-ietf- > siprec-protocol-06 document (I apologize if these have been addressed > earlier; pls. point me to mailing list discussions if these have been > already been addressed). >=20 > Carrying Recording Metadata through RE-INVITE or UPDATE, Section 5.2: > --------------------------------------------------------------------- >=20 We had a lot of discussion in the working group regarding the mechanism for= transporting meta-data and I believe had strong consensus to go with the c= urrent model using INVITE/RE-INVITE/UPDATE and the use of UPDATE to request= a snapshot. The reasons for this was at least partly due to the fact that = the SDP in the RS forms part of the metadata and there has to be direct lin= kage between the RS SDP and metadata so conveying it within the same reques= t and dialog was logical and simplifies the solution. Unless we have discovered that the mechanism currently specified is broken = then I don't think we need to restart the debate on this issue. > The SIPREC protocol draft section 5.2 suggests the use of INVITE, RE- > INVITE or UPDATE for conveying metadata from the SRC to the SRS. This > may have been discussed in SIPREC WG earlier, but the choice of these > methods for delivering metadata seems counterintuitive. This choice > certainly misses some use cases. >=20 > IMHO, the metadata information flow seems to better fit a > SUBSCRIBE/NOTIFY mechanism. The protocol should allow for decoupling of > RS session management (such as adding and removing media streams) from > metadata event communication. These two protocol communications are > somewhat independent. For example, the RS session management will tend > to be real-time with SDP changes back-and-forth to avoid clipping of > media. The metadata events are less real-time demanding because they > can be correlated with the recorded media as long as the timestamps > between the two flows are synchronized. For these reasons, the metadata > generation/consumption logic may exist in different processing units in > the SRC/SRC as compared to the RS session management and RTP media > handling. This is one of the reasons why the SIPREC protocol allows for > a non-SIP mechanism delivery of metadata even though it is out of scope > of SIPREC (section 4). >=20 > The CS/RS lifecycle diagrams in section 4 in RFC 6341 highlight some of > these requirements. In particular, use case 4 in RFC 6341 describes a > scenario where the RS exists longer than a CS. As a practical > implementation of this use case, the SRC sends a metadata event to the > SRS indicating a user logon (note that this means that metadata events > span a user logon lifespan and not just the CS lifespan) when the user > initially logs on but hasn't participated in a CS at this point. > Depending on the capacity available at the SRS, the logon event > triggers an INVITE from the SRS to the SRS to establish the RS. The > logon event is delivered through a subscription that the SRS has > previously established with the SRC. Such a message flow prevents > clipping of the initial media samples from being recorded, which is the > case when CS and RS are racing to establish at the same time. There are > also use cases around push-to-talk where metadata events are required > but turning RTP on and off thro > ugh SDP exchange (sendonly, inactive) is expensive and more prone to > media clipping. >=20 > In the SUBSCRIBE/NOTIFY mechanism, the SRC will subscribe to the SRS > for the metadata events. The SRC will push metadata events to the SRS > as the CS undergoes state changes (initiation, teardown, hold/resume > etc.) or when the user state that is targeted for recording undergoes > changes. The SUBSCRIBE/NOTIFY mechanism also allows for built in > bootstrapping of the SRS state where the SRS recovers after a failure > (the first NOTIFY to the SUBSCRIBE will carry the current snapshot of > the recording metadata; there may also be historical CS information in > this NOTIFY). Sending an UPDATE for a 'media snapshot request' from SRS > to SRC (as shown in Figure 2) seems counterintuitive to the usage of > the UPDATE method (why and what is the SRS updating the SRC about the > RS for?). A SUBSCRIBE will always fetch the current state as per the > definition. >=20 >=20 > Indicating recording preference in SDP (a=3Drecord, a=3Drecordpref), > Section 5.3: > ----------------------------------------------------------------------- > ------ >=20 > The notion that a CS is being recorded or not seems more like a SIP- > level construct (or maybe a metadata-level construct) as opposed to an > SDP-level context.=20 Since the indication/preference is on a media line basis then I don't know = where else we could put it. > Are these attributes really describing some > characteristic about the media being carried in the RS RTP (described > by SDP) or are they describing an RS characteristic itself? When an RS > carries multiple CSes, I'm assuming that the metadata will uniquely > identify each media stream in the RS (e.g. the SDP a=3Dlabel token will > also be present in the metadata in some form) and so such attributes > can be placed in the metadata. >=20 > In section 5.3, if the SRC chooses to ignore SRS' request to turn off > recording, how does the SRS learn about that and what should the SRS do > if it continues to receive media from the SRC? These indications apply to the CS not the RS so they don't impact the SRS a= t all. >=20 >=20 > Section 6.1, '+sip.rec' and 'siprec' tags': > ------------------------------------------- >=20 > Section 6.1 states: >=20 > In addition, when an SRC sends a REGISTER request > to a registrar, the SRC MUST include the '+sip.src' feature tag to > indicate the that it is a SRC. >=20 > The purpose of the Contact URI tags '+sip.src' and '+sip.srs' is not > very clear from the description. They don't seem to be helping with the > negotiating aspect of the recording feature and the SRS /SRS > communication may not be through a proxy server (which has access to a > registrar's location service). They are there to help ensure that things run smoothly and that it is clear= who is taking which role. An SRS for example will use this to make sure th= at an INVITE is from an SRC. The use in REGISTER is again only to help iden= tify SRC's and will not be useful in some scenarios. > The notion of an SRC registering using > the REGISTER method is also not very clear (e.g. when the SRC is an > SBC, does it register as a UA with a registrar)? As usual SBC behavior is not well defined and SIPREC is no different here a= n SBC could I guess add the SRC indication to a REGISTER requests it forwar= ds if it is going to act as a SRC on behalf of a UA but I don't think we ne= ed to say anything on that. >=20 > These Contact URI tags seem to overlap with the 'siprec' tag. Why does > an SRC or SRS must ensure that either one of these Contact URI tags > (depending on the direction of the INVITE) AND the 'siprec' tag must be > present in the RS INVITE? The "siprec" option tag is carried in the Require header so that if the INV= ITE finds its way to a non SIPREC aware UA then the INVITE will be rejected= . >=20 >=20 > Section 7.1, Scope of a=3Dlabel: > ------------------------------ >=20 > I think the following statement in section 7.1 could be clarified (I > think this means that the label can be reused after the previous stream > with that label is no longer active): >=20 > The scope of the label name only applies to the same SIP message as > the > SDP, meaning that the label name can be reused by another media > stream within the same recording session. >=20 >=20 I agree this could be made a bit clearer it really means that the scope of = the label is limited to the SDP and SIPREC Metadata conveyed in the bodies = of a single SIP Request/Response. > Regards, >=20 > Raj Jain >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Mon Oct 1 07:24: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 2541E11E8129 for ; Mon, 1 Oct 2012 07:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fv8bG8zZBi5I for ; Mon, 1 Oct 2012 07:24:39 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4A11E8121 for ; Mon, 1 Oct 2012 07:24:37 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 0BEAD23F045C; Mon, 1 Oct 2012 16:24:37 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.209]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 16:24:36 +0200 From: "Hutton, Andrew" To: Henry Lum , "siprec@ietf.org" Thread-Topic: Proposed text for security section in siprec-protocol Thread-Index: Ac2c+OuMs03xBiEJRUa4mlIqbj1ehAC5EJEA Date: Mon, 1 Oct 2012 14:24:36 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012E1D82@MCHP04MSX.global-ad.net> References: <059AF07365DC474393A19A3AF187DF74091A6FAA@NAHALD.us.int.genesyslab.com> In-Reply-To: <059AF07365DC474393A19A3AF187DF74091A6FAA@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 14:24:41 -0000 Hi Henry, See below. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Henry Lum > Sent: 27 September 2012 22:42 > To: siprec@ietf.org > Subject: [siprec] Proposed text for security section in siprec-protocol >=20 > It's my first attempt to begin writing the security section for the > protocol draft. I try to capture all the important points raised in the > previous meeting to ensure we have enough coverage for the security > concerns. >=20 > Regards, > Henry >=20 >=20 > 12. Security Considerations >=20 > The recording session is fundamentally a standard SIP dialog > [RFC3261], therefore, the recording session can reuse any of the > existing SIP security mechanism available for securing the recorded > media as well as metadata. Also for securing the SIP Signalling. > The user cases and requirements document > [RFC6341] outlines the general security considerations, and the > following describe specific security recommendations. >=20 > The SRC and SRS MUST support SIPS and TLS as per RFC3261. Probably should refer to RFC 5630 here rather than 3261. =20 > The > Recording Session SHOULD be at least as secure as the Communication > Session, meaning using at least the same strength of cipher suite as > the CS if the CS is secured. For example, if the CS uses SIPS for > signalling and RTP/SAVP for media, then the RS does not downgrade > the > level of security in the RS to SIP or plain RTP since doing so will > mean an automatic security downgrade for the CS. In deployments > where the SRC and the SRS are in the same administrative domain and > the same physical switch that prevents outside user access, some SRC > may choose lower the level of security when establishing the > recording session. While physically securing the SRC and SRS may > prevent an outside attacker from accessing important call > recordings, > this still does not prevent from an inside attacker from accessing > the internal network to gain access to the call recordings. >=20 > 12.1. Authentication and Authorization >=20 > The recording session reuses the SIP mechanism to challenge requests > that is based on HTTP authentication. The mechanism relies on 401 > and 407 SIP responses as well as other SIP header fields for > carrying > challenges and credentials. >=20 Should we also say something here about the use of TLS Authentication inclu= ding Mutual TLS Authentication? > The SRS may have its own set of recording policies to authorize > recording requests from the SRC. The use of recording policies is > outside the scope of the Session Recording Protocol. >=20 > The SRC and SRS MUST support mutual authentication for establishing > the recording session. In deployments where the SRC and the SRS are > in the same administrative domain, the deployment may choose not to > authenticate each other or only to have SRC authenticate the SRS as > there is an inherent trust relation between the SRC and the SRS when > they are hosted in the same administrative domain. In deployments > where the SRS can be hosted on a different administrative domain, > then it is important to perform mutual authentication to ensure the > authenticity of both the SRC and the SRS before transmitting any > recorded media. The risk of not authenticating the SRS is that the > recording may be sent to a compromised SRS and that sensitive call > recording will be obtained by an attacker. On the other hand, the > risk of not authenticating the SRC is that an SRS will be willingly > accept any call recording from an unknown SRC and allow potential > forgery of call recordings. >=20 > 12.2. RTP handling >=20 > In many scenarios it will be critical that the media transported > between the SRC and SRS to be protected. Media encryption is an > important element in the overall SIPREC solution; therefore SRC and > SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. RTP/ > SAVP and RTP/SAVPF provide media encryption, integrity protection, > replay protection, and a limited form of source authentication. > They > do not contain or require a specific keying mechanism. >=20 > When RTP/SAVP or RTP/SAVPF is used, RS can choose to use the same or > different security keys than the ones used in the CS. Some SRCs are > designed to simply replicate RTP packets from the CS media stream to > the SRS, and the SRC will be reusing the same keys as the CS. In > this case, the SRC MUST secure the SDES in the RS with at least the > same level of security as the CS. The risk of lowering the level of > security in the RS for this case is that it will effectively become > a > downgrade attack on the CS since the same key is used for both CS > and > RS. When referring to "SDES" can you change to "Source Description (SDES)" and = give the reference to RFC3550. Just to avoid any confusion. >=20 > For SRCs that perform transcoding or mixing of media before sending > to the SRS, the SRC MUST negotiate a different security key than the > one being used in the CS, to ensure that the security in the CS is > not compromised by the SRC when reusing the same security key. >=20 > 12.3. Metadata >=20 > Metadata contains sensitive information such as the address of > record > of the participants and other extension data placed by the SRC. It > is essential to protect the content of the metadata in the RS. > Since > metadata is a content type transmitted in SIP signalling, metadata > can be protected by SIPS/TLS. If the RS is not secured for any > reason, the metadata content can also be secured by using S/MIME. Can we make a firm recommendation to secure using TLS and not refer to S/MI= ME at all? >=20 > 12.4. Storage and playback >=20 > While storage and playback of the call recording is beyond the scope > of this document, it is worthwhile to mention here that it is also > important for the recording storage and playback to provide a level > of security that is comparable to the communication session. It > would defeat the purpose of securing both the communication session > and the recording session mentioned in the previous sections if the > recording can be easily played back with a simple unsecured HTTP > interface without any form of authentication or authorization. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@genesyslab.com Mon Oct 1 08:20: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 D41F21F0CCD for ; Mon, 1 Oct 2012 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjysMroDcqx3 for ; Mon, 1 Oct 2012 08:20:08 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id BDDD81F0C7E for ; Mon, 1 Oct 2012 08:20:07 -0700 (PDT) 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 q91FK41w008704; Mon, 1 Oct 2012 08:20:07 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Oct 2012 08:20:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Oct 2012 08:19:59 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7409209225@NAHALD.us.int.genesyslab.com> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] Comments on draft-ietf-siprec-protocol-06 Thread-Index: Ac2c5du5ZV1cJo+ySHq3n5ELyh8mhAC2bzqQAAlHiHA= References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com> <9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net> From: "Henry Lum" To: "Hutton, Andrew" , "Jain, Rajnish" , X-OriginalArrivalTime: 01 Oct 2012 15:20:00.0455 (UTC) FILETIME=[3933FD70:01CD9FE8] Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 15:20:09 -0000 Hi Raj,=20 Thanks for the review, please see inline. Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > Hutton, Andrew > Sent: October-01-12 8:49 AM > To: Jain, Rajnish; siprec@ietf.org > Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 >=20 > Hi Raj, >=20 > See below. >=20 > Regards > Andy (SIPREC Co-Chair) >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Jain, Rajnish > > Sent: 27 September 2012 20:24 > > To: siprec@ietf.org > > Subject: [siprec] Comments on draft-ietf-siprec-protocol-06 > > > > Pls. find below some of my questions and comments on the draft-ietf- > > siprec-protocol-06 document (I apologize if these have been addressed > > earlier; pls. point me to mailing list discussions if these have been > > already been addressed). > > > > Carrying Recording Metadata through RE-INVITE or UPDATE, Section 5.2: > > --------------------------------------------------------------------- > > >=20 > We had a lot of discussion in the working group regarding the mechanism for > transporting meta-data and I believe had strong consensus to go with the > current model using INVITE/RE-INVITE/UPDATE and the use of UPDATE to request a > snapshot. The reasons for this was at least partly due to the fact that the > SDP in the RS forms part of the metadata and there has to be direct linkage > between the RS SDP and metadata so conveying it within the same request and > dialog was logical and simplifies the solution. >=20 > Unless we have discovered that the mechanism currently specified is broken > then I don't think we need to restart the debate on this issue. >=20 >=20 > > The SIPREC protocol draft section 5.2 suggests the use of INVITE, RE- > > INVITE or UPDATE for conveying metadata from the SRC to the SRS. This > > may have been discussed in SIPREC WG earlier, but the choice of these > > methods for delivering metadata seems counterintuitive. This choice > > certainly misses some use cases. > > > > IMHO, the metadata information flow seems to better fit a > > SUBSCRIBE/NOTIFY mechanism. The protocol should allow for decoupling of > > RS session management (such as adding and removing media streams) from > > metadata event communication. These two protocol communications are > > somewhat independent. For example, the RS session management will tend > > to be real-time with SDP changes back-and-forth to avoid clipping of > > media. The metadata events are less real-time demanding because they > > can be correlated with the recorded media as long as the timestamps > > between the two flows are synchronized. For these reasons, the metadata > > generation/consumption logic may exist in different processing units in > > the SRC/SRC as compared to the RS session management and RTP media > > handling. This is one of the reasons why the SIPREC protocol allows for > > a non-SIP mechanism delivery of metadata even though it is out of scope > > of SIPREC (section 4). > > > > The CS/RS lifecycle diagrams in section 4 in RFC 6341 highlight some of > > these requirements. In particular, use case 4 in RFC 6341 describes a > > scenario where the RS exists longer than a CS. As a practical > > implementation of this use case, the SRC sends a metadata event to the > > SRS indicating a user logon (note that this means that metadata events > > span a user logon lifespan and not just the CS lifespan) when the user > > initially logs on but hasn't participated in a CS at this point. > > Depending on the capacity available at the SRS, the logon event > > triggers an INVITE from the SRS to the SRS to establish the RS. The > > logon event is delivered through a subscription that the SRS has > > previously established with the SRC. Such a message flow prevents > > clipping of the initial media samples from being recorded, which is the > > case when CS and RS are racing to establish at the same time. There are > > also use cases around push-to-talk where metadata events are required > > but turning RTP on and off thro > > ugh SDP exchange (sendonly, inactive) is expensive and more prone to > > media clipping. > > > > In the SUBSCRIBE/NOTIFY mechanism, the SRC will subscribe to the SRS > > for the metadata events. The SRC will push metadata events to the SRS > > as the CS undergoes state changes (initiation, teardown, hold/resume > > etc.) or when the user state that is targeted for recording undergoes > > changes. The SUBSCRIBE/NOTIFY mechanism also allows for built in > > bootstrapping of the SRS state where the SRS recovers after a failure > > (the first NOTIFY to the SUBSCRIBE will carry the current snapshot of > > the recording metadata; there may also be historical CS information in > > this NOTIFY). Sending an UPDATE for a 'media snapshot request' from SRS > > to SRC (as shown in Figure 2) seems counterintuitive to the usage of > > the UPDATE method (why and what is the SRS updating the SRC about the > > RS for?). A SUBSCRIBE will always fetch the current state as per the > > definition. > > > > > > Indicating recording preference in SDP (a=3Drecord, a=3Drecordpref), > > Section 5.3: > > ----------------------------------------------------------------------- > > ------ > > > > The notion that a CS is being recorded or not seems more like a SIP- > > level construct (or maybe a metadata-level construct) as opposed to an > > SDP-level context. >=20 > Since the indication/preference is on a media line basis then I don't know > where else we could put it. >=20 [Henry] Yes, we want to indicate whether you are being recorded for each media line (ie. audio only but not video) so SDP is the best place to indicate this. >=20 > > Are these attributes really describing some > > characteristic about the media being carried in the RS RTP (described > > by SDP) or are they describing an RS characteristic itself? When an RS > > carries multiple CSes, I'm assuming that the metadata will uniquely > > identify each media stream in the RS (e.g. the SDP a=3Dlabel token will > > also be present in the metadata in some form) and so such attributes > > can be placed in the metadata. > > > > In section 5.3, if the SRC chooses to ignore SRS' request to turn off > > recording, how does the SRS learn about that and what should the SRS do > > if it continues to receive media from the SRC? >=20 > These indications apply to the CS not the RS so they don't impact the SRS at > all. [Henry] Right, the SRS does not use these SDP attributes so they don't impact the SRS. If the SRS don't want to be recorded, then it can simply reject the RS or just terminate the RS. These attributes apply to a recording-aware participant in a CS. The participants set the recording preference and the participants will learn whether the participant is being recorded or not through the indication. The SRC must send indication to the participant so the participant will always get the up to date indication, and if the participant does not like being recorded or the call needs to be recorded and it's not, then it's up to the participant to abandon the call or take alternative action. >=20 >=20 > > > > > > Section 6.1, '+sip.rec' and 'siprec' tags': > > ------------------------------------------- > > > > Section 6.1 states: > > > > In addition, when an SRC sends a REGISTER request > > to a registrar, the SRC MUST include the '+sip.src' feature tag to > > indicate the that it is a SRC. > > > > The purpose of the Contact URI tags '+sip.src' and '+sip.srs' is not > > very clear from the description. They don't seem to be helping with the > > negotiating aspect of the recording feature and the SRS /SRS > > communication may not be through a proxy server (which has access to a > > registrar's location service). >=20 > They are there to help ensure that things run smoothly and that it is clear > who is taking which role. An SRS for example will use this to make sure that > an INVITE is from an SRC. The use in REGISTER is again only to help identify > SRC's and will not be useful in some scenarios. >=20 >=20 > > The notion of an SRC registering using > > the REGISTER method is also not very clear (e.g. when the SRC is an > > SBC, does it register as a UA with a registrar)? >=20 > As usual SBC behavior is not well defined and SIPREC is no different here an > SBC could I guess add the SRC indication to a REGISTER requests it forwards if > it is going to act as a SRC on behalf of a UA but I don't think we need to say > anything on that. >=20 > > > > These Contact URI tags seem to overlap with the 'siprec' tag. Why does > > an SRC or SRS must ensure that either one of these Contact URI tags > > (depending on the direction of the INVITE) AND the 'siprec' tag must be > > present in the RS INVITE? >=20 > The "siprec" option tag is carried in the Require header so that if the INVITE > finds its way to a non SIPREC aware UA then the INVITE will be rejected. [Henry] The +sip.src tag can also appear in the CS to indicate to the participants that an SRC is in the call. >=20 >=20 > > > > > > Section 7.1, Scope of a=3Dlabel: > > ------------------------------ > > > > I think the following statement in section 7.1 could be clarified (I > > think this means that the label can be reused after the previous stream > > with that label is no longer active): > > > > The scope of the label name only applies to the same SIP message as > > the > > SDP, meaning that the label name can be reused by another media > > stream within the same recording session. > > > > >=20 > I agree this could be made a bit clearer it really means that the scope of the > label is limited to the SDP and SIPREC Metadata conveyed in the bodies of a > single SIP Request/Response. [Henry] Let's rewrite this as: The scope of the a=3Dlabel attribute only applies to the SDP and = Metadata conveyed in the bodies of the SIP request or response that the label appeared in. >=20 >=20 >=20 > > Regards, > > > > Raj Jain > > > > > > _______________________________________________ > > siprec mailing 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 Oct 1 09:03: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 689821F0CCD for ; Mon, 1 Oct 2012 09:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvd3r45mVEsr for ; Mon, 1 Oct 2012 09:03:38 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 29BED1F0C7E for ; Mon, 1 Oct 2012 09:03:38 -0700 (PDT) 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 q91G3ZLB012027; Mon, 1 Oct 2012 09:03:37 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Oct 2012 09:03:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Oct 2012 09:03:32 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7409209271@NAHALD.us.int.genesyslab.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F374E29@STSNYEXMBX2.corp.root.ipc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed text for security section in siprec-protocol Thread-Index: Ac2c+OuMs03xBiEJRUa4mlIqbj1ehAAHf6WgALW+V7A= References: <059AF07365DC474393A19A3AF187DF74091A6FAA@NAHALD.us.int.genesyslab.com> <4C91F9B607136D48AE3411BDC594D2AE0F374E29@STSNYEXMBX2.corp.root.ipc.com> From: "Henry Lum" To: "Jain, Rajnish" , X-OriginalArrivalTime: 01 Oct 2012 16:03:33.0530 (UTC) FILETIME=[4EB797A0:01CD9FEE] Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 16:03:39 -0000 Thanks for the quick review. Please see inline. Henry > -----Original Message----- > From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com] > Sent: September-27-12 9:31 PM > To: Henry Lum; siprec@ietf.org > Subject: RE: Proposed text for security section in siprec-protocol >=20 > Hi Henry, >=20 > Pls. see a few comments in-line [rj]: >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > Henry Lum > Sent: Thursday, September 27, 2012 5:42 PM > To: siprec@ietf.org > Subject: [siprec] Proposed text for security section in siprec-protocol >=20 > It's my first attempt to begin writing the security section for the protocol > draft. I try to capture all the important points raised in the previous > meeting to ensure we have enough coverage for the security concerns. >=20 > Regards, > Henry >=20 >=20 > 12. Security Considerations >=20 > The recording session is fundamentally a standard SIP dialog > [RFC3261], therefore, the recording session can reuse any of the > existing SIP security mechanism available for securing the recorded > media as well as metadata. >=20 > [rj] The existing SIP security mechanisms will also allow secure RS SIP > signaling (such as over TLS or IPSec). > Substitute: ... available for securing _session signaling_, recorded media as > well as metadata. [Henry] Okay I will fix this. >=20 >=20 > The user cases and requirements document > [RFC6341] outlines the general security considerations, and the > following describe specific security recommendations. >=20 > [rj] _use cases_ >=20 > The SRC and SRS MUST support SIPS and TLS as per RFC3261. >=20 > [rj] RFC 3261 does not require TLS support in all SIP entities. Quote from RFC > 3261: [Henry] Let's change the wording to: The SRC and SRS MUST implement SIPS and TLS. >=20 > ------------ > 26.3.1 Requirements for Implementers of SIP >=20 > Proxy servers, redirect servers, and registrars MUST implement TLS, > and MUST support both mutual and one-way authentication. It is > strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also > be capable of acting as a TLS server. > ------------ >=20 > The Recording Session SHOULD be at least as secure as the Communication > Session, meaning using at least the same strength of cipher suite as > the CS if the CS is secured. For example, if the CS uses SIPS for > signalling and RTP/SAVP for media, then the RS does not downgrade the > level of security in the RS to SIP or plain RTP since doing so will > mean an automatic security downgrade for the CS. In deployments > where the SRC and the SRS are in the same administrative domain and > the same physical switch that prevents outside user access, some SRC > may choose lower the level of security when establishing the > recording session. While physically securing the SRC and SRS may > prevent an outside attacker from accessing important call recordings, > this still does not prevent from an inside attacker from accessing > the internal network to gain access to the call recordings. >=20 > 12.1. Authentication and Authorization >=20 > The recording session reuses the SIP mechanism to challenge requests > that is based on HTTP authentication. The mechanism relies on 401 > and 407 SIP responses as well as other SIP header fields for carrying > challenges and credentials. >=20 > The SRS may have its own set of recording policies to authorize > recording requests from the SRC. The use of recording policies is > outside the scope of the Session Recording Protocol. >=20 > The SRC and SRS MUST support mutual authentication for establishing > the recording session. In deployments where the SRC and the SRS are > in the same administrative domain, the deployment may choose not to > authenticate each other or only to have SRC authenticate the SRS as > there is an inherent trust relation between the SRC and the SRS when > they are hosted in the same administrative domain. In deployments > where the SRS can be hosted on a different administrative domain, > then it is important to perform mutual authentication to ensure the > authenticity of both the SRC and the SRS before transmitting any > recorded media. The risk of not authenticating the SRS is that the > recording may be sent to a compromised SRS and that sensitive call > recording will be obtained by an attacker. On the other hand, the > risk of not authenticating the SRC is that an SRS will be willingly > accept any call recording from an unknown SRC and allow potential > forgery of call recordings. >=20 > [rj] Since the paragraph above suggests that only server-side authentication > might be sufficient if SRC and SRS are in the same administrative domain, > shouldn't the first statement in the paragraph (a normative statement) loosen > the MUST strength. [Henry] I meant to say that the SRC and SRS must implement TLS mutual authentication, although not all deployments are required use them, so it's mandatory to implement and optional to use. >=20 > 12.2. RTP handling >=20 > In many scenarios it will be critical that the media transported > between the SRC and SRS to be protected. Media encryption is an > important element in the overall SIPREC solution; therefore SRC and > SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. RTP/ > SAVP and RTP/SAVPF provide media encryption, integrity protection, > replay protection, and a limited form of source authentication. They > do not contain or require a specific keying mechanism. >=20 > When RTP/SAVP or RTP/SAVPF is used, RS can choose to use the same or > different security keys than the ones used in the CS. Some SRCs are > designed to simply replicate RTP packets from the CS media stream to > the SRS, and the SRC will be reusing the same keys as the CS. In > this case, the SRC MUST secure the SDES in the RS with at least the > same level of security as the CS. The risk of lowering the level of > security in the RS for this case is that it will effectively become a > downgrade attack on the CS since the same key is used for both CS and > RS. >=20 > For SRCs that perform transcoding or mixing of media before sending > to the SRS, the SRC MUST negotiate a different security key than the > one being used in the CS, to ensure that the security in the CS is > not compromised by the SRC when reusing the same security key. >=20 > 12.3. Metadata >=20 > Metadata contains sensitive information such as the address of record > of the participants and other extension data placed by the SRC. It > is essential to protect the content of the metadata in the RS. Since > metadata is a content type transmitted in SIP signalling, metadata > can be protected by SIPS/TLS. If the RS is not secured for any > reason, the metadata content can also be secured by using S/MIME. >=20 > 12.4. Storage and playback >=20 > While storage and playback of the call recording is beyond the scope > of this document, it is worthwhile to mention here that it is also > important for the recording storage and playback to provide a level > of security that is comparable to the communication session. It > would defeat the purpose of securing both the communication session > and the recording session mentioned in the previous sections if the > recording can be easily played back with a simple unsecured HTTP > interface without any form of authentication or authorization. > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From Henry.Lum@genesyslab.com Mon Oct 1 09:21: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 9D53B21F89AD for ; Mon, 1 Oct 2012 09:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVzWjsYDwJN3 for ; Mon, 1 Oct 2012 09:21:55 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id 7735121F87C4 for ; Mon, 1 Oct 2012 09:21:55 -0700 (PDT) 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 q91GLpFm013348; Mon, 1 Oct 2012 09:21:55 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Oct 2012 09:21:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Oct 2012 09:21:49 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF7409209293@NAHALD.us.int.genesyslab.com> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF012E1D82@MCHP04MSX.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed text for security section in siprec-protocol Thread-Index: Ac2c+OuMs03xBiEJRUa4mlIqbj1ehAC5EJEAAARLKvA= References: <059AF07365DC474393A19A3AF187DF74091A6FAA@NAHALD.us.int.genesyslab.com> <9F33F40F6F2CD847824537F3C4E37DDF012E1D82@MCHP04MSX.global-ad.net> From: "Henry Lum" To: "Hutton, Andrew" , X-OriginalArrivalTime: 01 Oct 2012 16:21:50.0868 (UTC) FILETIME=[DCC81540:01CD9FF0] Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 16:21:57 -0000 Please see inline. > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: October-01-12 10:25 AM > To: Henry Lum; siprec@ietf.org > Subject: RE: Proposed text for security section in siprec-protocol >=20 > Hi Henry, >=20 > See below. >=20 > Regards > Andy >=20 >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf Of Henry Lum > > Sent: 27 September 2012 22:42 > > To: siprec@ietf.org > > Subject: [siprec] Proposed text for security section in siprec-protocol > > > > It's my first attempt to begin writing the security section for the > > protocol draft. I try to capture all the important points raised in the > > previous meeting to ensure we have enough coverage for the security > > concerns. > > > > Regards, > > Henry > > > > > > 12. Security Considerations > > > > The recording session is fundamentally a standard SIP dialog > > [RFC3261], therefore, the recording session can reuse any of the > > existing SIP security mechanism available for securing the recorded > > media as well as metadata. >=20 > Also for securing the SIP Signalling. [Henry] Ok >=20 >=20 > > The user cases and requirements document > > [RFC6341] outlines the general security considerations, and the > > following describe specific security recommendations. > > > > The SRC and SRS MUST support SIPS and TLS as per RFC3261. >=20 > Probably should refer to RFC 5630 here rather than 3261. [Henry] Would it be better to simply to say SRC/SRC must support SIPS/TLS without referring to this RFC? >=20 >=20 > > The > > Recording Session SHOULD be at least as secure as the Communication > > Session, meaning using at least the same strength of cipher suite as > > the CS if the CS is secured. For example, if the CS uses SIPS for > > signalling and RTP/SAVP for media, then the RS does not downgrade > > the > > level of security in the RS to SIP or plain RTP since doing so will > > mean an automatic security downgrade for the CS. In deployments > > where the SRC and the SRS are in the same administrative domain and > > the same physical switch that prevents outside user access, some SRC > > may choose lower the level of security when establishing the > > recording session. While physically securing the SRC and SRS may > > prevent an outside attacker from accessing important call > > recordings, > > this still does not prevent from an inside attacker from accessing > > the internal network to gain access to the call recordings. > > > > 12.1. Authentication and Authorization > > > > The recording session reuses the SIP mechanism to challenge requests > > that is based on HTTP authentication. The mechanism relies on 401 > > and 407 SIP responses as well as other SIP header fields for > > carrying > > challenges and credentials. > > >=20 > Should we also say something here about the use of TLS Authentication > including Mutual TLS Authentication? [Henry] This is mentioned in the second paragraph below, but it's a little unclear what it means. I will clarify that as must implement both TLS authentication and mutual TLS authentication. >=20 >=20 > > The SRS may have its own set of recording policies to authorize > > recording requests from the SRC. The use of recording policies is > > outside the scope of the Session Recording Protocol. > > > > The SRC and SRS MUST support mutual authentication for establishing > > the recording session. In deployments where the SRC and the SRS are > > in the same administrative domain, the deployment may choose not to > > authenticate each other or only to have SRC authenticate the SRS as > > there is an inherent trust relation between the SRC and the SRS when > > they are hosted in the same administrative domain. In deployments > > where the SRS can be hosted on a different administrative domain, > > then it is important to perform mutual authentication to ensure the > > authenticity of both the SRC and the SRS before transmitting any > > recorded media. The risk of not authenticating the SRS is that the > > recording may be sent to a compromised SRS and that sensitive call > > recording will be obtained by an attacker. On the other hand, the > > risk of not authenticating the SRC is that an SRS will be willingly > > accept any call recording from an unknown SRC and allow potential > > forgery of call recordings. > > > > 12.2. RTP handling > > > > In many scenarios it will be critical that the media transported > > between the SRC and SRS to be protected. Media encryption is an > > important element in the overall SIPREC solution; therefore SRC and > > SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. RTP/ > > SAVP and RTP/SAVPF provide media encryption, integrity protection, > > replay protection, and a limited form of source authentication. > > They > > do not contain or require a specific keying mechanism. > > > > When RTP/SAVP or RTP/SAVPF is used, RS can choose to use the same or > > different security keys than the ones used in the CS. Some SRCs are > > designed to simply replicate RTP packets from the CS media stream to > > the SRS, and the SRC will be reusing the same keys as the CS. In > > this case, the SRC MUST secure the SDES in the RS with at least the > > same level of security as the CS. The risk of lowering the level of > > security in the RS for this case is that it will effectively become > > a > > downgrade attack on the CS since the same key is used for both CS > > and > > RS. >=20 >=20 > When referring to "SDES" can you change to "Source Description (SDES)" and > give the reference to RFC3550. Just to avoid any confusion. [Henry] Okay. >=20 > > > > For SRCs that perform transcoding or mixing of media before sending > > to the SRS, the SRC MUST negotiate a different security key than the > > one being used in the CS, to ensure that the security in the CS is > > not compromised by the SRC when reusing the same security key. > > > > 12.3. Metadata > > > > Metadata contains sensitive information such as the address of > > record > > of the participants and other extension data placed by the SRC. It > > is essential to protect the content of the metadata in the RS. > > Since > > metadata is a content type transmitted in SIP signalling, metadata > > can be protected by SIPS/TLS. If the RS is not secured for any > > reason, the metadata content can also be secured by using S/MIME. >=20 > Can we make a firm recommendation to secure using TLS and not refer to S/MIME > at all? [Henry] I am okay with that and prefer only using TLS too :) I reference S/MIME since it was mentioned in RFC3261 as a way to protect the content, but then it's weird that you only protect metadata and not the rest of the content, unless you don't want any proxies in between to see the metadata. Anyone object to removing this? >=20 > > > > 12.4. Storage and playback > > > > While storage and playback of the call recording is beyond the scope > > of this document, it is worthwhile to mention here that it is also > > important for the recording storage and playback to provide a level > > of security that is comparable to the communication session. It > > would defeat the purpose of securing both the communication session > > and the recording session mentioned in the previous sections if the > > recording can be easily played back with a simple unsecured HTTP > > interface without any form of authentication or authorization. > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Mon Oct 1 14:45:38 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 079EE21F877A for ; Mon, 1 Oct 2012 14:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c7FL3phw4a3 for ; Mon, 1 Oct 2012 14:45:37 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7B421F8778 for ; Mon, 1 Oct 2012 14:45:37 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id 5mez1k0040xGWP855xlhAd; Mon, 01 Oct 2012 21:45:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 5xfl1k00e3ZTu2S3Yxfluy; Mon, 01 Oct 2012 21:39:46 +0000 Message-ID: <506A0DD3.9060703@alum.mit.edu> Date: Mon, 01 Oct 2012 17:40:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 21:45:38 -0000 I concur with what Andrew and Henry said. In addition I have one other comment: On 9/27/12 3:23 PM, Jain, Rajnish wrote: > Pls. find below some of my questions and comments on the draft-ietf-siprec-protocol-06 document (I apologize if these have been addressed earlier; pls. point me to mailing list discussions if these have been already been addressed). > > Carrying Recording Metadata through RE-INVITE or UPDATE, Section 5.2: > --------------------------------------------------------------------- > > The SIPREC protocol draft section 5.2 suggests the use of INVITE, RE-INVITE or UPDATE for conveying metadata from the SRC to the SRS. This may have been discussed in SIPREC WG earlier, but the choice of these methods for delivering metadata seems counterintuitive. This choice certainly misses some use cases. > > IMHO, the metadata information flow seems to better fit a SUBSCRIBE/NOTIFY mechanism. The protocol should allow for decoupling of RS session management (such as adding and removing media streams) from metadata event communication. These two protocol communications are somewhat independent. For example, the RS session management will tend to be real-time with SDP changes back-and-forth to avoid clipping of media. The metadata events are less real-time demanding because they can be correlated with the recorded media as long as the timestamps between the two flows are synchronized. For these reasons, the metadata generation/consumption logic may exist in different processing units in the SRC/SRC as compared to the RS session management and RTP media handling. This is one of the reasons why the SIPREC protocol allows for a non-SIP mechanism delivery of metadata even though it is out of scope of SIPREC (section 4). > > The CS/RS lifecycle diagrams in section 4 in RFC 6341 highlight some of these requirements. In particular, use case 4 in RFC 6341 describes a scenario where the RS exists longer than a CS. As a practical implementation of this use case, the SRC sends a metadata event to the SRS indicating a user logon (note that this means that metadata events span a user logon lifespan and not just the CS lifespan) when the user initially logs on but hasn't participated in a CS at this point. Depending on the capacity available at the SRS, the logon event triggers an INVITE from the SRS to the SRS to establish the RS. The logon event is delivered through a subscription that the SRS has previously established with the SRC. Such a message flow prevents clipping of the initial media samples from being recorded, which is the case when CS and RS are racing to establish at the same time. There are also use cases around push-to-talk where metadata events are required but turning RTP on and off th ro > ugh SDP exchange (sendonly, inactive) is expensive and more prone to media clipping. > > In the SUBSCRIBE/NOTIFY mechanism, the SRC will subscribe to the SRS for the metadata events. The SRC will push metadata events to the SRS as the CS undergoes state changes (initiation, teardown, hold/resume etc.) or when the user state that is targeted for recording undergoes changes. The SUBSCRIBE/NOTIFY mechanism also allows for built in bootstrapping of the SRS state where the SRS recovers after a failure (the first NOTIFY to the SUBSCRIBE will carry the current snapshot of the recording metadata; there may also be historical CS information in this NOTIFY). Sending an UPDATE for a 'media snapshot request' from SRS to SRC (as shown in Figure 2) seems counterintuitive to the usage of the UPDATE method (why and what is the SRS updating the SRC about the RS for?). A SUBSCRIBE will always fetch the current state as per the definition. One concern was for the speed of establishing an RS and getting going with recording. Being able to put metadata into the INVITE means that the SRS can have everything it needs to start recording immediately. Also, comments at this level would have been more practical to consider a couple of years ago when we were getting started on this work. At this point it is really too late to consider major architectural changes unless there is some severe malfunction in what we have. Thanks, Paul From DAVE.HIGTON@nice.com Tue Oct 2 06:12: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 8D2E021F87B0 for ; Tue, 2 Oct 2012 06:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5D4zSjYXll6 for ; Tue, 2 Oct 2012 06:12:42 -0700 (PDT) Received: from soumd01.eu.nice.com (UKEmail.nice.com [195.166.55.162]) by ietfa.amsl.com (Postfix) with ESMTP id C911A21F87AE for ; Tue, 2 Oct 2012 06:12:41 -0700 (PDT) Received: from SOUCAS01.eu.nice.com ([10.1.1.9]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 14:12:39 +0100 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS01.eu.nice.com ([::1]) with mapi; Tue, 2 Oct 2012 14:12:39 +0100 From: Dave Higton To: "siprec@ietf.org" Date: Tue, 2 Oct 2012 14:12:38 +0100 Thread-Topic: SIPREC captures Thread-Index: Ac2gn2wLFd14ZqvUSoSmWyJtvyzwjw== Message-ID: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26SOUEXC01eunic_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2012 13:12:39.0690 (UTC) FILETIME=[995D86A0:01CDA09F] Subject: [siprec] SIPREC captures X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2012 13:12:42 -0000 --_000_9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26SOUEXC01eunic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can anyone point me at, or send me, some SIPREC captures, please? PCAP for= mat preferred, but text of the SIPREC commands and responses would do. Thank you, Dave --_000_9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26SOUEXC01eunic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can anyone point= me at, or send me, some SIPREC captures, please?  PCAP format preferr= ed, but text of the SIPREC commands and responses would do.

<= p class=3DMsoNormal> 

Thank you,

 

= Dave

 

<= /html>= --_000_9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26SOUEXC01eunic_-- From leon.portman@gmail.com Tue Oct 2 06:14: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 360FA21F8793 for ; Tue, 2 Oct 2012 06:14:50 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j5AjN3FCP6p for ; Tue, 2 Oct 2012 06:14:49 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A820A21F876F for ; Tue, 2 Oct 2012 06:14:49 -0700 (PDT) Received: by danh15 with SMTP id h15so1947045dan.31 for ; Tue, 02 Oct 2012 06:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dxsm7IsSywttRo40t8h6Kla/iMVQmbuvJTCDcExrnkM=; b=xTqembYZvQ8uI2dJAkS2ry8nMUFO3FyvtlQBbQz0gPMYaT6Papn/iAEXwm5aeMSazQ 1vGjrDv3EYa2mrTtW7/iFIWInhF0Xele8eS2rBPByFJONF2d0ENkOa00wAZByR2Kq5rW TyKsAVwf87nE4NsJDsLWDKe+hljAmYwmiLLpiiZeV8wcDFdyv3lFG4CZgqzXFD0OqSni osctbrwHEsmDpXGeDCAVkeqo0gIW27AdQJsRpSI6KlO/4jV+SrlBZT+uZgXHZfHau7Bg GL7I+XqeJjzdfjQSw3tbDocJJ1VqEacTdc2eoHBWKABbrvztT6dM/eNNUbk8nfXJlA3S HxhA== MIME-Version: 1.0 Received: by 10.68.211.163 with SMTP id nd3mr1818815pbc.84.1349183689129; Tue, 02 Oct 2012 06:14:49 -0700 (PDT) Received: by 10.67.5.73 with HTTP; Tue, 2 Oct 2012 06:14:48 -0700 (PDT) Received: by 10.67.5.73 with HTTP; Tue, 2 Oct 2012 06:14:48 -0700 (PDT) In-Reply-To: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> References: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> Date: Tue, 2 Oct 2012 16:14:48 +0300 Message-ID: From: Leon Portman To: Dave Higton Content-Type: multipart/alternative; boundary=e89a8ff1c33e87002504cb134e6f Cc: "siprec@ietf.org" Subject: Re: [siprec] SIPREC captures X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2012 13:14:50 -0000 --e89a8ff1c33e87002504cb134e6f Content-Type: text/plain; charset=ISO-8859-1 On Oct 2, 2012 3:12 PM, "Dave Higton" wrote: > Can anyone point me at, or send me, some SIPREC captures, please? PCAP > format preferred, but text of the SIPREC commands and responses would do.* > *** > > ** ** > > Thank you,**** > > ** ** > > Dave**** > > ** ** > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > --e89a8ff1c33e87002504cb134e6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Oct 2, 2012 3:12 PM, "Dave Higton" = <DAVE.HIGTON@nice.com> wr= ote:

Can anyone point me at, or send me, some SIPREC captures, please? =A0PC= AP format preferred, but text of the SIPREC commands and responses would do= .

=A0

Thank yo= u,

=A0

Dave

=A0<= /p>


_______________________________________________
siprec mailing list
siprec@ietf.org
= https://www.ietf.org/mailman/listinfo/siprec

--e89a8ff1c33e87002504cb134e6f-- From internet-drafts@ietf.org Tue Oct 2 09:05:29 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 7D35A21F856F; Tue, 2 Oct 2012 09:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+Vr1F30L9ur; Tue, 2 Oct 2012 09:05:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D693921F8562; Tue, 2 Oct 2012 09:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121002160528.1770.79980.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 09:05:28 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-07.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:05:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Recording Protocol Author(s) : Leon Portman Henry Lum Charles Eckel Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-07.txt Pages : 43 Date : 2012-10-02 Abstract: This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-protocol-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Henry.Lum@genesyslab.com Tue Oct 2 09:07: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 3307721F8585 for ; Tue, 2 Oct 2012 09:07:07 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 134Kuywh-M0H for ; Tue, 2 Oct 2012 09:07:06 -0700 (PDT) Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id AEEB321F8562 for ; Tue, 2 Oct 2012 09:07:06 -0700 (PDT) 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 q92G752t006993 for ; Tue, 2 Oct 2012 09:07:05 -0700 (PDT) Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Oct 2012 09:06:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2012 09:06:52 -0700 Message-ID: <059AF07365DC474393A19A3AF187DF74092095F5@NAHALD.us.int.genesyslab.com> In-Reply-To: <20121002160528.1770.79980.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-protocol-07.txt Thread-Index: Ac2gt8AjwboxS4GXTCqvFRZfZaF6xAAAAzaw References: <20121002160528.1770.79980.idtracker@ietfa.amsl.com> From: "Henry Lum" To: X-OriginalArrivalTime: 02 Oct 2012 16:06:53.0204 (UTC) FILETIME=[F0252D40:01CDA0B7] Subject: Re: [siprec] I-D Action: draft-ietf-siprec-protocol-07.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:07:07 -0000 I have updated the draft to address all the comments from IETF84 as well as inserting the text for the security section. Regards, Henry > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: October-02-12 12:05 PM > To: i-d-announce@ietf.org > Cc: siprec@ietf.org > Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIP Recording Working Group of the IETF. >=20 > Title : Session Recording Protocol > Author(s) : Leon Portman > Henry Lum > Charles Eckel > Alan Johnston > Andrew Hutton > Filename : draft-ietf-siprec-protocol-07.txt > Pages : 43 > Date : 2012-10-02 >=20 > Abstract: > This document specifies the use of the Session Initiation Protocol > (SIP), the Session Description Protocol (SDP), and the Real Time > Protocol (RTP) for delivering real-time media and metadata from a > Communication Session (CS) to a recording device. The Session > Recording Protocol specifies the use of SIP, SDP, and RTP to > establish a Recording Session (RS) between the Session Recording > Client (SRC), which is on the path of the CS, and a Session Recording > Server (SRS) at the recording device. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-siprec-protocol-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From rmohanr@cisco.com Tue Oct 2 22:32: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 7B8D221F86AA for ; Tue, 2 Oct 2012 22:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxWfdpRwk9UI for ; Tue, 2 Oct 2012 22:32:47 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 777BF21F86A8 for ; Tue, 2 Oct 2012 22:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4805; q=dns/txt; s=iport; t=1349242367; x=1350451967; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=m4JSAkHdkzYqG4PgfJzzvkikbr2uqrkn+Y6HpY+hybk=; b=l2aQy5LTr6YMgQKnBkx7dGd/nUNVNfJSlcj2CoaRIQsyQuHuGtSlecoI WUua3Wl7wnOAu8JQ0jt/vEYFD+j7uqdO00qLayV/FWnBaSoarP24fxg2l EoKnOkGIbH8brgy5K+ouhTz7E+Uw3jatgnMjTKVHEF4FKm2TSMqgKoBEd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH3Na1CtJXG9/2dsb2JhbABFDr5jgQiCIAEBAQMBAQEBDwEnNBANAQgOCgoCARE3CyUCBAESCBqHXQYLmBqgCgSLOoVDYAOkK4Fpgiw7gVw7 X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="127747278" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 03 Oct 2012 05:32:47 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q935Wkmo023438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 05:32:46 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.134]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 00:32:46 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Comments on draft-ietf-siprec-protocol-06 Thread-Index: AQHNoSiELyYE05gBUUCuRhWs2ppCfw== Date: Wed, 3 Oct 2012 05:32:46 +0000 Message-ID: In-Reply-To: <506A0DD3.9060703@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.64.107] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--41.673900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8D5AD6FEA1C94C4F842BE05D269E2E07@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 05:32:48 -0000 > On 02/10/12 3:10 AM, "Paul Kyzivat" wrote: >I concur with what Andrew and Henry said. >In addition I have one other comment: > >On 9/27/12 3:23 PM, Jain, Rajnish wrote: >> Pls. find below some of my questions and comments on the >>draft-ietf-siprec-protocol-06 document (I apologize if these have been >>addressed earlier; pls. point me to mailing list discussions if these >>have been already been addressed). >> >> Carrying Recording Metadata through RE-INVITE or UPDATE, Section 5.2: >> --------------------------------------------------------------------- >> >> The SIPREC protocol draft section 5.2 suggests the use of INVITE, >>RE-INVITE or UPDATE for conveying metadata from the SRC to the SRS. This >>may have been discussed in SIPREC WG earlier, but the choice of these >>methods for delivering metadata seems counterintuitive. This choice >>certainly misses some use cases. >> >> IMHO, the metadata information flow seems to better fit a >>SUBSCRIBE/NOTIFY mechanism. The protocol should allow for decoupling of >>RS session management (such as adding and removing media streams) from >>metadata event communication. These two protocol communications are >>somewhat independent. For example, the RS session management will tend >>to be real-time with SDP changes back-and-forth to avoid clipping of >>media. The metadata events are less real-time demanding because they can >>be correlated with the recorded media as long as the timestamps between >>the two flows are synchronized. For these reasons, the metadata >>generation/consumption logic may exist in different processing units in >>the SRC/SRC as compared to the RS session management and RTP media >>handling. This is one of the reasons why the SIPREC protocol allows for >>a non-SIP mechanism delivery of metadata even though it is out of scope >>of SIPREC (section 4). >> >> The CS/RS lifecycle diagrams in section 4 in RFC 6341 highlight some of >>these requirements. In particular, use case 4 in RFC 6341 describes a >>scenario where the RS exists longer than a CS. As a practical >>implementation of this use case, the SRC sends a metadata event to the >>SRS indicating a user logon (note that this means that metadata events >>span a user logon lifespan and not just the CS lifespan) when the user >>initially logs on but hasn't participated in a CS at this point. >>Depending on the capacity available at the SRS, the logon event triggers >>an INVITE from the SRS to the SRS to establish the RS. The logon event >>is delivered through a subscription that the SRS has previously >>established with the SRC. Such a message flow prevents clipping of the >>initial media samples from being recorded, which is the case when CS and >>RS are racing to establish at the same time. There are also use cases >>around push-to-talk where metadata events are required but turning RTP >>on and off th > ro >> ugh SDP exchange (sendonly, inactive) is expensive and more prone to >>media clipping. >> >> In the SUBSCRIBE/NOTIFY mechanism, the SRC will subscribe to the SRS >>for the metadata events. The SRC will push metadata events to the SRS as >>the CS undergoes state changes (initiation, teardown, hold/resume etc.) >>or when the user state that is targeted for recording undergoes changes. >>The SUBSCRIBE/NOTIFY mechanism also allows for built in bootstrapping of >>the SRS state where the SRS recovers after a failure (the first NOTIFY >>to the SUBSCRIBE will carry the current snapshot of the recording >>metadata; there may also be historical CS information in this NOTIFY). >>Sending an UPDATE for a 'media snapshot request' from SRS to SRC (as >>shown in Figure 2) seems counterintuitive to the usage of the UPDATE >>method (why and what is the SRS updating the SRC about the RS for?). A >>SUBSCRIBE will always fetch the current state as per the definition. > >One concern was for the speed of establishing an RS and getting going >with recording. Being able to put metadata into the INVITE means that >the SRS can have everything it needs to start recording immediately. +1. I also agree with Paul and others here. SUB/NOT is some thing that was discussed 2 years back and after a lot of discussions it was agreed that INVITE based approach is the best one for SIPREC. Ram > >Also, comments at this level would have been more practical to consider >a couple of years ago when we were getting started on this work. At this >point it is really too late to consider major architectural changes >unless there is some severe malfunction in what we have. > > Thanks, > Paul > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From rajnish.jain@ipc.com Wed Oct 3 06:13: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 1FE9B21F8469 for ; Wed, 3 Oct 2012 06:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRozT0RtYkOM for ; Wed, 3 Oct 2012 06:13:57 -0700 (PDT) Received: from p01c12o148.mxlogic.net (p01c12o148.mxlogic.net [208.65.145.71]) by ietfa.amsl.com (Postfix) with ESMTP id E234821F8450 for ; Wed, 3 Oct 2012 06:13:56 -0700 (PDT) Received: from unknown [65.244.37.52] (EHLO p01c12o148.mxlogic.net) by p01c12o148.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id 41a3c605.7bede940.3294.00-596.7403.p01c12o148.mxlogic.net (envelope-from ); Wed, 03 Oct 2012 07:13:56 -0600 (MDT) X-MXL-Hash: 506c3a14480bbc86-083d1a39dbb680d4f80d8c0acae83ce10e4f34c0 Received: from unknown [65.244.37.52] by p01c12o148.mxlogic.net(mxl_mta-6.15.0-1) with SMTP id 21a3c605.0.3036.00-396.7355.p01c12o148.mxlogic.net (envelope-from ); Wed, 03 Oct 2012 07:13:56 -0600 (MDT) X-MXL-Hash: 506c3a145e210f09-5b1d4f428a7aa9508980ff9c5403724ac0c3d8f7 Received: from STSNYEXMBX2.corp.root.ipc.com ([fe80::157c:2ec6:ebe1:434b]) by STSNYEXHTCAS2.corp.root.ipc.com ([fe80::587a:3ab8:7c0b:6908%12]) with mapi id 14.02.0309.002; Wed, 3 Oct 2012 09:13:52 -0400 From: "Jain, Rajnish" To: "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: Comments on draft-ietf-siprec-protocol-06 Thread-Index: Ac2c5du5ZV1cJo+ySHq3n5ELyh8mhAC2bzqQAGTc+4A= Date: Wed, 3 Oct 2012 13:13:51 +0000 Message-ID: <4C91F9B607136D48AE3411BDC594D2AE0F376313@STSNYEXMBX2.corp.root.ipc.com> References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com> <9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.43.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=2.0 cv=Q4BlFfKa c=1 sm=0 a=D4USGbs0y0J827gn68Ljfg==:17 a] X-AnalysisOut: [=TI9zlQ3hUaoA:10 a=HLdq6XFp8tMA:10 a=lCc8-jNt9F8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=vvKfUcg] X-AnalysisOut: [jAAAA:8 a=bY863PJDRUAA:10 a=mYdOEvucW7gj96YsfaoA:9 a=CjuIK] X-AnalysisOut: [1q_8ugA:10] Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 13:13:58 -0000 Hi Andy, Thanks for your response. Pls. see inline: > Carrying Recording Metadata through RE-INVITE or UPDATE, Section 5.2: > --------------------------------------------------------------------- We had a lot of discussion in the working group regarding the mechanism for= transporting meta-data and I believe had strong consensus to go with the c= urrent model using INVITE/RE-INVITE/UPDATE and the use of UPDATE to request= a snapshot. The reasons for this was at least partly due to the fact that = the SDP in the RS forms part of the metadata and there has to be direct lin= kage between the RS SDP and metadata so conveying it within the same reques= t and dialog was logical and simplifies the solution. Unless we have discovered that the mechanism currently specified is broken = then I don't think we need to restart the debate on this issue. [rj] Understand. Sorry I couldn't participate in the protocol design discus= sions earlier. I understand that this may be too late to bring up. [rj] Just as a data point, we've currently in production an SRC system wher= e the metadata is carried by non-SIP means (the RS is established using SIP= ). The metadata is generated by a non-real-time part of the system (later c= orrelated with the RS in the SRS), whereas, the RS SIP session initiation i= s done by a real-time part of the system. Many of these design choices were= made to alleviate clipping of the recording media (a critical requirement = for us). I think this is typical in the industry because call metadata is g= enerally conveyed over the CDR/CTI interfaces (we've extended ECMA CSTA-WS = for this). We could have envisioned adopting the SIPREC metadata XML and tr= ansporting it in SUB/NOTIFY.=20 > Indicating recording preference in SDP (a=3Drecord, a=3Drecordpref),=20 > Section 5.3: > ---------------------------------------------------------------------- > - > ------ >=20 > The notion that a CS is being recorded or not seems more like a SIP-=20 > level construct (or maybe a metadata-level construct) as opposed to an=20 > SDP-level context. Since the indication/preference is on a media line basis then I don't know = where else we could put it. [rj] Ok. That makes sense. > Are these attributes really describing some characteristic about the=20 > media being carried in the RS RTP (described by SDP) or are they=20 > describing an RS characteristic itself? When an RS carries multiple=20 > CSes, I'm assuming that the metadata will uniquely identify each media=20 > stream in the RS (e.g. the SDP a=3Dlabel token will also be present in=20 > the metadata in some form) and so such attributes can be placed in the=20 > metadata. >=20 > In section 5.3, if the SRC chooses to ignore SRS' request to turn off=20 > recording, how does the SRS learn about that and what should the SRS=20 > do if it continues to receive media from the SRC? These indications apply to the CS not the RS so they don't impact the SRS a= t all. [rj] Ok. That makes sense. >=20 >=20 > Section 6.1, '+sip.rec' and 'siprec' tags': > ------------------------------------------- >=20 > Section 6.1 states: >=20 > In addition, when an SRC sends a REGISTER request > to a registrar, the SRC MUST include the '+sip.src' feature tag to > indicate the that it is a SRC. >=20 > The purpose of the Contact URI tags '+sip.src' and '+sip.srs' is not=20 > very clear from the description. They don't seem to be helping with=20 > the negotiating aspect of the recording feature and the SRS /SRS=20 > communication may not be through a proxy server (which has access to a=20 > registrar's location service). They are there to help ensure that things run smoothly and that it is clear= who is taking which role. An SRS for example will use this to make sure th= at an INVITE is from an SRC. The use in REGISTER is again only to help iden= tify SRC's and will not be useful in some scenarios. [rj] Ok. Regards, Raj Jain From br@brianrosen.net Wed Oct 3 06:44: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 92D1421F85AA for ; Wed, 3 Oct 2012 06:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.97 X-Spam-Level: X-Spam-Status: No, score=-98.97 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtjiAk-OIsCS for ; Wed, 3 Oct 2012 06:44:14 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id E1C5C21F859F for ; Wed, 3 Oct 2012 06:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=Mime-Version:To:Date:Message-Id:Subject:Content-Transfer-Encoding:Content-Type:From; bh=Gpy2sq1M9+PyadUcbIPUChI3gBLPeXyAoJBFmvJosC0=; b=tSO6kgYCdPG1WHLuJnkXcI3gMjg85j19K7yKXxqoRX/GPgyKNJT5tALT1O/GfMY+cWiwrGXcF4DrDdA8fCPS6FLC1xbKHWJcyQE/so5ffEA2Yq3aKUjBr39CtRoJgrPu; Received: from neustargw.va.neustar.com ([209.173.53.233]:20773 helo=[192.168.133.12]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TJPFF-0007XI-6U for siprec@ietf.org; Wed, 03 Oct 2012 09:44:13 -0400 From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <85CA3EE0-C2F4-4599-9D95-B1A5028A6761@brianrosen.net> Date: Wed, 3 Oct 2012 09:44:08 -0400 To: "siprec@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Subject: [siprec] Time Sync X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 13:44:14 -0000 We're planning on using siprec in NENA for Next Generation 9-1-1 media = recording. An issue arose in the past few days about how we would time = sync related recordings. This happens in several real world = circumstances where there is not one RS that has all of the media = streams when you play them back.=20 If RTCP is implemented on CS, then the SRC knows the relationship = between wall clock and RTP timestamps. Even if it doesn't have sender = reports, it knows when it received the packets and could relate wall = clock to it's view of RTP timestamps. If RTCP is implemented on the RS, the SRS could record absolute time of = the RS, and if it knew the delay of the SRC (if it was approximately = constant), that is probably good enough. But we have no text, and no = way for the SRC to tell the SRS about what it knows about the CS time. Brian= From simon.farrow@stancilcorp.com Wed Oct 3 09:17: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 5695C21F85F4 for ; Wed, 3 Oct 2012 09:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59srnM0D2y+4 for ; Wed, 3 Oct 2012 09:17:47 -0700 (PDT) Received: from mail43.atl.registeredsite.com (mail43.atl.registeredsite.com [209.237.134.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF3921F85D5 for ; Wed, 3 Oct 2012 09:17:46 -0700 (PDT) Received: from mymail.myregisteredsite.com (wmailnode1j.webmail.web.com [209.237.134.188]) by mail43.atl.registeredsite.com (8.12.11.20060308/8.12.11) with SMTP id q93GHk7e026411 for ; Wed, 3 Oct 2012 12:17:46 -0400 Received: (qmail 29847 invoked by uid 80); 3 Oct 2012 16:17:45 -0000 Received: from unknown (HELO VOXSTORSERVER) (simon.farrow@stancilcorp.com@65.244.196.81) by wmailnode1j.mymail.myregisteredsite.com with ESMTPA; 3 Oct 2012 16:17:45 -0000 From: "Simon Farrow" To: References: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> Date: Wed, 3 Oct 2012 09:14:40 -0700 Organization: Stancil Corporation Message-ID: <8E66DB23B8154FC89802B2DA6B5B509C@VOXSTORSERVER> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01CDA147.86D4DEE0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac2gn+z/zHVr/KISQs+Q2enFXs3LHgA4dcUg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [siprec] SIPREC captures X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: simon.farrow@stancilcorp.com List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:17:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0023_01CDA147.86D4DEE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am just reposting this request as this would very useful to us as well. Simon _____ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: Tuesday, October 02, 2012 6:15 AM To: Dave Higton Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC captures On Oct 2, 2012 3:12 PM, "Dave Higton" wrote: Can anyone point me at, or send me, some SIPREC captures, please? PCAP format preferred, but text of the SIPREC commands and responses would do. Thank you, Dave _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------=_NextPart_000_0023_01CDA147.86D4DEE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am just reposting this request as this = would very=20 useful to us as well. 
 
Simon
 
 

From: siprec-bounces@ietf.org=20 [mailto:siprec-bounces@ietf.org] On Behalf Of Leon=20 Portman
Sent: Tuesday, October 02, 2012 6:15 AM
To: = Dave=20 Higton
Cc: siprec@ietf.org
Subject: Re: [siprec] = SIPREC=20 captures

On Oct 2, 2012 3:12 PM, "Dave Higton" <DAVE.HIGTON@nice.com> = wrote:

Can anyone point me at, or send me, some SIPREC = captures,=20 please?  PCAP format preferred, but text of the SIPREC commands = and=20 responses would do.

 

Thank you,

 

Dave

 


_______________= ________________________________
siprec=20 mailing list
siprec@ietf.org
https://www.ietf.org/mailman/listinfo/siprec

<= /BLOCKQUOTE>
------=_NextPart_000_0023_01CDA147.86D4DEE0-- From partha@parthasarathi.co.in Wed Oct 3 10:22: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 BC30421F85A1 for ; Wed, 3 Oct 2012 10:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-0.996, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXRD7PkkqSc9 for ; Wed, 3 Oct 2012 10:22:16 -0700 (PDT) Received: from outbound-us3.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.155]) by ietfa.amsl.com (Postfix) with ESMTP id AE48421F8495 for ; Wed, 3 Oct 2012 10:22:14 -0700 (PDT) Received: from userPC (unknown [122.179.51.206]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 0F2C514D81AC; Wed, 3 Oct 2012 17:22:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1349284934; bh=/10iE/YKBcQ0UwlO8nHBaUDIvYHyE9WZ914oJr2sooI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=D19RfL+YF4Qixbyzj9VxNnMmBLfPs7WMmWkH+pkzrcGh0+x8u1HLvDKW1j4MT/tG8 Ony0eB1NNQh4I8KAjS1PYVEk6oil0KbGSEnzySgHmF69uhP7r3h9mtgRRMHr8pUybX dhtAtNdY9ptjUjEKPZ3luekYjv+a/60N+rM08fqE= From: "Parthasarathi R" To: "'Brian Rosen'" , References: <85CA3EE0-C2F4-4599-9D95-B1A5028A6761@brianrosen.net> In-Reply-To: <85CA3EE0-C2F4-4599-9D95-B1A5028A6761@brianrosen.net> Date: Wed, 3 Oct 2012 22:52:07 +0530 Message-ID: <003601cda18b$a07a2d20$e16e8760$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2hbTBzB16L0Uz9QZ2ehJMkGL6oqAAHby8w Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0207.506C7446.0036, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] Time Sync X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 17:22:17 -0000 Brian, Could you please clarify whether CS start-time attribute in Sec 6.3.1 of metadata draft (-07) shall be used to indicate about CS time from SRC to SRS. The attribute exact text is as follows: o Start-time - This optional attribute represents start time of CS as seen by SRC Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, October 03, 2012 7:14 PM To: siprec@ietf.org Subject: [siprec] Time Sync We're planning on using siprec in NENA for Next Generation 9-1-1 media recording. An issue arose in the past few days about how we would time sync related recordings. This happens in several real world circumstances where there is not one RS that has all of the media streams when you play them back. If RTCP is implemented on CS, then the SRC knows the relationship between wall clock and RTP timestamps. Even if it doesn't have sender reports, it knows when it received the packets and could relate wall clock to it's view of RTP timestamps. If RTCP is implemented on the RS, the SRS could record absolute time of the RS, and if it knew the delay of the SRC (if it was approximately constant), that is probably good enough. But we have no text, and no way for the SRC to tell the SRS about what it knows about the CS time. Brian _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From br@brianrosen.net Wed Oct 3 10:27: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 97B271F040A for ; Wed, 3 Oct 2012 10:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.876 X-Spam-Level: X-Spam-Status: No, score=-99.876 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_62=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2pmqDvBgrzK for ; Wed, 3 Oct 2012 10:27:07 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8A14A21F8470 for ; Wed, 3 Oct 2012 10:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=e05SlWNjiilYU1VPNhqu1XN2yOechq1eHw4vC8UTeUY=; b=TxfGPLTaXq0X4BongW/00c3Q+vz8JzOlCxMfzKvd64CHwebce4sEnfUDE86iwDEpDI1jTS4PvZdGC3cUsAsc3NJUafGTe63oXksZik5qvD6X8AlGO7efjnNVr39IrWP2; Received: from neustargw.va.neustar.com ([209.173.53.233]:24585 helo=[192.168.133.12]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TJSiw-000197-QK; Wed, 03 Oct 2012 13:27:06 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Brian Rosen In-Reply-To: <003601cda18b$a07a2d20$e16e8760$@co.in> Date: Wed, 3 Oct 2012 13:27:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94711D43-0686-45D6-9300-E8EC67898E26@brianrosen.net> References: <85CA3EE0-C2F4-4599-9D95-B1A5028A6761@brianrosen.net> <003601cda18b$a07a2d20$e16e8760$@co.in> To: "Parthasarathi R" X-Mailer: Apple Mail (2.1498) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: siprec@ietf.org Subject: Re: [siprec] Time Sync X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 17:27:08 -0000 This is the signaling time, right, not the RTP time? Start and End time value are derivable from Date header(if present in SIP message) in RS. In cases where Date header is not present, Start/End time are derivable from the time at which SRS receives the notification of SIP message to setup RS / disconnect RS. On Oct 3, 2012, at 1:22 PM, "Parthasarathi R" = wrote: > Brian, >=20 > Could you please clarify whether CS start-time attribute in Sec 6.3.1 = of > metadata draft (-07) shall be used to indicate about CS time from SRC = to > SRS. The attribute exact text is as follows: >=20 > o Start-time - This optional attribute represents start time of CS > as seen by SRC >=20 > Thanks > Partha >=20 > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of > Brian Rosen > Sent: Wednesday, October 03, 2012 7:14 PM > To: siprec@ietf.org > Subject: [siprec] Time Sync >=20 > We're planning on using siprec in NENA for Next Generation 9-1-1 media > recording. An issue arose in the past few days about how we would = time sync > related recordings. This happens in several real world circumstances = where > there is not one RS that has all of the media streams when you play = them > back.=20 >=20 > If RTCP is implemented on CS, then the SRC knows the relationship = between > wall clock and RTP timestamps. Even if it doesn't have sender = reports, it > knows when it received the packets and could relate wall clock to it's = view > of RTP timestamps. >=20 > If RTCP is implemented on the RS, the SRS could record absolute time = of the > RS, and if it knew the delay of the SRC (if it was approximately = constant), > that is probably good enough. But we have no text, and no way for the = SRC > to tell the SRS about what it knows about the CS time. >=20 > Brian > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec >=20 From partha@parthasarathi.co.in Wed Oct 3 10:28: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 219E421F84EA for ; Wed, 3 Oct 2012 10:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9whYGEBylBm for ; Wed, 3 Oct 2012 10:28:36 -0700 (PDT) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1681121F84CF for ; Wed, 3 Oct 2012 10:28:36 -0700 (PDT) Received: from userPC (unknown [122.179.51.206]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 909301908330; Wed, 3 Oct 2012 17:28:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1349285315; bh=p05hyQ6ZMIl6hiKTDlVahMYFmOddSaU0y+HtpnF+dnw=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ZUKlRZeZv78UVF8yb/YOyU+LUyEfGLzy2pRfCdXKg6jpphKw/9OX5YgQR5hIILrop EQV/giYV7fo2NF/WxvcGpsPh+0ifTyHjeorSOY6QCkpnxiM8C81YL1/Mvk+9VRoSqB TCahk+zSfNvkA1TqE9x4V3zr0mhN6W3aFas1vt/g= From: "Parthasarathi R" To: , References: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> <8E66DB23B8154FC89802B2DA6B5B509C@VOXSTORSERVER> In-Reply-To: <8E66DB23B8154FC89802B2DA6B5B509C@VOXSTORSERVER> Date: Wed, 3 Oct 2012 22:58:28 +0530 Message-ID: <003701cda18c$836dffd0$8a49ff70$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01CDA1BA.9D263BD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2gn+z/zHVr/KISQs+Q2enFXs3LHgA4dcUgAAKEC0A= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0204.506C75C3.010C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] SIPREC captures X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 17:28:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0038_01CDA1BA.9D263BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Sec 4.1 of SIPRE callflow document (http://tools.ietf.org/html/draft-ram-siprec-callflows-00) captures SIPREC messages with SDP & metadata XML. We have received the offline review comments to put RS SIP, SDP and XML message in the callflow document. We will update SIPREC callflow document with SIP messages in the next revision. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Simon Farrow Sent: Wednesday, October 03, 2012 9:45 PM To: siprec@ietf.org Subject: Re: [siprec] SIPREC captures I am just reposting this request as this would very useful to us as well. Simon _____ From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman Sent: Tuesday, October 02, 2012 6:15 AM To: Dave Higton Cc: siprec@ietf.org Subject: Re: [siprec] SIPREC captures On Oct 2, 2012 3:12 PM, "Dave Higton" wrote: Can anyone point me at, or send me, some SIPREC captures, please? PCAP format preferred, but text of the SIPREC commands and responses would do. Thank you, Dave _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ------=_NextPart_000_0038_01CDA1BA.9D263BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Sec 4.1 of SIPRE callflow document = (http://tools.ietf.org/html/draft-ram-siprec-callflows-00) captures SIPREC messages with SDP & metadata XML.  We have = received the offline review comments to put RS SIP, SDP and XML message in the = callflow document.  We will update SIPREC callflow document with SIP = messages  in the next revision.

 

Thanks

Partha

 

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Simon Farrow
Sent: Wednesday, October 03, 2012 9:45 PM
To: siprec@ietf.org
Subject: Re: [siprec] SIPREC captures

 

I am just reposting this request as this would very useful = to us as well. 

 

Simon

 

 

 

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Leon Portman
Sent: Tuesday, October 02, 2012 6:15 AM
To: Dave Higton
Cc: siprec@ietf.org
Subject: Re: [siprec] SIPREC captures

On Oct 2, 2012 3:12 PM, "Dave Higton" = <DAVE.HIGTON@nice.com> = wrote:

Can anyone point me at, or send me, some SIPREC captures, = please?  PCAP format preferred, but text of the SIPREC commands and = responses would do.

 

Thank you,

 

Dave

 


_______________________________________________
siprec mailing list
siprec@ietf.org
https://www.ietf.org/mailman/listinfo/siprec

------=_NextPart_000_0038_01CDA1BA.9D263BD0-- From rmohanr@cisco.com Wed Oct 3 10:32: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 D7AF421F84EA for ; Wed, 3 Oct 2012 10:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgN7NhAdqjQ3 for ; Wed, 3 Oct 2012 10:32:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 369B821F84CF for ; Wed, 3 Oct 2012 10:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=768; q=dns/txt; s=iport; t=1349285559; x=1350495159; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=vmukBIIXnsaIHYp8xPZWXqXsPqLv8wdZl78GRmEr1Ic=; b=KZpWwhlJ3FP7r0/DsTlnavRdCQq46rM807+49d1usuZlJda2YCFGM5KL wDnTGLhAdiWzgGTCcgclD8teY1C0HqImw7gpXQkJJkSmhV02aNZsSm3Bz Y6zQK2iaPd8FEqS5mWR9IZdIO0tSyH10j2QTZU5jDFsWSF5UQMMQiJsS1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAFB2bFCtJV2Y/2dsb2JhbABFhUa5MIEIgiABAQEDARIBaw0BCCJWJQIEARIIGoddBpdXn3qQfWADiCOcCIFpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="127996604" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 03 Oct 2012 17:32:34 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q93HWYAU012795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 17:32:34 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.134]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 12:32:33 -0500 From: "Ram Mohan R (rmohanr)" To: Henry Lum , "Hutton, Andrew" , "siprec@ietf.org" Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0SRlFTOq7/y0SQ+aCXjp5Rvw== Date: Wed, 3 Oct 2012 17:32:33 +0000 Message-ID: In-Reply-To: <059AF07365DC474393A19A3AF187DF7409209293@NAHALD.us.int.genesyslab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.74.100] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--31.447800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 17:32:40 -0000 > On 01/10/12 9:51 PM, "Henry Lum" wrote: >>Can we make a firm recommendation to secure using TLS and not refer to >S/MIME >>at all? >[Henry] I am okay with that and prefer only using TLS too :) I reference >S/MIME since it was mentioned in RFC3261 as a way to protect the >content, but then it's weird that you only protect metadata and not the >rest of the content, unless you don't want any proxies in between to see >the metadata. Anyone object to removing this? If mandating TLS between SRC and SRS is the intent here, I don=B9t think we can mandate that. Of course we can add a recommendation saying for deployments where SRC and SRS are in different administrative domains it is highly recommended to use TLS. Ram From simon.farrow@stancilcorp.com Wed Oct 3 10:45: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 6EE6721F86B8 for ; Wed, 3 Oct 2012 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkE4YVHZ8Qbf for ; Wed, 3 Oct 2012 10:45:13 -0700 (PDT) Received: from mail44.atl.registeredsite.com (mail44.atl.registeredsite.com [209.237.134.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4F74521F8578 for ; Wed, 3 Oct 2012 10:45:12 -0700 (PDT) Received: from mymail.myregisteredsite.com (wmailnode1f.webmail.web.com [209.237.134.171]) by mail44.atl.registeredsite.com (8.12.11.20060308/8.12.11) with SMTP id q93HjBEx012273 for ; Wed, 3 Oct 2012 13:45:11 -0400 Received: (qmail 9001 invoked by uid 80); 3 Oct 2012 17:45:10 -0000 Received: from unknown (HELO VOXSTORSERVER) (simon.farrow@stancilcorp.com@65.244.196.81) by wmailnode1f.mymail.myregisteredsite.com with ESMTPA; 3 Oct 2012 17:45:10 -0000 From: "Simon Farrow" To: References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com><9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F376313@STSNYEXMBX2.corp.root.ipc.com> Date: Wed, 3 Oct 2012 10:42:05 -0700 Organization: Stancil Corporation Message-ID: <01485BE70BDE49A3B9404CDB2920DAE2@VOXSTORSERVER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F376313@STSNYEXMBX2.corp.root.ipc.com> Thread-Index: Ac2c5du5ZV1cJo+ySHq3n5ELyh8mhAC2bzqQAGTc+4AAC+MPsA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [siprec] RFC 3428, RFC 4975 and RFC 4103 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: simon.farrow@stancilcorp.com List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:45:14 -0000 Will SIPREC support SIP MESSAGE (RFC 3428) and MSRP (RFC 4975). There should be no impact supporting RFC 4103 payload for Text Conversation, is that a correct assumption. Simon Farrow Stancil Corporation 2644 South Croddy Way Santa Ana CA 92704 http://www.stancilcorp.com simon.farrow@stancilcorp.com 714-546-2002 ext 4311 From partha@parthasarathi.co.in Wed Oct 3 11:05: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 808C521F845B for ; Wed, 3 Oct 2012 11:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqH17qj8186Z for ; Wed, 3 Oct 2012 11:05:16 -0700 (PDT) Received: from outbound-us3.mailhostbox.com (ift1.mail.pw [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id ABC2921F8203 for ; Wed, 3 Oct 2012 11:05:16 -0700 (PDT) Received: from userPC (unknown [122.179.51.206]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id 81CDC14D81AA; Wed, 3 Oct 2012 18:05:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1349287515; bh=GfaVWFfVXEJbVhDtCGQ8G5xDDL2pxbVpJNAlO3ijK5Y=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OHti+k5kgA/UfsfuusDrQ2YWbJCre6tNlUQlk3okdVcyp2SDCJ8zurvbtdiYXiFhF b2URJufhgpjIwBixX1RgE+96YdaD4V15xFcuURx2HTJlMKl8O555zc/kLeRIJ88Ob+ M7BJtx78rhedItrb9zc5I4vVp9MJr4DsoejBEpmY= From: "Parthasarathi R" To: "'Brian Rosen'" References: <85CA3EE0-C2F4-4599-9D95-B1A5028A6761@brianrosen.net> <003601cda18b$a07a2d20$e16e8760$@co.in> <94711D43-0686-45D6-9300-E8EC67898E26@brianrosen.net> In-Reply-To: <94711D43-0686-45D6-9300-E8EC67898E26@brianrosen.net> Date: Wed, 3 Oct 2012 23:35:09 +0530 Message-ID: <004201cda191$a32c6d20$e9854760$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2hjFNhhnJznad1QKiym4FhKjLuewAAhjeA Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0208.506C7E5B.0189, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: siprec@ietf.org Subject: Re: [siprec] Time Sync X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 18:05:17 -0000 Brian, As you expect, start-time is not RTP time and it is CS signaling start time. In case of SRC acts as RTP endpoint towards RS, SRC will override CS RTP timestamp while passing towards RS. In case the requirement is to convey CS RTP timestamp in RS RTP packets, then it is a new open item. Currently from SRC to SRS, the following timestamps are forwarded as part of metadata to understand the signaling timing of the session: 1) Start-time - CS start-time for a session 2) Stop-time - CS stop-time for a session 3) Associate-time - RS is associated with CS 4) Disassociate-time - RS is disassociated with CS Thanks Partha PS: RS date header or the first message of RS is not required to be CS start-time as RS may start during CS mid-session. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, October 03, 2012 10:57 PM To: Parthasarathi R Cc: siprec@ietf.org Subject: Re: [siprec] Time Sync This is the signaling time, right, not the RTP time? Start and End time value are derivable from Date header(if present in SIP message) in RS. In cases where Date header is not present, Start/End time are derivable from the time at which SRS receives the notification of SIP message to setup RS / disconnect RS. On Oct 3, 2012, at 1:22 PM, "Parthasarathi R" wrote: > Brian, > > Could you please clarify whether CS start-time attribute in Sec 6.3.1 of > metadata draft (-07) shall be used to indicate about CS time from SRC to > SRS. The attribute exact text is as follows: > > o Start-time - This optional attribute represents start time of CS > as seen by SRC > > Thanks > Partha > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Wednesday, October 03, 2012 7:14 PM > To: siprec@ietf.org > Subject: [siprec] Time Sync > > We're planning on using siprec in NENA for Next Generation 9-1-1 media > recording. An issue arose in the past few days about how we would time sync > related recordings. This happens in several real world circumstances where > there is not one RS that has all of the media streams when you play them > back. > > If RTCP is implemented on CS, then the SRC knows the relationship between > wall clock and RTP timestamps. Even if it doesn't have sender reports, it > knows when it received the packets and could relate wall clock to it's view > of RTP timestamps. > > If RTCP is implemented on the RS, the SRS could record absolute time of the > RS, and if it knew the delay of the SRC (if it was approximately constant), > that is probably good enough. But we have no text, and no way for the SRC > to tell the SRS about what it knows about the CS time. > > Brian > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From partha@parthasarathi.co.in Wed Oct 3 11:09:03 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 C44411F0381 for ; Wed, 3 Oct 2012 11:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uiW5onaoDS9 for ; Wed, 3 Oct 2012 11:09:02 -0700 (PDT) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.229]) by ietfa.amsl.com (Postfix) with ESMTP id 674B821F84E2 for ; Wed, 3 Oct 2012 11:09:02 -0700 (PDT) Received: from userPC (unknown [122.179.51.206]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 453101EBFAA7; Wed, 3 Oct 2012 18:08:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1349287742; bh=kG9Sx/Kheg6R/FQC9RyrNj45u9mfEklEpUt/r2C5D6o=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=B+XV6xBHl2/FTaqPhrWKxxC7z7p6pafWup6WhSnht75lygjx1yAiuwRoc/kZjVC2K na/AWXLHJ9XceMD8+ZGu1+blnIgp1Jk6vjiBgKJRGuPBEA5SNw/J7ZUKJVzFlhseFR bFFk8/IKd+mU3v8KubRWFB2eXhvYv/LAIaSPhGJo= From: "Parthasarathi R" To: "'Jain, Rajnish'" , "'Hutton, Andrew'" , References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com> <9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F376313@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F376313@STSNYEXMBX2.corp.root.ipc.com> Date: Wed, 3 Oct 2012 23:38:54 +0530 Message-ID: <004301cda192$29f658c0$7de30a40$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2c5du5ZV1cJo+ySHq3n5ELyh8mhAC2bzqQAGTc+4AADmWzcA== Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0203.506C7F3E.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 18:09:03 -0000 Hi Rajnish, The current SIPREC architecture provides persistent RS recording to avoid the initial clipping. In fact, there is no mandate to send SIPREC metadata in the first RS message (INVITE) wherein SIPREC metadata shall be included in persistent RS once the CS is established in SRC. The advantage of current SIPREC mechanism is that 1) There is no need of external interfaces like CTI for recording. 2) Extra dialog (SUBSCRIBE/NOTIFY) is not required to be established between SRC and SRS to pass metadata. Please note that the metadata in SIPREC is specific to CS related info in real-time and other recording metadata is considered as outside the scope of SIPREC. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Jain, Rajnish Sent: Wednesday, October 03, 2012 6:44 PM To: Hutton, Andrew; siprec@ietf.org Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06 Hi Andy, Thanks for your response. Pls. see inline: > Carrying Recording Metadata through RE-INVITE or UPDATE, Section 5.2: > --------------------------------------------------------------------- We had a lot of discussion in the working group regarding the mechanism for transporting meta-data and I believe had strong consensus to go with the current model using INVITE/RE-INVITE/UPDATE and the use of UPDATE to request a snapshot. The reasons for this was at least partly due to the fact that the SDP in the RS forms part of the metadata and there has to be direct linkage between the RS SDP and metadata so conveying it within the same request and dialog was logical and simplifies the solution. Unless we have discovered that the mechanism currently specified is broken then I don't think we need to restart the debate on this issue. [rj] Understand. Sorry I couldn't participate in the protocol design discussions earlier. I understand that this may be too late to bring up. [rj] Just as a data point, we've currently in production an SRC system where the metadata is carried by non-SIP means (the RS is established using SIP). The metadata is generated by a non-real-time part of the system (later correlated with the RS in the SRS), whereas, the RS SIP session initiation is done by a real-time part of the system. Many of these design choices were made to alleviate clipping of the recording media (a critical requirement for us). I think this is typical in the industry because call metadata is generally conveyed over the CDR/CTI interfaces (we've extended ECMA CSTA-WS for this). We could have envisioned adopting the SIPREC metadata XML and transporting it in SUB/NOTIFY. > Indicating recording preference in SDP (a=record, a=recordpref), > Section 5.3: > ---------------------------------------------------------------------- > - > ------ > > The notion that a CS is being recorded or not seems more like a SIP- > level construct (or maybe a metadata-level construct) as opposed to an > SDP-level context. Since the indication/preference is on a media line basis then I don't know where else we could put it. [rj] Ok. That makes sense. > Are these attributes really describing some characteristic about the > media being carried in the RS RTP (described by SDP) or are they > describing an RS characteristic itself? When an RS carries multiple > CSes, I'm assuming that the metadata will uniquely identify each media > stream in the RS (e.g. the SDP a=label token will also be present in > the metadata in some form) and so such attributes can be placed in the > metadata. > > In section 5.3, if the SRC chooses to ignore SRS' request to turn off > recording, how does the SRS learn about that and what should the SRS > do if it continues to receive media from the SRC? These indications apply to the CS not the RS so they don't impact the SRS at all. [rj] Ok. That makes sense. > > > Section 6.1, '+sip.rec' and 'siprec' tags': > ------------------------------------------- > > Section 6.1 states: > > In addition, when an SRC sends a REGISTER request > to a registrar, the SRC MUST include the '+sip.src' feature tag to > indicate the that it is a SRC. > > The purpose of the Contact URI tags '+sip.src' and '+sip.srs' is not > very clear from the description. They don't seem to be helping with > the negotiating aspect of the recording feature and the SRS /SRS > communication may not be through a proxy server (which has access to a > registrar's location service). They are there to help ensure that things run smoothly and that it is clear who is taking which role. An SRS for example will use this to make sure that an INVITE is from an SRC. The use in REGISTER is again only to help identify SRC's and will not be useful in some scenarios. [rj] Ok. Regards, Raj Jain _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From br@brianrosen.net Wed Oct 3 11:19: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 5BB3D21F864D for ; Wed, 3 Oct 2012 11:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.873 X-Spam-Level: X-Spam-Status: No, score=-99.873 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_62=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DojYEnjWJcW2 for ; Wed, 3 Oct 2012 11:19:38 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8A76321F8620 for ; Wed, 3 Oct 2012 11:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=jlbAstH/tBaxCXQp78QqRmhptUoV13PtDIjvWSeQAL8=; b=mQliUlE378SB8wQVP2AC5njrHZ122HJkN6Jy0bBOfjW6aaN3ME9miwRtmXwtkyUL3+QDZvv7N+24BYN8xIMnADpDyo326WN6GOEacbdUZne/TS8YMXXrQWtlXfSwRM7o; Received: from neustargw.va.neustar.com ([209.173.53.233]:25487 helo=[192.168.133.12]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TJTXl-0003vL-Ge; Wed, 03 Oct 2012 14:19:37 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Brian Rosen In-Reply-To: <004201cda191$a32c6d20$e9854760$@co.in> Date: Wed, 3 Oct 2012 14:19:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <672C58E5-A00E-4E7F-89CC-EC661C85E347@brianrosen.net> References: <85CA3EE0-C2F4-4599-9D95-B1A5028A6761@brianrosen.net> <003601cda18b$a07a2d20$e16e8760$@co.in> <94711D43-0686-45D6-9300-E8EC67898E26@brianrosen.net> <004201cda191$a32c6d20$e9854760$@co.in> To: Parthasarathi R X-Mailer: Apple Mail (2.1498) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: siprec@ietf.org Subject: Re: [siprec] Time Sync X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2012 18:19:39 -0000 I'm not sure what we need, because I'm not sure what the actual = differences are between the items. I know there is quite a bit of difference between the RTP and the = signaling, so I know we need something that gets us wall time of the = RTP. It may be that if the RS has RTCP and there is negligible delay in = the SRC between when it gets a packet on the CS and sends one on the RS, = then just recording based on sender reports of RTCP on the RS may be = okay. However, if there is substantial delay, or especially if there is = variable substantial delay, this may not be satisfactory. Brian On Oct 3, 2012, at 2:05 PM, Parthasarathi R = wrote: > Brian, >=20 > As you expect, start-time is not RTP time and it is CS signaling start = time. > In case of SRC acts as RTP endpoint towards RS, SRC will override CS = RTP > timestamp while passing towards RS. In case the requirement is to = convey CS > RTP timestamp in RS RTP packets, then it is a new open item.=20 >=20 > Currently from SRC to SRS, the following timestamps are forwarded as = part of > metadata to understand the signaling timing of the session: >=20 > 1) Start-time - CS start-time for a session > 2) Stop-time - CS stop-time for a session > 3) Associate-time - RS is associated with CS > 4) Disassociate-time - RS is disassociated with CS=20 >=20 > Thanks > Partha >=20 > PS: RS date header or the first message of RS is not required to be CS > start-time as RS may start during CS mid-session.=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, October 03, 2012 10:57 PM > To: Parthasarathi R > Cc: siprec@ietf.org > Subject: Re: [siprec] Time Sync >=20 > This is the signaling time, right, not the RTP time? >=20 > Start and End time value are derivable from Date header(if present in > SIP message) in RS. In cases where Date header is not present, > Start/End time are derivable from the time at which SRS receives the > notification of SIP message to setup RS / disconnect RS. >=20 >=20 > On Oct 3, 2012, at 1:22 PM, "Parthasarathi R" = > wrote: >=20 >> Brian, >>=20 >> Could you please clarify whether CS start-time attribute in Sec 6.3.1 = of >> metadata draft (-07) shall be used to indicate about CS time from SRC = to >> SRS. The attribute exact text is as follows: >>=20 >> o Start-time - This optional attribute represents start time of CS >> as seen by SRC >>=20 >> Thanks >> Partha >>=20 >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf > Of >> Brian Rosen >> Sent: Wednesday, October 03, 2012 7:14 PM >> To: siprec@ietf.org >> Subject: [siprec] Time Sync >>=20 >> We're planning on using siprec in NENA for Next Generation 9-1-1 = media >> recording. An issue arose in the past few days about how we would = time > sync >> related recordings. This happens in several real world circumstances > where >> there is not one RS that has all of the media streams when you play = them >> back.=20 >>=20 >> If RTCP is implemented on CS, then the SRC knows the relationship = between >> wall clock and RTP timestamps. Even if it doesn't have sender = reports, it >> knows when it received the packets and could relate wall clock to = it's > view >> of RTP timestamps. >>=20 >> If RTCP is implemented on the RS, the SRS could record absolute time = of > the >> RS, and if it knew the delay of the SRC (if it was approximately > constant), >> that is probably good enough. But we have no text, and no way for = the SRC >> to tell the SRS about what it knows about the CS time. >>=20 >> Brian >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >>=20 >=20 From pkyzivat@alum.mit.edu Thu Oct 4 11:57: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 C65441F0C93 for ; Thu, 4 Oct 2012 11:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUpUHssnG4pf for ; Thu, 4 Oct 2012 11:57:13 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 37EA71F0C8E for ; Thu, 4 Oct 2012 11:57:13 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id 6yPG1k0010Fqzac536xHXA; Thu, 04 Oct 2012 18:57:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 76s31k0163ZTu2S3U6s3Hd; Thu, 04 Oct 2012 18:52:04 +0000 Message-ID: <506DDADB.9040609@alum.mit.edu> Date: Thu, 04 Oct 2012 14:52:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com><9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F376313@STSNYEXMBX2.corp.root.ipc.com> <01485BE70BDE49A3B9404CDB2920DAE2@VOXSTORSERVER> In-Reply-To: <01485BE70BDE49A3B9404CDB2920DAE2@VOXSTORSERVER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] RFC 3428, RFC 4975 and RFC 4103 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2012 18:57:13 -0000 On 10/3/12 1:42 PM, Simon Farrow wrote: > > Will SIPREC support SIP MESSAGE (RFC 3428) and MSRP (RFC 4975). There should > be no impact supporting RFC 4103 payload for Text Conversation, is that a > correct assumption. We did not explicitly address any of these. (We were trying to bound the scope of the effort.) However: - everything should be there to support RFC 4103, since it's also RTP. - implementations could probably support recording of MSRP in the spirit of what is there, and maybe successfully interoperate. But to be certain there would need to be a followon effort to investigate what issues might arise. - Supporting MESSAGE raises all sorts of potential issues. Do you mean individual MESSAGE requests (page-mode, sessionless)? Or do you mean dialogs containing multiple MESSAGEs? (That usage is not sanctioned.) Thanks, Paul From simon.farrow@stancilcorp.com Thu Oct 4 12:13: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 B80D71F0C95 for ; Thu, 4 Oct 2012 12:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up0NkdFFYiok for ; Thu, 4 Oct 2012 12:13:35 -0700 (PDT) Received: from mail46.atl.registeredsite.com (mail46.atl.registeredsite.com [209.237.134.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6551F0C93 for ; Thu, 4 Oct 2012 12:13:34 -0700 (PDT) Received: from mymail.myregisteredsite.com (wmailnode1g.webmail.web.com [209.237.134.185]) by mail46.atl.registeredsite.com (8.12.11.20060308/8.12.11) with SMTP id q94J42O8012243 for ; Thu, 4 Oct 2012 15:04:04 -0400 Received: (qmail 17565 invoked by uid 80); 4 Oct 2012 19:13:32 -0000 Received: from unknown (HELO VOXSTORSERVER) (simon.farrow@stancilcorp.com@65.244.196.81) by wmailnode1g.mymail.myregisteredsite.com with ESMTPA; 4 Oct 2012 19:13:32 -0000 From: "Simon Farrow" To: "'Paul Kyzivat'" , References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com><9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net><4C91F9B607136D48AE3411BDC594D2AE0F376313@STSNYEXMBX2.corp.root.ipc.com><01485BE70BDE49A3B9404CDB2920DAE2@VOXSTORSERVER> <506DDADB.9040609@alum.mit.edu> Date: Thu, 4 Oct 2012 12:10:25 -0700 Organization: Stancil Corporation Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac2iYhSdd9nkbuCITmm2HKkMfcsZ1QAACuFw In-Reply-To: <506DDADB.9040609@alum.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [siprec] RFC 3428, RFC 4975 and RFC 4103 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: simon.farrow@stancilcorp.com List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 19:13:36 -0000 Paul Thank you for your reply. I understand the points regarding RFC 4103 and MSRP and agree with your assessments. To answer your question with regards to MESSAGE. I was only considering individual messages which has useful associated metadata to them. (e.g. participants, who typed it, when etc). It would be up to the SRS client on how to display them for the user. Thanks, Simon -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, October 04, 2012 11:52 AM To: siprec@ietf.org Subject: Re: [siprec] RFC 3428, RFC 4975 and RFC 4103 On 10/3/12 1:42 PM, Simon Farrow wrote: > > Will SIPREC support SIP MESSAGE (RFC 3428) and MSRP (RFC 4975). There > should be no impact supporting RFC 4103 payload for Text Conversation, > is that a correct assumption. We did not explicitly address any of these. (We were trying to bound the scope of the effort.) However: - everything should be there to support RFC 4103, since it's also RTP. - implementations could probably support recording of MSRP in the spirit of what is there, and maybe successfully interoperate. But to be certain there would need to be a followon effort to investigate what issues might arise. - Supporting MESSAGE raises all sorts of potential issues. Do you mean individual MESSAGE requests (page-mode, sessionless)? Or do you mean dialogs containing multiple MESSAGEs? (That usage is not sanctioned.) Thanks, Paul _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Oct 4 12:58:12 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 76E9F21F8752 for ; Thu, 4 Oct 2012 12:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nAs+1RQrbYL for ; Thu, 4 Oct 2012 12:58:12 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id E602721F8751 for ; Thu, 4 Oct 2012 12:58:11 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 774T1k0081ZXKqc5B7yFL0; Thu, 04 Oct 2012 19:58:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id 77uG1k00y3ZTu2S3h7uGTo; Thu, 04 Oct 2012 19:54:16 +0000 Message-ID: <506DE926.1090904@alum.mit.edu> Date: Thu, 04 Oct 2012 15:53:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simon.farrow@stancilcorp.com References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com><9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net><4C91F9B607136D48AE3411BDC594D2AE0F376313@STSNYEXMBX2.corp.root.ipc.com><01485BE70BDE49A3B9404CDB2920DAE2@VOXSTORSERVER> <506DDADB.9040609@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] RFC 3428, RFC 4975 and RFC 4103 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 04 Oct 2012 19:58:12 -0000 On 10/4/12 3:10 PM, Simon Farrow wrote: > Paul > > Thank you for your reply. I understand the points regarding RFC 4103 and > MSRP and agree with your assessments. > > To answer your question with regards to MESSAGE. I was only considering > individual messages which has useful associated metadata to them. (e.g. > participants, who typed it, when etc). It would be up to the SRS client on > how to display them for the user. OK. For single MESSAGEs I think we would need to do extension work. My thought is that it would be recorded as metadata-only. But the details need to be worked out. If these things are important to you then they should be added to the list of desired extension work that we *ought* to be collecting. Thanks, Paul From pkyzivat@alum.mit.edu Fri Oct 5 07:25: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 8B05021F86A1 for ; Fri, 5 Oct 2012 07:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QDcZe9lC8pj for ; Fri, 5 Oct 2012 07:25:53 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id E9DBC21F85C2 for ; Fri, 5 Oct 2012 07:25:49 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta14.westchester.pa.mail.comcast.net with comcast id 7SEU1k0041ZXKqc5ESRtL9; Fri, 05 Oct 2012 14:25:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id 7SMu1k00A3ZTu2S3hSMuzr; Fri, 05 Oct 2012 14:21:54 +0000 Message-ID: <506EECC0.3090607@alum.mit.edu> Date: Fri, 05 Oct 2012 10:20:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2012 14:25:53 -0000 I see no point in mentioning S/MIME. AFAIK *nobody* implements it. Paul On 10/3/12 1:32 PM, Ram Mohan R (rmohanr) wrote: >> On 01/10/12 9:51 PM, "Henry Lum" wrote: > >>> Can we make a firm recommendation to secure using TLS and not refer to >> S/MIME >>> at all? >> [Henry] I am okay with that and prefer only using TLS too :) I reference >> S/MIME since it was mentioned in RFC3261 as a way to protect the >> content, but then it's weird that you only protect metadata and not the >> rest of the content, unless you don't want any proxies in between to see >> the metadata. Anyone object to removing this? > > If mandating TLS between SRC and SRS is the intent here, I don¹t think we > can mandate that. Of course we can add a recommendation saying for > deployments where SRC and SRS are in different administrative domains it > is highly recommended to use TLS. > > Ram > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Fri Oct 5 07:31: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 4ABA321F86A7 for ; Fri, 5 Oct 2012 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MqdPxhwBtJM for ; Fri, 5 Oct 2012 07:31:31 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8450021F86CF for ; Fri, 5 Oct 2012 07:31:31 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 56B6423F0464 for ; Fri, 5 Oct 2012 16:31:30 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.209]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 16:31:30 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: siprec - Requested session has been scheduled for IETF 85 Thread-Index: AQHNomg3O0FeQYfjL0O6S8j7/kMo5peqxfzQ Date: Fri, 5 Oct 2012 14:31:28 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012E73F4@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [siprec] FW: siprec - Requested session has been scheduled for IETF 85 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2012 14:31:32 -0000 SGkgQWxsLA0KDQpXZSBoYXZlIGJlZW4gc2NoZWR1bGVkIGEgVGh1cnNkYXkgYWZ0ZXJub29uIHNs b3QgZm9yIEF0bGFudGEgYnV0IHBsZWFzZSBub3RlIHRoYXQgdGhlIHRpbWVzbG90IGNvdWxkIHN0 aWxsIGNoYW5nZS4gSSBob3BlIHRvIHNlZSB5b3UgYWxsIHRoZXJlLg0KDQpXZSByZWFsbHkgY291 bGQgZG8gd2l0aCBtb3JlIHJldmlldyBlc3BlY2lhbGx5IG9mIHRoZSBtZXRhZGF0YSBkcmFmdCBi ZWZvcmUgdGhlIG1lZXRpbmcgKFNlZSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXNpcHJlYy1tZXRhZGF0YS0wNykNCg0KUmVnYXJkcw0KQW5keQ0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICJJRVRGIFNlY3JldGFyaWF0IiBbbWFpbHRvOmFnZW5k YUBpZXRmLm9yZ10gDQpTZW50OiAwNCBPY3RvYmVyIDIwMTIgMjA6NDENClRvOiBIdXR0b24sIEFu ZHJldw0KQ2M6IHNpcHJlYy1hZHNAdG9vbHMuaWV0Zi5vcmc7IGJyQGJyaWFucm9zZW4ubmV0OyBI dXR0b24sIEFuZHJldzsgd2xvQGFtc2wuY29tDQpTdWJqZWN0OiBzaXByZWMgLSBSZXF1ZXN0ZWQg c2Vzc2lvbiBoYXMgYmVlbiBzY2hlZHVsZWQgZm9yIElFVEYgODUNCg0KRGVhciBBbmRyZXcgSHV0 dG9uLA0KDQpUaGUgc2Vzc2lvbihzKSB0aGF0IHlvdSBoYXZlIHJlcXVlc3RlZCBoYXZlIGJlZW4g c2NoZWR1bGVkLg0KQmVsb3cgaXMgdGhlIHNjaGVkdWxlZCBzZXNzaW9uIGluZm9ybWF0aW9uIGZv bGxvd2VkIGJ5DQp0aGUgb3JpZ2luYWwgcmVxdWVzdC4gDQoNCnNpcHJlYyBTZXNzaW9uIDEgKDI6 MDA6MDApDQogICAgVGh1cnNkYXksIEFmdGVybm9vbiBTZXNzaW9uIElJIDE1MTAtMTcxMA0KICAg IFJvb20gTmFtZTogUm9vbSAyMDkNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiAgICANCg0KDQpSZXF1ZXN0IEluZm9ybWF0aW9uOg0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV29y a2luZyBHcm91cCBOYW1lOiANCkFyZWEgTmFtZTogDQpTZXNzaW9uIFJlcXVlc3RlcjogDQoNCk51 bWJlciBvZiBTZXNzaW9uczogMQ0KTGVuZ3RoIG9mIFNlc3Npb24ocyk6ICAyIEhvdXJzDQpOdW1i ZXIgb2YgQXR0ZW5kZWVzOiA0MA0KQ29uZmxpY3RzIHRvIEF2b2lkOiANCiBGaXJzdCBQcmlvcml0 eTogYXRvY2EgYXZ0Y29yZSBhdnRleHQgYmxpc3MgYmZjcGJpcyBjbHVlIGRpc3BhdGNoIGVjcml0 IGdlb3ByaXYgaGlwIG1lZGlhY3RybCBtbXVzaWMgcDJwc2lwIHBhd3MgcnRjd2ViIHNpcGNvcmUg dmlwciBpbnNpcGlkIHNhbHVkIHN0cmF3DQogU2Vjb25kIFByaW9yaXR5OiBhbHRvIGNvZGVjIGN1 c3MgZHJpbmtzIHNpcGNsZiBzb2Mgc3BlZWNoc2MgeG1wcA0KDQoNCg0KU3BlY2lhbCBSZXF1ZXN0 czoNCiAgTWVldGVjaG8gZm9yIHJlbW90ZSBwYXJ0aWNpcGF0aW9uLCBqYWJiZXIsIGFuZCByZWNv cmRpbmcgb2YgdGhlIHNlc3Npb24uDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From andrew.hutton@siemens-enterprise.com Fri Oct 5 08:39: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 5E97721F8731 for ; Fri, 5 Oct 2012 08:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC5Bt6+eoRnR for ; Fri, 5 Oct 2012 08:39:56 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4F83621F8747 for ; Fri, 5 Oct 2012 08:39:56 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8B26B23F0474; Fri, 5 Oct 2012 17:39:55 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.209]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 17:39:54 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "simon.farrow@stancilcorp.com" Thread-Topic: [siprec] RFC 3428, RFC 4975 and RFC 4103 Thread-Index: AQHNomqXo1obo8bpI02WhyrLZ6WcF5eqztlA Date: Fri, 5 Oct 2012 15:39:53 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012E7646@MCHP04MSX.global-ad.net> References: <4C91F9B607136D48AE3411BDC594D2AE0F374D2C@STSNYEXMBX2.corp.root.ipc.com><9F33F40F6F2CD847824537F3C4E37DDF012E1B7A@MCHP04MSX.global-ad.net><4C91F9B607136D48AE3411BDC594D2AE0F376313@STSNYEXMBX2.corp.root.ipc.com><01485BE70BDE49A3B9404CDB2920DAE2@VOXSTORSERVER> <506DDADB.9040609@alum.mit.edu> <506DE926.1090904@alum.mit.edu> In-Reply-To: <506DE926.1090904@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] RFC 3428, RFC 4975 and RFC 4103 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2012 15:39:57 -0000 Hi, Regarding RFC 4103 then this it is one of our requirements to support the r= ecording of this media type see below the text in RFC 6341 (SIPREC Requirem= ents). I am not aware of any reason why this would not work in the current = solution. If anybody see's a problem please let us know. o REQ-007: The mechanism MUST support the recording of the following RTP media types: voice, DTMF (as defined by [RFC4733]), video, and text (as defined by [RFC4103]) Regarding the recording of MSRP or SIP MESSAGE then as Paul stated this was= not covered by our requirements and has not been discussed in the group. I= am sure we could build this in as an extension if people have requirements= but it would not be covered by the existing drafts. Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 04 October 2012 20:53 > To: simon.farrow@stancilcorp.com > Cc: siprec@ietf.org > Subject: Re: [siprec] RFC 3428, RFC 4975 and RFC 4103 >=20 > On 10/4/12 3:10 PM, Simon Farrow wrote: > > Paul > > > > Thank you for your reply. I understand the points regarding RFC 4103 > and > > MSRP and agree with your assessments. > > > > To answer your question with regards to MESSAGE. I was only > considering > > individual messages which has useful associated metadata to them. > (e.g. > > participants, who typed it, when etc). It would be up to the SRS > client on > > how to display them for the user. >=20 > OK. For single MESSAGEs I think we would need to do extension work. > My thought is that it would be recorded as metadata-only. But the > details need to be worked out. >=20 > If these things are important to you then they should be added to the > list of desired extension work that we *ought* to be collecting. >=20 > Thanks, > Paul >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Fri Oct 5 09:01: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 A05C321F8716 for ; Fri, 5 Oct 2012 09:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRmpL98EMwYE for ; Fri, 5 Oct 2012 09:01:33 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id D3A0A21F86EC for ; Fri, 5 Oct 2012 09:01:11 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id B8E661EB8442; Fri, 5 Oct 2012 18:01:10 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.209]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 18:01:10 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , Henry Lum , "siprec@ietf.org" Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0SRlFTOq7/y0SQ+aCXjp5Rv5eq3wQQ Date: Fri, 5 Oct 2012 16:01:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> References: <059AF07365DC474393A19A3AF187DF7409209293@NAHALD.us.int.genesyslab.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2012 16:01:33 -0000 Hi Ram, We do make TLS support by the SRC and SRS a MUST requirement in the protoco= l draft and I think this is the correct thing to do. So it is mandatory to = implement but not mandatory to use. It has to be like that otherwise we cou= ld not support the requirement to make the RS at least as secure as the CS. Regards Andy > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 03 October 2012 18:33 > To: Henry Lum; Hutton, Andrew; siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in siprec- > protocol >=20 > > On 01/10/12 9:51 PM, "Henry Lum" wrote: >=20 > >>Can we make a firm recommendation to secure using TLS and not refer > to > >S/MIME > >>at all? > >[Henry] I am okay with that and prefer only using TLS too :) I > reference > >S/MIME since it was mentioned in RFC3261 as a way to protect the > >content, but then it's weird that you only protect metadata and not > the > >rest of the content, unless you don't want any proxies in between to > see > >the metadata. Anyone object to removing this? >=20 > If mandating TLS between SRC and SRS is the intent here, I don=B9t think > we > can mandate that. Of course we can add a recommendation saying for > deployments where SRC and SRS are in different administrative domains > it > is highly recommended to use TLS. >=20 > Ram From rmohanr@cisco.com Fri Oct 5 09:26: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 DCA1B21F8687 for ; Fri, 5 Oct 2012 09:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.846 X-Spam-Level: X-Spam-Status: No, score=-8.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR-SlDh-P8mB for ; Fri, 5 Oct 2012 09:26:57 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3005421F85C3 for ; Fri, 5 Oct 2012 09:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2184; q=dns/txt; s=iport; t=1349454417; x=1350664017; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=mVUj8DeBfBdjnwAT220ENd2Zk6PIf1qSrguWwGqs6MI=; b=R2Tv/77rIFTbgmpU/2EOV8rLSOpTKzZ6vrLTO/5A2/fqUgDGYmRIgXPh iyKV4jBMfJgmYtNcNmVH/NuKv43DVMmoeyMgZC6/Sxjeq9kDSgqImBB3h 8LD0MQ1gawJ4KCBVU4dyK0F1uwame5fsalByBGbi0TC6Bq2/jNq5mEgci 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJMJb1CtJV2a/2dsb2JhbABFhhC4E36BCIIgAQEBAwESASFKBwYBCBEEAQEBBAYdBQQwFAkIAgQBEggah10GmEuNFAWSeIEciiKEcjdgA6QwgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="128731550" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 05 Oct 2012 16:26:56 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q95GQuIK023746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Oct 2012 16:26:56 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.134]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Fri, 5 Oct 2012 11:26:56 -0500 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , Henry Lum , "siprec@ietf.org" Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoxY88SI5GO/xmUuAE/BbmcNhaQ== Date: Fri, 5 Oct 2012 16:26:55 +0000 Message-ID: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.81.109] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19242.001 x-tm-as-result: No--42.866800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="euc-kr" Content-ID: <8E88331E4FA2034395BC2F660F1CD529@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2012 16:26:58 -0000 PiBPbiAwNS8xMC8xMiA5OjMxIFBNLCAiSHV0dG9uLCBBbmRyZXciDQo+PGFuZHJldy5odXR0b25A c2llbWVucy1lbnRlcnByaXNlLmNvbT4gd3JvdGU6DQoNCj5IaSBSYW0sDQo+DQo+V2UgZG8gbWFr ZSBUTFMgc3VwcG9ydCBieSB0aGUgU1JDIGFuZCBTUlMgYSBNVVNUIHJlcXVpcmVtZW50IGluIHRo ZQ0KPnByb3RvY29sIGRyYWZ0IGFuZCBJIHRoaW5rIHRoaXMgaXMgdGhlIGNvcnJlY3QgdGhpbmcg dG8gZG8uIFNvIGl0IGlzDQo+bWFuZGF0b3J5IHRvIGltcGxlbWVudCBidXQgbm90IG1hbmRhdG9y eSB0byB1c2UuIEl0IGhhcyB0byBiZSBsaWtlIHRoYXQNCj5vdGhlcndpc2Ugd2UgY291bGQgbm90 IHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50IHRvIG1ha2UgdGhlIFJTIGF0IGxlYXN0IGFzDQo+c2Vj dXJlIGFzIHRoZSBDUy4NCg0KT2sgc291bmRzIGZpbmUuDQoNClRoYW5rcywNClJhbQ0KDQo+DQo+ UmVnYXJkcw0KPkFuZHkNCj4NCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PiBGcm9tOiBSYW0gTW9oYW4gUiAocm1vaGFucikgW21haWx0bzpybW9oYW5yQGNpc2NvLmNvbV0N Cj4+IFNlbnQ6IDAzIE9jdG9iZXIgMjAxMiAxODozMw0KPj4gVG86IEhlbnJ5IEx1bTsgSHV0dG9u LCBBbmRyZXc7IHNpcHJlY0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzaXByZWNdIFByb3Bv c2VkIHRleHQgZm9yIHNlY3VyaXR5IHNlY3Rpb24gaW4gc2lwcmVjLQ0KPj4gcHJvdG9jb2wNCj4+ IA0KPj4gPiBPbiAwMS8xMC8xMiA5OjUxIFBNLCAiSGVucnkgTHVtIiA8SGVucnkuTHVtQGdlbmVz eXNsYWIuY29tPiB3cm90ZToNCj4+IA0KPj4gPj5DYW4gd2UgbWFrZSBhIGZpcm0gcmVjb21tZW5k YXRpb24gdG8gc2VjdXJlIHVzaW5nIFRMUyBhbmQgbm90IHJlZmVyDQo+PiB0bw0KPj4gPlMvTUlN RQ0KPj4gPj5hdCBhbGw/DQo+PiA+W0hlbnJ5XSBJIGFtIG9rYXkgd2l0aCB0aGF0IGFuZCBwcmVm ZXIgb25seSB1c2luZyBUTFMgdG9vIDopIEkNCj4+IHJlZmVyZW5jZQ0KPj4gPlMvTUlNRSBzaW5j ZSBpdCB3YXMgbWVudGlvbmVkIGluIFJGQzMyNjEgYXMgYSB3YXkgdG8gcHJvdGVjdCB0aGUNCj4+ ID5jb250ZW50LCBidXQgdGhlbiBpdCdzIHdlaXJkIHRoYXQgeW91IG9ubHkgcHJvdGVjdCBtZXRh ZGF0YSBhbmQgbm90DQo+PiB0aGUNCj4+ID5yZXN0IG9mIHRoZSBjb250ZW50LCB1bmxlc3MgeW91 IGRvbid0IHdhbnQgYW55IHByb3hpZXMgaW4gYmV0d2VlbiB0bw0KPj4gc2VlDQo+PiA+dGhlIG1l dGFkYXRhLiBBbnlvbmUgb2JqZWN0IHRvIHJlbW92aW5nIHRoaXM/DQo+PiANCj4+IElmIG1hbmRh dGluZyBUTFMgYmV0d2VlbiBTUkMgYW5kIFNSUyBpcyB0aGUgaW50ZW50IGhlcmUsIEkgZG9uqfZ0 IHRoaW5rDQo+PiB3ZQ0KPj4gY2FuIG1hbmRhdGUgdGhhdC4gT2YgY291cnNlIHdlIGNhbiBhZGQg YSByZWNvbW1lbmRhdGlvbiBzYXlpbmcgZm9yDQo+PiBkZXBsb3ltZW50cyB3aGVyZSBTUkMgYW5k IFNSUyBhcmUgaW4gZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIGRvbWFpbnMNCj4+IGl0DQo+PiBp cyBoaWdobHkgcmVjb21tZW5kZWQgdG8gdXNlIFRMUy4NCj4+IA0KPj4gUmFtDQo+DQo+DQoNCg0K From pkyzivat@alum.mit.edu Fri Oct 5 13:14:44 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 0565921F8670 for ; Fri, 5 Oct 2012 13:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdqg4Q6auNND for ; Fri, 5 Oct 2012 13:14:43 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A3D3821F8647 for ; Fri, 5 Oct 2012 13:14:42 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id 7Ryt1k0070ldTLk53YElLy; Fri, 05 Oct 2012 20:14:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 7Y9X1k00b3ZTu2S3QY9Xf2; Fri, 05 Oct 2012 20:09:31 +0000 Message-ID: <506F3E83.2020307@alum.mit.edu> Date: Fri, 05 Oct 2012 16:09:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> <8E66DB23B8154FC89802B2DA6B5B509C@VOXSTORSERVER> In-Reply-To: <8E66DB23B8154FC89802B2DA6B5B509C@VOXSTORSERVER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] SIPREC captures X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2012 20:14:44 -0000 IMO there is a great need for more examples, done by different people, rather than just having ones done by the authors of the schema. It is really important to get different interpretations to expose ambiguities, etc. Ideally we would have examples that are done as captures from real implementations. But it would also be helpful to have samples constructed by hand for interesting cases. Once we get some of those it's important that they be widely reviewed. Two kinds of reviews are both of interest: - a review from the perspective of an SRS implementer - commenting on whether the example looks correct, semantically clear, and able to be supported by an implementation. - a review from the perspective of an SRC implementer - commenting on differences from how the reviewer would have represented the same case, and whether the differences are both reasonable alternatives, which (if any) is preferable, and whether it makes sense to have both alternatives. Thanks, Paul On 10/3/12 12:14 PM, Simon Farrow wrote: > I am just reposting this request as this would very useful to us as well. > Simon > > ------------------------------------------------------------------------ > *From:* siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Leon Portman > *Sent:* Tuesday, October 02, 2012 6:15 AM > *To:* Dave Higton > *Cc:* siprec@ietf.org > *Subject:* Re: [siprec] SIPREC captures > > On Oct 2, 2012 3:12 PM, "Dave Higton" > wrote: > > Can anyone point me at, or send me, some SIPREC captures, please? > PCAP format preferred, but text of the SIPREC commands and > responses would do.____ > > ____ > > Thank you,____ > > ____ > > Dave____ > > ____ > > > _______________________________________________ > siprec mailing 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 Oct 8 15:32: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 5E5EF21F87BE for ; Mon, 8 Oct 2012 15:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx5-s3k7zCh6 for ; Mon, 8 Oct 2012 15:32:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 044D521F87CC for ; Mon, 8 Oct 2012 15:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2359; q=dns/txt; s=iport; t=1349735558; x=1350945158; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7yoSD2DHR27GreHpPbkWqF102egCMRtgXlS3kJbpziY=; b=ekklIPRhKn7qlEGxtoW9jb2ZDCBnr6R0pVTyjvBaN0ZGzT2cknPfn9Yl 2cAbkTJEbrxJUALtsDUNoLHNGl2ZQ76Qu31eOG6Yfsg1q6MKOMjequZ+x TtQOCnKfIvXOm7N8gaTFV+5Fi6Fti2If9vmyz8NN4tFUqmPLEyiYMrF0r E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF9Tc1CtJXG8/2dsb2JhbABFvzGBCIIgAQEBBAEBAQ8BWxcEAgEIEQQBAQEKHQcnCxQJCAIEARIIGodiAQuaKp98BItHgzqBeWADiCOcDYFpgmANghc X-IronPort-AV: E=Sophos;i="4.80,556,1344211200"; d="scan'208";a="129524297" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 08 Oct 2012 22:32:37 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q98MWbQP015053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 22:32:37 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 17:32:37 -0500 From: "Charles Eckel (eckelcu)" To: "Ram Mohan R (rmohanr)" , "Hutton, Andrew" , Henry Lum , "siprec@ietf.org" Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: Ac2c+OuMs03xBiEJRUa4mlIqbj1ehAC5EJEAAARLKvAAcigegABhZAeAAADmX4AAmRGksA== Date: Mon, 8 Oct 2012 22:32:36 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.23] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--57.279500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2012 22:32:39 -0000 I agree with making TLS support a MUST. I am not as sure about SIPS.=20 To me, it is more important that TLS with SIP be supported than TLS with SI= PS. Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Ram Mohan R (rmohanr) > Sent: Friday, October 05, 2012 9:27 AM > To: Hutton, Andrew; Henry Lum; siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in siprec-protoc= ol >=20 > > On 05/10/12 9:31 PM, "Hutton, Andrew" > > wrote: >=20 > >Hi Ram, > > > >We do make TLS support by the SRC and SRS a MUST requirement in the > >protocol draft and I think this is the correct thing to do. So it is > >mandatory to implement but not mandatory to use. It has to be like that > >otherwise we could not support the requirement to make the RS at least a= s > >secure as the CS. >=20 > Ok sounds fine. >=20 > Thanks, > Ram >=20 > > > >Regards > >Andy > > > > > > > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> Sent: 03 October 2012 18:33 > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org > >> Subject: Re: [siprec] Proposed text for security section in siprec- > >> protocol > >> > >> > On 01/10/12 9:51 PM, "Henry Lum" > wrote: > >> > >> >>Can we make a firm recommendation to secure using TLS and not refer > >> to > >> >S/MIME > >> >>at all? > >> >[Henry] I am okay with that and prefer only using TLS too :) I > >> reference > >> >S/MIME since it was mentioned in RFC3261 as a way to protect the > >> >content, but then it's weird that you only protect metadata and not > >> the > >> >rest of the content, unless you don't want any proxies in between to > >> see > >> >the metadata. Anyone object to removing this? > >> > >> If mandating TLS between SRC and SRS is the intent here, I don=B9t thi= nk > >> we > >> can mandate that. Of course we can add a recommendation saying for > >> deployments where SRC and SRS are in different administrative domains > >> it > >> is highly recommended to use TLS. > >> > >> Ram > > > > >=20 >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec From andrew.hutton@siemens-enterprise.com Tue Oct 9 01:25: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 450BE21F87A2 for ; Tue, 9 Oct 2012 01:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDZkEJaqrm4a for ; Tue, 9 Oct 2012 01:25:38 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9414521F8746 for ; Tue, 9 Oct 2012 01:25:24 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 6EFE61EB8490; Tue, 9 Oct 2012 10:25:23 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 10:25:23 +0200 From: "Hutton, Andrew" To: "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , Henry Lum , "siprec@ietf.org" Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0SRlFTOq7/y0SQ+aCXjp5RvwC5EJEAAARLKvAAcigegABhZAeAAADmX4AAmRGksJefVPUQ Date: Tue, 9 Oct 2012 08:25:22 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 08:25:39 -0000 +1. Andy > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 08 October 2012 23:33 > To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org > Subject: RE: [siprec] Proposed text for security section in siprec- > protocol >=20 > I agree with making TLS support a MUST. I am not as sure about SIPS. > To me, it is more important that TLS with SIP be supported than TLS > with SIPS. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05, 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org > > Subject: Re: [siprec] Proposed text for security section in siprec- > protocol > > > > > On 05/10/12 9:31 PM, "Hutton, Andrew" > > > wrote: > > > > >Hi Ram, > > > > > >We do make TLS support by the SRC and SRS a MUST requirement in the > > >protocol draft and I think this is the correct thing to do. So it is > > >mandatory to implement but not mandatory to use. It has to be like > that > > >otherwise we could not support the requirement to make the RS at > least as > > >secure as the CS. > > > > Ok sounds fine. > > > > Thanks, > > Ram > > > > > > > >Regards > > >Andy > > > > > > > > > > > >> -----Original Message----- > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >> Sent: 03 October 2012 18:33 > > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org > > >> Subject: Re: [siprec] Proposed text for security section in > siprec- > > >> protocol > > >> > > >> > On 01/10/12 9:51 PM, "Henry Lum" > > wrote: > > >> > > >> >>Can we make a firm recommendation to secure using TLS and not > refer > > >> to > > >> >S/MIME > > >> >>at all? > > >> >[Henry] I am okay with that and prefer only using TLS too :) I > > >> reference > > >> >S/MIME since it was mentioned in RFC3261 as a way to protect the > > >> >content, but then it's weird that you only protect metadata and > not > > >> the > > >> >rest of the content, unless you don't want any proxies in between > to > > >> see > > >> >the metadata. Anyone object to removing this? > > >> > > >> If mandating TLS between SRC and SRS is the intent here, I don=B9t > think > > >> we > > >> can mandate that. Of course we can add a recommendation saying for > > >> deployments where SRC and SRS are in different administrative > domains > > >> it > > >> is highly recommended to use TLS. > > >> > > >> Ram > > > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec From rajnish.jain@ipc.com Tue Oct 9 01:57:04 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 5971121F886B for ; Tue, 9 Oct 2012 01:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K0kIiuvxOs4 for ; Tue, 9 Oct 2012 01:57:03 -0700 (PDT) Received: from p01c11o148.mxlogic.net (p01c11o148.mxlogic.net [208.65.144.71]) by ietfa.amsl.com (Postfix) with ESMTP id E8B7021F8864 for ; Tue, 9 Oct 2012 01:57:02 -0700 (PDT) Received: from unknown [65.244.37.52] (EHLO p01c11o148.mxlogic.net) by p01c11o148.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id ed6e3705.6cec9940.22602.00-559.41256.p01c11o148.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 02:57:02 -0600 (MDT) X-MXL-Hash: 5073e6de7c217c5e-b83a2f79cfb1cc824b6fa91b419abdd31983359e Received: from unknown [65.244.37.52] (EHLO mail.ipc.com) by p01c11o148.mxlogic.net(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id bd6e3705.0.22593.00-372.41239.p01c11o148.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 02:57:02 -0600 (MDT) X-MXL-Hash: 5073e6de746273f8-881622b5196e88832de652120d8fe472740df1c4 Received: from STSNYEXMBX2.corp.root.ipc.com ([fe80::157c:2ec6:ebe1:434b]) by STSNYEXHTCAS2.corp.root.ipc.com ([fe80::587a:3ab8:7c0b:6908%12]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 04:56:58 -0400 From: "Jain, Rajnish" To: "Hutton, Andrew" , "Charles Eckel (eckelcu)" , "Ram Mohan R (rmohanr)" , Henry Lum , "siprec@ietf.org" Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0S/oW4otRVB0G1cv9D6PjMnZeq3wQQgABNZ4CABR0qAIAApZ4A///B6yA= Date: Tue, 9 Oct 2012 08:56:58 +0000 Message-ID: <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.43.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=2.0 cv=YO8oP26x c=1 sm=0 a=D4USGbs0y0J827gn68Ljfg==:17 a] X-AnalysisOut: [=TI9zlQ3hUaoA:10 a=RDifYy2iUvAA:10 a=lCc8-jNt9F8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=vvKfUcg] X-AnalysisOut: [jAAAA:8 a=UopzfNgKjUQA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:] X-AnalysisOut: [8 a=ag3Orf1RAAAA:8 a=Tn40LXQWAAAA:8 a=FTWWKvgIrR_Wq6YMzFgA] X-AnalysisOut: [:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a] X-AnalysisOut: [=KwNp_X_GjOYA:10 a=Pw_wLAgS6uQA:10 a=o_4nq8umfotfuc6V:21 a] X-AnalysisOut: [=2mFfQMDLaW3pZBKq:21] Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 08:57:04 -0000 I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. I agr= ee that RS should be as secure as CS (and we should leave it that way).=20 I think most of the SRC/SRS deployments are going to be (as they currently = are) in Trust Domain governed by their own Spec(T). If we're going to manda= te TLS than are we also mandating which cipher suites SRC and SRS must impl= ement? I view siprec as an extension of the SIP protocol and not a mechanis= m for dictating security. Raj -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Tuesday, October 09, 2012 4:25 AM To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; siprec@ietf.= org Subject: Re: [siprec] Proposed text for security section in siprec-protocol +1. Andy > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 08 October 2012 23:33 > To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org > Subject: RE: [siprec] Proposed text for security section in siprec-=20 > protocol >=20 > I agree with making TLS support a MUST. I am not as sure about SIPS. > To me, it is more important that TLS with SIP be supported than TLS=20 > with SIPS. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05, 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org > > Subject: Re: [siprec] Proposed text for security section in siprec- > protocol > > > > > On 05/10/12 9:31 PM, "Hutton, Andrew" > > > wrote: > > > > >Hi Ram, > > > > > >We do make TLS support by the SRC and SRS a MUST requirement in the=20 > > >protocol draft and I think this is the correct thing to do. So it=20 > > >is mandatory to implement but not mandatory to use. It has to be=20 > > >like > that > > >otherwise we could not support the requirement to make the RS at > least as > > >secure as the CS. > > > > Ok sounds fine. > > > > Thanks, > > Ram > > > > > > > >Regards > > >Andy > > > > > > > > > > > >> -----Original Message----- > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >> Sent: 03 October 2012 18:33 > > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org > > >> Subject: Re: [siprec] Proposed text for security section in > siprec- > > >> protocol > > >> > > >> > On 01/10/12 9:51 PM, "Henry Lum" > > wrote: > > >> > > >> >>Can we make a firm recommendation to secure using TLS and not > refer > > >> to > > >> >S/MIME > > >> >>at all? > > >> >[Henry] I am okay with that and prefer only using TLS too :) I > > >> reference > > >> >S/MIME since it was mentioned in RFC3261 as a way to protect the=20 > > >> >content, but then it's weird that you only protect metadata and > not > > >> the > > >> >rest of the content, unless you don't want any proxies in=20 > > >> >between > to > > >> see > > >> >the metadata. Anyone object to removing this? > > >> > > >> If mandating TLS between SRC and SRS is the intent here, I don=B9t > think > > >> we > > >> can mandate that. Of course we can add a recommendation saying=20 > > >> for deployments where SRC and SRS are in different administrative > domains > > >> it > > >> is highly recommended to use TLS. > > >> > > >> Ram > > > > > > > > > > > > _______________________________________________ > > siprec mailing 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 mary.ietf.barnes@gmail.com Tue Oct 9 06:35: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 97FEE1F0C42 for ; Tue, 9 Oct 2012 06:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.346 X-Spam-Level: X-Spam-Status: No, score=-103.346 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0oAzqN6+AR6 for ; Tue, 9 Oct 2012 06:35:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1179711E8112 for ; Tue, 9 Oct 2012 06:35:12 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so4127453lbo.31 for ; Tue, 09 Oct 2012 06:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TqrrpYJXRL15BXSc5AIYkVkJ/xQU0dJ+vtNKU1N4wQw=; b=bAcVvMNZJv2OXAadkSivlwIsrk4ZyqfBA9C95YytRQtqe0yh51DtHaqpcULeImpXqY XSk3+oPYTl1HAMSJTMecUfYq/FA1GitgKlpnVvdCo3pSkbIoxy1bz9BgK77940Di1dYP v7WLh3gNj6ZNMHjfAmDjhfOlmUBrX9Es0TayN3KNKO+MAty7YyNaVffaFOL87HnBmsEw RI6BsFjO8fmf8PC3EsMBaN3rve9hxeqILfDuu7f82NVh5FvI7mjsOycyoyM015+VJsPU VSu/gIjk5ZLgFjLN8GHIiRP1ad891p68cUk4o40cONucrpwGPDd6UPh6kCB9Rm9jdfK5 qbAw== MIME-Version: 1.0 Received: by 10.152.108.66 with SMTP id hi2mr7084610lab.11.1349789711985; Tue, 09 Oct 2012 06:35:11 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 9 Oct 2012 06:35:11 -0700 (PDT) In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> Date: Tue, 9 Oct 2012 08:35:11 -0500 Message-ID: From: Mary Barnes To: "Jain, Rajnish" Content-Type: multipart/alternative; boundary=bcaec54eecc84deb0404cba0680b Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 13:35:14 -0000 --bcaec54eecc84deb0404cba0680b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Raj, This document won't get through the IESG/Secdir review without having a mandatory to implement security protocol. Spec(T) won't do anything to help you. That concept was introduced in the context of a specific P-header and is not a standard SIP concept. SIPREC is intended to be used in non-trusted domains and the protocol spec must have a mandatory to implement security protocol. Mary. On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish wrote: > I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. I > agree that RS should be as secure as CS (and we should leave it that way)= . > > I think most of the SRC/SRS deployments are going to be (as they currentl= y > are) in Trust Domain governed by their own Spec(T). If we're going to > mandate TLS than are we also mandating which cipher suites SRC and SRS mu= st > implement? I view siprec as an extension of the SIP protocol and not a > mechanism for dictating security. > > Raj > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Hutton, Andrew > Sent: Tuesday, October 09, 2012 4:25 AM > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; > siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in siprec-protoc= ol > > +1. > > Andy > > > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: 08 October 2012 23:33 > > To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org > > Subject: RE: [siprec] Proposed text for security section in siprec- > > protocol > > > > I agree with making TLS support a MUST. I am not as sure about SIPS. > > To me, it is more important that TLS with SIP be supported than TLS > > with SIPS. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > > Behalf > > > Of Ram Mohan R (rmohanr) > > > Sent: Friday, October 05, 2012 9:27 AM > > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org > > > Subject: Re: [siprec] Proposed text for security section in siprec- > > protocol > > > > > > > On 05/10/12 9:31 PM, "Hutton, Andrew" > > > > wrote: > > > > > > >Hi Ram, > > > > > > > >We do make TLS support by the SRC and SRS a MUST requirement in the > > > >protocol draft and I think this is the correct thing to do. So it > > > >is mandatory to implement but not mandatory to use. It has to be > > > >like > > that > > > >otherwise we could not support the requirement to make the RS at > > least as > > > >secure as the CS. > > > > > > Ok sounds fine. > > > > > > Thanks, > > > Ram > > > > > > > > > > >Regards > > > >Andy > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > >> Sent: 03 October 2012 18:33 > > > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org > > > >> Subject: Re: [siprec] Proposed text for security section in > > siprec- > > > >> protocol > > > >> > > > >> > On 01/10/12 9:51 PM, "Henry Lum" > > > wrote: > > > >> > > > >> >>Can we make a firm recommendation to secure using TLS and not > > refer > > > >> to > > > >> >S/MIME > > > >> >>at all? > > > >> >[Henry] I am okay with that and prefer only using TLS too :) I > > > >> reference > > > >> >S/MIME since it was mentioned in RFC3261 as a way to protect the > > > >> >content, but then it's weird that you only protect metadata and > > not > > > >> the > > > >> >rest of the content, unless you don't want any proxies in > > > >> >between > > to > > > >> see > > > >> >the metadata. Anyone object to removing this? > > > >> > > > >> If mandating TLS between SRC and SRS is the intent here, I don=B9t > > think > > > >> we > > > >> can mandate that. Of course we can add a recommendation saying > > > >> for deployments where SRC and SRS are in different administrative > > domains > > > >> it > > > >> is highly recommended to use TLS. > > > >> > > > >> Ram > > > > > > > > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > --bcaec54eecc84deb0404cba0680b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Raj,

This document won't get through the IESG/Secdir= review without having a mandatory to implement security protocol. =A0Spec(= T) won't do anything to help you. That concept was introduced in the co= ntext of a specific P-header and is not a standard SIP concept. =A0SIPREC i= s intended to be used in non-trusted domains and the protocol spec must hav= e a mandatory to implement security protocol.=A0

Mary.

On Tue, Oct 9, = 2012 at 3:56 AM, Jain, Rajnish <Rajnish.Jain@ipc.com> wro= te:
I'm not sure if SIP-over-TLS should be a= MUST requirement for siprec. I agree that RS should be as secure as CS (an= d we should leave it that way).

I think most of the SRC/SRS deployments are going to be (as they currently = are) in Trust Domain governed by their own Spec(T). If we're going to m= andate TLS than are we also mandating which cipher suites SRC and SRS must = implement? I view siprec as an extension of the SIP protocol and not a mech= anism for dictating security.

Raj

-----Original Message-----
From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.or= g] On Behalf Of Hutton, Andrew
Sent: Tuesday, October 09, 2012 4:25 AM
To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; siprec@ietf.org
Subject: Re: [siprec] Proposed text for security section in siprec-protocol=

+1.

Andy


> -----Original Message-----
> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
> Sent: 08 October 2012 23:33
> To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org
> Subject: RE: [siprec] Proposed text for security section in siprec- > protocol
>
> I agree with making TLS support a MUST. I am not as sure about SIPS. > To me, it is more important that TLS with SIP be supported than TLS > with SIPS.
>
> Cheers,
> Charles
>
> > -----Original Message-----
> > From: siprec-bounces@i= etf.org [mailto:siprec-bounc= es@ietf.org] On
> Behalf
> > Of Ram Mohan R (rmohanr)
> > Sent: Friday, October 05, 2012 9:27 AM
> > To: Hutton, Andrew; Henry Lum; siprec@ietf.org
> > Subject: Re: [siprec] Proposed text for security section in sipre= c-
> protocol
> >
> > > On 05/10/12 9:31 PM, "Hutton, Andrew"
> > ><a= ndrew.hutton@siemens-enterprise.com> wrote:
> >
> > >Hi Ram,
> > >
> > >We do make TLS support by the SRC and SRS a MUST requirement = in the
> > >protocol draft and I think this is the correct thing to do. S= o it
> > >is mandatory to implement but not mandatory to use. It has to= be
> > >like
> that
> > >otherwise we could not support the requirement to make the RS= at
> least as
> > >secure as the CS.
> >
> > Ok sounds fine.
> >
> > Thanks,
> > Ram
> >
> > >
> > >Regards
> > >Andy
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> > >> Sent: 03 October 2012 18:33
> > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org
> > >> Subject: Re: [siprec] Proposed text for security section= in
> siprec-
> > >> protocol
> > >>
> > >> > On 01/10/12 9:51 PM, "Henry Lum" <Henry.Lum@genesyslab.com> > > wrote:
> > >>
> > >> >>Can we make a firm recommendation to secure usin= g TLS and not
> refer
> > >> to
> > >> >S/MIME
> > >> >>at all?
> > >> >[Henry] I am okay with that and prefer only using TL= S too :) I
> > >> reference
> > >> >S/MIME since it was mentioned in RFC3261 as a way to= protect the
> > >> >content, but then it's weird that you only prote= ct metadata and
> not
> > >> the
> > >> >rest of the content, unless you don't want any p= roxies in
> > >> >between
> to
> > >> see
> > >> >the metadata. Anyone object to removing this?
> > >>
> > >> If mandating TLS between SRC and SRS is the intent here,= I don=B9t
> think
> > >> we
> > >> can mandate that. Of course we can add a recommendation = saying
> > >> for deployments where SRC and SRS are in different admin= istrative
> domains
> > >> it
> > >> is highly recommended to use TLS.
> > >>
> > >> Ram
> > >
> > >
> >
> >
> > _______________________________________________
> > siprec mailing list
> > siprec@ietf.org
> > https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
siprec mailing list
siprec@ietf.org
= https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
siprec mailing list
siprec@ietf.org
= https://www.ietf.org/mailman/listinfo/siprec

--bcaec54eecc84deb0404cba0680b-- From prvs=1629beb40f=MSmith@dss-corp.com Tue Oct 9 07:03:44 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 DA72C21F85A8 for ; Tue, 9 Oct 2012 07:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojVLCBS4cVBe for ; Tue, 9 Oct 2012 07:03:44 -0700 (PDT) Received: from spam.dss-corp.com (spam.dss-corp.com [67.214.118.46]) by ietfa.amsl.com (Postfix) with ESMTP id D4DDE21F8588 for ; Tue, 9 Oct 2012 07:03:43 -0700 (PDT) Received: from spam.dss-corp.com (127.0.0.1) by spam.dss-corp.com (MlfMTA v3.2r9) id hegoi80171sm for ; Tue, 9 Oct 2012 10:13:55 -0400 (envelope-from ) Received: from exc.dss-corp.com ([192.168.1.5]) by spam.dss-corp.com (SonicWALL 7.2.4.3929) with ESMTP; Tue, 09 Oct 2012 10:13:55 -0400 Received: from EXC01.dss.lan ([fe80::109b:ad4:1a47:2813]) by exc01.dss.lan ([fe80::109b:ad4:1a47:2813%13]) with mapi; Tue, 9 Oct 2012 10:03:41 -0400 From: Michael Smith To: "siprec@ietf.org" Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0W4YQKrvkIbU6V+Mi4Ztp50perJTiAgAAHM4CABR0qAIAApZ4AgAAI1ACAABCo8A== Date: Tue, 9 Oct 2012 14:03:33 +0000 Message-ID: <05D56509F27CCE4DAF8136C02386880D8D5B81CB@exc01.dss.lan> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 7.2.4.3929 X-Mlf-UniqueId: o201210091413540090664 Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 14:03:45 -0000 Correct me if I'm wrong, but I think the proposal is that SIP-over-TLS must= be supported by the SRC and SRS, but use of it on an RS is only mandatory = when the CS is using it. Is that correct? If so, that seems reasonable and = advisable. Michael Smith (APCO/NENA NG9-1-1 PSAP WG co-leader) Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243=20 DSS Corporation / Equature 18311=A0=A0 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.dss-corp.com www.dispatchimprovement.com -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Jain, Rajnish Sent: Tuesday, October 09, 2012 4:57 AM To: Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry L= um; siprec@ietf.org Subject: Re: [siprec] Proposed text for security section in siprec-protocol I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. I agr= ee that RS should be as secure as CS (and we should leave it that way).=20 I think most of the SRC/SRS deployments are going to be (as they currently = are) in Trust Domain governed by their own Spec(T). If we're going to manda= te TLS than are we also mandating which cipher suites SRC and SRS must impl= ement? I view siprec as an extension of the SIP protocol and not a mechanis= m for dictating security. Raj -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Tuesday, October 09, 2012 4:25 AM To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; siprec@ietf.= org Subject: Re: [siprec] Proposed text for security section in siprec-protocol +1. Andy > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 08 October 2012 23:33 > To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org > Subject: RE: [siprec] Proposed text for security section in siprec-=20 > protocol >=20 > I agree with making TLS support a MUST. I am not as sure about SIPS. > To me, it is more important that TLS with SIP be supported than TLS=20 > with SIPS. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05, 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org > > Subject: Re: [siprec] Proposed text for security section in siprec- > protocol > > > > > On 05/10/12 9:31 PM, "Hutton, Andrew" > > > wrote: > > > > >Hi Ram, > > > > > >We do make TLS support by the SRC and SRS a MUST requirement in the=20 > > >protocol draft and I think this is the correct thing to do. So it=20 > > >is mandatory to implement but not mandatory to use. It has to be=20 > > >like > that > > >otherwise we could not support the requirement to make the RS at > least as > > >secure as the CS. > > > > Ok sounds fine. > > > > Thanks, > > Ram > > > > > > > >Regards > > >Andy > > > > > > > > > > > >> -----Original Message----- > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >> Sent: 03 October 2012 18:33 > > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org > > >> Subject: Re: [siprec] Proposed text for security section in > siprec- > > >> protocol > > >> > > >> > On 01/10/12 9:51 PM, "Henry Lum" > > wrote: > > >> > > >> >>Can we make a firm recommendation to secure using TLS and not > refer > > >> to > > >> >S/MIME > > >> >>at all? > > >> >[Henry] I am okay with that and prefer only using TLS too :) I > > >> reference > > >> >S/MIME since it was mentioned in RFC3261 as a way to protect the=20 > > >> >content, but then it's weird that you only protect metadata and > not > > >> the > > >> >rest of the content, unless you don't want any proxies in=20 > > >> >between > to > > >> see > > >> >the metadata. Anyone object to removing this? > > >> > > >> If mandating TLS between SRC and SRS is the intent here, I don=B9t > think > > >> we > > >> can mandate that. Of course we can add a recommendation saying=20 > > >> for deployments where SRC and SRS are in different administrative > domains > > >> it > > >> is highly recommended to use TLS. > > >> > > >> Ram > > > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing 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 Oct 9 10:43: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 4BC061F0CAB for ; Tue, 9 Oct 2012 10:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9mOFQm4OtWK for ; Tue, 9 Oct 2012 10:43:34 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 638991F0C9B for ; Tue, 9 Oct 2012 10:43:34 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta08.westchester.pa.mail.comcast.net with comcast id 93n51k0051wpRvQ585jeas; Tue, 09 Oct 2012 17:43:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 95wB1k00x3ZTu2S3e5wCh6; Tue, 09 Oct 2012 17:56:12 +0000 Message-ID: <50746119.4070307@alum.mit.edu> Date: Tue, 09 Oct 2012 13:38:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 17:43:36 -0000 On 10/9/12 4:56 AM, Jain, Rajnish wrote: > I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. I agree that RS should be as secure as CS (and we should leave it that way). > > I think most of the SRC/SRS deployments are going to be (as they currently are) in Trust Domain governed by their own Spec(T). If we're going to mandate TLS than are we also mandating which cipher suites SRC and SRS must implement? I view siprec as an extension of the SIP protocol and not a mechanism for dictating security. So, are you saying that there can be a valid implementation that doesn't support TLS if it only records calls that didn't use TLS? I guess that might be ok. Perhaps we should then add some wording that makes it explicit that if the SRC cannot establish an RS as secure as the CS it will not record the CS at all. Thanks, Paul > Raj > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew > Sent: Tuesday, October 09, 2012 4:25 AM > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in siprec-protocol > > +1. > > Andy > > >> -----Original Message----- >> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >> Sent: 08 October 2012 23:33 >> To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org >> Subject: RE: [siprec] Proposed text for security section in siprec- >> protocol >> >> I agree with making TLS support a MUST. I am not as sure about SIPS. >> To me, it is more important that TLS with SIP be supported than TLS >> with SIPS. >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf >>> Of Ram Mohan R (rmohanr) >>> Sent: Friday, October 05, 2012 9:27 AM >>> To: Hutton, Andrew; Henry Lum; siprec@ietf.org >>> Subject: Re: [siprec] Proposed text for security section in siprec- >> protocol >>> >>>> On 05/10/12 9:31 PM, "Hutton, Andrew" >>>> wrote: >>> >>>> Hi Ram, >>>> >>>> We do make TLS support by the SRC and SRS a MUST requirement in the >>>> protocol draft and I think this is the correct thing to do. So it >>>> is mandatory to implement but not mandatory to use. It has to be >>>> like >> that >>>> otherwise we could not support the requirement to make the RS at >> least as >>>> secure as the CS. >>> >>> Ok sounds fine. >>> >>> Thanks, >>> Ram >>> >>>> >>>> Regards >>>> Andy >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>>>> Sent: 03 October 2012 18:33 >>>>> To: Henry Lum; Hutton, Andrew; siprec@ietf.org >>>>> Subject: Re: [siprec] Proposed text for security section in >> siprec- >>>>> protocol >>>>> >>>>>> On 01/10/12 9:51 PM, "Henry Lum" >>> wrote: >>>>> >>>>>>> Can we make a firm recommendation to secure using TLS and not >> refer >>>>> to >>>>>> S/MIME >>>>>>> at all? >>>>>> [Henry] I am okay with that and prefer only using TLS too :) I >>>>> reference >>>>>> S/MIME since it was mentioned in RFC3261 as a way to protect the >>>>>> content, but then it's weird that you only protect metadata and >> not >>>>> the >>>>>> rest of the content, unless you don't want any proxies in >>>>>> between >> to >>>>> see >>>>>> the metadata. Anyone object to removing this? >>>>> >>>>> If mandating TLS between SRC and SRS is the intent here, I don¹t >> think >>>>> we >>>>> can mandate that. Of course we can add a recommendation saying >>>>> for deployments where SRC and SRS are in different administrative >> domains >>>>> it >>>>> is highly recommended to use TLS. >>>>> >>>>> Ram >>>> >>>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From rajnish.jain@ipc.com Tue Oct 9 12:17: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 5F7CB11E8110 for ; Tue, 9 Oct 2012 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1jZlaYxwWbC for ; Tue, 9 Oct 2012 12:17:22 -0700 (PDT) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by ietfa.amsl.com (Postfix) with ESMTP id EAD4811E80ED for ; Tue, 9 Oct 2012 12:17:21 -0700 (PDT) Received: from unknown [65.244.37.52] (EHLO p01c11o144.mxlogic.net) by p01c11o144.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id 14874705.54f1b940.24145.00-570.60816.p01c11o144.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 13:17:21 -0600 (MDT) X-MXL-Hash: 50747841736f2218-1d51315f573ea50196acbfe0bb55144bfa9dfa8f Received: from unknown [65.244.37.52] (EHLO mail.ipc.com) by p01c11o144.mxlogic.net(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f3874705.0.24114.00-343.60729.p01c11o144.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 13:17:21 -0600 (MDT) X-MXL-Hash: 5074784126e8c748-363bb9148adcda248793dde356cd2dfb137a7ba4 Received: from STSNYEXMBX2.corp.root.ipc.com ([fe80::157c:2ec6:ebe1:434b]) by STSNYEXHTCAS2.corp.root.ipc.com ([fe80::587a:3ab8:7c0b:6908%12]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 15:17:18 -0400 From: "Jain, Rajnish" To: Mary Barnes Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0S/oW4otRVB0G1cv9D6PjMnZeq3wQQgABNZ4CABR0qAIAApZ4A///B6yCAAJSlgIAAFEtQ Date: Tue, 9 Oct 2012 19:17:17 +0000 Message-ID: <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.43.75] Content-Type: multipart/alternative; boundary="_000_4C91F9B607136D48AE3411BDC594D2AE0F37CBC6STSNYEXMBX2corp_" MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=2.0 cv=Q4BlFfKa c=1 sm=0 a=D4USGbs0y0J827gn68Ljfg==:17 a] X-AnalysisOut: [=TI9zlQ3hUaoA:10 a=RDifYy2iUvAA:10 a=lCc8-jNt9F8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=xqWC_Br6kY4A:10 a=vvKfUcgjAAAA:8 a=UopzfNgK] X-AnalysisOut: [jUQA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8] X-AnalysisOut: [ a=ag3Orf1RAAAA:8 a=Tn40LXQWAAAA:8 a=qHpt-Nrc73z-MUfq884A:] X-AnalysisOut: [9 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [OeN1TrMypwAA:10 a=JfD0Fch1gWkA:10 a=KwNp_X_GjOYA:10 a=Pw_w] X-AnalysisOut: [LAgS6uQA:10 a=5e-Vwoi-zABu6LgL:21 a=7uICO5Jt2hzfSb1q:21 a=] X-AnalysisOut: [yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=9iJ4AB3GigQ5r_XxkBUA:9 a] X-AnalysisOut: [=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz] X-AnalysisOut: [4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=1p6_GbLOHFR8rlYr:21 a=7Ru] X-AnalysisOut: [Y3FAAzttPZKQK:21 a=NnmfcdJxBdsk3Z_U:21] Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 19:17:26 -0000 --_000_4C91F9B607136D48AE3411BDC594D2AE0F37CBC6STSNYEXMBX2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, Understand. I think we can address this with correct wording. The idea woul= d be to not compromise security (RS must be as secure as CS - no more no le= ss). Thanks, Raj From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Tuesday, October 09, 2012 9:35 AM To: Jain, Rajnish Cc: Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry L= um; siprec@ietf.org Subject: Re: [siprec] Proposed text for security section in siprec-protocol Raj, This document won't get through the IESG/Secdir review without having a man= datory to implement security protocol. Spec(T) won't do anything to help y= ou. That concept was introduced in the context of a specific P-header and i= s not a standard SIP concept. SIPREC is intended to be used in non-trusted= domains and the protocol spec must have a mandatory to implement security = protocol. Mary. On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish > wrote: I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. I agr= ee that RS should be as secure as CS (and we should leave it that way). I think most of the SRC/SRS deployments are going to be (as they currently = are) in Trust Domain governed by their own Spec(T). If we're going to manda= te TLS than are we also mandating which cipher suites SRC and SRS must impl= ement? I view siprec as an extension of the SIP protocol and not a mechanis= m for dictating security. Raj -----Original Message----- From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of Hutton, An= drew Sent: Tuesday, October 09, 2012 4:25 AM To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; siprec@ietf.= org Subject: Re: [siprec] Proposed text for security section in siprec-protocol +1. Andy > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 08 October 2012 23:33 > To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org > Subject: RE: [siprec] Proposed text for security section in siprec- > protocol > > I agree with making TLS support a MUST. I am not as sure about SIPS. > To me, it is more important that TLS with SIP be supported than TLS > with SIPS. > > Cheers, > Charles > > > -----Original Message----- > > From: siprec-bounces@ietf.org [mailto:s= iprec-bounces@ietf.org] On > Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05, 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org > > Subject: Re: [siprec] Proposed text for security section in siprec- > protocol > > > > > On 05/10/12 9:31 PM, "Hutton, Andrew" > > >> wrote: > > > > >Hi Ram, > > > > > >We do make TLS support by the SRC and SRS a MUST requirement in the > > >protocol draft and I think this is the correct thing to do. So it > > >is mandatory to implement but not mandatory to use. It has to be > > >like > that > > >otherwise we could not support the requirement to make the RS at > least as > > >secure as the CS. > > > > Ok sounds fine. > > > > Thanks, > > Ram > > > > > > > >Regards > > >Andy > > > > > > > > > > > >> -----Original Message----- > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >> Sent: 03 October 2012 18:33 > > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org > > >> Subject: Re: [siprec] Proposed text for security section in > siprec- > > >> protocol > > >> > > >> > On 01/10/12 9:51 PM, "Henry Lum" > > > wrote: > > >> > > >> >>Can we make a firm recommendation to secure using TLS and not > refer > > >> to > > >> >S/MIME > > >> >>at all? > > >> >[Henry] I am okay with that and prefer only using TLS too :) I > > >> reference > > >> >S/MIME since it was mentioned in RFC3261 as a way to protect the > > >> >content, but then it's weird that you only protect metadata and > not > > >> the > > >> >rest of the content, unless you don't want any proxies in > > >> >between > to > > >> see > > >> >the metadata. Anyone object to removing this? > > >> > > >> If mandating TLS between SRC and SRS is the intent here, I don=B9t > think > > >> we > > >> can mandate that. Of course we can add a recommendation saying > > >> for deployments where SRC and SRS are in different administrative > domains > > >> it > > >> is highly recommended to use TLS. > > >> > > >> Ram > > > > > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------------------ DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. --_000_4C91F9B607136D48AE3411BDC594D2AE0F37CBC6STSNYEXMBX2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mary,

 <= /p>

Understand. I think we ca= n address this with correct wording. The idea would be to not compromise se= curity (RS must be as secure as CS – no more no less).

 <= /p>

Thanks,=

Raj

 <= /p>

From: Mary Bar= nes [mailto:mary.ietf.barnes@gmail.com]
Sent: Tuesday, October 09, 2012 9:35 AM
To: Jain, Rajnish
Cc: Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); = Henry Lum; siprec@ietf.org
Subject: Re: [siprec] Proposed text for security section in siprec-p= rotocol

 

Raj,

 

This document won't get through the IESG/Secdir revi= ew without having a mandatory to implement security protocol.  Spec(T)= won't do anything to help you. That concept was introduced in the context = of a specific P-header and is not a standard SIP concept.  SIPREC is intended to be used in non-trusted domains an= d the protocol spec must have a mandatory to implement security protocol.&n= bsp;

 

Mary.

On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish <Rajnish.Jain@ipc.co= m> wrote:

I'm not sure if SIP-over-TLS should be a MUST requir= ement for siprec. I agree that RS should be as secure as CS (and we should = leave it that way).

I think most of the SRC/SRS deployments are going to be (as they currently = are) in Trust Domain governed by their own Spec(T). If we're going to manda= te TLS than are we also mandating which cipher suites SRC and SRS must impl= ement? I view siprec as an extension of the SIP protocol and not a mechanism for dictating security.

Raj


-----Original Message-----
From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.or= g] On Behalf Of Hutton, Andrew
Sent: Tuesday, October 09, 2012 4:25 AM
To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; siprec@ietf.org
Subject: Re: [siprec] Proposed text for security section in siprec-protocol=

+1.

Andy


> -----Original Message-----
> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
> Sent: 08 October 2012 23:33
> To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org
> Subject: RE: [siprec] Proposed text for security section in siprec- > protocol
>
> I agree with making TLS support a MUST. I am not as sure about SIPS. > To me, it is more important that TLS with SIP be supported than TLS > with SIPS.
>
> Cheers,
> Charles
>
> > -----Original Message-----
> > From: siprec-bounces@i= etf.org [mailto:siprec-bounc= es@ietf.org] On
> Behalf
> > Of Ram Mohan R (rmohanr)
> > Sent: Friday, October 05, 2012 9:27 AM
> > To: Hutton, Andrew; Henry Lum; siprec@ietf.org
> > Subject: Re: [siprec] Proposed text for security section in sipre= c-
> protocol
> >
> > > On 05/10/12 9:31 PM, "Hutton, Andrew"
> > ><a= ndrew.hutton@siemens-enterprise.com> wrote:
> >
> > >Hi Ram,
> > >
> > >We do make TLS support by the SRC and SRS a MUST requirement = in the
> > >protocol draft and I think this is the correct thing to do. S= o it
> > >is mandatory to implement but not mandatory to use. It has to= be
> > >like
> that
> > >otherwise we could not support the requirement to make the RS= at
> least as
> > >secure as the CS.
> >
> > Ok sounds fine.
> >
> > Thanks,
> > Ram
> >
> > >
> > >Regards
> > >Andy
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> > >> Sent: 03 October 2012 18:33
> > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org
> > >> Subject: Re: [siprec] Proposed text for security section= in
> siprec-
> > >> protocol
> > >>
> > >> > On 01/10/12 9:51 PM, "Henry Lum" <Henry.Lum@genesyslab.com> > > wrote:
> > >>
> > >> >>Can we make a firm recommendation to secure usin= g TLS and not
> refer
> > >> to
> > >> >S/MIME
> > >> >>at all?
> > >> >[Henry] I am okay with that and prefer only using TL= S too :) I
> > >> reference
> > >> >S/MIME since it was mentioned in RFC3261 as a way to= protect the
> > >> >content, but then it's weird that you only protect m= etadata and
> not
> > >> the
> > >> >rest of the content, unless you don't want any proxi= es in
> > >> >between
> to
> > >> see
> > >> >the metadata. Anyone object to removing this?
> > >>
> > >> If mandating TLS between SRC and SRS is the intent here,= I don=B9t
> think
> > >> we
> > >> can mandate that. Of course we can add a recommendation = saying
> > >> for deployments where SRC and SRS are in different admin= istrative
> domains
> > >> it
> > >> is highly recommended to use TLS.
> > >>
> > >> Ram
> > >
> > >
> >
> >
> > _______________________________________________
> > siprec mailing list
> > siprec@ietf.org
> > https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
siprec mailing list
siprec@ietf.org
= https://www.ietf.org/mailman/listinfo/siprec
_______________________________________________
siprec mailing list
siprec@ietf.org
= https://www.ietf.org/mailman/listinfo/siprec

 

-----------------------------------------------= ---------------------------------------------------------------------------= ----------------------------------------------------------------

DISCLAIMER: This e-mai= l may contain information that is confidential, privileged or otherwise pro= tected from disclosure. If you are not an intended recipient of this e-mail= , do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender t= hat you have received it in error. Unintended recipients are prohibited fro= m taking action on the basis of information in this e-mail.E-mail messages = may contain computer viruses or other defects, may not be accurately replicated on other systems, or may b= e intercepted, deleted or interfered with without the knowledge of the send= er or the intended recipient. If you are not comfortable with the risks ass= ociated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the rig= ht, to the extent and under circumstances permitted by applicable law, to r= etain, monitor and intercept e-mail messages to and from its systems.


--_000_4C91F9B607136D48AE3411BDC594D2AE0F37CBC6STSNYEXMBX2corp_-- From pkyzivat@alum.mit.edu Tue Oct 9 12:41: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 6B3DA21F87B3 for ; Tue, 9 Oct 2012 12:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JI0Hb5v9ZFye for ; Tue, 9 Oct 2012 12:41:15 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 67C2321F8789 for ; Tue, 9 Oct 2012 12:41:15 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id 8zwr1k0050mv7h0597hK6a; Tue, 09 Oct 2012 19:41:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 97c51k01M3ZTu2S3X7c6ga; Tue, 09 Oct 2012 19:36:06 +0000 Message-ID: <50747CAD.7010805@alum.mit.edu> Date: Tue, 09 Oct 2012 15:36:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 19:41:16 -0000 Note that 3261 says proxies MUST implement TLS, while UAs are not required to. I think that implies that a UA that is acting as its own SRC should not be required to implement TLS, as long as it's consistent. A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probably can't depend on the 3261 requirement applying to it, but IMO we are justified in imposing that requirement on it as an SRC. IMO it makes sense to require an SRS to support TLS. Thanks, Paul On 10/9/12 3:17 PM, Jain, Rajnish wrote: > Mary, > > Understand. I think we can address this with correct wording. The idea > would be to not compromise security (RS must be as secure as CS – no > more no less). > > Thanks, > > Raj > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Tuesday, October 09, 2012 9:35 AM > *To:* Jain, Rajnish > *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); > Henry Lum; siprec@ietf.org > *Subject:* Re: [siprec] Proposed text for security section in > siprec-protocol > > Raj, > > This document won't get through the IESG/Secdir review without having a > mandatory to implement security protocol. Spec(T) won't do anything to > help you. That concept was introduced in the context of a specific > P-header and is not a standard SIP concept. SIPREC is intended to be > used in non-trusted domains and the protocol spec must have a mandatory > to implement security protocol. > > Mary. > > On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish > wrote: > > I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. I > agree that RS should be as secure as CS (and we should leave it that way). > > I think most of the SRC/SRS deployments are going to be (as they > currently are) in Trust Domain governed by their own Spec(T). If we're > going to mandate TLS than are we also mandating which cipher suites SRC > and SRS must implement? I view siprec as an extension of the SIP > protocol and not a mechanism for dictating security. > > Raj > > > -----Original Message----- > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org ] On > Behalf Of Hutton, Andrew > Sent: Tuesday, October 09, 2012 4:25 AM > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; > siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in siprec-protocol > > +1. > > Andy > > > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com > ] > > Sent: 08 October 2012 23:33 > > To: Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org > > > Subject: RE: [siprec] Proposed text for security section in siprec- > > protocol > > > > I agree with making TLS support a MUST. I am not as sure about SIPS. > > To me, it is more important that TLS with SIP be supported than TLS > > with SIPS. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org ] On > > Behalf > > > Of Ram Mohan R (rmohanr) > > > Sent: Friday, October 05, 2012 9:27 AM > > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org > > > Subject: Re: [siprec] Proposed text for security section in siprec- > > protocol > > > > > > > On 05/10/12 9:31 PM, "Hutton, Andrew" > > > > > wrote: > > > > > > >Hi Ram, > > > > > > > >We do make TLS support by the SRC and SRS a MUST requirement in the > > > >protocol draft and I think this is the correct thing to do. So it > > > >is mandatory to implement but not mandatory to use. It has to be > > > >like > > that > > > >otherwise we could not support the requirement to make the RS at > > least as > > > >secure as the CS. > > > > > > Ok sounds fine. > > > > > > Thanks, > > > Ram > > > > > > > > > > >Regards > > > >Andy > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com > ] > > > >> Sent: 03 October 2012 18:33 > > > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org > > > > >> Subject: Re: [siprec] Proposed text for security section in > > siprec- > > > >> protocol > > > >> > > > >> > On 01/10/12 9:51 PM, "Henry Lum" > > > > wrote: > > > >> > > > >> >>Can we make a firm recommendation to secure using TLS and not > > refer > > > >> to > > > >> >S/MIME > > > >> >>at all? > > > >> >[Henry] I am okay with that and prefer only using TLS too :) I > > > >> reference > > > >> >S/MIME since it was mentioned in RFC3261 as a way to protect the > > > >> >content, but then it's weird that you only protect metadata and > > not > > > >> the > > > >> >rest of the content, unless you don't want any proxies in > > > >> >between > > to > > > >> see > > > >> >the metadata. Anyone object to removing this? > > > >> > > > >> If mandating TLS between SRC and SRS is the intent here, I don¹t > > think > > > >> we > > > >> can mandate that. Of course we can add a recommendation saying > > > >> for deployments where SRC and SRS are in different administrative > > domains > > > >> it > > > >> is highly recommended to use TLS. > > > >> > > > >> Ram > > > > > > > > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > > > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it > by any means. Please delete it and any attachments and notify the sender > that you have received it in error. Unintended recipients are prohibited > from taking action on the basis of information in this e-mail.E-mail > messages may contain computer viruses or other defects, may not be > accurately replicated on other systems, or may be intercepted, deleted > or interfered with without the knowledge of the sender or the intended > recipient. If you are not comfortable with the risks associated with > e-mail messages, you may decide not to use e-mail to communicate with > IPC. IPC reserves the right, to the extent and under circumstances > permitted by applicable law, to retain, monitor and intercept e-mail > messages to and from its systems. > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From rajnish.jain@ipc.com Tue Oct 9 12:58: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 C930921F847C for ; Tue, 9 Oct 2012 12:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIs3ydfTd3lx for ; Tue, 9 Oct 2012 12:58:36 -0700 (PDT) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by ietfa.amsl.com (Postfix) with ESMTP id B18E221F8475 for ; Tue, 9 Oct 2012 12:58:32 -0700 (PDT) Received: from unknown [65.244.37.52] (EHLO p01c11o145.mxlogic.net) by p01c11o145.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id 8e184705.66c86940.99404.00-505.250283.p01c11o145.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 13:58:32 -0600 (MDT) X-MXL-Hash: 507481e825f605ad-70295ecd719838ed7822b976b61517d7564bbfc3 Received: from unknown [65.244.37.52] by p01c11o145.mxlogic.net(mxl_mta-6.15.0-1) with SMTP id 5e184705.0.99390.00-326.250242.p01c11o145.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 13:58:32 -0600 (MDT) X-MXL-Hash: 507481e84c4d959b-00c27b60ca54215a6ad5facf5b8890d10553d718 Received: from STSNYEXMBX2.corp.root.ipc.com ([fe80::157c:2ec6:ebe1:434b]) by STSNYEXHTCAS2.corp.root.ipc.com ([fe80::587a:3ab8:7c0b:6908%12]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 15:58:27 -0400 From: "Jain, Rajnish" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0S/oW4otRVB0G1cv9D6PjMnZeq3wQQgABNZ4CABR0qAIAApZ4A///B6yCAAJSlgIAAFEtQgABQlID//79PEA== Date: Tue, 9 Oct 2012 19:58:26 +0000 Message-ID: <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> <50747CAD.7010805@alum.mit.edu> In-Reply-To: <50747CAD.7010805@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.43.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=2.0 cv=G7+r5aY5 c=1 sm=0 a=D4USGbs0y0J827gn68Ljfg==:17 a] X-AnalysisOut: [=TI9zlQ3hUaoA:10 a=RDifYy2iUvAA:10 a=lCc8-jNt9F8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=vvKfUcg] X-AnalysisOut: [jAAAA:8 a=UopzfNgKjUQA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:] X-AnalysisOut: [8 a=AUd_NHdVAAAA:8 a=ag3Orf1RAAAA:8 a=Tn40LXQWAAAA:8 a=eWA] X-AnalysisOut: [KzPfVxP7R1RuRMNcA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [MSl-tDqOz04A:10 a=OeN1TrMypwAA:10 a=JfD0Fch1gWkA:10 a=KwNp] X-AnalysisOut: [_X_GjOYA:10 a=Pw_wLAgS6uQA:10 a=27H4tRzOqdtHYJP9:21 a=g0rl] X-AnalysisOut: [pGtiMhoqs57s:21] Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 19:58:36 -0000 Paul, I agree. I think it makes sense to require SRS (not SRC) to implement TLS (= drawing parallel to 3261). This way, TLS becomes optional to implement/use = in SRC (with the condition that RS must be as secure as CS). Thanks, Raj -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Tuesday, October 09, 2012 3:36 PM To: siprec@ietf.org Subject: Re: [siprec] Proposed text for security section in siprec-protocol Note that 3261 says proxies MUST implement TLS, while UAs are not required = to. I think that implies that a UA that is acting as its own SRC should not be = required to implement TLS, as long as it's consistent. A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probably ca= n't depend on the 3261 requirement applying to it, but IMO we are justified= in imposing that requirement on it as an SRC. IMO it makes sense to require an SRS to support TLS. Thanks, Paul On 10/9/12 3:17 PM, Jain, Rajnish wrote: > Mary, > > Understand. I think we can address this with correct wording. The idea=20 > would be to not compromise security (RS must be as secure as CS - no=20 > more no less). > > Thanks, > > Raj > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Tuesday, October 09, 2012 9:35 AM > *To:* Jain, Rajnish > *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 > Henry Lum; siprec@ietf.org > *Subject:* Re: [siprec] Proposed text for security section in=20 > siprec-protocol > > Raj, > > This document won't get through the IESG/Secdir review without having=20 > a mandatory to implement security protocol. Spec(T) won't do anything=20 > to help you. That concept was introduced in the context of a specific=20 > P-header and is not a standard SIP concept. SIPREC is intended to be=20 > used in non-trusted domains and the protocol spec must have a=20 > mandatory to implement security protocol. > > Mary. > > On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish > wrote: > > I'm not sure if SIP-over-TLS should be a MUST requirement for siprec.=20 > I agree that RS should be as secure as CS (and we should leave it that wa= y). > > I think most of the SRC/SRS deployments are going to be (as they=20 > currently are) in Trust Domain governed by their own Spec(T). If we're=20 > going to mandate TLS than are we also mandating which cipher suites=20 > SRC and SRS must implement? I view siprec as an extension of the SIP=20 > protocol and not a mechanism for dictating security. > > Raj > > > -----Original Message----- > From: siprec-bounces@ietf.org =20 > [mailto:siprec-bounces@ietf.org ] On=20 > Behalf Of Hutton, Andrew > Sent: Tuesday, October 09, 2012 4:25 AM > To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum;=20 > siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in=20 > siprec-protocol > > +1. > > Andy > > > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com=20 > ] > Sent: 08 October 2012 23:33 > To: Ram=20 > Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org=20 > > Subject: RE: [siprec] Proposed text for=20 > security section in siprec- > protocol > > I agree with making TLS=20 > support a MUST. I am not as sure about SIPS. > > To me, it is more important that TLS with SIP be supported than TLS =20 > > with SIPS. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: siprec-bounces@ietf.org =20 > [mailto:siprec-bounces@ietf.org ] On =20 > > Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05,=20 > 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org=20 > > > Subject: Re: [siprec] Proposed text for=20 > security section in siprec- > protocol > > > > > On 05/10/12 9:31=20 > PM, "Hutton, Andrew" > > > > > wrote: > > > > > > >Hi Ram, > > > > > > > >We do make TLS support by the SRC and SRS a MUST requirement in=20 > the > > >protocol draft and I think this is the correct thing to do.=20 > So it > > >is mandatory to implement but not mandatory to use. It has=20 > to be > > >like > that > > >otherwise we could not support the=20 > requirement to make the RS at > least as > > >secure as the CS. > > > > > > Ok sounds fine. > > > > > > Thanks, > > > Ram > > > > > > > > > > >Regards > > > >Andy > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com=20 > ] > > >> Sent: 03 October 2012 18:33 > >=20 > >> To: Henry Lum; Hutton, Andrew; siprec@ietf.org=20 > > > >> Subject: Re: [siprec] Proposed text=20 > for security section in > siprec- > > >> protocol > > >> > > >> >=20 > On 01/10/12 9:51 PM, "Henry Lum" > > > > wrote: > > > >> > > > >> >>Can we make a firm recommendation to secure using TLS and=20 > not > refer > > >> to > > >> >S/MIME > > >> >>at all? > > > >> >[Henry] I am okay with that and prefer only using TLS too :)=20 > I > > >> reference > > >> >S/MIME since it was mentioned in RFC3261=20 > as a way to protect the > > >> >content, but then it's weird that you=20 > only protect metadata and > not > > >> the > > >> >rest of the=20 > content, unless you don't want any proxies in > > >> >between > to =20 > > > >> see > > >> >the metadata. Anyone object to removing this? > > > >> > > > >> If mandating TLS between SRC and SRS is the intent here, I=20 > don=B9t > think > > >> we > > >> can mandate that. Of course we can=20 > add a recommendation saying > > >> for deployments where SRC and SRS=20 > are in different administrative > domains > > >> it > > >> is=20 > highly recommended to use TLS. > > > >> > > > >> Ram > > > > > > > > > > > > > > > > > _______________________________________________ > > > siprec mailing list > > > siprec@ietf.org > >=20 > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org =20 > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org =20 > https://www.ietf.org/mailman/listinfo/siprec > > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ---------------------------------------------- > > DISCLAIMER: This e-mail may contain information that is confidential,=20 > privileged or otherwise protected from disclosure. If you are not an=20 > intended recipient of this e-mail, do not duplicate or redistribute it=20 > by any means. Please delete it and any attachments and notify the=20 > sender that you have received it in error. Unintended recipients are=20 > prohibited from taking action on the basis of information in this=20 > e-mail.E-mail messages may contain computer viruses or other defects,=20 > may not be accurately replicated on other systems, or may be=20 > intercepted, deleted or interfered with without the knowledge of the=20 > sender or the intended recipient. If you are not comfortable with the=20 > risks associated with e-mail messages, you may decide not to use=20 > e-mail to communicate with IPC. IPC reserves the right, to the extent=20 > and under circumstances permitted by applicable law, to retain,=20 > monitor and intercept e-mail messages to and from its systems. > > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Tue Oct 9 13:23: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 96D1C1F0C69 for ; Tue, 9 Oct 2012 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0RgKlfiGeOU for ; Tue, 9 Oct 2012 13:22:47 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 44EC41F0C5F for ; Tue, 9 Oct 2012 13:22:45 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id 97hq1k0031c6gX85E8NpJf; Tue, 09 Oct 2012 20:22:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 98H71k00P3ZTu2S3j8H7P9; Tue, 09 Oct 2012 20:17:07 +0000 Message-ID: <50748667.6030404@alum.mit.edu> Date: Tue, 09 Oct 2012 16:17:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Jain, Rajnish" References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> <50747CAD.7010805@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 20:23:00 -0000 On 10/9/12 3:58 PM, Jain, Rajnish wrote: > Paul, > > I agree. I think it makes sense to require SRS (not SRC) to implement TLS (drawing parallel to 3261). This way, TLS becomes optional to implement/use in SRC (with the condition that RS must be as secure as CS). Note that I'm also proposing that we require a B2BUA acting as an SRC (e.g. an SBC or PBX) be required to support TLS. Another thing to consider is RS sessions initiated by an SRS. What if the SRS wants to use TLS? Thanks, Paul > Thanks, > Raj > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, October 09, 2012 3:36 PM > To: siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in siprec-protocol > > Note that 3261 says proxies MUST implement TLS, while UAs are not required to. > > I think that implies that a UA that is acting as its own SRC should not be required to implement TLS, as long as it's consistent. > > A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probably can't depend on the 3261 requirement applying to it, but IMO we are justified in imposing that requirement on it as an SRC. > > IMO it makes sense to require an SRS to support TLS. > > Thanks, > Paul > > On 10/9/12 3:17 PM, Jain, Rajnish wrote: >> Mary, >> >> Understand. I think we can address this with correct wording. The idea >> would be to not compromise security (RS must be as secure as CS - no >> more no less). >> >> Thanks, >> >> Raj >> >> *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> *Sent:* Tuesday, October 09, 2012 9:35 AM >> *To:* Jain, Rajnish >> *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); >> Henry Lum; siprec@ietf.org >> *Subject:* Re: [siprec] Proposed text for security section in >> siprec-protocol >> >> Raj, >> >> This document won't get through the IESG/Secdir review without having >> a mandatory to implement security protocol. Spec(T) won't do anything >> to help you. That concept was introduced in the context of a specific >> P-header and is not a standard SIP concept. SIPREC is intended to be >> used in non-trusted domains and the protocol spec must have a >> mandatory to implement security protocol. >> >> Mary. >> >> On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish > > wrote: >> >> I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. >> I agree that RS should be as secure as CS (and we should leave it that way). >> >> I think most of the SRC/SRS deployments are going to be (as they >> currently are) in Trust Domain governed by their own Spec(T). If we're >> going to mandate TLS than are we also mandating which cipher suites >> SRC and SRS must implement? I view siprec as an extension of the SIP >> protocol and not a mechanism for dictating security. >> >> Raj >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org ] On >> Behalf Of Hutton, Andrew >> Sent: Tuesday, October 09, 2012 4:25 AM >> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; >> siprec@ietf.org >> Subject: Re: [siprec] Proposed text for security section in >> siprec-protocol >> >> +1. >> >> Andy >> >> >> > -----Original Message----- >> > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com >> ] > Sent: 08 October 2012 23:33 > To: Ram >> Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org >> > Subject: RE: [siprec] Proposed text for >> security section in siprec- > protocol > > I agree with making TLS >> support a MUST. I am not as sure about SIPS. >> > To me, it is more important that TLS with SIP be supported than TLS >>> with SIPS. >> > >> > Cheers, >> > Charles >> > >> > > -----Original Message----- >> > > From: siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org ] On >>> Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05, >> 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org >> > > Subject: Re: [siprec] Proposed text for >> security section in siprec- > protocol > > > > > On 05/10/12 9:31 >> PM, "Hutton, Andrew" >> > > >> > wrote: >> > > >> > > >Hi Ram, >> > > > >> > > >We do make TLS support by the SRC and SRS a MUST requirement in >> the > > >protocol draft and I think this is the correct thing to do. >> So it > > >is mandatory to implement but not mandatory to use. It has >> to be > > >like > that > > >otherwise we could not support the >> requirement to make the RS at > least as > > >secure as the CS. >> > > >> > > Ok sounds fine. >> > > >> > > Thanks, >> > > Ram >> > > >> > > > >> > > >Regards >> > > >Andy >> > > > >> > > > >> > > > >> > > >> -----Original Message----- >> > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com >> ] > > >> Sent: 03 October 2012 18:33 > > >>>> To: Henry Lum; Hutton, Andrew; siprec@ietf.org >> > > >> Subject: Re: [siprec] Proposed text >> for security section in > siprec- > > >> protocol > > >> > > >> > >> On 01/10/12 9:51 PM, "Henry Lum" > > >> > > wrote: >> > > >> >> > > >> >>Can we make a firm recommendation to secure using TLS and >> not > refer > > >> to > > >> >S/MIME > > >> >>at all? >> > > >> >[Henry] I am okay with that and prefer only using TLS too :) >> I > > >> reference > > >> >S/MIME since it was mentioned in RFC3261 >> as a way to protect the > > >> >content, but then it's weird that you >> only protect metadata and > not > > >> the > > >> >rest of the >> content, unless you don't want any proxies in > > >> >between > to >>>>>> see > > >> >the metadata. Anyone object to removing this? >> > > >> >> > > >> If mandating TLS between SRC and SRS is the intent here, I >> don¹t > think > > >> we > > >> can mandate that. Of course we can >> add a recommendation saying > > >> for deployments where SRC and SRS >> are in different administrative > domains > > >> it > > >> is >> highly recommended to use TLS. >> > > >> >> > > >> Ram >> > > > >> > > > >> > > >> > > >> > > _______________________________________________ >> > > siprec mailing list >> > > siprec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> >> ---------------------------------------------------------------------- >> ---------------------------------------------------------------------- >> ---------------------------------------------- >> >> DISCLAIMER: This e-mail may contain information that is confidential, >> privileged or otherwise protected from disclosure. If you are not an >> intended recipient of this e-mail, do not duplicate or redistribute it >> by any means. Please delete it and any attachments and notify the >> sender that you have received it in error. Unintended recipients are >> prohibited from taking action on the basis of information in this >> e-mail.E-mail messages may contain computer viruses or other defects, >> may not be accurately replicated on other systems, or may be >> intercepted, deleted or interfered with without the knowledge of the >> sender or the intended recipient. If you are not comfortable with the >> risks associated with e-mail messages, you may decide not to use >> e-mail to communicate with IPC. IPC reserves the right, to the extent >> and under circumstances permitted by applicable law, to retain, >> monitor and intercept e-mail messages to and from its systems. >> >> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From rajnish.jain@ipc.com Tue Oct 9 14:19: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 2BC4D11E80B8 for ; Tue, 9 Oct 2012 14:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slVmHiGBtpdN for ; Tue, 9 Oct 2012 14:19:16 -0700 (PDT) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB3BC11E808A for ; Tue, 9 Oct 2012 14:19:15 -0700 (PDT) Received: from unknown [65.244.37.52] (EHLO p01c12o149.mxlogic.net) by p01c12o149.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id 3d494705.5b244940.70719.00-577.186405.p01c12o149.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 15:19:15 -0600 (MDT) X-MXL-Hash: 507494d304115445-d7c981b47c61e93cb4a9a3ed9ea9e42b575eb936 Received: from unknown [65.244.37.52] (EHLO mail.ipc.com) by p01c12o149.mxlogic.net(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 1d494705.0.70672.00-299.186327.p01c12o149.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 15:19:15 -0600 (MDT) X-MXL-Hash: 507494d32824f6e3-662fc7755f2d4c9841c76b938f50455e08f6bcb9 Received: from STSNYEXMBX2.corp.root.ipc.com ([fe80::157c:2ec6:ebe1:434b]) by STSNYEXHTCAS2.corp.root.ipc.com ([fe80::587a:3ab8:7c0b:6908%12]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 17:19:12 -0400 From: "Jain, Rajnish" To: Paul Kyzivat Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0S/oW4otRVB0G1cv9D6PjMnZeq3wQQgABNZ4CABR0qAIAApZ4A///B6yCAAJSlgIAAFEtQgABQlID//79PEIAATEmA///KMFA= Date: Tue, 9 Oct 2012 21:19:12 +0000 Message-ID: <4C91F9B607136D48AE3411BDC594D2AE0F37CCD9@STSNYEXMBX2.corp.root.ipc.com> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> <50747CAD.7010805@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> <50748667.6030404@alum.mit.edu> In-Reply-To: <50748667.6030404@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.43.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=2.0 cv=A4rbydqG c=1 sm=0 a=D4USGbs0y0J827gn68Ljfg==:17 a] X-AnalysisOut: [=TI9zlQ3hUaoA:10 a=RDifYy2iUvAA:10 a=lCc8-jNt9F8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=vvKfUcg] X-AnalysisOut: [jAAAA:8 a=UopzfNgKjUQA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:] X-AnalysisOut: [8 a=AUd_NHdVAAAA:8 a=ag3Orf1RAAAA:8 a=Tn40LXQWAAAA:8 a=Q9s] X-AnalysisOut: [WK1YnZj90Ol4O41kA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [MSl-tDqOz04A:10 a=OeN1TrMypwAA:10 a=JfD0Fch1gWkA:10 a=KwNp] X-AnalysisOut: [_X_GjOYA:10 a=Pw_wLAgS6uQA:10 a=FljnFT4CKuOlCMn8:21 a=5W4W] X-AnalysisOut: [UMrFvdlPBM1N:21] Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 21:19:17 -0000 Paul, Pls. see inline: > Note that I'm also proposing that we require a B2BUA acting as an SRC (e.= g. an SBC or PBX) be required to support TLS. [rj] That's fine. I don't know what a B2BUA is anymore (because most practi= cal server-side SIP implementations are some sort of UAs combined in some f= ashion). I don't know if you're referring to passive recording (sniffing me= dia and recording that media).=20 Another thing to consider is RS sessions initiated by an SRS. What if the SRS wants to use TLS? [rj] That's fine as well. In this case, the administrator has decided to us= e TLS between SRS and SRC. Pls. note that it is left to the administrator/i= mplementer to decide. Thanks, Raj > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: Tuesday, October 09, 2012 3:36 PM > To: siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in=20 > siprec-protocol > > Note that 3261 says proxies MUST implement TLS, while UAs are not require= d to. > > I think that implies that a UA that is acting as its own SRC should not b= e required to implement TLS, as long as it's consistent. > > A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probably = can't depend on the 3261 requirement applying to it, but IMO we are justifi= ed in imposing that requirement on it as an SRC. > > IMO it makes sense to require an SRS to support TLS. > > Thanks, > Paul > > On 10/9/12 3:17 PM, Jain, Rajnish wrote: >> Mary, >> >> Understand. I think we can address this with correct wording. The=20 >> idea would be to not compromise security (RS must be as secure as CS=20 >> - no more no less). >> >> Thanks, >> >> Raj >> >> *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> *Sent:* Tuesday, October 09, 2012 9:35 AM >> *To:* Jain, Rajnish >> *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr);=20 >> Henry Lum; siprec@ietf.org >> *Subject:* Re: [siprec] Proposed text for security section in=20 >> siprec-protocol >> >> Raj, >> >> This document won't get through the IESG/Secdir review without having=20 >> a mandatory to implement security protocol. Spec(T) won't do=20 >> anything to help you. That concept was introduced in the context of a=20 >> specific P-header and is not a standard SIP concept. SIPREC is=20 >> intended to be used in non-trusted domains and the protocol spec must=20 >> have a mandatory to implement security protocol. >> >> Mary. >> >> On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish > > wrote: >> >> I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. >> I agree that RS should be as secure as CS (and we should leave it that w= ay). >> >> I think most of the SRC/SRS deployments are going to be (as they=20 >> currently are) in Trust Domain governed by their own Spec(T). If=20 >> we're going to mandate TLS than are we also mandating which cipher=20 >> suites SRC and SRS must implement? I view siprec as an extension of=20 >> the SIP protocol and not a mechanism for dictating security. >> >> Raj >> >> >> -----Original Message----- >> From: siprec-bounces@ietf.org =20 >> [mailto:siprec-bounces@ietf.org ] On=20 >> Behalf Of Hutton, Andrew >> Sent: Tuesday, October 09, 2012 4:25 AM >> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum;=20 >> siprec@ietf.org >> Subject: Re: [siprec] Proposed text for security section in=20 >> siprec-protocol >> >> +1. >> >> Andy >> >> >> > -----Original Message----- >> > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com=20 >> ] > Sent: 08 October 2012 23:33 > To: Ram=20 >> Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org=20 >> > Subject: RE: [siprec] Proposed text for=20 >> security section in siprec- > protocol > > I agree with making TLS=20 >> support a MUST. I am not as sure about SIPS. >> > To me, it is more important that TLS with SIP be supported than=20 >> TLS >>> with SIPS. >> > >> > Cheers, >> > Charles >> > >> > > -----Original Message----- >> > > From: siprec-bounces@ietf.org =20 >> [mailto:siprec-bounces@ietf.org ] On >>> Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05, >> 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org=20 >> > > Subject: Re: [siprec] Proposed text for=20 >> security section in siprec- > protocol > > > > > On 05/10/12 9:31=20 >> PM, "Hutton, Andrew" >> > > >> > wrote: >> > > >> > > >Hi Ram, >> > > > >> > > >We do make TLS support by the SRC and SRS a MUST requirement=20 >> in the > > >protocol draft and I think this is the correct thing to do. >> So it > > >is mandatory to implement but not mandatory to use. It=20 >> has to be > > >like > that > > >otherwise we could not support the=20 >> requirement to make the RS at > least as > > >secure as the CS. >> > > >> > > Ok sounds fine. >> > > >> > > Thanks, >> > > Ram >> > > >> > > > >> > > >Regards >> > > >Andy >> > > > >> > > > >> > > > >> > > >> -----Original Message----- >> > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com=20 >> ] > > >> Sent: 03 October 2012 18:33 > > >>>> To: Henry Lum; Hutton, Andrew; siprec@ietf.org >> > > >> Subject: Re: [siprec] Proposed text=20 >> for security section in > siprec- > > >> protocol > > >> > > >> >=20 >> On 01/10/12 9:51 PM, "Henry Lum" > > >> > > wrote: >> > > >> >> > > >> >>Can we make a firm recommendation to secure using TLS and=20 >> not > refer > > >> to > > >> >S/MIME > > >> >>at all? >> > > >> >[Henry] I am okay with that and prefer only using TLS too=20 >> :) I > > >> reference > > >> >S/MIME since it was mentioned in=20 >> RFC3261 as a way to protect the > > >> >content, but then it's weird=20 >> that you only protect metadata and > not > > >> the > > >> >rest=20 >> of the content, unless you don't want any proxies in > > >> >between =20 >> > to >>>>>> see > > >> >the metadata. Anyone object to removing this? >> > > >> >> > > >> If mandating TLS between SRC and SRS is the intent here, I=20 >> don=B9t > think > > >> we > > >> can mandate that. Of course we can=20 >> add a recommendation saying > > >> for deployments where SRC and SRS=20 >> are in different administrative > domains > > >> it > > >> is=20 >> highly recommended to use TLS. >> > > >> >> > > >> Ram >> > > > >> > > > >> > > >> > > >> > > _______________________________________________ >> > > siprec mailing list >> > > siprec@ietf.org > >=20 >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/siprec >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/siprec >> >> --------------------------------------------------------------------- >> - >> --------------------------------------------------------------------- >> - >> ---------------------------------------------- >> >> DISCLAIMER: This e-mail may contain information that is confidential,=20 >> privileged or otherwise protected from disclosure. If you are not an=20 >> intended recipient of this e-mail, do not duplicate or redistribute=20 >> it by any means. Please delete it and any attachments and notify the=20 >> sender that you have received it in error. Unintended recipients are=20 >> prohibited from taking action on the basis of information in this=20 >> e-mail.E-mail messages may contain computer viruses or other defects,=20 >> may not be accurately replicated on other systems, or may be=20 >> intercepted, deleted or interfered with without the knowledge of the=20 >> sender or the intended recipient. If you are not comfortable with the=20 >> risks associated with e-mail messages, you may decide not to use=20 >> e-mail to communicate with IPC. IPC reserves the right, to the extent=20 >> and under circumstances permitted by applicable law, to retain,=20 >> monitor and intercept e-mail messages to and from its systems. >> >> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Tue Oct 9 14:55: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 A38BE1F0C95 for ; Tue, 9 Oct 2012 14:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JIJdABAqm0T for ; Tue, 9 Oct 2012 14:55:16 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8531F041C for ; Tue, 9 Oct 2012 14:55:16 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id 8yGE1k00B1YDfWL539vLcV; Tue, 09 Oct 2012 21:55:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 99pZ1k00C3ZTu2S3g9paD5; Tue, 09 Oct 2012 21:49:35 +0000 Message-ID: <50749C14.3040907@alum.mit.edu> Date: Tue, 09 Oct 2012 17:50:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Jain, Rajnish" References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> <50747CAD.7010805@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> <50748667.6030404@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CCD9@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F37CCD9@STSNYEXMBX2.corp.root.ipc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 21:55:17 -0000 On 10/9/12 5:19 PM, Jain, Rajnish wrote: > Paul, > > Pls. see inline: > >> Note that I'm also proposing that we require a B2BUA acting as an SRC (e.g. an SBC or PBX) be required to support TLS. > > [rj] That's fine. I don't know what a B2BUA is anymore (because most practical server-side SIP implementations are some sort of UAs combined in some fashion). I don't know if you're referring to passive recording (sniffing media and recording that media). If it terminates one dialog and initiates another, and keeps them connected in order to establish a single "call" then it's a B2BUA. That is true whether it terminates media or not. You can see the documents of the STRAW WG for more on current thinking about B2BUAs. An entirely passive recorder is out of scope for siprec. The SRC must be able to cause an indication of recording to be conveyed to the participants, either in the CS sip signaling or in the media to the participants. Thanks, Paul > Another thing to consider is RS sessions initiated by an SRS. > What if the SRS wants to use TLS? > > [rj] That's fine as well. In this case, the administrator has decided to use TLS between SRS and SRC. Pls. note that it is left to the administrator/implementer to decide. > > Thanks, > Raj > >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Tuesday, October 09, 2012 3:36 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Proposed text for security section in >> siprec-protocol >> >> Note that 3261 says proxies MUST implement TLS, while UAs are not required to. >> >> I think that implies that a UA that is acting as its own SRC should not be required to implement TLS, as long as it's consistent. >> >> A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probably can't depend on the 3261 requirement applying to it, but IMO we are justified in imposing that requirement on it as an SRC. >> >> IMO it makes sense to require an SRS to support TLS. >> >> Thanks, >> Paul >> >> On 10/9/12 3:17 PM, Jain, Rajnish wrote: >>> Mary, >>> >>> Understand. I think we can address this with correct wording. The >>> idea would be to not compromise security (RS must be as secure as CS >>> - no more no less). >>> >>> Thanks, >>> >>> Raj >>> >>> *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >>> *Sent:* Tuesday, October 09, 2012 9:35 AM >>> *To:* Jain, Rajnish >>> *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R (rmohanr); >>> Henry Lum; siprec@ietf.org >>> *Subject:* Re: [siprec] Proposed text for security section in >>> siprec-protocol >>> >>> Raj, >>> >>> This document won't get through the IESG/Secdir review without having >>> a mandatory to implement security protocol. Spec(T) won't do >>> anything to help you. That concept was introduced in the context of a >>> specific P-header and is not a standard SIP concept. SIPREC is >>> intended to be used in non-trusted domains and the protocol spec must >>> have a mandatory to implement security protocol. >>> >>> Mary. >>> >>> On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish >> > wrote: >>> >>> I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. >>> I agree that RS should be as secure as CS (and we should leave it that way). >>> >>> I think most of the SRC/SRS deployments are going to be (as they >>> currently are) in Trust Domain governed by their own Spec(T). If >>> we're going to mandate TLS than are we also mandating which cipher >>> suites SRC and SRS must implement? I view siprec as an extension of >>> the SIP protocol and not a mechanism for dictating security. >>> >>> Raj >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org ] On >>> Behalf Of Hutton, Andrew >>> Sent: Tuesday, October 09, 2012 4:25 AM >>> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; >>> siprec@ietf.org >>> Subject: Re: [siprec] Proposed text for security section in >>> siprec-protocol >>> >>> +1. >>> >>> Andy >>> >>> >>> > -----Original Message----- >>> > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com >>> ] > Sent: 08 October 2012 23:33 > To: Ram >>> Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org >>> > Subject: RE: [siprec] Proposed text for >>> security section in siprec- > protocol > > I agree with making TLS >>> support a MUST. I am not as sure about SIPS. >>> > To me, it is more important that TLS with SIP be supported than >>> TLS >>>> with SIPS. >>> > >>> > Cheers, >>> > Charles >>> > >>> > > -----Original Message----- >>> > > From: siprec-bounces@ietf.org >>> [mailto:siprec-bounces@ietf.org ] On >>>> Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05, >>> 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org >>> > > Subject: Re: [siprec] Proposed text for >>> security section in siprec- > protocol > > > > > On 05/10/12 9:31 >>> PM, "Hutton, Andrew" >>> > > >>> > wrote: >>> > > >>> > > >Hi Ram, >>> > > > >>> > > >We do make TLS support by the SRC and SRS a MUST requirement >>> in the > > >protocol draft and I think this is the correct thing to do. >>> So it > > >is mandatory to implement but not mandatory to use. It >>> has to be > > >like > that > > >otherwise we could not support the >>> requirement to make the RS at > least as > > >secure as the CS. >>> > > >>> > > Ok sounds fine. >>> > > >>> > > Thanks, >>> > > Ram >>> > > >>> > > > >>> > > >Regards >>> > > >Andy >>> > > > >>> > > > >>> > > > >>> > > >> -----Original Message----- >>> > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com >>> ] > > >> Sent: 03 October 2012 18:33 > > >>>>> To: Henry Lum; Hutton, Andrew; siprec@ietf.org >>> > > >> Subject: Re: [siprec] Proposed text >>> for security section in > siprec- > > >> protocol > > >> > > >> > >>> On 01/10/12 9:51 PM, "Henry Lum" >> > >>> > > wrote: >>> > > >> >>> > > >> >>Can we make a firm recommendation to secure using TLS and >>> not > refer > > >> to > > >> >S/MIME > > >> >>at all? >>> > > >> >[Henry] I am okay with that and prefer only using TLS too >>> :) I > > >> reference > > >> >S/MIME since it was mentioned in >>> RFC3261 as a way to protect the > > >> >content, but then it's weird >>> that you only protect metadata and > not > > >> the > > >> >rest >>> of the content, unless you don't want any proxies in > > >> >between >>>> to >>>>>>> see > > >> >the metadata. Anyone object to removing this? >>> > > >> >>> > > >> If mandating TLS between SRC and SRS is the intent here, I >>> don¹t > think > > >> we > > >> can mandate that. Of course we can >>> add a recommendation saying > > >> for deployments where SRC and SRS >>> are in different administrative > domains > > >> it > > >> is >>> highly recommended to use TLS. >>> > > >> >>> > > >> Ram >>> > > > >>> > > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > siprec mailing list >>> > > siprec@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> --------------------------------------------------------------------- >>> - >>> --------------------------------------------------------------------- >>> - >>> ---------------------------------------------- >>> >>> DISCLAIMER: This e-mail may contain information that is confidential, >>> privileged or otherwise protected from disclosure. If you are not an >>> intended recipient of this e-mail, do not duplicate or redistribute >>> it by any means. Please delete it and any attachments and notify the >>> sender that you have received it in error. Unintended recipients are >>> prohibited from taking action on the basis of information in this >>> e-mail.E-mail messages may contain computer viruses or other defects, >>> may not be accurately replicated on other systems, or may be >>> intercepted, deleted or interfered with without the knowledge of the >>> sender or the intended recipient. If you are not comfortable with the >>> risks associated with e-mail messages, you may decide not to use >>> e-mail to communicate with IPC. IPC reserves the right, to the extent >>> and under circumstances permitted by applicable law, to retain, >>> monitor and intercept e-mail messages to and from its systems. >>> >>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > From rajnish.jain@ipc.com Tue Oct 9 16:07: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 892C711E80D5 for ; Tue, 9 Oct 2012 16:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpWFBwslE6Pl for ; Tue, 9 Oct 2012 16:07:37 -0700 (PDT) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by ietfa.amsl.com (Postfix) with ESMTP id 238DD11E80A6 for ; Tue, 9 Oct 2012 16:07:37 -0700 (PDT) Received: from unknown [65.244.37.85] (EHLO p01c11o142.mxlogic.net) by p01c11o142.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id 93ea4705.4d000940.57286.00-593.137621.p01c11o142.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 17:07:37 -0600 (MDT) X-MXL-Hash: 5074ae395ff7b53f-5e3195212f4b02674d26d4fdc507c27679079dd0 Received: from unknown [65.244.37.85] (EHLO mail.ipc.com) by p01c11o142.mxlogic.net(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 92ea4705.0.57199.00-383.137436.p01c11o142.mxlogic.net (envelope-from ); Tue, 09 Oct 2012 17:07:22 -0600 (MDT) X-MXL-Hash: 5074ae2a418b9bba-a2027bb4b9898fae49e877beb4c92950c2c84342 Received: from STSNYEXMBX2.corp.root.ipc.com ([fe80::157c:2ec6:ebe1:434b]) by STSNYEXHTCAS1.corp.root.ipc.com ([fe80::142:b161:c064:665b%12]) with mapi id 14.02.0309.002; Tue, 9 Oct 2012 19:07:20 -0400 From: "Jain, Rajnish" To: Paul Kyzivat Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0S/oW4otRVB0G1cv9D6PjMnZeq3wQQgABNZ4CABR0qAIAApZ4A///B6yCAAJSlgIAAFEtQgABQlID//79PEIAATEmA///KMFAACfT3AAAGbX4w Date: Tue, 9 Oct 2012 23:07:20 +0000 Message-ID: <4C91F9B607136D48AE3411BDC594D2AE0F37CDC0@STSNYEXMBX2.corp.root.ipc.com> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> <50747CAD.7010805@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> <50748667.6030404@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CCD9@STSNYEXMBX2.corp.root.ipc.com> <50749C14.3040907@alum.mit.edu> In-Reply-To: <50749C14.3040907@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.43.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.85] X-AnalysisOut: [v=2.0 cv=GOq/5JxK c=1 sm=0 a=P2kxRH3pYPRvCTvaOY9ozw==:17 a] X-AnalysisOut: [=TI9zlQ3hUaoA:10 a=RDifYy2iUvAA:10 a=lCc8-jNt9F8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=vvKfUcg] X-AnalysisOut: [jAAAA:8 a=UopzfNgKjUQA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:] X-AnalysisOut: [8 a=AUd_NHdVAAAA:8 a=ag3Orf1RAAAA:8 a=Tn40LXQWAAAA:8 a=p-b] X-AnalysisOut: [Yel3d0TGj6VxhVzcA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [MSl-tDqOz04A:10 a=OeN1TrMypwAA:10 a=JfD0Fch1gWkA:10 a=KwNp] X-AnalysisOut: [_X_GjOYA:10 a=bMJFfM6m6Bqjj0Hu:21 a=O2Ef-WTew72QupeU:21] Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 09 Oct 2012 23:07:39 -0000 Hi Paul, While this discussion isn't about defining B2BUAs, I'd like to express *as = an SRC implementer* that the 3261 definition of a B2BUA has got muddied wit= h time and as we've gained more implementation experience. E.g. I've state = machines in my product that don't fit the definition of a B2BUA (as per 326= 1) but they do work. SUBSCRIBE/NOTIFY and OOB NOTIFY are at the forefront o= f such examples. Coming back to the TLS topic, I wish we could relax TLS for SRC (I'd be hon= est; our SRC TLS implementation doesn't scale well with TLS enabled and our= customers do not require it). Thanks, Raj -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Tuesday, October 09, 2012 5:50 PM To: Jain, Rajnish Cc: siprec@ietf.org Subject: Re: [siprec] Proposed text for security section in siprec-protocol On 10/9/12 5:19 PM, Jain, Rajnish wrote: > Paul, > > Pls. see inline: > >> Note that I'm also proposing that we require a B2BUA acting as an SRC (e= .g. an SBC or PBX) be required to support TLS. > > [rj] That's fine. I don't know what a B2BUA is anymore (because most prac= tical server-side SIP implementations are some sort of UAs combined in some= fashion). I don't know if you're referring to passive recording (sniffing = media and recording that media). If it terminates one dialog and initiates another, and keeps them connected= in order to establish a single "call" then it's a B2BUA. That is true whet= her it terminates media or not. You can see the documents of the STRAW WG f= or more on current thinking about B2BUAs. An entirely passive recorder is out of scope for siprec. The SRC must be ab= le to cause an indication of recording to be conveyed to the participants, = either in the CS sip signaling or in the media to the participants. Thanks, Paul > Another thing to consider is RS sessions initiated by an SRS. > What if the SRS wants to use TLS? > > [rj] That's fine as well. In this case, the administrator has decided to = use TLS between SRS and SRC. Pls. note that it is left to the administrator= /implementer to decide. > > Thanks, > Raj > >> >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: Tuesday, October 09, 2012 3:36 PM >> To: siprec@ietf.org >> Subject: Re: [siprec] Proposed text for security section in=20 >> siprec-protocol >> >> Note that 3261 says proxies MUST implement TLS, while UAs are not requir= ed to. >> >> I think that implies that a UA that is acting as its own SRC should not = be required to implement TLS, as long as it's consistent. >> >> A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probably= can't depend on the 3261 requirement applying to it, but IMO we are justif= ied in imposing that requirement on it as an SRC. >> >> IMO it makes sense to require an SRS to support TLS. >> >> Thanks, >> Paul >> >> On 10/9/12 3:17 PM, Jain, Rajnish wrote: >>> Mary, >>> >>> Understand. I think we can address this with correct wording. The=20 >>> idea would be to not compromise security (RS must be as secure as CS >>> - no more no less). >>> >>> Thanks, >>> >>> Raj >>> >>> *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >>> *Sent:* Tuesday, October 09, 2012 9:35 AM >>> *To:* Jain, Rajnish >>> *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R=20 >>> (rmohanr); Henry Lum; siprec@ietf.org >>> *Subject:* Re: [siprec] Proposed text for security section in=20 >>> siprec-protocol >>> >>> Raj, >>> >>> This document won't get through the IESG/Secdir review without=20 >>> having a mandatory to implement security protocol. Spec(T) won't do=20 >>> anything to help you. That concept was introduced in the context of=20 >>> a specific P-header and is not a standard SIP concept. SIPREC is=20 >>> intended to be used in non-trusted domains and the protocol spec=20 >>> must have a mandatory to implement security protocol. >>> >>> Mary. >>> >>> On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish >> > wrote: >>> >>> I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. >>> I agree that RS should be as secure as CS (and we should leave it that = way). >>> >>> I think most of the SRC/SRS deployments are going to be (as they=20 >>> currently are) in Trust Domain governed by their own Spec(T). If=20 >>> we're going to mandate TLS than are we also mandating which cipher=20 >>> suites SRC and SRS must implement? I view siprec as an extension of=20 >>> the SIP protocol and not a mechanism for dictating security. >>> >>> Raj >>> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org =20 >>> [mailto:siprec-bounces@ietf.org ] On=20 >>> Behalf Of Hutton, Andrew >>> Sent: Tuesday, October 09, 2012 4:25 AM >>> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum;=20 >>> siprec@ietf.org >>> Subject: Re: [siprec] Proposed text for security section in=20 >>> siprec-protocol >>> >>> +1. >>> >>> Andy >>> >>> >>> > -----Original Message----- >>> > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com=20 >>> ] > Sent: 08 October 2012 23:33 > To:=20 >>> Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org=20 >>> > Subject: RE: [siprec] Proposed text for=20 >>> security section in siprec- > protocol > > I agree with making=20 >>> TLS support a MUST. I am not as sure about SIPS. >>> > To me, it is more important that TLS with SIP be supported than=20 >>> TLS >>>> with SIPS. >>> > >>> > Cheers, >>> > Charles >>> > >>> > > -----Original Message----- >>> > > From: siprec-bounces@ietf.org=20 >>> [mailto:siprec-bounces@ietf.org=20 >>> ] On >>>> Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05, >>> 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org=20 >>> > > Subject: Re: [siprec] Proposed text=20 >>> for security section in siprec- > protocol > > > > > On 05/10/12=20 >>> 9:31 PM, "Hutton, Andrew" >>> > > >>> > wrote: >>> > > >>> > > >Hi Ram, >>> > > > >>> > > >We do make TLS support by the SRC and SRS a MUST requirement=20 >>> in the > > >protocol draft and I think this is the correct thing to do= . >>> So it > > >is mandatory to implement but not mandatory to use. It=20 >>> has to be > > >like > that > > >otherwise we could not support=20 >>> the requirement to make the RS at > least as > > >secure as the CS. >>> > > >>> > > Ok sounds fine. >>> > > >>> > > Thanks, >>> > > Ram >>> > > >>> > > > >>> > > >Regards >>> > > >Andy >>> > > > >>> > > > >>> > > > >>> > > >> -----Original Message----- >>> > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com=20 >>> ] > > >> Sent: 03 October 2012 18:33 > > >>>>> To: Henry Lum; Hutton, Andrew; siprec@ietf.org >>> > > >> Subject: Re: [siprec] Proposed text=20 >>> for security section in > siprec- > > >> protocol > > >> > > >>=20 >>> > On 01/10/12 9:51 PM, "Henry Lum" >> > >>> > > wrote: >>> > > >> >>> > > >> >>Can we make a firm recommendation to secure using TLS=20 >>> and not > refer > > >> to > > >> >S/MIME > > >> >>at all? >>> > > >> >[Henry] I am okay with that and prefer only using TLS too >>> :) I > > >> reference > > >> >S/MIME since it was mentioned in >>> RFC3261 as a way to protect the > > >> >content, but then it's=20 >>> weird that you only protect metadata and > not > > >> the > > >>=20 >>> >rest of the content, unless you don't want any proxies in > > >>=20 >>> >between >>>> to >>>>>>> see > > >> >the metadata. Anyone object to removing this? >>> > > >> >>> > > >> If mandating TLS between SRC and SRS is the intent here, I=20 >>> don=B9t > think > > >> we > > >> can mandate that. Of course we can= =20 >>> add a recommendation saying > > >> for deployments where SRC and=20 >>> SRS are in different administrative > domains > > >> it > > >> is=20 >>> highly recommended to use TLS. >>> > > >> >>> > > >> Ram >>> > > > >>> > > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > siprec mailing list >>> > > siprec@ietf.org > >=20 >>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/siprec >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> -------------------------------------------------------------------- >>> - >>> - >>> -------------------------------------------------------------------- >>> - >>> - >>> ---------------------------------------------- >>> >>> DISCLAIMER: This e-mail may contain information that is=20 >>> confidential, privileged or otherwise protected from disclosure. If=20 >>> you are not an intended recipient of this e-mail, do not duplicate=20 >>> or redistribute it by any means. Please delete it and any=20 >>> attachments and notify the sender that you have received it in=20 >>> error. Unintended recipients are prohibited from taking action on=20 >>> the basis of information in this e-mail.E-mail messages may contain=20 >>> computer viruses or other defects, may not be accurately replicated=20 >>> on other systems, or may be intercepted, deleted or interfered with=20 >>> without the knowledge of the sender or the intended recipient. If=20 >>> you are not comfortable with the risks associated with e-mail=20 >>> messages, you may decide not to use e-mail to communicate with IPC.=20 >>> IPC reserves the right, to the extent and under circumstances=20 >>> permitted by applicable law, to retain, monitor and intercept e-mail me= ssages to and from its systems. >>> >>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > From pkyzivat@alum.mit.edu Tue Oct 9 19:47: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 15DAF1F041F for ; Tue, 9 Oct 2012 19:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fWY0bKbH3V2 for ; Tue, 9 Oct 2012 19:47:45 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id D4C341F0C3A for ; Tue, 9 Oct 2012 19:47:44 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta02.westchester.pa.mail.comcast.net with comcast id 90Zb1k0061ZXKqc51Enor7; Wed, 10 Oct 2012 02:47:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id 9Ejr1k00A3ZTu2S3hEjrYs; Wed, 10 Oct 2012 02:43:51 +0000 Message-ID: <5074E0A2.4060904@alum.mit.edu> Date: Tue, 09 Oct 2012 22:42:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Jain, Rajnish" References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> <50747CAD.7010805@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> <50748667.6030404@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CCD9@STSNYEXMBX2.corp.root.ipc.com> <50749C14.3040907@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CDC0@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F37CDC0@STSNYEXMBX2.corp.root.ipc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2012 02:47:46 -0000 On 10/9/12 7:07 PM, Jain, Rajnish wrote: > Hi Paul, > > While this discussion isn't about defining B2BUAs, > I'd like to express *as an SRC implementer* that the 3261 definition > of a B2BUA has got muddied with time and as we've gained more > implementation experience. IMO it is not the B2BUA definition that has gotten muddy. It is perfectly clear. Some related problems that I see are: - people wish to build something that is more than a proxy but less than a B2BUA. There is no spec for building such a thing, or measuring compliance of one. So they build things and we find they have unpredictable effects. - there are many different sorts of things that people can build that are all at their heart a B2BUA. But often people who do so don't realize that all such things don't work the way theirs does. > E.g. I've state machines in my product > that don't fit the definition of a B2BUA (as per 3261) but they do work. So I suspect you are building one of those things I describe in the first bullet above. You say "they do work". I don't doubt that they work for you in the cases where you have tested them. But I am concerned that we can find sip compliant boxes you didn't consider that your product won't work with. Feel free to write up a small informational draft describing what you have built and publish it for comments. > SUBSCRIBE/NOTIFY and OOB NOTIFY are at the forefront of such examples. OOB NOTIFY? Do you mean a NOTIFY sent outside of a dialog? Certainly I am aware that it is done. (Cisco has used it in products.) But there are good reasons why such behavior has not been, and will not be, standardized. > Coming back to the TLS topic, I wish we could relax TLS for SRC (I'd be honest; our SRC TLS implementation doesn't scale well with TLS enabled and our customers do not require it). We will see. The security review may not allow such. Of course there is nothing to prevent you from building such a box even if the spec says you must not. In any case, we only say it is required to implement, not to use. You apparently *have* an implementation. You can certainly control it with a configuration option and put up a big warning when somebody turns it on. That will be compliant. Assuming that the disable of TLS applies equally to the CS and RS legs in your B2BUA, then you will never have any secure CS sessions, and so no need to use TLS on the RS. Thanks, Paul > Thanks, > Raj > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, October 09, 2012 5:50 PM > To: Jain, Rajnish > Cc: siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in siprec-protocol > > On 10/9/12 5:19 PM, Jain, Rajnish wrote: >> Paul, >> >> Pls. see inline: >> >>> Note that I'm also proposing that we require a B2BUA acting as an SRC (e.g. an SBC or PBX) be required to support TLS. >> >> [rj] That's fine. I don't know what a B2BUA is anymore (because most practical server-side SIP implementations are some sort of UAs combined in some fashion). I don't know if you're referring to passive recording (sniffing media and recording that media). > > If it terminates one dialog and initiates another, and keeps them connected in order to establish a single "call" then it's a B2BUA. That is true whether it terminates media or not. You can see the documents of the STRAW WG for more on current thinking about B2BUAs. > > An entirely passive recorder is out of scope for siprec. The SRC must be able to cause an indication of recording to be conveyed to the participants, either in the CS sip signaling or in the media to the participants. > > Thanks, > Paul > >> Another thing to consider is RS sessions initiated by an SRS. >> What if the SRS wants to use TLS? >> >> [rj] That's fine as well. In this case, the administrator has decided to use TLS between SRS and SRC. Pls. note that it is left to the administrator/implementer to decide. >> >> Thanks, >> Raj >> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Tuesday, October 09, 2012 3:36 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Proposed text for security section in >>> siprec-protocol >>> >>> Note that 3261 says proxies MUST implement TLS, while UAs are not required to. >>> >>> I think that implies that a UA that is acting as its own SRC should not be required to implement TLS, as long as it's consistent. >>> >>> A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probably can't depend on the 3261 requirement applying to it, but IMO we are justified in imposing that requirement on it as an SRC. >>> >>> IMO it makes sense to require an SRS to support TLS. >>> >>> Thanks, >>> Paul >>> >>> On 10/9/12 3:17 PM, Jain, Rajnish wrote: >>>> Mary, >>>> >>>> Understand. I think we can address this with correct wording. The >>>> idea would be to not compromise security (RS must be as secure as CS >>>> - no more no less). >>>> >>>> Thanks, >>>> >>>> Raj >>>> >>>> *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >>>> *Sent:* Tuesday, October 09, 2012 9:35 AM >>>> *To:* Jain, Rajnish >>>> *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R >>>> (rmohanr); Henry Lum; siprec@ietf.org >>>> *Subject:* Re: [siprec] Proposed text for security section in >>>> siprec-protocol >>>> >>>> Raj, >>>> >>>> This document won't get through the IESG/Secdir review without >>>> having a mandatory to implement security protocol. Spec(T) won't do >>>> anything to help you. That concept was introduced in the context of >>>> a specific P-header and is not a standard SIP concept. SIPREC is >>>> intended to be used in non-trusted domains and the protocol spec >>>> must have a mandatory to implement security protocol. >>>> >>>> Mary. >>>> >>>> On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish >>> > wrote: >>>> >>>> I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. >>>> I agree that RS should be as secure as CS (and we should leave it that way). >>>> >>>> I think most of the SRC/SRS deployments are going to be (as they >>>> currently are) in Trust Domain governed by their own Spec(T). If >>>> we're going to mandate TLS than are we also mandating which cipher >>>> suites SRC and SRS must implement? I view siprec as an extension of >>>> the SIP protocol and not a mechanism for dictating security. >>>> >>>> Raj >>>> >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org ] On >>>> Behalf Of Hutton, Andrew >>>> Sent: Tuesday, October 09, 2012 4:25 AM >>>> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum; >>>> siprec@ietf.org >>>> Subject: Re: [siprec] Proposed text for security section in >>>> siprec-protocol >>>> >>>> +1. >>>> >>>> Andy >>>> >>>> >>>> > -----Original Message----- >>>> > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com >>>> ] > Sent: 08 October 2012 23:33 > To: >>>> Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org >>>> > Subject: RE: [siprec] Proposed text for >>>> security section in siprec- > protocol > > I agree with making >>>> TLS support a MUST. I am not as sure about SIPS. >>>> > To me, it is more important that TLS with SIP be supported than >>>> TLS >>>>> with SIPS. >>>> > >>>> > Cheers, >>>> > Charles >>>> > >>>> > > -----Original Message----- >>>> > > From: siprec-bounces@ietf.org >>>> [mailto:siprec-bounces@ietf.org >>>> ] On >>>>> Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October 05, >>>> 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org >>>> > > Subject: Re: [siprec] Proposed text >>>> for security section in siprec- > protocol > > > > > On 05/10/12 >>>> 9:31 PM, "Hutton, Andrew" >>>> > > >>>> > wrote: >>>> > > >>>> > > >Hi Ram, >>>> > > > >>>> > > >We do make TLS support by the SRC and SRS a MUST requirement >>>> in the > > >protocol draft and I think this is the correct thing to do. >>>> So it > > >is mandatory to implement but not mandatory to use. It >>>> has to be > > >like > that > > >otherwise we could not support >>>> the requirement to make the RS at > least as > > >secure as the CS. >>>> > > >>>> > > Ok sounds fine. >>>> > > >>>> > > Thanks, >>>> > > Ram >>>> > > >>>> > > > >>>> > > >Regards >>>> > > >Andy >>>> > > > >>>> > > > >>>> > > > >>>> > > >> -----Original Message----- >>>> > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com >>>> ] > > >> Sent: 03 October 2012 18:33 > > >>>>>> To: Henry Lum; Hutton, Andrew; siprec@ietf.org >>>> > > >> Subject: Re: [siprec] Proposed text >>>> for security section in > siprec- > > >> protocol > > >> > > >> >>>>> On 01/10/12 9:51 PM, "Henry Lum" >>> > >>>> > > wrote: >>>> > > >> >>>> > > >> >>Can we make a firm recommendation to secure using TLS >>>> and not > refer > > >> to > > >> >S/MIME > > >> >>at all? >>>> > > >> >[Henry] I am okay with that and prefer only using TLS too >>>> :) I > > >> reference > > >> >S/MIME since it was mentioned in >>>> RFC3261 as a way to protect the > > >> >content, but then it's >>>> weird that you only protect metadata and > not > > >> the > > >> >>>>> rest of the content, unless you don't want any proxies in > > >> >>>>> between >>>>> to >>>>>>>> see > > >> >the metadata. Anyone object to removing this? >>>> > > >> >>>> > > >> If mandating TLS between SRC and SRS is the intent here, I >>>> don¹t > think > > >> we > > >> can mandate that. Of course we can >>>> add a recommendation saying > > >> for deployments where SRC and >>>> SRS are in different administrative > domains > > >> it > > >> is >>>> highly recommended to use TLS. >>>> > > >> >>>> > > >> Ram >>>> > > > >>>> > > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > siprec mailing list >>>> > > siprec@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> -------------------------------------------------------------------- >>>> - >>>> - >>>> -------------------------------------------------------------------- >>>> - >>>> - >>>> ---------------------------------------------- >>>> >>>> DISCLAIMER: This e-mail may contain information that is >>>> confidential, privileged or otherwise protected from disclosure. If >>>> you are not an intended recipient of this e-mail, do not duplicate >>>> or redistribute it by any means. Please delete it and any >>>> attachments and notify the sender that you have received it in >>>> error. Unintended recipients are prohibited from taking action on >>>> the basis of information in this e-mail.E-mail messages may contain >>>> computer viruses or other defects, may not be accurately replicated >>>> on other systems, or may be intercepted, deleted or interfered with >>>> without the knowledge of the sender or the intended recipient. If >>>> you are not comfortable with the risks associated with e-mail >>>> messages, you may decide not to use e-mail to communicate with IPC. >>>> IPC reserves the right, to the extent and under circumstances >>>> permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> > > From rajnish.jain@ipc.com Wed Oct 10 05:27: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 7349C21F86C9 for ; Wed, 10 Oct 2012 05:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENPa4vip0I1g for ; Wed, 10 Oct 2012 05:27:58 -0700 (PDT) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) by ietfa.amsl.com (Postfix) with ESMTP id 09BAD21F849C for ; Wed, 10 Oct 2012 05:27:57 -0700 (PDT) Received: from unknown [65.244.37.52] (EHLO p01c11o143.mxlogic.net) by p01c11o143.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id ec965705.6a905940.82870.00-574.155771.p01c11o143.mxlogic.net (envelope-from ); Wed, 10 Oct 2012 06:27:58 -0600 (MDT) X-MXL-Hash: 507569ce492d878d-c640adff77f3c43ba668570c8ea76fec9d3637d3 Received: from unknown [65.244.37.52] by p01c11o143.mxlogic.net(mxl_mta-6.15.0-1) with SMTP id cc965705.0.82764.00-324.155752.p01c11o143.mxlogic.net (envelope-from ); Wed, 10 Oct 2012 06:27:57 -0600 (MDT) X-MXL-Hash: 507569cd3c86db09-f13052efc33edb6fa46645c9fd1519f182378925 Received: from STSNYEXMBX2.corp.root.ipc.com ([fe80::157c:2ec6:ebe1:434b]) by STSNYEXHTCAS2.corp.root.ipc.com ([fe80::587a:3ab8:7c0b:6908%12]) with mapi id 14.02.0309.002; Wed, 10 Oct 2012 08:27:18 -0400 From: "Jain, Rajnish" To: Paul Kyzivat Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0S/oW4otRVB0G1cv9D6PjMnZeq3wQQgABNZ4CABR0qAIAApZ4A///B6yCAAJSlgIAAFEtQgABQlID//79PEIAATEmA///KMFAACfT3AAAGbX4wAAPJqgAAC+mP4A== Date: Wed, 10 Oct 2012 12:27:17 +0000 Message-ID: <4C91F9B607136D48AE3411BDC594D2AE0F37D0F7@STSNYEXMBX2.corp.root.ipc.com> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> <50747CAD.7010805@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> <50748667.6030404@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CCD9@STSNYEXMBX2.corp.root.ipc.com> <50749C14.3040907@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CDC0@STSNYEXMBX2.corp.root.ipc.com> <5074E0A2.4060904@alum.mit.edu> In-Reply-To: <5074E0A2.4060904@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.43.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=2.0 cv=Kof6LxqN c=1 sm=0 a=D4USGbs0y0J827gn68Ljfg==:17 a] X-AnalysisOut: [=TI9zlQ3hUaoA:10 a=RDifYy2iUvAA:10 a=lCc8-jNt9F8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=vvKfUcg] X-AnalysisOut: [jAAAA:8 a=UopzfNgKjUQA:10 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:] X-AnalysisOut: [8 a=AUd_NHdVAAAA:8 a=ag3Orf1RAAAA:8 a=Tn40LXQWAAAA:8 a=c9H] X-AnalysisOut: [hp__wzItxJJefCnoA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=] X-AnalysisOut: [MSl-tDqOz04A:10 a=OeN1TrMypwAA:10 a=JfD0Fch1gWkA:10 a=KwNp] X-AnalysisOut: [_X_GjOYA:10 a=Oh_L0_Jo7H3auic-:21 a=xn1cI7RqiK6MjeYp:21] Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2012 12:27:59 -0000 Hi Paul, I'm just hoping that we don't require TLS support in SRC (RFC 3261 is a pre= cedence). Obviously, the WG will weigh in. Thanks, Raj -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Tuesday, October 09, 2012 10:43 PM To: Jain, Rajnish Cc: siprec@ietf.org Subject: Re: [siprec] Proposed text for security section in siprec-protocol On 10/9/12 7:07 PM, Jain, Rajnish wrote: > Hi Paul, > > While this discussion isn't about defining B2BUAs, I'd like to express=20 > *as an SRC implementer* that the 3261 definition of a B2BUA has got=20 > muddied with time and as we've gained more implementation experience. IMO it is not the B2BUA definition that has gotten muddy. It is perfectly clear. Some related problems that I see are: - people wish to build something that is more than a proxy but less than a B2BUA. There is no spec for building such a thing, or measuring compliance of one. So they build things and we find they have unpredictable effects. - there are many different sorts of things that people can build that are all at their heart a B2BUA. But often people who do so don't realize that all such things don't work the way theirs does. > E.g. I've state machines in my product that don't fit the definition=20 > of a B2BUA (as per 3261) but they do work. So I suspect you are building one of those things I describe in the first b= ullet above. You say "they do work". I don't doubt that they work for you in the cases w= here you have tested them. But I am concerned that we can find sip complian= t boxes you didn't consider that your product won't work with. Feel free to write up a small informational draft describing what you have = built and publish it for comments. > SUBSCRIBE/NOTIFY and OOB NOTIFY are at the forefront of such examples. OOB NOTIFY? Do you mean a NOTIFY sent outside of a dialog? Certainly I am aware that it is done. (Cisco has used it in products.) But = there are good reasons why such behavior has not been, and will not be, sta= ndardized. > Coming back to the TLS topic, I wish we could relax TLS for SRC (I'd be h= onest; our SRC TLS implementation doesn't scale well with TLS enabled and o= ur customers do not require it). We will see. The security review may not allow such. Of course there is nothing to prevent you from building such a box even if = the spec says you must not. In any case, we only say it is required to impl= ement, not to use. You apparently *have* an implementation. You can certain= ly control it with a configuration option and put up a big warning when som= ebody turns it on. That will be compliant. Assuming that the disable of TLS applies equally to the CS and RS legs in y= our B2BUA, then you will never have any secure CS sessions, and so no need = to use TLS on the RS. Thanks, Paul > Thanks, > Raj > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, October 09, 2012 5:50 PM > To: Jain, Rajnish > Cc: siprec@ietf.org > Subject: Re: [siprec] Proposed text for security section in=20 > siprec-protocol > > On 10/9/12 5:19 PM, Jain, Rajnish wrote: >> Paul, >> >> Pls. see inline: >> >>> Note that I'm also proposing that we require a B2BUA acting as an SRC (= e.g. an SBC or PBX) be required to support TLS. >> >> [rj] That's fine. I don't know what a B2BUA is anymore (because most pra= ctical server-side SIP implementations are some sort of UAs combined in som= e fashion). I don't know if you're referring to passive recording (sniffing= media and recording that media). > > If it terminates one dialog and initiates another, and keeps them connect= ed in order to establish a single "call" then it's a B2BUA. That is true wh= ether it terminates media or not. You can see the documents of the STRAW WG= for more on current thinking about B2BUAs. > > An entirely passive recorder is out of scope for siprec. The SRC must be = able to cause an indication of recording to be conveyed to the participants= , either in the CS sip signaling or in the media to the participants. > > Thanks, > Paul > >> Another thing to consider is RS sessions initiated by an SRS. >> What if the SRS wants to use TLS? >> >> [rj] That's fine as well. In this case, the administrator has decided to= use TLS between SRS and SRC. Pls. note that it is left to the administrato= r/implementer to decide. >> >> Thanks, >> Raj >> >>> >>> -----Original Message----- >>> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat >>> Sent: Tuesday, October 09, 2012 3:36 PM >>> To: siprec@ietf.org >>> Subject: Re: [siprec] Proposed text for security section in=20 >>> siprec-protocol >>> >>> Note that 3261 says proxies MUST implement TLS, while UAs are not requi= red to. >>> >>> I think that implies that a UA that is acting as its own SRC should not= be required to implement TLS, as long as it's consistent. >>> >>> A B2BUA acting as an SRC is *morally* equivalent to a proxy. We probabl= y can't depend on the 3261 requirement applying to it, but IMO we are justi= fied in imposing that requirement on it as an SRC. >>> >>> IMO it makes sense to require an SRS to support TLS. >>> >>> Thanks, >>> Paul >>> >>> On 10/9/12 3:17 PM, Jain, Rajnish wrote: >>>> Mary, >>>> >>>> Understand. I think we can address this with correct wording. The=20 >>>> idea would be to not compromise security (RS must be as secure as=20 >>>> CS >>>> - no more no less). >>>> >>>> Thanks, >>>> >>>> Raj >>>> >>>> *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >>>> *Sent:* Tuesday, October 09, 2012 9:35 AM >>>> *To:* Jain, Rajnish >>>> *Cc:* Hutton, Andrew; Charles Eckel (eckelcu); Ram Mohan R=20 >>>> (rmohanr); Henry Lum; siprec@ietf.org >>>> *Subject:* Re: [siprec] Proposed text for security section in=20 >>>> siprec-protocol >>>> >>>> Raj, >>>> >>>> This document won't get through the IESG/Secdir review without=20 >>>> having a mandatory to implement security protocol. Spec(T) won't=20 >>>> do anything to help you. That concept was introduced in the context=20 >>>> of a specific P-header and is not a standard SIP concept. SIPREC=20 >>>> is intended to be used in non-trusted domains and the protocol spec=20 >>>> must have a mandatory to implement security protocol. >>>> >>>> Mary. >>>> >>>> On Tue, Oct 9, 2012 at 3:56 AM, Jain, Rajnish >>> > wrote: >>>> >>>> I'm not sure if SIP-over-TLS should be a MUST requirement for siprec. >>>> I agree that RS should be as secure as CS (and we should leave it that= way). >>>> >>>> I think most of the SRC/SRS deployments are going to be (as they=20 >>>> currently are) in Trust Domain governed by their own Spec(T). If=20 >>>> we're going to mandate TLS than are we also mandating which cipher=20 >>>> suites SRC and SRS must implement? I view siprec as an extension of=20 >>>> the SIP protocol and not a mechanism for dictating security. >>>> >>>> Raj >>>> >>>> >>>> -----Original Message----- >>>> From: siprec-bounces@ietf.org =20 >>>> [mailto:siprec-bounces@ietf.org ]=20 >>>> On Behalf Of Hutton, Andrew >>>> Sent: Tuesday, October 09, 2012 4:25 AM >>>> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Henry Lum;=20 >>>> siprec@ietf.org >>>> Subject: Re: [siprec] Proposed text for security section in=20 >>>> siprec-protocol >>>> >>>> +1. >>>> >>>> Andy >>>> >>>> >>>> > -----Original Message----- >>>> > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com=20 >>>> ] > Sent: 08 October 2012 23:33 > To: >>>> Ram Mohan R (rmohanr); Hutton, Andrew; Henry Lum; siprec@ietf.org=20 >>>> > Subject: RE: [siprec] Proposed text for=20 >>>> security section in siprec- > protocol > > I agree with making=20 >>>> TLS support a MUST. I am not as sure about SIPS. >>>> > To me, it is more important that TLS with SIP be supported=20 >>>> than TLS >>>>> with SIPS. >>>> > >>>> > Cheers, >>>> > Charles >>>> > >>>> > > -----Original Message----- >>>> > > From: siprec-bounces@ietf.org=20 >>>> [mailto:siprec-bounces@ietf.org=20 >>>> ] On >>>>> Behalf > > Of Ram Mohan R (rmohanr) > > Sent: Friday, October=20 >>>>> 05, >>>> 2012 9:27 AM > > To: Hutton, Andrew; Henry Lum; siprec@ietf.org=20 >>>> > > Subject: Re: [siprec] Proposed text=20 >>>> for security section in siprec- > protocol > > > > > On 05/10/12 >>>> 9:31 PM, "Hutton, Andrew" >>>> > > >>>> > wrote: >>>> > > >>>> > > >Hi Ram, >>>> > > > >>>> > > >We do make TLS support by the SRC and SRS a MUST=20 >>>> requirement in the > > >protocol draft and I think this is the correc= t thing to do. >>>> So it > > >is mandatory to implement but not mandatory to use. It=20 >>>> has to be > > >like > that > > >otherwise we could not support=20 >>>> the requirement to make the RS at > least as > > >secure as the CS. >>>> > > >>>> > > Ok sounds fine. >>>> > > >>>> > > Thanks, >>>> > > Ram >>>> > > >>>> > > > >>>> > > >Regards >>>> > > >Andy >>>> > > > >>>> > > > >>>> > > > >>>> > > >> -----Original Message----- >>>> > > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com=20 >>>> ] > > >> Sent: 03 October 2012 18:33 >=20 >>>> > >>>>>> To: Henry Lum; Hutton, Andrew; siprec@ietf.org >>>> > > >> Subject: Re: [siprec] Proposed=20 >>>> text for security section in > siprec- > > >> protocol > > >> >=20 >>>> > >> >>>>> On 01/10/12 9:51 PM, "Henry Lum" >>> > >>>> > > wrote: >>>> > > >> >>>> > > >> >>Can we make a firm recommendation to secure using TLS=20 >>>> and not > refer > > >> to > > >> >S/MIME > > >> >>at all? >>>> > > >> >[Henry] I am okay with that and prefer only using TLS=20 >>>> too >>>> :) I > > >> reference > > >> >S/MIME since it was mentioned in >>>> RFC3261 as a way to protect the > > >> >content, but then it's=20 >>>> weird that you only protect metadata and > not > > >> the > > >> >>>>> rest of the content, unless you don't want any proxies in > > >>=20 >>>>> between to >>>>>>>> see > > >> >the metadata. Anyone object to removing this? >>>> > > >> >>>> > > >> If mandating TLS between SRC and SRS is the intent here,=20 >>>> I don=B9t > think > > >> we > > >> can mandate that. Of course we=20 >>>> can add a recommendation saying > > >> for deployments where SRC=20 >>>> and SRS are in different administrative > domains > > >> it > >=20 >>>> >> is highly recommended to use TLS. >>>> > > >> >>>> > > >> Ram >>>> > > > >>>> > > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > siprec mailing list >>>> > > siprec@ietf.org > >=20 >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> ------------------------------------------------------------------- >>>> - >>>> - >>>> - >>>> ------------------------------------------------------------------- >>>> - >>>> - >>>> - >>>> ---------------------------------------------- >>>> >>>> DISCLAIMER: This e-mail may contain information that is=20 >>>> confidential, privileged or otherwise protected from disclosure. If=20 >>>> you are not an intended recipient of this e-mail, do not duplicate=20 >>>> or redistribute it by any means. Please delete it and any=20 >>>> attachments and notify the sender that you have received it in=20 >>>> error. Unintended recipients are prohibited from taking action on=20 >>>> the basis of information in this e-mail.E-mail messages may contain=20 >>>> computer viruses or other defects, may not be accurately replicated=20 >>>> on other systems, or may be intercepted, deleted or interfered with=20 >>>> without the knowledge of the sender or the intended recipient. If=20 >>>> you are not comfortable with the risks associated with e-mail=20 >>>> messages, you may decide not to use e-mail to communicate with IPC. >>>> IPC reserves the right, to the extent and under circumstances=20 >>>> permitted by applicable law, to retain, monitor and intercept e-mail m= essages to and from its systems. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> > > From andrew.hutton@siemens-enterprise.com Tue Oct 16 08:13: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 C484321F8699 for ; Tue, 16 Oct 2012 08:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLMzCFSS6dIR for ; Tue, 16 Oct 2012 08:13:46 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1015521F8694 for ; Tue, 16 Oct 2012 08:13:46 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id F2D0723F04A2; Tue, 16 Oct 2012 17:13:43 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 17:13:43 +0200 From: "Hutton, Andrew" To: "Jain, Rajnish" , Paul Kyzivat Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0SRlFTOq7/y0SQ+aCXjp5Rv5eq3wQQgABNZ4CABR0qAIAApZ4A///B6yCAAJSlgIAAFEtQgABQlID//79PEIAATEmA///KMFAACfT3AAAGbX4wAAPJqgAAC+mP4AEy2ySw Date: Tue, 16 Oct 2012 15:13:41 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130473F@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> <50747CAD.7010805@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> <50748667.6030404@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CCD9@STSNYEXMBX2.corp.root.ipc.com> <50749C14.3040907@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CDC0@STSNYEXMBX2.corp.root.ipc.com> <5074E0A2.4060904@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37D0F7@STSNYEXMBX2.corp.root.ipc.com> In-Reply-To: <4C91F9B607136D48AE3411BDC594D2AE0F37D0F7@STSNYEXMBX2.corp.root.ipc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 15:13:46 -0000 Hi, On 10 October 2012 13:27 Jain, Rajnish wrote: >=20 > I'm just hoping that we don't require TLS support in SRC (RFC 3261 is a > precedence). Obviously, the WG will weigh in. >=20 What I have heard so far is that security is very important and needs to be= clearly described if we are to get the SIPREC protocol released as an RFC.= RFC 3261 is only the base on which we build so the fact that it does not m= andate SIP over TLS is not something we can use as an argument for not requ= iring it in SIPREC. We all agree that the RS MUST be at least as secure as the CS therefore to = cover the generic case it makes sense to me to mandate that the SRS support= s TLS as it does not know what is being used on the CS. Then it also makes = sense to mandate TLS in the SRC especially as Paul points out if the RS is = SRS initiated. It is of course true that many real world deployments will not use TLS but = that is a choice to be made depending on the deployment model. However for = the SIPREC protocol spec that aims to provide interoperability between vend= ors it seems to make sense to mandate that both the SRC and SRS supports SI= P over TLS.=20 Regards Andy From andrew.hutton@siemens-enterprise.com Tue Oct 16 08:20: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 5255F21F8973 for ; Tue, 16 Oct 2012 08:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pB2h1AfHvmR for ; Tue, 16 Oct 2012 08:20:36 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5D41421F897E for ; Tue, 16 Oct 2012 08:20:35 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id A30BC23F046B for ; Tue, 16 Oct 2012 17:20:34 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 17:20:34 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: SIPREC Metadata Reviewers and examples needed. Thread-Index: AQHNozYRFYKK3Fe3gEyZahOzHahI6Je8G6ng Date: Tue, 16 Oct 2012 15:20:33 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130479E@MCHP04MSX.global-ad.net> References: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> <8E66DB23B8154FC89802B2DA6B5B509C@VOXSTORSERVER> <506F3E83.2020307@alum.mit.edu> In-Reply-To: <506F3E83.2020307@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] SIPREC Metadata Reviewers and examples needed. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 15:20:37 -0000 Hi All, As Paul pointed out below we really need more review of example usage of Me= tadata either of real captures of hand generated examples. Volunteers would be highly appreciated and if we could have discussion befo= re IETF85 (3 weeks time) that would also be great. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 05 October 2012 21:10 > To: siprec@ietf.org > Subject: Re: [siprec] SIPREC captures >=20 > IMO there is a great need for more examples, done by different people, > rather than just having ones done by the authors of the schema. It is > really important to get different interpretations to expose > ambiguities, > etc. >=20 > Ideally we would have examples that are done as captures from real > implementations. But it would also be helpful to have samples > constructed by hand for interesting cases. >=20 > Once we get some of those it's important that they be widely reviewed. > Two kinds of reviews are both of interest: > - a review from the perspective of an SRS implementer - commenting on > whether the example looks correct, semantically clear, and > able to be supported by an implementation. >=20 > - a review from the perspective of an SRC implementer - commenting on > differences from how the reviewer would have represented the same > case, and whether the differences are both reasonable alternatives, > which (if any) is preferable, and whether it makes sense to have > both alternatives. >=20 > Thanks, > Paul >=20 > On 10/3/12 12:14 PM, Simon Farrow wrote: > > I am just reposting this request as this would very useful to us as > well. > > Simon > > > > --------------------------------------------------------------------- > --- > > *From:* siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > > Behalf Of *Leon Portman > > *Sent:* Tuesday, October 02, 2012 6:15 AM > > *To:* Dave Higton > > *Cc:* siprec@ietf.org > > *Subject:* Re: [siprec] SIPREC captures > > > > On Oct 2, 2012 3:12 PM, "Dave Higton" > > wrote: > > > > Can anyone point me at, or send me, some SIPREC captures, please? > > PCAP format preferred, but text of the SIPREC commands and > > responses would do.____ > > > > ____ > > > > Thank you,____ > > > > ____ > > > > Dave____ > > > > ____ > > > > > > _______________________________________________ > > siprec mailing 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 rajnish.jain@ipc.com Tue Oct 16 08:32:29 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 11B6321F89A9 for ; Tue, 16 Oct 2012 08:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgjJZ2fOWjjl for ; Tue, 16 Oct 2012 08:32:28 -0700 (PDT) Received: from p01c12o143.mxlogic.net (p01c12o143.mxlogic.net [208.65.145.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67D21F8994 for ; Tue, 16 Oct 2012 08:32:28 -0700 (PDT) Received: from unknown [65.244.37.85] (EHLO p01c12o143.mxlogic.net) by p01c12o143.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id c0e7d705.7c7f2940.51089.00-599.127075.p01c12o143.mxlogic.net (envelope-from ); Tue, 16 Oct 2012 09:32:28 -0600 (MDT) X-MXL-Hash: 507d7e0c2946f7fd-d5ed61fa9ddc1177a693597c99ef83fed6cb0757 Received: from unknown [65.244.37.85] by p01c12o143.mxlogic.net(mxl_mta-6.15.0-1) with SMTP id 90e7d705.0.51026.00-386.127018.p01c12o143.mxlogic.net (envelope-from ); Tue, 16 Oct 2012 09:32:27 -0600 (MDT) X-MXL-Hash: 507d7e0b5f4aabb7-161a85c9b5772c3d683034d6d8d3338c3b076311 Received: from STSNYEXMBX2.corp.root.ipc.com ([fe80::157c:2ec6:ebe1:434b]) by STSNYEXHTCAS1.corp.root.ipc.com ([fe80::142:b161:c064:665b%12]) with mapi id 14.02.0309.002; Tue, 16 Oct 2012 11:32:20 -0400 From: "Jain, Rajnish" To: "Hutton, Andrew" , Paul Kyzivat Thread-Topic: [siprec] Proposed text for security section in siprec-protocol Thread-Index: AQHNoY0S/oW4otRVB0G1cv9D6PjMnZeq3wQQgABNZ4CABR0qAIAApZ4A///B6yCAAJSlgIAAFEtQgABQlID//79PEIAATEmA///KMFAACfT3AAAGbX4wAAPJqgAAC+mP4AE8EGCAAAf8oqA= Date: Tue, 16 Oct 2012 15:32:19 +0000 Message-ID: <4C91F9B607136D48AE3411BDC594D2AE0F38F243@STSNYEXMBX2.corp.root.ipc.com> References: <9F33F40F6F2CD847824537F3C4E37DDF012E775C@MCHP04MSX.global-ad.net> <92B7E61ADAC1BB4F941F943788C088280DFB23@xmb-aln-x08.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF012F6B07@MCHP04MSX.global-ad.net> <4C91F9B607136D48AE3411BDC594D2AE0F37C66F@STSNYEXMBX2.corp.root.ipc.com> <4C91F9B607136D48AE3411BDC594D2AE0F37CBC6@STSNYEXMBX2.corp.root.ipc.com> <50747CAD.7010805@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CC3B@STSNYEXMBX2.corp.root.ipc.com> <50748667.6030404@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CCD9@STSNYEXMBX2.corp.root.ipc.com> <50749C14.3040907@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37CDC0@STSNYEXMBX2.corp.root.ipc.com> <5074E0A2.4060904@alum.mit.edu> <4C91F9B607136D48AE3411BDC594D2AE0F37D0F7@STSNYEXMBX2.corp.root.ipc.com> <9F33F40F6F2CD847824537F3C4E37DDF0130473F@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0130473F@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.43.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.85] X-AnalysisOut: [v=2.0 cv=bdzcppzB c=1 sm=0 a=P2kxRH3pYPRvCTvaOY9ozw==:17 a] X-AnalysisOut: [=TI9zlQ3hUaoA:10 a=RDifYy2iUvAA:10 a=lCc8-jNt9F8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=vvKfUcg] X-AnalysisOut: [jAAAA:8 a=UopzfNgKjUQA:10 a=ag3Orf1RAAAA:8 a=48vgC7mUAAAA:] X-AnalysisOut: [8 a=jij2Wi2TTq-yBLr1fWgA:9 a=CjuIK1q_8ugA:10 a=KwNp_X_GjOY] X-AnalysisOut: [A:10 a=lZB815dzVvQA:10] Cc: "siprec@ietf.org" Subject: Re: [siprec] Proposed text for security section in siprec-protocol X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2012 15:32:29 -0000 Andy, That's fine. I think I was mistaking a "MUST-support" statement with a "MUS= T-use" philosophy. So I think it makes sense to require MUST support for TL= S for SRC. Thanks, Raj=20 -----Original Message----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Sent: Tuesday, October 16, 2012 11:14 AM To: Jain, Rajnish; Paul Kyzivat Cc: siprec@ietf.org Subject: RE: [siprec] Proposed text for security section in siprec-protocol Hi, On 10 October 2012 13:27 Jain, Rajnish wrote: >=20 > I'm just hoping that we don't require TLS support in SRC (RFC 3261 is=20 > a precedence). Obviously, the WG will weigh in. >=20 What I have heard so far is that security is very important and needs to be= clearly described if we are to get the SIPREC protocol released as an RFC.= RFC 3261 is only the base on which we build so the fact that it does not m= andate SIP over TLS is not something we can use as an argument for not requ= iring it in SIPREC. We all agree that the RS MUST be at least as secure as the CS therefore to = cover the generic case it makes sense to me to mandate that the SRS support= s TLS as it does not know what is being used on the CS. Then it also makes = sense to mandate TLS in the SRC especially as Paul points out if the RS is = SRS initiated. It is of course true that many real world deployments will not use TLS but = that is a choice to be made depending on the deployment model. However for = the SIPREC protocol spec that aims to provide interoperability between vend= ors it seems to make sense to mandate that both the SRC and SRS supports SI= P over TLS.=20 Regards Andy From Ofir.Roth@nice.com Wed Oct 17 02:33: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 B323121F85C7 for ; Wed, 17 Oct 2012 02:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfim8bb+8dyO for ; Wed, 17 Oct 2012 02:33:55 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 94D8121F85A7 for ; Wed, 17 Oct 2012 02:33:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,599,1344200400"; d="scan'208,217";a="4637029" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 17 Oct 2012 11:33:53 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Wed, 17 Oct 2012 11:33:51 +0200 Thread-Topic: Metadata XML schema Thread-Index: Ac2sSE7TgIgWVjj6SbCRNjOitX8iuAAAirbg Message-ID: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC05503TLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] Metadata XML schema X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2012 09:33:55 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC05503TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, My name is Ofir and I am working for NICE systems. While reviewing the draft: draft-ietf-siprec-metadata-07, I have noticed th= at the recording element defined in metadata XML schema, does not include p= articipantsessionassoc & participantstreamassoc. It might cause issues when trying to validate the metadata against the XML = schema. I will appreciate any comment on that. Thanks, Ofir. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC05503TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

My name= is Ofir and I am working for NICE systems.

While reviewing the draft: draft-ietf-siprec-metadata-07, I hav= e noticed that the recording element defined in metadata XML schema, does n= ot include participantsessionassoc & participantstreamassoc.

It = might cause issues when trying to validate the metadata against the XML sch= ema.

 

I will appreciate any comment on that.

 

Thanks,

Ofir.  

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC05503TLVMBX01nicec_-- From Ofir.Roth@nice.com Wed Oct 17 03:04: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 2558921F84F9 for ; Wed, 17 Oct 2012 03:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk6CnhsT-Mph for ; Wed, 17 Oct 2012 03:04:21 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id EF22E21F84EA for ; Wed, 17 Oct 2012 03:04:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,599,1344200400"; d="scan'208,217";a="4637607" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 17 Oct 2012 12:04:13 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Wed, 17 Oct 2012 12:04:12 +0200 Thread-Topic: redundancy of session_id in participantsessionassoc/participant Thread-Index: Ac2sTlib11h/Lk4iSL2/IIlmzOCeUA== Message-ID: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC0554DTLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] redundancy of session_id in participantsessionassoc/participant X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2012 10:04:22 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC0554DTLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am reviewing draft-ietf-siprec-metadata-07 and observed the follwoing: "participant" element contains both session_id and participant_id. "participantsessionassoc" element is used to associate participant within s= ession (also contains participant_id & session_id attributes as a key). In that case, what is the point of setting/keeping the session_id within th= e participant element? Thanks, Ofir. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC0554DTLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am revie= wing draft-ietf-siprec-metadata-07 and observed the follwoing:<= /o:p>

 

&qu= ot;participant" element contains both session_id and participant_id. <= o:p>

"participantsessionassoc" elem= ent is used to associate participant within session (also contains particip= ant_id & session_id attributes as a key).

In that case, what is= the point of setting/keeping the session_id within the participant element= ?

 

Thanks,
Ofir.

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC0554DTLVMBX01nicec_-- From Ofir.Roth@nice.com Wed Oct 17 04:15: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 D27F321F87E4 for ; Wed, 17 Oct 2012 04:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FucPXoQHpaQ for ; Wed, 17 Oct 2012 04:15:49 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9B07B21F87E1 for ; Wed, 17 Oct 2012 04:15:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,600,1344200400"; d="scan'208,217";a="4640564" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 17 Oct 2012 13:15:47 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Wed, 17 Oct 2012 13:15:46 +0200 Thread-Topic: draft-ram-siprec-callflows-01 Thread-Index: Ac2sV49ORvpLdO1+SSymgnCxmyNtBQ== Message-ID: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC055A3TLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] draft-ram-siprec-callflows-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 11:15:50 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC055A3TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I am reviewing the examples provided in draft-ram-siprec-callflows-01 and n= oticed that it is not aligned according to draft-ietf-siprec-metadata-07. For example: 1. Session element does not contain start/stop time 2. Participant does not include disassociate-time (as in section 4.5) If those are known issues, I will appreciate if someone can let me know. Thanks, Ofir. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC055A3TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am re= viewing the examples provided in draft-ram-siprec-callflows-01 and noticed = that it is not aligned according to draft-ietf-siprec-metadata-07.

 

For e= xample:

 

<= ![if !supportLists]>1.       = Session element does not contain start/sto= p time

2.   &nbs= p;   Participant d= oes not include disassociate-time (as in section 4.5)

 

If those are known = issues, I will appreciate if someone can let me know.

 

Thanks,
Ofir.

 

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC055A3TLVMBX01nicec_-- From Ofir.Roth@nice.com Wed Oct 17 06:38: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 C7D3121F8441 for ; Wed, 17 Oct 2012 06:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsDk17orc4Qs for ; Wed, 17 Oct 2012 06:38:32 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAFD21F8606 for ; Wed, 17 Oct 2012 06:38:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,600,1344200400"; d="txt'?zip'48?scan'48,208,48";a="4646263" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 17 Oct 2012 15:38:29 +0200 From: Ofir Roth To: "Hutton, Andrew" , "siprec@ietf.org" Date: Wed, 17 Oct 2012 15:38:27 +0200 Thread-Topic: SIPREC Metadata Reviewers and examples needed. Thread-Index: AQHNozYRFYKK3Fe3gEyZahOzHahI6Je8G6nggAFu4QA= Message-ID: References: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> <8E66DB23B8154FC89802B2DA6B5B509C@VOXSTORSERVER> <506F3E83.2020307@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF0130479E@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0130479E@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC05684TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] SIPREC Metadata Reviewers and examples needed. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2012 13:38:32 -0000 --_002_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC05684TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Andrew, Attached please find are two examples of call flows:=20 1. Simple call between Alice & Bob. Alice hang up the call. 2. Simple call between Alice & Bob. Alice hold/resume the call and then han= gs up the call. I am currently working on more complex scenarios which I will post once the= y are ready.=20 I'll be happy to discuss/get comments about them.=20 Thanks, Ofir. -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Hutton, Andrew Sent: Tuesday, October 16, 2012 5:21 PM To: siprec@ietf.org Subject: [siprec] SIPREC Metadata Reviewers and examples needed. Hi All, As Paul pointed out below we really need more review of example usage of Me= tadata either of real captures of hand generated examples. Volunteers would be highly appreciated and if we could have discussion befo= re IETF85 (3 weeks time) that would also be great. Regards Andy (SIPREC Co-Chair). > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 05 October 2012 21:10 > To: siprec@ietf.org > Subject: Re: [siprec] SIPREC captures >=20 > IMO there is a great need for more examples, done by different people, > rather than just having ones done by the authors of the schema. It is > really important to get different interpretations to expose > ambiguities, > etc. >=20 > Ideally we would have examples that are done as captures from real > implementations. But it would also be helpful to have samples > constructed by hand for interesting cases. >=20 > Once we get some of those it's important that they be widely reviewed. > Two kinds of reviews are both of interest: > - a review from the perspective of an SRS implementer - commenting on > whether the example looks correct, semantically clear, and > able to be supported by an implementation. >=20 > - a review from the perspective of an SRC implementer - commenting on > differences from how the reviewer would have represented the same > case, and whether the differences are both reasonable alternatives, > which (if any) is preferable, and whether it makes sense to have > both alternatives. >=20 > Thanks, > Paul >=20 > On 10/3/12 12:14 PM, Simon Farrow wrote: > > I am just reposting this request as this would very useful to us as > well. > > Simon > > > > --------------------------------------------------------------------- > --- > > *From:* siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > > Behalf Of *Leon Portman > > *Sent:* Tuesday, October 02, 2012 6:15 AM > > *To:* Dave Higton > > *Cc:* siprec@ietf.org > > *Subject:* Re: [siprec] SIPREC captures > > > > On Oct 2, 2012 3:12 PM, "Dave Higton" > > wrote: > > > > Can anyone point me at, or send me, some SIPREC captures, please? > > PCAP format preferred, but text of the SIPREC commands and > > responses would do.____ > > > > ____ > > > > Thank you,____ > > > > ____ > > > > Dave____ > > > > ____ > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > > > > > > > _______________________________________________ > > siprec mailing list > > siprec@ietf.org > > https://www.ietf.org/mailman/listinfo/siprec > > >=20 > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec --_002_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC05684TLVMBX01nicec_ Content-Type: application/x-zip-compressed; name="SimpleCallScenario.zip" Content-Description: SimpleCallScenario.zip Content-Disposition: attachment; filename="SimpleCallScenario.zip"; size=1767; creation-date="Wed, 17 Oct 2012 13:25:47 GMT"; modification-date="Wed, 17 Oct 2012 13:25:47 GMT" Content-Transfer-Encoding: base64 UEsDBBQAAAAIADJ7UUENl1TV0QIAANgKAAAWAAAAU2ltcGxlQ2FsbFNjZW5hcmlvLnR4dN2W3W6b MBSAr1ep7+BxOxEwTdYWAV3TBK3p2gEBsu5mcsBJUAAjcJvu2XaxR9orzBiapa1YQtftYhECx5yf 7/gcm6O9FkUQoDgGU0xXGKfgNI4CDCgBfTIFomjs7yU6ugkjAmCv2+sBx7WkU98C8v4e0nOaJShT ZWCdXXrSkSzz2RhNcazCcljgNCRp/HV/76Gdw93tKJt2XgFQmvrx7bt2cpfE4BbnRURSXYAdWQA4 DUgYpXNduKEz8Ug4YfRajgOSl7OAKaSFeldEurCgNFMlabVadVYHHZLPJUWWofTp8sM4WOAEiVFa UJQGWFhrhdu1amHmPk/VCNOZmqEcJUw7iVVmZI0iMDAAtBBRlJAQGwFJshhTrEnrKS4wz8lNBvj9 S8QA/GU2sePPlu0t+u4wnNgwu3bmul7ZYwqoKEgQIYpFGiXYUGSoiFAW4aELeyq7FNg5UrrdA7n7 RlZUWdakRxrcrcQ9VuMCF+UKg/rJMcZwceEue54Dr6794cgeez56gMH1xRzPjCbi2geXqXzWDqp/ bN1oFEQZSinYGHPvDjT7/vJu5PiOOTb9C2cYo7HNvLdjTFGCzwcAkVwXUFn071J267BU3IvUQgbf EprEx7WyVGnX6BuE2/Ft2LfcpX/teqOBM3QGrkeRv/oj/CmZNsKzbfxc9JqHV8jfysJOBft2a8E2 ULcL6YUy869DojlGScsk3bOW56rhm1cfPWhe2svMnPjOubO8OvdPyz3KX9ei7PC6NVzPtFwzG/je yPWG8ftJvLDcVSnKXz8l/wXXCrwxFQ/Am2megDfHuCN4NQGqB2ds8t6yXPhXzoCaVA3aFFFvaxFV uE0RNC3KsyJQnhPB9m2wjoBnqvp8GmUPILb8lTpa2e5UHU6YkyzDIZjlJAFn46rV+d/6Cl7QKH7c Vux6IL7QGR9GxW+LQZFVRekcHB9vFsNTpW3H4maB/ARQSwMEFAAAAAgAMXtRQfzb0ScEAwAA0g8A ABwAAABTaW1wbGVIb2xkUmVzdW1lU2NlbmFyaW8udHh07VbdbpswGL1epb6Dx+1EMDRZWwRsbUeq dm2V8lvlZnLASVAAI3Ca7Nl2sUfaKwxs2qWNaJIu7aRtURQc8/0c+zv2d7S3oggCFMdggOkM4xQc xVGAASXgmAyAKBq7O4mOpmFEgNxpdw6B5fSkI68H4O4O0nOaJShTIeidXLrSAYRsNkYDHKtyNSxw GpI0/rq78yDOe3n9OMpinDcAVKF+fPuufZgnMbjFeRGRVBfkFhQATgMSRulIF6Z0KB4IH0r0Wo4D klezoHRIC3VeRLowpjRTJWk2m7Vmey2SjyQFQlm6ubywgzFOkBilBUVpgIV7r3C1V21cps9TNcJ0 qGYoR0npncRqGeQeilACA0ALEUUJCbERkCSLMcWadD/FDEY5mWaA/X6JSgB2d3xjda2ePen6jte/ dmB4Yo10nccrHVBRkCBCFIs0SrChQFkRZSjK+47cUcuvorTaUGnvwfY7qKgQatIjD5ZWYhn5uMBF tcOgfjIYrnl47nnjMwueI2syPrYn8o17tACD+Ys5HhpNiOsczIbnrBPwf+W+0SiIMpRSsDDmm+Ad 969h99Jz+58dLzRdc+77VfbNMKYowWefACK5LqCK9B/T8qdVluLOpDYy2JHQJDaunSXuXUNfQLga vm92HNfzrrxJ1/YmVs+CmWVf/xb8ARk0gi+P8XOh13gYQ16qClsibAPqzZa0pcq89pJojlGyYZHu sFb3qmFDanqxd+rFfdd36althn2fnVH2ujYtL69bw3XDM9+NkeV6rmXOLxzz6sphpuz1MvJf4DYC 3liKB8Cb0SwBb17jmsD5BOAPToSG7BvShXU5Q9YkPtguiTjcphU0bcqzVqC88ApYpXj7NCoNIG74 qXy0Su5whTPGcQjoGHP1syR0OusLlKeETmd//ThM6EQpCmh0i/9SocNOGIof65w1b4WV19kW7qgt 0yzHxTTBxRNM++OS+j/PNubZ67bNLVMyzEmW4RAMc5KAE5sz8h8kwCuo2zAqnmyDCuRtcG+xDS47 rRKEiwT5CVBLAQIUABQAAAAIADJ7UUENl1TV0QIAANgKAAAWAAAAAAAAAAEAIAAAAAAAAABTaW1w bGVDYWxsU2NlbmFyaW8udHh0UEsBAhQAFAAAAAgAMXtRQfzb0ScEAwAA0g8AABwAAAAAAAAAAQAg AAAABQMAAFNpbXBsZUhvbGRSZXN1bWVTY2VuYXJpby50eHRQSwUGAAAAAAIAAgCOAAAAQwYAAAAA --_002_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC05684TLVMBX01nicec_-- From partha@parthasarathi.co.in Wed Oct 17 08:27: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 93CC521F8525 for ; Wed, 17 Oct 2012 08:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.278 X-Spam-Level: X-Spam-Status: No, score=0.278 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ72kSlRqq2P for ; Wed, 17 Oct 2012 08:27:57 -0700 (PDT) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id 0266F21F84E4 for ; Wed, 17 Oct 2012 08:27:56 -0700 (PDT) Received: from userPC (unknown [122.166.139.129]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id C02BD1EBFD09; Wed, 17 Oct 2012 15:27:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1350487676; bh=T6WsJX1t3Qdr22HlHaJeTkIiCEQOk591GQZCPQzdzdY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=lGv22dqxe+//hxuyW1VFFpFKUbFhQREG3wQVN/ZLcsS1hpGVfr8gjEb+yOAHQHk34 ut7nmDFHAkVCcDdVwL4MT8e4JPbc48qxQUrhPUL164CSTZHEODz7d1yog5HoOdnfkD 5g9MFyN6AX49ei9/x+W9NPoBn0R4+Bg6wrWCY/LM= From: "Parthasarathi R" To: "'Ofir Roth'" , References: In-Reply-To: Date: Wed, 17 Oct 2012 20:57:48 +0530 Message-ID: <003401cdac7b$f98d3bf0$eca7b3d0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01CDACAA.134577F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2sV49ORvpLdO1+SSymgnCxmyNtBQAIdO/A Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0203.507ECE7C.012C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [siprec] draft-ram-siprec-callflows-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:27:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0035_01CDACAA.134577F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ofir, Thanks for your review. Please read inline. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth Sent: Wednesday, October 17, 2012 4:46 PM To: siprec@ietf.org Subject: [siprec] draft-ram-siprec-callflows-01 Hello, I am reviewing the examples provided in draft-ram-siprec-callflows-01 and noticed that it is not aligned according to draft-ietf-siprec-metadata-07. For example: 1. Session element does not contain start/stop time I guess that you wish to see the example with start/stop time. We will add in the next revision. BTW,start/stop time are optional elements in session. So, the callflow is inline with metadata -07 draft. 2. Participant does not include disassociate-time (as in section 4.5) Sec 4.5 is call disconnect example and so, disassociate-time exists. Please let me know the exact location where disassociate-time is missing. If those are known issues, I will appreciate if someone can let me know. Thanks, Ofir. ------=_NextPart_000_0035_01CDACAA.134577F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ofir,

 

Thanks for your = review. Please read inline.

 

Thanks

Partha

 

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ofir Roth
Sent: Wednesday, October 17, 2012 4:46 PM
To: siprec@ietf.org
Subject: [siprec] = draft-ram-siprec-callflows-01

 

Hello,

 

I am reviewing the examples provided in draft-ram-siprec-callflows-01 and noticed that it is not aligned = according to draft-ietf-siprec-metadata-07.

 

For example:

 

1.       Session element does not contain start/stop = time

<Partha> I = guess that you wish to see the example with start/stop time. We will add in = the

 next revision. =

  =

BTW,start/stop time = are optional elements in session.  So, the callflow is

inline with metadata = -07 draft.

 

</Partha>

 

2.       Participant does not include disassociate-time = (as in section 4.5)

<Partha> Sec = 4.5 is call disconnect example and so, disassociate-time exists. Please let me know = the exact location where disassociate-time is missing. = </Partha>

 

If those are known issues, I will appreciate if = someone can let me know.

 

Thanks,
Ofir.

 

------=_NextPart_000_0035_01CDACAA.134577F0-- From rmohanr@cisco.com Wed Oct 17 09:14: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 F26DD21F863C for ; Wed, 17 Oct 2012 09:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.723 X-Spam-Level: X-Spam-Status: No, score=-9.723 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdxFeQPCuhJr for ; Wed, 17 Oct 2012 09:14:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB9221F8605 for ; Wed, 17 Oct 2012 09:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=796; q=dns/txt; s=iport; t=1350490460; x=1351700060; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=SbliYXaLLznOZMvXb0tuX/wrayHXViAaS0iIXIAkBTk=; b=hgQRpbT1NvQMraWfUzEqcN1e4Z7vBeM4QyMeFX//DDEcR68PrW4Wi3vG bJiIoftAkfM5WGsyqzB6AswkEZe5OOaWE8YViLfC2ICCstYbJjYvc2IRP LoaPtrorM/3lqJOd4qvhEBM662vx3rpeNJomQczWRjxEu3P/c9lJwUnqp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAA7YflCtJV2Y/2dsb2JhbABFhUq6VoEIghkHAQEBAwEBAQEPASc0EA0BCCIUNwslAgQBEggahScHgi4GC5snoCcEkTpgA5YcjhiBa4JvgVwjGA X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="132632896" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 17 Oct 2012 16:14:20 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9HGEKlg022438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 16:14:20 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 11:14:20 -0500 From: "Ram Mohan R (rmohanr)" To: Ofir Roth , "siprec@ietf.org" Thread-Topic: [siprec] Metadata XML schema Thread-Index: AQHNrIJ2lL09mgjXiEyHZVfrIZS/CA== Date: Wed, 17 Oct 2012 16:14:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.70.132] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--31.916600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <4CE1042557859745A9D30F0D73046BCA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata XML schema X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2012 16:14:25 -0000 Ofir, Thanks for your comment. This is fixed and will be included in the next revision (ver 08) that I plan to publish later today. Ram > On 17/10/12 3:03 PM, "Ofir Roth" wrote: >Hello, >=20 >My name is Ofir and I am working for NICE systems. >While reviewing the draft: draft-ietf-siprec-metadata-07, I have noticed >that the recording element defined in metadata XML schema, does not >include participantsessionassoc & participantstreamassoc. > >It might cause issues when trying to validate the metadata against the >XML schema.=20 >=20 >I will appreciate any comment on that. >=20 >Thanks, >Ofir. =20 > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Wed Oct 17 09:14: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 4D03621F863C for ; Wed, 17 Oct 2012 09:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbh+8psipIqU for ; Wed, 17 Oct 2012 09:14:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 99AC021F8605 for ; Wed, 17 Oct 2012 09:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=789; q=dns/txt; s=iport; t=1350490497; x=1351700097; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=atY47xwwdFFu2D5NQP6Hsu91BihU2kp18JRAurSledY=; b=h6EdthF60mBFQUwt1skCiipLe9r1OSVi+V84u0EJuC+PR81MG2t8UODZ fiQUwuHjSzYJ6fj6thFK1VE9PNv0xqrvA3ZHIKNXT8DytTk6oMCm2/Lkh shnDzfTP8M25/7PXJXnxMqT0mS46GMkeXRMfjenudeHCKFH/p5/wSisSD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FADzZflCtJXHA/2dsb2JhbABFhUq6VoEIgiABAQEDAQEBAQ8BJzQQDQEIIhQ3CyUCBAESCBqHXAYLmyigJwSROmADnymFC4Frgm+CFw X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="132673042" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 17 Oct 2012 16:14:56 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9HGEurV000835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 16:14:56 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 11:14:55 -0500 From: "Ram Mohan R (rmohanr)" To: Ofir Roth , "siprec@ietf.org" Thread-Topic: [siprec] redundancy of session_id in participantsessionassoc/participant Thread-Index: AQHNrIKLpZbE1IdXl0qHr1eIeZlaFw== Date: Wed, 17 Oct 2012 16:14:55 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.70.132] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--35.412200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] redundancy of session_id in participantsessionassoc/participant X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2012 16:14:58 -0000 > On 17/10/12 3:34 PM, "Ofir Roth" wrote: >Hi, >=20 >I am reviewing draft-ietf-siprec-metadata-07 and observed the follwoing: >=20 >"participant" element contains both session_id and participant_id. >"participantsessionassoc" element is used to associate participant within >session (also contains participant_id & session_id attributes as a key). > >In that case, what is the point of setting/keeping the session_id within >the participant element? element will not have session_id. This is taken care and will be updated in the next revision. Regards, Ram >=20 >=20 >Thanks, >Ofir. > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From pkyzivat@alum.mit.edu Wed Oct 17 09:17: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 E33C321F867F for ; Wed, 17 Oct 2012 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owvMEbtQxToc for ; Wed, 17 Oct 2012 09:17:46 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id E26CA21F866B for ; Wed, 17 Oct 2012 09:17:45 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id CFxf1k05a1ZXKqc53GHq2A; Wed, 17 Oct 2012 16:17:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id CGDt1k0113ZTu2S3hGDuYK; Wed, 17 Oct 2012 16:13:55 +0000 Message-ID: <507ED8F5.9010905@alum.mit.edu> Date: Wed, 17 Oct 2012 12:12:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> <8E66DB23B8154FC89802B2DA6B5B509C@VOXSTORSERVER> <506F3E83.2020307@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF0130479E@MCHP04MSX.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] SIPREC Metadata Reviewers and examples needed. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 17 Oct 2012 16:17:47 -0000 Hi Ofir, Welcome! Are you filling in now that Leon has left Nice? On 10/17/12 9:38 AM, Ofir Roth wrote: > Hello Andrew, > > Attached please find are two examples of call flows: Are these constructed manually? Or have they been constructed by a software implementation of siprec? (I appreciate both. Some automated ones would be good because we have a chance of getting more complete examples than are feasible manually.) Thanks, Paul > 1. Simple call between Alice & Bob. Alice hang up the call. > 2. Simple call between Alice & Bob. Alice hold/resume the call and then hangs up the call. > > I am currently working on more complex scenarios which I will post once they are ready. > I'll be happy to discuss/get comments about them. > > > Thanks, > Ofir. > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Hutton, Andrew > Sent: Tuesday, October 16, 2012 5:21 PM > To: siprec@ietf.org > Subject: [siprec] SIPREC Metadata Reviewers and examples needed. > > Hi All, > > As Paul pointed out below we really need more review of example usage of Metadata either of real captures of hand generated examples. > > Volunteers would be highly appreciated and if we could have discussion before IETF85 (3 weeks time) that would also be great. > > Regards > Andy (SIPREC Co-Chair). > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 05 October 2012 21:10 >> To: siprec@ietf.org >> Subject: Re: [siprec] SIPREC captures >> >> IMO there is a great need for more examples, done by different people, >> rather than just having ones done by the authors of the schema. It is >> really important to get different interpretations to expose >> ambiguities, >> etc. >> >> Ideally we would have examples that are done as captures from real >> implementations. But it would also be helpful to have samples >> constructed by hand for interesting cases. >> >> Once we get some of those it's important that they be widely reviewed. >> Two kinds of reviews are both of interest: >> - a review from the perspective of an SRS implementer - commenting on >> whether the example looks correct, semantically clear, and >> able to be supported by an implementation. >> >> - a review from the perspective of an SRC implementer - commenting on >> differences from how the reviewer would have represented the same >> case, and whether the differences are both reasonable alternatives, >> which (if any) is preferable, and whether it makes sense to have >> both alternatives. >> >> Thanks, >> Paul >> >> On 10/3/12 12:14 PM, Simon Farrow wrote: >>> I am just reposting this request as this would very useful to us as >> well. >>> Simon >>> >>> --------------------------------------------------------------------- >> --- >>> *From:* siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On >>> Behalf Of *Leon Portman >>> *Sent:* Tuesday, October 02, 2012 6:15 AM >>> *To:* Dave Higton >>> *Cc:* siprec@ietf.org >>> *Subject:* Re: [siprec] SIPREC captures >>> >>> On Oct 2, 2012 3:12 PM, "Dave Higton" >> > wrote: >>> >>> Can anyone point me at, or send me, some SIPREC captures, please? >>> PCAP format preferred, but text of the SIPREC commands and >>> responses would do.____ >>> >>> ____ >>> >>> Thank you,____ >>> >>> ____ >>> >>> Dave____ >>> >>> ____ >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From internet-drafts@ietf.org Thu Oct 18 01:16: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 D111C21F853B; Thu, 18 Oct 2012 01:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2Q6L3QAAj7q; Thu, 18 Oct 2012 01:16:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E354B21F8611; Thu, 18 Oct 2012 01:16:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121018081604.32698.39230.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 01:16:04 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-metadata-08.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 08:16:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Initiation Protocol (SIP) Recording Metadata Author(s) : Ram Mohan Ravindranath Parthasarathi Ravindran Paul Kyzivat Filename : draft-ietf-siprec-metadata-08.txt Pages : 48 Date : 2012-10-18 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-metadata-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rmohanr@cisco.com Thu Oct 18 01:23: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 64ED121F84B8 for ; Thu, 18 Oct 2012 01:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuXRbpRslZiR for ; Thu, 18 Oct 2012 01:23:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3EC21F845B for ; Thu, 18 Oct 2012 01:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2612; q=dns/txt; s=iport; t=1350548636; x=1351758236; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=eANABZ25wwcmoHuvev6decFwEeKpbKgD4GdYGG+Ykes=; b=bNGKEn371fc4M4+8bMVN3aDu5C+1i7eCBUfGkxW1Y2xwKWb7kFpQZF/R p9+3EM6OIR+bl6oW2Ww97RnDjd1zQO4/Sqrds3taTLkE9zofA0DWkzx0v WI+S9noXEJF73txm7z4f8LOr7E0jB8XrlcyWTKrlEwp3UKgccZKRcGVOR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGi7f1CtJV2Y/2dsb2JhbABFwDyBCIIgAQEBAwEBAQEPASc0EA0BCCIUNwslAgQTCAEZh1wGC5pTgSugJYtyhUhgA5cAjTSBa4JvgWM0 X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="132911922" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 18 Oct 2012 08:23:56 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9I8Ntql023224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Oct 2012 08:23:55 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 03:23:55 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: [siprec] I-D Action: draft-ietf-siprec-metadata-08.txt Thread-Index: AQHNrQnpFGNEPEIDtU6bwvg/I8u2XA== Date: Thu, 18 Oct 2012 08:23:55 +0000 Message-ID: In-Reply-To: <20121018081604.32698.39230.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.64.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--38.848200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <033CCF5ECB3F494EBB3C18AF673ADBD5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] I-D Action: draft-ietf-siprec-metadata-08.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 08:23:57 -0000 Hi all, Following are the changes done from ver 07 of the draft. You can get the diffs here http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-siprec-= meta data-08.txt 1) Incorporated the following accepted comments - XML schema change and all the example instances . See this http://www.ietf.org/mail-archive/web/siprec/current/msg03298.html - Editorial comments CSRS association in the model. See http://www.ietf.org/mail-archive/web/siprec/current/msg03310.html - Editorial comments from Simon. See http://www.ietf.org/mail-archive/web/siprec/current/msg03312.html - Editorial comments from Alan - Pauls proposal for stream here and updated examples to reflect the same http://www.ietf.org/mail-archive/web/siprec/current/msg03356.html - Comments from Ofir Roth Please review and let us know your comments. Regards, Ram > On 18/10/12 1:46 PM, "internet-drafts@ietf.org" > wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the SIP Recording Working Group of the IETF. > > Title : Session Initiation Protocol (SIP) Recording Metadata > Author(s) : Ram Mohan Ravindranath > Parthasarathi Ravindran > Paul Kyzivat > Filename : draft-ietf-siprec-metadata-08.txt > Pages : 48 > Date : 2012-10-18 > >Abstract: > Session recording is a critical requirement in many communications > environments such as call centers and financial trading. In some of > these environments, all calls must be recorded for regulatory, > compliance, and consumer protection reasons. Recording of a session > is typically performed by sending a copy of a media stream to a > recording device. This document describes the metadata model as > viewed by Session Recording Server(SRS) and the Recording metadata > format. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-siprec-metadata-08 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-metadata-08 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From rmohanr@cisco.com Thu Oct 18 01:28: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 934B721F848B for ; Thu, 18 Oct 2012 01:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnubWJc7E3BF for ; Thu, 18 Oct 2012 01:28:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6505B21F8467 for ; Thu, 18 Oct 2012 01:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=797; q=dns/txt; s=iport; t=1350548922; x=1351758522; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=R5tXWEvMhr58jKhjBW3TIwBdLX7UdMf3MysyZqoWRaU=; b=UUybfvHE9Inn9OG5U4esfxD0CX4IK3xnh0B0WUQr1WUsdZGw7J/B4kuR lj3rrTwt4ub+cDc+FU9Tst/y67CmVN6aMCxuqshQYSr7Rd9JsicM6CoLM jH20UxYEzIEoSxXOnRI08T1BrSE8u1FlceOxzpZe3pq2bn196QA0pFhOM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACa9f1CtJXHA/2dsb2JhbABFwDyBCIIiAQQSASdRASoUQicEGxqHYppegSugJYtihVhgA6Q0gWuCb4IX X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="132693584" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 18 Oct 2012 08:28:42 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9I8SgOr031046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Oct 2012 08:28:42 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 03:28:41 -0500 From: "Ram Mohan R (rmohanr)" To: "siprec@ietf.org" Thread-Topic: Two questions on draft-ietf-siprec-metadata Thread-Index: AQHNrQqU5qNQ89wCc06Y7ZJvLCpf9A== Date: Thu, 18 Oct 2012 08:28:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [173.39.64.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--33.105800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <62ABD971908C8141A2ECDA93FD4A33DB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Two questions on draft-ietf-siprec-metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 08:28:43 -0000 Hi All, I have two questions for which I need inputs on what we could do: 1) The object diagrams in the Appendix A have gone out of sync now due to changes in the model. It would take some time to re-draw. I wonder if they are really needed now ? I don't know if any one have paidsome attention to them ? Comments ? I feel the UML diagram is sufficient enough and we may not need the Appendix A. 2)What about Appendix B. Do we need that now given that we are having call flows in a separate draft ? My preference here to move the Appendix B to call flow ID and have both call flows + metadata in the same document (draft-ram-siprec-callflows). draft-ietf-siprec-metadata can just refer to call flows document for examples Let me know your comments on this. Regards, Ram From trac+siprec@trac.tools.ietf.org Thu Oct 18 01:52: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 5154921F8557 for ; Thu, 18 Oct 2012 01:52:08 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk3oXoMgRY9v for ; Thu, 18 Oct 2012 01:52:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB321F8533 for ; Thu, 18 Oct 2012 01:52:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:56974 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOlpb-0002g6-My; Thu, 18 Oct 2012 10:51:55 +0200 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: rmohanr@cisco.com X-Trac-Project: siprec Date: Thu, 18 Oct 2012 08:51:55 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/72#comment:1 Message-ID: <073.bd3a40451f0b6fd212d5a78efcf551b9@trac.tools.ietf.org> References: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <058.f76a86cfba526ca37c258c5ffc98b278@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #72: How to represent attributes of association in metadata Model and in XML ? 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, 18 Oct 2012 08:52:08 -0000 #72: How to represent attributes of association in metadata Model and in XML ? Changes (by rmohanr@…): * status: new => closed * resolution: => fixed Comment: This has been taken care now and is in draft from ver 06 -- --------------------------------+------------------------ Reporter: rmohanr@… | Owner: rmohanr@… Type: defect | Status: closed Priority: major | Milestone: Component: metadata | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------ Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Thu Oct 18 01:52: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 BA87F21F85A4 for ; Thu, 18 Oct 2012 01:52:50 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rWzrSuFHvHk for ; Thu, 18 Oct 2012 01:52:49 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id C325921F855D for ; Thu, 18 Oct 2012 01:52:49 -0700 (PDT) Received: from localhost ([127.0.0.1]:57124 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOlqS-0003KU-Er; Thu, 18 Oct 2012 10:52:48 +0200 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: rmohanr@cisco.com X-Trac-Project: siprec Date: Thu, 18 Oct 2012 08:52:48 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/77#comment:1 Message-ID: <073.9f44e49bc835563573daf4c3e815513a@trac.tools.ietf.org> References: <058.40bd2ad76f0bbaeee8ea367ea03f4689@trac.tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <058.40bd2ad76f0bbaeee8ea367ea03f4689@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #77: Address terminology/language comments sent on metadata ver - 04 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, 18 Oct 2012 08:52:50 -0000 #77: Address terminology/language comments sent on metadata ver - 04 Changes (by rmohanr@…): * status: new => closed * resolution: => fixed Comment: taken care -- --------------------------------+------------------------ Reporter: rmohanr@… | Owner: rmohanr@… Type: defect | Status: closed Priority: minor | Milestone: Component: Metadata Model | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------ Ticket URL: siprec From trac+siprec@trac.tools.ietf.org Thu Oct 18 01:53: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 63BA821F85F0 for ; Thu, 18 Oct 2012 01:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CASljHPFBeCV for ; Thu, 18 Oct 2012 01:53:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 978A621F855D for ; Thu, 18 Oct 2012 01:53:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:57222 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOlqw-0003LW-92; Thu, 18 Oct 2012 10:53:18 +0200 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: rmohanr@cisco.com X-Trac-Project: siprec Date: Thu, 18 Oct 2012 08:53:18 -0000 X-URL: http://tools.ietf.org/siprec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/siprec/trac/ticket/74#comment:1 Message-ID: <073.3fdd2741a65018ccde8ef29661a2bdc8@trac.tools.ietf.org> References: <058.4a0278465406200a047a48f641305ebc@trac.tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <058.4a0278465406200a047a48f641305ebc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: rmohanr@cisco.com, siprec@ietf.org X-SA-Exim-Mail-From: trac+siprec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: siprec@ietf.org Subject: Re: [siprec] #74: Usage of xs:string in metadata schema 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, 18 Oct 2012 08:53:20 -0000 #74: Usage of xs:string in metadata schema Changes (by rmohanr@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------ Reporter: rmohanr@… | Owner: rmohanr@… Type: defect | Status: closed Priority: minor | Milestone: Component: metadata | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------ Ticket URL: siprec From rmohanr@cisco.com Thu Oct 18 09:27:04 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 8F37C21F883B for ; Thu, 18 Oct 2012 09:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3y8YxoNIJ+b for ; Thu, 18 Oct 2012 09:27:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F099D21F8741 for ; Thu, 18 Oct 2012 09:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2260; q=dns/txt; s=iport; t=1350577624; x=1351787224; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=CApmxppOroZHlipNudJd6vYIjS6s73AeFFHcIXfpqQk=; b=YrnjAyw8pR2vQzIRIcQ80jHDsH3/pBy9dN+uQ7rHwur7cbCM1MEEs1xL bPMUOvEjAAafwhs1ZR1ykDTaHUNkIbhEWhJHc5Ppvqb5lP09t5XCXhMTA RkoptgRIDNmg9WeyxteQx66Iz8vUlbyao3lDzLA2Zk2FuuDs2o2MAwGZI E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMwsgFCtJXG+/2dsb2JhbABFwEqBCIIgAQEBAwEBAQEPASc0BAwNAQgOFBQ3CyUCBAESCBqHXAYLnF+gNgSROmADpDSBa4Jvghc X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="133091550" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 18 Oct 2012 16:27:03 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9IGR3A6014832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 16:27:03 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 11:27:03 -0500 From: "Ram Mohan R (rmohanr)" To: Brian Rosen , "siprec@ietf.org" Thread-Topic: [siprec] Time Sync Thread-Index: AQHNrU1nUN8F1j8yY0uNd/TwRyu62A== Date: Thu, 18 Oct 2012 16:27:03 +0000 Message-ID: In-Reply-To: <85CA3EE0-C2F4-4599-9D95-B1A5028A6761@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.83.90] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--48.045100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7E87F7C6FC10C1419CEAAC300EA4D833@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Time Sync X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2012 16:27:04 -0000 Hello Brian, Please see inline for some comments on this question. > On 03/10/12 7:14 PM, "Brian Rosen" wrote: >We're planning on using siprec in NENA for Next Generation 9-1-1 media >recording. An issue arose in the past few days about how we would time >sync related recordings. This happens in several real world >circumstances where there is not one RS that has all of the media streams >when you play them back. 1) When you say related recordings, how are the recording related ? Are all these recording part of same CS but having multiple Recording Sessions (RS) from the same SRC ? Or 2) are they different CS's from the same SRC stitched together as part of same CS-group ? Or 3) Is it some other scenario ? IOW I believe SRC would definitely have knowledge that these Recording Sessions are related and must have conveyed the same in the metadata either by having same session_id in case it is like (1) or cs-group Unique ID in case of (2).=20 Apart from conveying this at this level in the metadata we don't have any thing at stream level. In general I would be interested in hearing of any feedback from your implementation if the current metadata is not sufficient for the use-case/scenario you have. Please let us know. >=20 > >If RTCP is implemented on CS, then the SRC knows the relationship between >wall clock and RTP timestamps. Even if it doesn't have sender reports, >it knows when it received the packets and could relate wall clock to it's >view of RTP timestamps. In case RTCP is present on the CS, SRC can definitely learn wall clock time of CS RTP streams. Now depending on the RTP model at the SRC the RTCP reports may be sent as is or re-generated. The protocol document has some text on the same. Ram > >If RTCP is implemented on the RS, the SRS could record absolute time of >the RS, and if it knew the delay of the SRC (if it was approximately >constant), that is probably good enough. But we have no text, and no way >for the SRC to tell the SRS about what it knows about the CS time. > >Brian >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From br@brianrosen.net Thu Oct 18 22:35: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 268DB21F8592 for ; Thu, 18 Oct 2012 22:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.139 X-Spam-Level: X-Spam-Status: No, score=-100.139 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7uYIAIHjz8K for ; Thu, 18 Oct 2012 22:35:55 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2937321F858F for ; Thu, 18 Oct 2012 22:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=XFPqnXYDrBHu6C5X5upPPdlwslZzRlu9NU8EG6hyRQs=; b=D0+cSW9//OS6hACfa4Mjj2PhxqhrmicpCh7U3IhktxZWOmoVwoWw9VY5oHInG5P2bEDDQRd4WGShEkzA8nTOCcffFbM24veNevxel8rK3oonnqPQEct2bxAHTQJxjWKy; Received: from neustargw.va.neustar.com ([209.173.53.233]:45013 helo=[192.168.133.131]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TP5FR-0007Bt-Sr; Fri, 19 Oct 2012 01:35:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Rosen In-Reply-To: Date: Fri, 19 Oct 2012 07:35:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8DA914E5-9162-4431-9D0E-9DE2FA302D21@brianrosen.net> References: To: Ram Mohan R (rmohanr) X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: "siprec@ietf.org" Subject: Re: [siprec] Time Sync X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2012 05:35:56 -0000 See inline On Oct 18, 2012, at 6:27 PM, Ram Mohan R (rmohanr) = wrote: > Hello Brian, >=20 > Please see inline for some comments on this question. >=20 >> On 03/10/12 7:14 PM, "Brian Rosen" wrote: >=20 >> We're planning on using siprec in NENA for Next Generation 9-1-1 = media >> recording. An issue arose in the past few days about how we would = time >> sync related recordings. This happens in several real world >> circumstances where there is not one RS that has all of the media = streams >> when you play them back. >=20 > 1) When you say related recordings, how are the recording related ? = Are > all these recording part of same CS but having multiple Recording = Sessions > (RS) from the same SRC ? > Or 2) are they different CS's from the same SRC stitched together as = part > of same CS-group ? > Or 3) Is it some other scenario ? Two examples: There is an ongoing incident, with media recorded. Then = another incident that is related to, but separate from the first. On = playback, you need a time synced version of both. The other is more = common - you continuously record a radio channel because there is no = practical way to identify specific radio transmissions for a specific = incident. You then record, say a 9-1-1 call which has a caller on the = line when the responder arrives. You need to play back the radio = channel and the 9-1-1 call simultaneously. >=20 > IOW I believe SRC would definitely have knowledge that these Recording > Sessions are related and must have conveyed the same in the metadata > either by having same session_id in case it is like (1) or cs-group = Unique > ID in case of (2).=20 >=20 > Apart from conveying this at this level in the metadata we don't have = any > thing at stream level. >=20 > In general I would be interested in hearing of any feedback from your > implementation if the current metadata is not sufficient for the > use-case/scenario you have. Please let us know. In the first case, we can relate them, but when the incidents start, we = don't know they are related. After a while, we figure out that they are = related. Then we can change the metadata. However, the time sync has = to exist for the entirety of the calls. In the second, there is no practical way to have common metadata. >=20 >=20 >>=20 >>=20 >> If RTCP is implemented on CS, then the SRC knows the relationship = between >> wall clock and RTP timestamps. Even if it doesn't have sender = reports, >> it knows when it received the packets and could relate wall clock to = it's >> view of RTP timestamps. >=20 > In case RTCP is present on the CS, SRC can definitely learn wall clock > time of CS RTP streams. Now depending on the RTP model at the SRC the = RTCP > reports may be sent as is or re-generated. The protocol document has = some > text on the same. >=20 >=20 > Ram >=20 >=20 >>=20 >> If RTCP is implemented on the RS, the SRS could record absolute time = of >> the RS, and if it knew the delay of the SRC (if it was approximately >> constant), that is probably good enough. But we have no text, and no = way >> for the SRC to tell the SRS about what it knows about the CS time. >>=20 >> Brian >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >>=20 >=20 >=20 From Ofir.Roth@nice.com Fri Oct 19 12:05: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 E14EB21F878C for ; Fri, 19 Oct 2012 12:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAR9dDm7MaJi for ; Fri, 19 Oct 2012 12:05:41 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id B9C0E21F87EB for ; Fri, 19 Oct 2012 12:05:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,615,1344200400"; d="scan'208,217";a="4677716" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Fri, 19 Oct 2012 21:05:37 +0200 From: Ofir Roth To: Parthasarathi R , "siprec@ietf.org" Date: Fri, 19 Oct 2012 21:05:35 +0200 Thread-Topic: [siprec] draft-ram-siprec-callflows-01 Thread-Index: Ac2sV49ORvpLdO1+SSymgnCxmyNtBQAIdO/AAGyk/3A= Message-ID: References: <003401cdac7b$f98d3bf0$eca7b3d0$@co.in> In-Reply-To: <003401cdac7b$f98d3bf0$eca7b3d0$@co.in> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC75BD1TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] draft-ram-siprec-callflows-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:05:42 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC75BD1TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, According to the metadata scheme: There is no associate/disassociate time as part of the participant definiti= on while it appears in the call flow example of section 4.5. And session is defined as follow: According to the session definition, session does not contain start/stop ti= me while it appears in call flow document. I am interested which is the up to date version that should be used (call f= low or metadata scheme). Thanks, Ofir. From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: Wednesday, October 17, 2012 5:28 PM To: Ofir Roth; siprec@ietf.org Subject: RE: [siprec] draft-ram-siprec-callflows-01 Hi Ofir, Thanks for your review. Please read inline. Thanks Partha From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of Ofir Roth Sent: Wednesday, October 17, 2012 4:46 PM To: siprec@ietf.org Subject: [siprec] draft-ram-siprec-callflows-01 Hello, I am reviewing the examples provided in draft-ram-siprec-callflows-01 and n= oticed that it is not aligned according to draft-ietf-siprec-metadata-07. For example: 1. Session element does not contain start/stop time I guess that you wish to see the example with start/stop time. We = will add in the next revision. BTW,start/stop time are optional elements in session. So, the callflow is inline with metadata -07 draft. 2. Participant does not include disassociate-time (as in section 4.5) Sec 4.5 is call disconnect example and so, disassociate-time exist= s. Please let me know the exact location where disassociate-time is missing= . If those are known issues, I will appreciate if someone can let me know. Thanks, Ofir. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC75BD1TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

According to the metadata scheme:

=

 =

<xs:complexType n= ame=3D"participant">

       = <xs:sequence>

         &n= bsp; <xs:element name=3D"nameID" type=3D"nameID"

 =             maxOccur= s=3D"1"/>

        <xs:any n= amespace=3D'##other'

         &n= bsp;         minOccurs=3D'0'

 &nb= sp;            =      maxOccurs=3D'unbounded'

     = ;            &n= bsp; processContents=3D'lax'/>

       </xs= :sequence>

       <xs:attribute name=3D&qu= ot;participant_id" type=3D"xs:base64Binary"

   &= nbsp;        use=3D"required"/= >

       <xs:attribute name=3D"sessio= n_id" type=3D"xs:base64Binary"

     &n= bsp;      use=3D"required"/>

  = ; </xs:complexType>

There is no associate/disassociate time as part of t= he participant definition while it appears in the call flow example of sect= ion 4.5.

 

And session is defined as follow:

 

<xs:complexType name=3D&q= uot;session">

       <xs:seque= nce>

         <xs:element name= =3D"reason" type=3D"xs:string"

    &nb= sp;           minOccurs= =3D"0"/>

         <xs:= element name=3D"group-ref" type=3D"xs:base64Binary"

 =             &nb= sp;  minOccurs=3D"0" maxOccurs=3D"1"/>

  = ;         <xs:any namespace=3D'#= #other'

           &nbs= p;       minOccurs=3D'0'

        &nb= sp;          maxOccurs=3D'unbo= unded'

            = ;       processContents=3D'lax'/>

  = ;     </xs:sequence>

     &= nbsp; <xs:attribute name=3D"session_id" type=3D"xs:base64= Binary"

           = ; use=3D"required"/>

   </xs:complexType>

 = ;

Accord= ing to the session definition, session does not contain start/stop time whi= le it appears in call flow document.

 

I am interested which is the up to d= ate version that should be used (call flow or metadata scheme).<= /span>

 

Thanks,Ofir.

 

From:<= /b> Part= hasarathi R [mailto:partha@parthasarathi.co.in]
Sent: Wednesday,= October 17, 2012 5:28 PM
To: Ofir Roth; siprec@ietf.org
Su= bject: RE: [siprec] draft-ram-siprec-callflows-01

=

 

= Hi Ofir,

 

Thanks for your review. Please read= inline.

 

Thanks

Partha

 

From: siprec-bounces@ietf.o= rg [mailto:siprec-bounces@ie= tf.org] On Behalf Of Ofir Roth
Sent: Wednesday, Octobe= r 17, 2012 4:46 PM
To: siprec@= ietf.org
Subject: [siprec] draft-ram-siprec-callflows-01=

 

Hello,

 

I am reviewing the examples provided in draft-ram= -siprec-callflows-01 and noticed that it is not aligned according to draft-= ietf-siprec-metadata-07.

 

For example:

 

1.   &n= bsp;   Session ele= ment does not contain start/stop time

<Partha> I guess that you wish to see the= example with start/stop time. We will add in the

 next revision.

 

BTW,= start/stop time are optional elements in session.  So, the callflow is=

i= nline with metadata -07 draft.

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

</Partha>

 

<= p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 = lfo2'>2.       = Participant does not include disass= ociate-time (as in section 4.5)

<Partha> Sec 4.5 is call disconnect example and= so, disassociate-time exists. Please let me know the exact location where = disassociate-time is missing. </Partha>

 

If those are known i= ssues, I will appreciate if someone can let me know.

 

Thanks,
Ofir.

 

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BC75BD1TLVMBX01nicec_-- From Ofir.Roth@nice.com Fri Oct 19 12:34: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 D8E1921F859E for ; Fri, 19 Oct 2012 12:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ycbUroo2GL for ; Fri, 19 Oct 2012 12:34:54 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 22BEA21F8562 for ; Fri, 19 Oct 2012 12:34:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,616,1344200400"; d="scan'208";a="4678138" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Fri, 19 Oct 2012 21:34:24 +0200 From: Ofir Roth To: Paul Kyzivat , "siprec@ietf.org" Date: Fri, 19 Oct 2012 21:34:21 +0200 Thread-Topic: [siprec] SIPREC Metadata Reviewers and examples needed. Thread-Index: Ac2sgvaOBDjQWvU5T2GTUKa5VxnIXABqfKTA Message-ID: References: <9B0B6FB9606F4D4AB133C5E9A203B694055EA31D26@SOUEXC01.eu.nice.com> <8E66DB23B8154FC89802B2DA6B5B509C@VOXSTORSERVER> <506F3E83.2020307@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF0130479E@MCHP04MSX.global-ad.net> <507ED8F5.9010905@alum.mit.edu> In-Reply-To: <507ED8F5.9010905@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] SIPREC Metadata Reviewers and examples needed. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 19 Oct 2012 19:34:55 -0000 Thanks Paul! The code examples were constructed by a software. I wrote some code that en= ables to create call flows pretty easily.=20 In addition, I am currently working on some more complex scenarios which I = plan to post soon.=20 BR, Ofir. =20 -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Wednesday, October 17, 2012 6:13 PM To: siprec@ietf.org Subject: Re: [siprec] SIPREC Metadata Reviewers and examples needed. Hi Ofir, Welcome! Are you filling in now that Leon has left Nice? On 10/17/12 9:38 AM, Ofir Roth wrote: > Hello Andrew, > > Attached please find are two examples of call flows: Are these constructed manually? Or have they been constructed by a software= implementation of siprec? (I appreciate both. Some automated ones would be good because we have a cha= nce of getting more complete examples than are feasible manually.) Thanks, Paul > 1. Simple call between Alice & Bob. Alice hang up the call. > 2. Simple call between Alice & Bob. Alice hold/resume the call and then h= angs up the call. > > I am currently working on more complex scenarios which I will post once t= hey are ready. > I'll be happy to discuss/get comments about them. > > > Thanks, > Ofir. > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 > Behalf Of Hutton, Andrew > Sent: Tuesday, October 16, 2012 5:21 PM > To: siprec@ietf.org > Subject: [siprec] SIPREC Metadata Reviewers and examples needed. > > Hi All, > > As Paul pointed out below we really need more review of example usage of = Metadata either of real captures of hand generated examples. > > Volunteers would be highly appreciated and if we could have discussion be= fore IETF85 (3 weeks time) that would also be great. > > Regards > Andy (SIPREC Co-Chair). > > >> -----Original Message----- >> From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: 05 October 2012 21:10 >> To: siprec@ietf.org >> Subject: Re: [siprec] SIPREC captures >> >> IMO there is a great need for more examples, done by different=20 >> people, rather than just having ones done by the authors of the=20 >> schema. It is really important to get different interpretations to=20 >> expose ambiguities, etc. >> >> Ideally we would have examples that are done as captures from real=20 >> implementations. But it would also be helpful to have samples=20 >> constructed by hand for interesting cases. >> >> Once we get some of those it's important that they be widely reviewed. >> Two kinds of reviews are both of interest: >> - a review from the perspective of an SRS implementer - commenting on >> whether the example looks correct, semantically clear, and >> able to be supported by an implementation. >> >> - a review from the perspective of an SRC implementer - commenting on >> differences from how the reviewer would have represented the same >> case, and whether the differences are both reasonable alternatives, >> which (if any) is preferable, and whether it makes sense to have >> both alternatives. >> >> Thanks, >> Paul >> >> On 10/3/12 12:14 PM, Simon Farrow wrote: >>> I am just reposting this request as this would very useful to us as >> well. >>> Simon >>> >>> -------------------------------------------------------------------- >>> - >> --- >>> *From:* siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On=20 >>> Behalf Of *Leon Portman >>> *Sent:* Tuesday, October 02, 2012 6:15 AM >>> *To:* Dave Higton >>> *Cc:* siprec@ietf.org >>> *Subject:* Re: [siprec] SIPREC captures >>> >>> On Oct 2, 2012 3:12 PM, "Dave Higton" >> > wrote: >>> >>> Can anyone point me at, or send me, some SIPREC captures, please? >>> PCAP format preferred, but text of the SIPREC commands and >>> responses would do.____ >>> >>> ____ >>> >>> Thank you,____ >>> >>> ____ >>> >>> Dave____ >>> >>> ____ >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >>> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > > > > _______________________________________________ > siprec mailing 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 Sat Oct 20 06:03:12 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 70C3521F8789 for ; Sat, 20 Oct 2012 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.161 X-Spam-Level: X-Spam-Status: No, score=-10.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYUoUD1GbgRE for ; Sat, 20 Oct 2012 06:03:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 89B7E21F865F for ; Sat, 20 Oct 2012 06:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3589; q=dns/txt; s=iport; t=1350738191; x=1351947791; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ul9Ua4fLUNQrinXC5cHP90YmuR87ezy/9342oSURe1o=; b=E3ysB96ijaM4ASke4O8dwRHmqGYKy9LHwp/XBTjtXHeJBL/bT5xtRJK4 hsQDTuyjfo98ZkvObFk4DvNhrLIzqzNbe1apZYvF3019ZC3SdRIjFWc4K vYnLPIQUY9m0P41TwRYZrc24gvuuSJKfIpr9lS8VTbZu9B8RWPFaYiV3k w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJigglCtJV2Y/2dsb2JhbABEwQyBCIIgAQEBAwEBAQEPASc0EA0BCBEEAQELFAkuCxQJCAIEARIIGodcBgubSJ9MBItahg9gA6Q7gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,621,1344211200"; d="scan'208";a="133683637" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 20 Oct 2012 13:03:11 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9KD3As4023033 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 20 Oct 2012 13:03:11 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.251]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Sat, 20 Oct 2012 08:03:10 -0500 From: "Ram Mohan R (rmohanr)" To: Ofir Roth , Parthasarathi R , "siprec@ietf.org" Thread-Topic: [siprec] draft-ram-siprec-callflows-01 Thread-Index: AQHNrsNBoux/T2+ES0W7qhHp5LkoQA== Date: Sat, 20 Oct 2012 13:03:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.65.79.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19290.004 x-tm-as-result: No--44.148000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <21DA2C94481E3144A55DC606E32994D0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] draft-ram-siprec-callflows-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 13:03:12 -0000 Ofir, The schema in the ver 08 is the latest one. The examples in callflows-01 are not yet in sync with that. We will publish soon the call flows. As paul mentioned in the other thread, we appreciate if you have any call flows from the implementation/software that we can use. Regards, Ram > On 20/10/12 12:35 AM, "Ofir Roth" wrote: >Hi, >=20 >According to the metadata scheme: >=20 > > > maxOccurs=3D"1"/> > minOccurs=3D'0' > maxOccurs=3D'unbounded' > processContents=3D'lax'/> > > use=3D"required"/> > use=3D"required"/> > >There is no associate/disassociate time as part of the participant >definition while it appears in the call flow example of section 4.5. >=20 >And session is defined as follow: >=20 > > > minOccurs=3D"0"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D'0' > maxOccurs=3D'unbounded' > processContents=3D'lax'/> > > use=3D"required"/> > >=20 >According to the session definition, session does not contain start/stop >time while it appears in call flow document. >=20 >I am interested which is the up to date version that should be used (call >flow or metadata scheme). >=20 >Thanks, >Ofir. >=20 >From: Parthasarathi R [mailto:partha@parthasarathi.co.in] >Sent: Wednesday, October 17, 2012 5:28 PM >To: Ofir Roth; siprec@ietf.org >Subject: RE: [siprec] draft-ram-siprec-callflows-01 > > >=20 >Hi Ofir, >=20 >Thanks for your review. Please read inline. >=20 >Thanks >Partha >=20 >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Ofir Roth >Sent: Wednesday, October 17, 2012 4:46 PM >To: siprec@ietf.org >Subject: [siprec] draft-ram-siprec-callflows-01 > > >=20 >Hello, >=20 >I am reviewing the examples provided in draft-ram-siprec-callflows-01 and >noticed that it is not aligned according to >draft-ietf-siprec-metadata-07. >=20 >For example:=20 >=20 >1. Session element does not contain start/stop time > I guess that you wish to see the example with start/stop time. >We will add in the > next revision.=20 > =20 >BTW,start/stop time are optional elements in session. So, the callflow >is=20 >inline with metadata -07 draft. >=20 > >=20 >2. Participant does not include disassociate-time (as in section >4.5) > Sec 4.5 is call disconnect example and so, disassociate-time >exists. Please let me know the exact location where disassociate-time is >missing. >=20 >If those are known issues, I will appreciate if someone can let me know. >=20 >Thanks, >Ofir. >=20 > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Sat Oct 20 12:17: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 B988521F88DE for ; Sat, 20 Oct 2012 12:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBdDxZI4rBsW for ; Sat, 20 Oct 2012 12:17:49 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF7D21F88CF for ; Sat, 20 Oct 2012 12:17:49 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id CE6BE23F044B for ; Sat, 20 Oct 2012 21:17:47 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Sat, 20 Oct 2012 21:17:47 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: IETF85 Agenda. Thread-Index: Ac2u95XzqoXaX4mhQvmbXwdqUdsmuw== Date: Sat, 20 Oct 2012 19:17:46 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0130BE26@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] IETF85 Agenda. X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Oct 2012 19:17:49 -0000 Hi All, We need to start thinking about the agenda for the SIPREC meeting in Atlant= a (Thursday, Nov 8th). I am assuming we will want to discuss the status of the protocol and metada= ta and probably what to do regarding the call flows draft. Can we have volunteers for presenting and any other proposals for agenda it= ems. The deadline for publishing a draft agenda is Wednesday. Regards Andy (SIPREC Co-Chair). From Ofir.Roth@nice.com Sat Oct 20 15:44: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 C674821F8917 for ; Sat, 20 Oct 2012 15:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5AXzANFgw62 for ; Sat, 20 Oct 2012 15:44:55 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id ADB1E21F8744 for ; Sat, 20 Oct 2012 15:44:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,623,1344200400"; d="scan'208";a="4683146" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sun, 21 Oct 2012 00:44:52 +0200 From: Ofir Roth To: "Ram Mohan R (rmohanr)" , Parthasarathi R , "siprec@ietf.org" Date: Sun, 21 Oct 2012 00:44:50 +0200 Thread-Topic: [siprec] draft-ram-siprec-callflows-01 Thread-Index: AQHNrsNBoux/T2+ES0W7qhHp5LkoQJfCyyuQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] draft-ram-siprec-callflows-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 22:44:56 -0000 Thanks Ram. I have posted two scenarios which are aligned according to the metadata dra= ft. Have you had a chance to check them? BR, Ofir. -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Saturday, October 20, 2012 3:03 PM To: Ofir Roth; Parthasarathi R; siprec@ietf.org Subject: Re: [siprec] draft-ram-siprec-callflows-01 Ofir, The schema in the ver 08 is the latest one. The examples in callflows-01 ar= e not yet in sync with that. We will publish soon the call flows. As paul mentioned in the other thread, we appreciate if you have any call f= lows from the implementation/software that we can use. Regards, Ram > On 20/10/12 12:35 AM, "Ofir Roth" wrote: >Hi, >=20 >According to the metadata scheme: >=20 > > > maxOccurs=3D"1"/> > minOccurs=3D'0' > maxOccurs=3D'unbounded' > processContents=3D'lax'/> > > use=3D"required"/> > use=3D"required"/> > >There is no associate/disassociate time as part of the participant=20 >definition while it appears in the call flow example of section 4.5. >=20 >And session is defined as follow: >=20 > > > minOccurs=3D"0"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D'0' > maxOccurs=3D'unbounded' > processContents=3D'lax'/> > > use=3D"required"/> > >=20 >According to the session definition, session does not contain=20 >start/stop time while it appears in call flow document. >=20 >I am interested which is the up to date version that should be used=20 >(call flow or metadata scheme). >=20 >Thanks, >Ofir. >=20 >From: Parthasarathi R [mailto:partha@parthasarathi.co.in] >Sent: Wednesday, October 17, 2012 5:28 PM >To: Ofir Roth; siprec@ietf.org >Subject: RE: [siprec] draft-ram-siprec-callflows-01 > > >=20 >Hi Ofir, >=20 >Thanks for your review. Please read inline. >=20 >Thanks >Partha >=20 >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On=20 >Behalf Of Ofir Roth >Sent: Wednesday, October 17, 2012 4:46 PM >To: siprec@ietf.org >Subject: [siprec] draft-ram-siprec-callflows-01 > > >=20 >Hello, >=20 >I am reviewing the examples provided in draft-ram-siprec-callflows-01=20 >and noticed that it is not aligned according to=20 >draft-ietf-siprec-metadata-07. >=20 >For example:=20 >=20 >1. Session element does not contain start/stop time > I guess that you wish to see the example with start/stop time. >We will add in the > next revision.=20 > =20 >BTW,start/stop time are optional elements in session. So, the callflow=20 >is inline with metadata -07 draft. >=20 > >=20 >2. Participant does not include disassociate-time (as in section >4.5) > Sec 4.5 is call disconnect example and so, disassociate-time=20 >exists. Please let me know the exact location where disassociate-time=20 >is missing. >=20 >If those are known issues, I will appreciate if someone can let me know. >=20 >Thanks, >Ofir. >=20 > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec > From internet-drafts@ietf.org Sun Oct 21 21:05: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 8330721F8A6A; Sun, 21 Oct 2012 21:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKLce29EatbE; Sun, 21 Oct 2012 21:05:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A504221F845B; Sun, 21 Oct 2012 21:05:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022040509.31199.81897.idtracker@ietfa.amsl.com> Date: Sun, 21 Oct 2012 21:05:09 -0700 Cc: siprec@ietf.org Subject: [siprec] I-D Action: draft-ietf-siprec-protocol-08.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 04:05:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Recording Working Group of the IETF. Title : Session Recording Protocol Author(s) : Leon Portman Henry Lum Charles Eckel Alan Johnston Andrew Hutton Filename : draft-ietf-siprec-protocol-08.txt Pages : 43 Date : 2012-10-21 Abstract: This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-siprec-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-siprec-protocol-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-siprec-protocol-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From partha@parthasarathi.co.in Mon Oct 22 09:36: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 2643021F8B70 for ; Mon, 22 Oct 2012 09:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S9DukLf-N-b for ; Mon, 22 Oct 2012 09:36:17 -0700 (PDT) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [70.87.28.138]) by ietfa.amsl.com (Postfix) with ESMTP id C1B4021F8B7E for ; Mon, 22 Oct 2012 09:36:16 -0700 (PDT) Received: from userPC (unknown [122.179.43.209]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 30B5F1EBFDFA; Mon, 22 Oct 2012 16:36:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1350923776; bh=RqiAXADBhBh6x7A274e1ZEXZOiI3rB6hFrKU4QDHb2E=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=XibeArVDUayUN3b09CiK5t8O+o/v6gHIPMTo0WDOjssXWnvKKt8u4YAcRFVj91RqN 27kWhniy1JaJ4394vPN8NZjdnCGZLefEUSojYpbr4mQaRPq989oeguz7ZzZP5Qu90O Tke3HJCAzfhR8QcAVSMES+53eumJpTfq9GexPM4A= From: "Parthasarathi R" To: "'Ofir Roth'" , References: <003401cdac7b$f98d3bf0$eca7b3d0$@co.in> In-Reply-To: Date: Mon, 22 Oct 2012 22:05:57 +0530 Message-ID: <007d01cdb073$5ac65f50$10531df0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01CDB0A1.747E9B50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2sV49ORvpLdO1+SSymgnCxmyNtBQAIdO/AAGyk/3AAkb7KIA== Content-Language: en-us X-CTCH-Spam: Suspect X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0203.50857600.00C4, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 Subject: Re: [siprec] draft-ram-siprec-callflows-01 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:36:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007E_01CDB0A1.747E9B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ofir, Thanks for the review. Please read inline. Thanks Partha From: Ofir Roth [mailto:Ofir.Roth@nice.com] Sent: Saturday, October 20, 2012 12:36 AM To: Parthasarathi R; siprec@ietf.org Subject: RE: [siprec] draft-ram-siprec-callflows-01 Hi, According to the metadata scheme: There is no associate/disassociate time as part of the participant definition while it appears in the call flow example of section 4.5. This is callflow document issue and the actual XML element is participantsessionassoc. This is updated in -02 callflow draft And session is defined as follow: According to the session definition, session does not contain start/stop time while it appears in call flow document. This issue is related to XML schema in Metadata draft and has to be fixed in the next revision as There was consensus to add start/stop time as part of the session element I am interested which is the up to date version that should be used (call flow or metadata scheme). Thanks, Ofir. From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: Wednesday, October 17, 2012 5:28 PM To: Ofir Roth; siprec@ietf.org Subject: RE: [siprec] draft-ram-siprec-callflows-01 Hi Ofir, Thanks for your review. Please read inline. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth Sent: Wednesday, October 17, 2012 4:46 PM To: siprec@ietf.org Subject: [siprec] draft-ram-siprec-callflows-01 Hello, I am reviewing the examples provided in draft-ram-siprec-callflows-01 and noticed that it is not aligned according to draft-ietf-siprec-metadata-07. For example: 1. Session element does not contain start/stop time I guess that you wish to see the example with start/stop time. We will add in the next revision. BTW,start/stop time are optional elements in session. So, the callflow is inline with metadata -07 draft. 2. Participant does not include disassociate-time (as in section 4.5) Sec 4.5 is call disconnect example and so, disassociate-time exists. Please let me know the exact location where disassociate-time is missing. If those are known issues, I will appreciate if someone can let me know. Thanks, Ofir. ------=_NextPart_000_007E_01CDB0A1.747E9B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ofir,

 

Thanks for the = review. Please read inline.

 

Thanks

Partha

 

From:= Ofir Roth [mailto:Ofir.Roth@nice.com]
Sent: Saturday, October 20, 2012 12:36 AM
To: Parthasarathi R; siprec@ietf.org
Subject: RE: [siprec] = draft-ram-siprec-callflows-01

 

Hi,

 

According to the = metadata scheme:

 

<xs:complexType = name=3D"participant">

       <xs:sequence>

        &= nbsp;  <xs:element name=3D"nameID" = type=3D"nameID"

        &= nbsp;    maxOccurs=3D"1"/>

        <xs:any namespace=3D'##other'

        &= nbsp;          minOccurs=3D'0'

        &= nbsp;          maxOccurs=3D'unbounded'

        &= nbsp;          processContents=3D'lax'/>

       </xs:sequence>

       <xs:attribute name=3D"participant_id" type=3D"xs:base64Binary"

        &= nbsp;   use=3D"required"/>

       <xs:attribute name=3D"session_id" = type=3D"xs:base64Binary"

        &= nbsp;   use=3D"required"/>

   </xs:complexType>

There is no associate/disassociate time as part of the participant definition while = it appears in the call flow example of section 4.5.

<Partha> This = is callflow document issue and the actual XML element is participantsessionassoc. = This is updated in -02 callflow draft </Partha>

 

And session is = defined as follow:

 

<xs:complexType = name=3D"session">

       <xs:sequence>

         <xs:element name=3D"reason" type=3D"xs:string"

        &= nbsp;       minOccurs=3D"0"/>

         <xs:element name=3D"group-ref" = type=3D"xs:base64Binary"

        &= nbsp;       minOccurs=3D"0" = maxOccurs=3D"1"/>

        &= nbsp;  <xs:any namespace=3D'##other'

        &= nbsp;          minOccurs=3D'0'

        &= nbsp;          maxOccurs=3D'unbounded'

        &= nbsp;          processContents=3D'lax'/>

       </xs:sequence>

       <xs:attribute name=3D"session_id" = type=3D"xs:base64Binary"

        &= nbsp;   use=3D"required"/>

   </xs:complexType>

 

According to the = session definition, session does not contain start/stop time while it appears in = call flow document.

<Partha> This = issue is related to XML schema in Metadata draft and has to be fixed in the next revision as

There was consensus = to add start/stop time as part of the session element = </Partha>

 

I am interested which = is the up to date version that should be used (call flow or metadata = scheme).

 

Thanks,
Ofir.

 

From:= = Parthasarathi R [mailto:partha@parthasarathi.co.in]
Sent: Wednesday, October 17, 2012 5:28 PM
To: Ofir Roth; siprec@ietf.org
Subject: RE: [siprec] = draft-ram-siprec-callflows-01

 

Hi = Ofir,

 

Thanks for your = review. Please read inline.

 

Thanks

Partha

 

 

Hello,

 

I am reviewing the examples provided in draft-ram-siprec-callflows-01 and noticed that it is not aligned = according to draft-ietf-siprec-metadata-07.

 

For example:

 

1.       Session element does not contain start/stop = time

<Partha> I = guess that you wish to see the example with start/stop time. We will add in = the

 next revision. =

  =

BTW,start/stop time = are optional elements in session.  So, the callflow is

inline with metadata = -07 draft.

 

</Partha>

 

2.       Participant does not include disassociate-time = (as in section 4.5)

<Partha> Sec = 4.5 is call disconnect example and so, disassociate-time exists. Please let me know = the exact location where disassociate-time is missing. = </Partha>

 

If those are known issues, I will appreciate if = someone can let me know.

 

Thanks,
Ofir.

 

------=_NextPart_000_007E_01CDB0A1.747E9B50-- From partha@parthasarathi.co.in Mon Oct 22 10:55:52 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 00C9321F8A71 for ; Mon, 22 Oct 2012 10:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL-RT4yiOVR6 for ; Mon, 22 Oct 2012 10:55:51 -0700 (PDT) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [70.87.28.138]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65F21F8A6E for ; Mon, 22 Oct 2012 10:55:51 -0700 (PDT) Received: from userPC (unknown [122.179.43.209]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id A25F01EBF9B5 for ; Mon, 22 Oct 2012 17:55:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1350928550; bh=9xcJXMyoV7IFB7q+meQ5dpz6ZrKN+DYuT5yHO+gY3HQ=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=etLNA45aK2/QQN30qGGcXQyPX8JZgZGx+55QGqphG3EyJ9P8a0u5hkoaz34F6T6Ai XMTSWGHghatg0Y6cAjDvcdMtu/EL+ACDotVJA3xXxxj5e95PCMSZFFrulyG1ngTn9C VFQaMg+aUEFzCg5paZfsE68SYVnCJerWDm2kccnM= From: "Parthasarathi R" To: Date: Mon, 22 Oct 2012 23:25:46 +0530 Message-ID: <008901cdb07e$78ff0840$6afd18c0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2wex0ks8AbuINQQK24PeueYzN4BQAAie+Q Content-Language: en-us X-CTCH-Spam: Suspect X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A150204.508588A6.00E8, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 Subject: [siprec] FW: New Version Notification for draft-ram-siprec-callflows-02.txt X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:55:52 -0000 Hi all, draft-ram-siprec-callflows-02 is published with the following update: 1) Updated the callflow as per draft-ietf-siprec-metadata-08=20 2) Removed Metadata Example section=20 3) Incorporated Ofir Rath review comments The current open issue in the drafts 1) Incorporating RS SIP messages with metadata XML messages for all = callflow 2) Callflows provided by Ofir Rath has to be discussed and added. Could you please provide your valuable comments on=20 draft-ram-siprec-callflows-02. Thanks Partha -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 22, 2012 11:02 PM To: partha@parthasarathi.co.in Cc: rmohanr@cisco.com; pkyzivat@alum.mit.edu Subject: New Version Notification for draft-ram-siprec-callflows-02.txt A new version of I-D, draft-ram-siprec-callflows-02.txt has been successfully submitted by Parthasarathi Ravindran and posted to = the IETF repository. Filename: draft-ram-siprec-callflows Revision: 02 Title: Session Initiation Protocol (SIP) Recording Call Flows Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 18 URL: = http://www.ietf.org/internet-drafts/draft-ram-siprec-callflows-02.txt Status: = http://datatracker.ietf.org/doc/draft-ram-siprec-callflows Htmlized: = http://tools.ietf.org/html/draft-ram-siprec-callflows-02 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ram-siprec-callflows-02 Abstract: Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows that has snapshot of metadata sent from SRC to SRS, the metadata format for which is described in [I-D.ietf-siprec-metadata] . This is purely an informational document that is written to support the model defined the metadata draft. = =20 The IETF Secretariat From partha@parthasarathi.co.in Tue Oct 23 22:58: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 5126F21F8D32 for ; Tue, 23 Oct 2012 22:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP4+PBZtbzxg for ; Tue, 23 Oct 2012 22:58:09 -0700 (PDT) Received: from outbound-us3.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6524521F8D2F for ; Tue, 23 Oct 2012 22:58:09 -0700 (PDT) Received: from userPC (unknown [122.179.43.209]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us3.mailhostbox.com (Postfix) with ESMTPA id D2D4F14D844B; Wed, 24 Oct 2012 05:58:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1351058288; bh=pQcE3TulwKUrsAng5tBx2nr3apTFdsmREAt9pPK3t4s=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=nikzbnt9t4B7SLLDQmgnjrO3NLxwm7FJyGo3cVzUnmc9ROzicHp9TRIBuL+NuMlGF Tec14yCFERZ9yANA1K4ACMR+46kjGzb+mOnUM5/lUvcJRdMwpjQJD1aEonKdw8OxnM SHsUEfqCCbcnvWjDsGtrVcqL07PoQKc5CghhyYDI= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , References: In-Reply-To: Date: Wed, 24 Oct 2012 11:28:01 +0530 Message-ID: <000f01cdb1ac$89ee00a0$9dca01e0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNrQqU5qNQ89wCc06Y7ZJvLCpf9JfH+1iA Content-Language: en-us X-CTCH-Spam: Suspect X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0209.50878370.014E, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 Subject: Re: [siprec] Two questions on draft-ietf-siprec-metadata X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 05:58:10 -0000 Hi all, Object instance diagram was useful while forming Metadata XML format. As the metadata XML format is matured and few implementation already exists, I'm not seeing more advantages in having object instances. IMO, Object instance (Appendix A) shall be removed until otherwise somebody have trouble in review the metadata model relationship with current metadata XML schema. I agree with Ram that metadata example shall be removed from Appendix B as it is subset of SIPREC callflow document. Also, SIPREC callflow document shall include SIP & SDP message apart from metadata XML. Thanks Partha -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Thursday, October 18, 2012 1:59 PM To: siprec@ietf.org Subject: [siprec] Two questions on draft-ietf-siprec-metadata Hi All, I have two questions for which I need inputs on what we could do: 1) The object diagrams in the Appendix A have gone out of sync now due to changes in the model. It would take some time to re-draw. I wonder if they are really needed now ? I don't know if any one have paidsome attention to them ? Comments ? I feel the UML diagram is sufficient enough and we may not need the Appendix A. 2)What about Appendix B. Do we need that now given that we are having call flows in a separate draft ? My preference here to move the Appendix B to call flow ID and have both call flows + metadata in the same document (draft-ram-siprec-callflows). draft-ietf-siprec-metadata can just refer to call flows document for examples Let me know your comments on this. Regards, Ram _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From Ofir.Roth@nice.com Wed Oct 24 00:39:19 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 30D6E21F8472 for ; Wed, 24 Oct 2012 00:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p654qOTZs-1 for ; Wed, 24 Oct 2012 00:39:18 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3B41221F8462 for ; Wed, 24 Oct 2012 00:39:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,639,1344200400"; d="scan'208,217";a="4723545" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 24 Oct 2012 09:39:14 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Wed, 24 Oct 2012 09:39:13 +0200 Thread-Topic: Metadata version indication Thread-Index: Ac2xuoKlnQ0d4/p1R2+UYYJTcCmk7Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2D9ETLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] Metadata version indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 07:39:19 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2D9ETLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >From our experience in SIPREC implementations, we often come across vendors= that use different versions of the SIPREC metadata versions (which are not= necessarily aligned with the latest version of metadata). AFAIK, there is no way to indicate the metadata version as part of the XML/= SIP headers. I think that having such indication will be very useful for SIPREC implemen= ters as they can reject or handle the metadata according to their ability t= o use those versions. I will appreciate your comment on that. Thanks, Ofir Roth. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2D9ETLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

From our e= xperience in SIPREC implementations, we often come across vendors that use = different versions of the SIPREC metadata versions (which are not necessari= ly aligned with the latest version of metadata).

AFAIK, there is no way to indicate the metadata version as part o= f the XML/SIP headers.

 

I think that having such indication will be very = useful for SIPREC implementers as they can reject or handle the metadata ac= cording to their ability to use those versions.

I will appreciate y= our comment on that.

 <= /p>

Thanks,
Ofir Roth.  

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2D9ETLVMBX01nicec_-- From Ofir.Roth@nice.com Wed Oct 24 01:15: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 6959C21F84BF for ; Wed, 24 Oct 2012 01:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGFXRSdoUvBM for ; Wed, 24 Oct 2012 01:15:31 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEAA21F84AB for ; Wed, 24 Oct 2012 01:15:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,639,1344200400"; d="scan'208,217";a="4724019" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Wed, 24 Oct 2012 10:15:28 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Wed, 24 Oct 2012 10:15:28 +0200 Thread-Topic: Review of draft-ietf-siprec-metadata-08 Thread-Index: Ac2xvdrepyzMR3idQxy1cT+vR/UWcw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2DE2TLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] Review of draft-ietf-siprec-metadata-08 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2012 08:15:31 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2DE2TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have reviewed the updated draft: draft-ietf-siprec-metadata-08 and I have= some comments: regarding the metadata schema: 1. According to the metadata schema, recording element does not conta= in any association elements: 1. sessionrecordingassoc 2. participantsessionassoc 3. participantstreamassoc As a result, there is no way to add those elements as child elements of the= recording element. 2. Session element does not contain start/stop time. Thanks, Ofir Roth. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2DE2TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have rev= iewed the updated draft: draft-ietf-siprec-metadata-08 and I have some comm= ents: regarding the metadata schema:

 

1.    =    According to th= e metadata schema, recording element does not contain any associatio= n elements:

<= b>1.       sessionrecordingassoc

2.     &nbs= p; participantsession= assoc

<= span style=3D'mso-list:Ignore'>3.       Session element does not contain = start/stop time.

 

<= p class=3DMsoNormal>Thanks,
Ofir Roth.

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2DE2TLVMBX01nicec_-- From partha@parthasarathi.co.in Wed Oct 24 02:09:29 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 43B8C21F8567 for ; Wed, 24 Oct 2012 02:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fthJPwK+scnq for ; Wed, 24 Oct 2012 02:09:26 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [70.87.28.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1013621F84CE for ; Wed, 24 Oct 2012 02:09:10 -0700 (PDT) Received: from userPC (unknown [122.179.43.209]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id AA9993E28C4; Wed, 24 Oct 2012 09:09:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1351069749; bh=PS0/A8FGKd45slnV+/v4ixskyjelE4P0M08IjcLBqoY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=d4MPQcLpXQE3zv9ujfgqH2sg4g9r4lJnovpVvcub6jgoK+R4gzy2DNE+T2hRbNybu 7F96Fy+cWermVETTM1UJCbFjadgFDANj+7ZwIaS6JmtQtLJBwSAJIi6CQDTKgsVXSx IQe+R6CGNvpa5gFz8osJexwX8AI8fE24Zn4HkWm4= From: "Parthasarathi R" To: "'Ofir Roth'" , References: In-Reply-To: Date: Wed, 24 Oct 2012 14:38:46 +0530 Message-ID: <002201cdb1c7$38b6ba40$aa242ec0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01CDB1F5.526EF640" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2xvdrepyzMR3idQxy1cT+vR/UWcwABpghQ Content-Language: en-us X-CTCH-Spam: Suspect X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0206.5087B035.0125, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 Subject: Re: [siprec] Review of draft-ietf-siprec-metadata-08 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2012 09:09:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0023_01CDB1F5.526EF640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ofir, Thanks a lot for your review comments. Please read inline. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth Sent: Wednesday, October 24, 2012 1:45 PM To: siprec@ietf.org Subject: [siprec] Review of draft-ietf-siprec-metadata-08 Hi, I have reviewed the updated draft: draft-ietf-siprec-metadata-08 and I have some comments: regarding the metadata schema: 1. According to the metadata schema, recording element does not contain any association elements: 1. sessionrecordingassoc 2. participantsessionassoc 3. participantstreamassoc As a result, there is no way to add those elements as child elements of the recording element. Agreed, recording XML element in sec 8 will be updated in the next revision to accommodate all these three elements 2. Session element does not contain start/stop time. Agreed. In Sec 8, Session XML element will be updated in the next revision with the following two elements Hope the above proposed XML schema helps to close your review comments. Thanks, Ofir Roth. ------=_NextPart_000_0023_01CDB1F5.526EF640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ofir,

 

Thanks a lot for your = review comments. Please read inline.

 

Thanks

Partha

 

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ofir Roth
Sent: Wednesday, October 24, 2012 1:45 PM
To: siprec@ietf.org
Subject: [siprec] Review of = draft-ietf-siprec-metadata-08

 

Hi,

 

I have reviewed the updated draft: draft-ietf-siprec-metadata-08 and I have some comments: regarding the = metadata schema:

 

1.       According to the metadata schema, = recording element does not contain any association elements:

1.       = sessionrecordingassoc

2.       = participantsessionassoc

=

3.       = participantstreamassoc

As a result, there is no = way to add those elements as child elements of the recording = element.

<Partha> = Agreed, recording XML element in sec 8 will be updated in the next revision to accommodate = all these three

elements

 

<xs:element name=3D"sessionrecordingassoc"

           &= nbsp;   type=3D"sessionrecordingassoc"

           &= nbsp;   minOccurs=3D"0" = maxOccurs=3D"unbounded"/>

          <xs:element = name=3D"participantsessionassoc"

               type=3D"participantsession= assoc"

           &= nbsp;   minOccurs=3D"0" = maxOccurs=3D"unbounded"/>

          <xs:element = name=3D"participantstreamassoc"

           &= nbsp;   type=3D"participantstreamassoc"

           &= nbsp;   minOccurs=3D"0" = maxOccurs=3D"unbounded"/>

 

</Partha>

 

2.       Session element does not contain = start/stop time.

<Partha> =  Agreed.  In Sec 8,  Session XML element will be updated in the next revision = with the following two elements

 

       <xs:element name=3D"start-time" = type=3D"xs:dateTime"

           &= nbsp;    minOccurs=3D"0" = maxOccurs=3D"1"/>

       <xs:element name=3D"stop-time" = type=3D"xs:dateTime"

           &= nbsp;    minOccurs=3D"0" = maxOccurs=3D"1"/>

 

Hope the above = proposed XML schema helps to close your review comments.

</Partha>

 

Thanks,
Ofir Roth.

------=_NextPart_000_0023_01CDB1F5.526EF640-- From partha@parthasarathi.co.in Wed Oct 24 02:19: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 C71E221F8823 for ; Wed, 24 Oct 2012 02:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtPb9RTj1ZYN for ; Wed, 24 Oct 2012 02:19:15 -0700 (PDT) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [70.87.28.138]) by ietfa.amsl.com (Postfix) with ESMTP id 6013021F881E for ; Wed, 24 Oct 2012 02:19:15 -0700 (PDT) Received: from userPC (unknown [122.179.43.209]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id 7C66E1EBF1CC; Wed, 24 Oct 2012 09:19:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1351070354; bh=YDEAka+pLBiLKByHl4Dhcwr+UaKYG5gUhzjwBCCQgyI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=aHvvcYMJKfPNR0n6fLDndSkVGIXj19+Tn0qi631MtbNS3o6G/v5fUlx2CrcCpqDXE AuaiNQccGm6+R8iftndt201ATDmAs8hBXWw5WgeCIOBG2slrn5N/rc0Ewo3wiaSvaL vGmQmR7Gf4RFVX2x7k55Uo3sh+iImpG0OX6TdaWc= From: "Parthasarathi R" To: "'Ofir Roth'" , References: In-Reply-To: Date: Wed, 24 Oct 2012 14:49:08 +0530 Message-ID: <002701cdb1c8$a1cbdc80$e5639580$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01CDB1F6.BB841880" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2xuoKlnQ0d4/p1R2+UYYJTcCmk7QADLHTg Content-Language: en-us X-CTCH-Spam: Suspect X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0201.5087B292.0250, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 Subject: Re: [siprec] Metadata version indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 09:19:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0028_01CDB1F6.BB841880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ofir, This issues was raised earlier by Hadriel. I agree that it is good to have "version" element inside recording element to indicate the current version of the SIPREC metadata. This helps in case the metadata is extended from 1.0 to 2.0 by the update of RFC. I'm not very sure whether it is accepted in IETF draft to update the version of XML schema for each revision of the draft. For example, the current version for the metadata draft will be 0.8 and the next revision of the draft will be updated as 0.9. Let us look more comments for the generic approach to solve this issue. Thanks Partha From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Ofir Roth Sent: Wednesday, October 24, 2012 1:09 PM To: siprec@ietf.org Subject: [siprec] Metadata version indication Hi, >From our experience in SIPREC implementations, we often come across vendors that use different versions of the SIPREC metadata versions (which are not necessarily aligned with the latest version of metadata). AFAIK, there is no way to indicate the metadata version as part of the XML/SIP headers. I think that having such indication will be very useful for SIPREC implementers as they can reject or handle the metadata according to their ability to use those versions. I will appreciate your comment on that. Thanks, Ofir Roth. ------=_NextPart_000_0028_01CDB1F6.BB841880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ofir,

 

This issues was = raised earlier by Hadriel. I agree that it is good to have “version” element = inside recording element to indicate the current version of the SIPREC = metadata. This helps in case the metadata is extended from 1.0 to 2.0 by the update of = RFC.

 

I’m not very = sure whether it is accepted in IETF draft to update the version of XML schema for = each revision of the draft. For example, the current version for the metadata = draft will be 0.8 and the next revision of the draft will be updated as 0.9. Let us = look more comments for the generic approach to solve this = issue.

 

Thanks

Partha =

 

From:= siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of = Ofir Roth
Sent: Wednesday, October 24, 2012 1:09 PM
To: siprec@ietf.org
Subject: [siprec] Metadata version = indication

 

Hi,

 

From our experience in SIPREC implementations, we = often come across vendors that use different versions of the SIPREC metadata = versions (which are not necessarily aligned with the latest version of metadata). =

AFAIK, there is no way to indicate the metadata = version as part of the XML/SIP headers.

 

I think that having such indication will be very = useful for SIPREC implementers as they can reject or handle the metadata according = to their ability to use those versions.

I will appreciate your comment on that.

 

Thanks,
Ofir Roth.  

------=_NextPart_000_0028_01CDB1F6.BB841880-- From Ofir.Roth@nice.com Wed Oct 24 02:23: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 3794E21F8A6B for ; Wed, 24 Oct 2012 02:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOvSC7KOMQel for ; Wed, 24 Oct 2012 02:23:34 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 59B0E21F8B88 for ; Wed, 24 Oct 2012 02:23:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,639,1344200400"; d="scan'208,217";a="4725051" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 24 Oct 2012 11:23:31 +0200 From: Ofir Roth To: Parthasarathi R , "siprec@ietf.org" Date: Wed, 24 Oct 2012 11:23:30 +0200 Thread-Topic: [siprec] Review of draft-ietf-siprec-metadata-08 Thread-Index: Ac2xvdrepyzMR3idQxy1cT+vR/UWcwABpghQAAElqIA= Message-ID: References: <002201cdb1c7$38b6ba40$aa242ec0$@co.in> In-Reply-To: <002201cdb1c7$38b6ba40$aa242ec0$@co.in> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2E78TLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Review of draft-ietf-siprec-metadata-08 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2012 09:23:35 -0000 --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2E78TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Partha, I will update the schema according to your comments below and will resend t= he up to date metadata examples. Thanks, Ofir. From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: Wednesday, October 24, 2012 11:09 AM To: Ofir Roth; siprec@ietf.org Subject: RE: [siprec] Review of draft-ietf-siprec-metadata-08 Hi Ofir, Thanks a lot for your review comments. Please read inline. Thanks Partha From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of Ofir Roth Sent: Wednesday, October 24, 2012 1:45 PM To: siprec@ietf.org Subject: [siprec] Review of draft-ietf-siprec-metadata-08 Hi, I have reviewed the updated draft: draft-ietf-siprec-metadata-08 and I have= some comments: regarding the metadata schema: 1. According to the metadata schema, recording element does not conta= in any association elements: 1. sessionrecordingassoc 2. participantsessionassoc 3. participantstreamassoc As a result, there is no way to add those elements as child elements of the= recording element. Agreed, recording XML element in sec 8 will be updated in the next= revision to accommodate all these three elements 2. Session element does not contain start/stop time. Agreed. In Sec 8, Session XML element will be updated in the ne= xt revision with the following two elements Hope the above proposed XML schema helps to close your review comments. Thanks, Ofir Roth. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2E78TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Partha,

 

I will updat= e the schema according to your comments below and will resend the up to dat= e metadata examples.

Thanks,

Ofir.

 

From: Parthasarathi R [mailto:partha@parthasarathi.co.= in]
Sent: Wednesday, October 24, 2012 11:09 AM
To: Ofi= r Roth; siprec@ietf.org
Subject: RE: [siprec] Review of draft-iet= f-siprec-metadata-08

=  

Hi = Ofir,

 

Thanks a lot for your review comments. Please read inline.

 <= /o:p>

Thanks

Part= ha

=  

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On = Behalf Of Ofir Roth
Sent: Wednesday, October 24, 2012 1:45 PM=
To: siprec@ietf.org
Subject: [siprec] Review of draft-ietf-siprec-metadata-08

 

Hi,

 

I have reviewed the updated draft: draft-ietf-siprec-metadat= a-08 and I have some comments: regarding the metadata schema:

 

1.       According to the metadata schema, recording element does n= ot contain any association elements:

1.       = sessionrecordingassoc

2. &= nbsp;     <= /span>participantsessionassoc

3.       <= /span>participantstreamassoc

As a result, = there is no way to add those elements as child elements of the recording el= ement.

<= ;Partha> Agreed, recording XML element in sec 8 will be updated in the n= ext revision to accommodate all these three

elements

 

<xs:element name=3D"sessionrecordingassoc"=

      = ;         type=3D"sessionrecor= dingassoc"

   &n= bsp;           minOccurs= =3D"0" maxOccurs=3D"unbounded"/>

          = <xs:element name=3D"participantsessionassoc"=

         &nbs= p;     type=3D"participantsessionassoc"<= o:p>

      =          minOccurs=3D"0" = maxOccurs=3D"unbounded"/>

            = ;   type=3D"participantstreamassoc"

         &= nbsp;     minOccurs=3D"0" maxOccurs=3D"u= nbounded"/>

 

</Partha>

 

2.       Session element does not contain start= /stop time.

<Partha>  Agreed.  In Sec 8,  Session XML element w= ill be updated in the next revision with the following two elements

&nbs= p;

       &= lt;xs:element name=3D"start-time" type=3D"xs:dateTime"<= o:p>

      =           minOccurs=3D"0&= quot; maxOccurs=3D"1"/>

       <xs:element name=3D"stop-time= " type=3D"xs:dateTime"

 

Hope the above proposed XML schema helps to close your review comments.

<= /Partha>

 

Thanks,
Ofir R= oth.

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2E78TLVMBX01nicec_-- From Ofir.Roth@nice.com Wed Oct 24 05:22: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 61D2221F8A2A for ; Wed, 24 Oct 2012 05:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WCWy3A6++dI for ; Wed, 24 Oct 2012 05:22:44 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3D14021F8A17 for ; Wed, 24 Oct 2012 05:22:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,640,1344200400"; d="txt'?zip'48?scan'48,208,217,48";a="4727416" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 24 Oct 2012 14:22:41 +0200 From: Ofir Roth To: Parthasarathi R , "siprec@ietf.org" Date: Wed, 24 Oct 2012 14:22:39 +0200 Thread-Topic: [siprec] Review of draft-ietf-siprec-metadata-08 Thread-Index: Ac2xvdrepyzMR3idQxy1cT+vR/UWcwABpghQAAElqIAABhlcMA== Message-ID: References: <002201cdb1c7$38b6ba40$aa242ec0$@co.in> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: multipart/mixed; boundary="_004_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2F9CTLVMBX01nicec_" MIME-Version: 1.0 Subject: Re: [siprec] Review of draft-ietf-siprec-metadata-08 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2012 12:22:46 -0000 --_004_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2F9CTLVMBX01nicec_ Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2F9CTLVMBX01nicec_" --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2F9CTLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Attached please find are the new simple scenarios aligned with the changes = below. I will appreciate any comment. Thanks, Ofir Roth. From: Ofir Roth Sent: Wednesday, October 24, 2012 11:24 AM To: 'Parthasarathi R'; siprec@ietf.org Subject: RE: [siprec] Review of draft-ietf-siprec-metadata-08 Hi Partha, I will update the schema according to your comments below and will resend t= he up to date metadata examples. Thanks, Ofir. From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: Wednesday, October 24, 2012 11:09 AM To: Ofir Roth; siprec@ietf.org Subject: RE: [siprec] Review of draft-ietf-siprec-metadata-08 Hi Ofir, Thanks a lot for your review comments. Please read inline. Thanks Partha From: siprec-bounces@ietf.org [mailto:sipre= c-bounces@ietf.org] On Behalf Of Ofir Roth Sent: Wednesday, October 24, 2012 1:45 PM To: siprec@ietf.org Subject: [siprec] Review of draft-ietf-siprec-metadata-08 Hi, I have reviewed the updated draft: draft-ietf-siprec-metadata-08 and I have= some comments: regarding the metadata schema: 1. According to the metadata schema, recording element does not conta= in any association elements: 1. sessionrecordingassoc 2. participantsessionassoc 3. participantstreamassoc As a result, there is no way to add those elements as child elements of the= recording element. Agreed, recording XML element in sec 8 will be updated in the next= revision to accommodate all these three elements 2. Session element does not contain start/stop time. Agreed. In Sec 8, Session XML element will be updated in the ne= xt revision with the following two elements Hope the above proposed XML schema helps to close your review comments. Thanks, Ofir Roth. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2F9CTLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Attached please find are the new simple scenarios aligne= d with the changes below.

I will appreciate any comment.

 

Thanks,
Ofir Rot= h.

=  

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Ofir Rot= h
Sent: Wednesday, October 24, 2012 11:24 AM
To: 'Part= hasarathi R'; siprec@ietf.org
Subject: RE: [siprec] Review of dra= ft-ietf-siprec-metadata-08

 

Hi Partha,

 

I will update the schema acco= rding to your comments below and will resend the up to date metadata exampl= es.

Thanks,

Ofir.

 

From: Parthasarathi R [mailto:par= tha@parthasarathi.co.in]
Sent: Wednesday, October 24, 2012 1= 1:09 AM
To: Ofir Roth; siprec@= ietf.org
Subject: RE: [siprec] Review of draft-ietf-siprec-me= tadata-08

 =

Hi Ofir,<= /o:p>

&nb= sp;

Than= ks a lot for your review comments. Please read inline.

 

Thanks

Partha

 =

From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of <= /b>Ofir Roth
Sent: Wednesday, October 24, 2012 1:45 PM
To:<= /b> siprec@ietf.org
Subject: [siprec] Review of draft-ietf-siprec-metadata-08

 

Hi= ,

 

I have reviewed the updated draft: draft-ietf-siprec-metadata-08 and I = have some comments: regarding the metadata schema:

 

1. &= nbsp;     According to the metadata schema, recording element does not conta= in any association elements:

1.       <= /b>sessionrecordingassoc=

2.   = ;    p= articipantsessionassoc

3.       participantstreamassoc<= /p>

As a result, there is = no way to add those elements as child elements of the recording element.

<Partha&g= t; Agreed, recording XML element in sec 8 will be updated in the next revis= ion to accommodate all these three

elements

 

<xs:element name=3D"sessionrecordingassoc"

       &n= bsp;       type=3D"sessionrecordingassoc= "

     = ;          minOccurs=3D"0= " maxOccurs=3D"unbounded"/>

          <xs:ele= ment name=3D"participantsessionassoc"

           &n= bsp;   type=3D"participantsessionassoc"=

       &n= bsp;       minOccurs=3D"0" maxOccur= s=3D"unbounded"/>

 = ;         <xs:element name=3D&qu= ot;participantstreamassoc"

&nbs= p;            &= nbsp; type=3D"participantstreamassoc"

          &nb= sp;    minOccurs=3D"0" maxOccurs=3D"unbounded= "/>

 

</Partha>

 

2.       Session element does not contain start/stop time= .

<Par= tha>  Agreed.  In Sec 8,  Session XML element will be upd= ated in the next revision with the following two elements

 

       <xs:elem= ent name=3D"start-time" type=3D"xs:dateTime"=

       &n= bsp;        minOccurs=3D"0" ma= xOccurs=3D"1"/>

 &= nbsp;     <xs:element name=3D"stop-time" t= ype=3D"xs:dateTime"

 =             &nb= sp;  minOccurs=3D"0" maxOccurs=3D"1"/>

 =

Hope th= e above proposed XML schema helps to close your review comments.

</Partha&= gt;

 

Thanks,
Ofir Roth.

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2F9CTLVMBX01nicec_-- --_004_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2F9CTLVMBX01nicec_ Content-Type: application/x-zip-compressed; name="SimpleScenarios.zip" Content-Description: SimpleScenarios.zip Content-Disposition: attachment; filename="SimpleScenarios.zip"; size=1800; creation-date="Wed, 24 Oct 2012 12:21:19 GMT"; modification-date="Wed, 24 Oct 2012 12:21:19 GMT" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAG9yWEFSrFFD5wIAAOEKAAAWAAAAU2ltcGxlQ2FsbFNjZW5hcmlvLnR4dN2W3XKa QBTHr+uM77DltoMsqK0yQGqsZpJJNKILjTedFVZlAiwDm5g+Wy/6SH2Frgu1TCxRO81NvYAVzsfv 7J7/spGJH/yAArXdareBPbtVes4tgPUaNlOWRDjRIbjt3yClA6F4GuIFCXV1O8xI7NM4/Fqv1WtR Kc6H4+No5ThvANiGMt7KMvBwGIIFYRtCYtALA48ARsE5XQBZtuq1H9++G2dPUQgeSZoFNDYltQEl QGKP+kG8MqUHtpQ70hk3NVLi0XT7FHCHONOfssCU1owluqJsNpvGptmg6UrRIFSVzzfXU29NIiwH ccZw7BFp5+Uf9iqMefo01gPClnqCUxxx7yjUeZAdisTBADB8zHBEfWJ5NEpCwoih7B4Jg1VKHxIg rl8CDoDCq4uJk2DXGc4maG5PnKE7W5lmHo874CyjXoAZkVkQEUuDqiarUNZaM7Wpt6He6jS0Zrvb bWnvoKZDaCjPPERaRWTMxxnJtjMMinuOgeaXbjj6hAbJzEbd6QSOxs6mhMHnLmUvIbwvI5SsC3+R X07J0qqquGAUNjlzAZj/4/POAi9IcMxAaSzoZyicu8OrC3ugjtxBu+8M2LVbnsQYR+TyE8A0NSW8 7b2PMb80+CL9MimMLNGZhiLGhbOSexdQpdyHwSaqfYfQeoTg1Xh63x07qn9n9yrAFnRRicV1chJU xlKCI5Df8hW+t+d8dQcIJjcIhRduaPedCUc5rQ+Eyi3VUPJBsVAiTVVmZ6C6E+TYaHjed+7X7myw HqPeX2bWXsicR9tJUujgtBxHia17UGx/JNnrlsIqxzy6pV+hoM7BgiqoTyupUgyvUNLhNTq6JNFh Jy7SbtfkH0Krqv+3fcJfF6a8WR6tKpEaini9T/4b7iTwg/uSIKum2QOvrvEYcGGVS8XaHhjkE3+7 Q0Z+rvBTmiTEB8uURqA//T8PGGIycfj8fHGsGP/R/uIH2ct6bOutbgOqzbIe950OSbLcID8BUEsD BBQAAAAIAIVyWEEOe6+0DwMAANkPAAAcAAAAU2ltcGxlSG9sZFJlc3VtZVNjZW5hcmlvLnR4dO2W 327aMBTGr4fUd/C4nUIcCmuJknSF0nWolUrApuvNZBIDUZ0/Skzpnm0Xe6S9whwnY2lpCqxVO3Xj IpjkHJ+f7e+EzzfJ3PVCoDUbzSawh+fqIT4HcKdCzJhHPol0CM47Z0jdh1DeZWRMma6lw4QGbhiw rzuVnYpfmGdv83nqxXneAJBOZbxVFOAQxsCY8gWlAThknkMBD0E7HANFsXYqP759Nw5ufAauaZx4 YWBWtRqsAho4oesFU7M65xNlv3ogQo2YOmGc3gUiIUj0m8QzqzPOI11VF4tFbbFbC+OpWodQUy/O TgfOjPpE8YKEk8Ch1WWWuz4rDxbl40D3KJ/oEYmJL7J9potJlihVAQaA4RJO/NCllhP6EaOcGury lgyYxuE8AvL6xRMAfc0eIoyP7W6rN0Ctkz5sjlDfNLP5RAJJktDxCKcK93xq1aFWVzSo1BtDbVdv Qr3RqkHtfavVqL+DdR1CQ72TIcuqsmI2TmiS7jDIvyXGAM4QgvxigCN71I16iLVtdFjAEHsX840R CtF5vqyvxHRila04Z5QxGXMOmP0S+849x4tIwEFhLOmRxk6Q1h6NWLuDr3qd4VXUtoubGBCffjoC JIzNKkm19yEQl5o4pF8heZAllWmocpwnq1l2DlWovR5shCKMkdYZYmwLwEuM2BGeloCNw3EpluiT raASHlPig+wrQ7nil33cwzab2QPELkfohoxSlO10ILvc0gw1G+QHJcuUVR6yWRd17Y+4657i4+gC M/wZLf6wcv2Bytlsy5aUfbBdjSdqtntJVtSSR2WYG0v6RRZUQr3dkkqb4e9eklTYloe0fGuKP0Kr TP+pTsTjPFSI5doqa1JDlY9XyX/DbQW+9r0kycppVsDL17gJuIzKWsVKDYOy5ee2W3kp1+MFxOHe NS26nszozChzAZ/RzAS9Sr8jz5awu3ZnQz2ubaQn6I7XIbL7rHUmspgmc58m/3X2GJ097wv78ZK8 pQA3DqOIumAShz7oDP5ZATyDr3K95GEf0sx8yF7Rh6wmrbMiRYH8BFBLAQIUABQAAAAIAG9yWEFS rFFD5wIAAOEKAAAWAAAAAAAAAAEAIAAAAAAAAABTaW1wbGVDYWxsU2NlbmFyaW8udHh0UEsBAhQA FAAAAAgAhXJYQQ57r7QPAwAA2Q8AABwAAAAAAAAAAQAgAAAAGwMAAFNpbXBsZUhvbGRSZXN1bWVT Y2VuYXJpby50eHRQSwUGAAAAAAIAAgCOAAAAZAYAAAAA --_004_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC2F9CTLVMBX01nicec_-- From pkyzivat@alum.mit.edu Wed Oct 24 09:03: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 6DE5321F8C55 for ; Wed, 24 Oct 2012 09:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZYsGIBC33yU for ; Wed, 24 Oct 2012 09:03:40 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id B767821F8C13 for ; Wed, 24 Oct 2012 09:03:39 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id Ey7S1k0050cZkys5343kYs; Wed, 24 Oct 2012 16:03:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id F43c1k00c3ZTu2S3W43cfW; Wed, 24 Oct 2012 16:03:36 +0000 Message-ID: <50881159.6050407@alum.mit.edu> Date: Wed, 24 Oct 2012 12:03:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> In-Reply-To: <002701cdb1c8$a1cbdc80$e5639580$@co.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] Metadata version indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 16:03:40 -0000 I appreciate the problem here. There are a variety of ways to solve it. The obvious one would be to keep changing the content-type, by embedding a version number in the mime-type name itself. This could present some logistical difficulties as we transition from draft to RFC. I guess it might also not be approved by mime gurus. It has the advantage that you won't accidentally try to parse a syntax you aren't prepared for. Another way is to change the xmlns urn for each draft. As long as every version starts with the element that will be sufficient to disambiguate without getting into parsing trouble. Another would be to add another (optional?) attribute to the element. I don't know enough about XML to have a strong preference among these. But it may be a little late for this. How many more changes to the schema do we expect before RFC? Thanks, Paul On 10/24/12 5:19 AM, Parthasarathi R wrote: > Hi Ofir, > > This issues was raised earlier by Hadriel. I agree that it is good to > have “version” element inside recording element to indicate the current > version of the SIPREC metadata. This helps in case the metadata is > extended from 1.0 to 2.0 by the update of RFC. > > I’m not very sure whether it is accepted in IETF draft to update the > version of XML schema for each revision of the draft. For example, the > current version for the metadata draft will be 0.8 and the next revision > of the draft will be updated as 0.9. Let us look more comments for the > generic approach to solve this issue. > > Thanks > > Partha > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > Behalf Of *Ofir Roth > *Sent:* Wednesday, October 24, 2012 1:09 PM > *To:* siprec@ietf.org > *Subject:* [siprec] Metadata version indication > > Hi, > > From our experience in SIPREC implementations, we often come across > vendors that use different versions of the SIPREC metadata versions > (which are not necessarily aligned with the latest version of metadata). > > AFAIK, there is no way to indicate the metadata version as part of the > XML/SIP headers. > > I think that having such indication will be very useful for SIPREC > implementers as they can reject or handle the metadata according to > their ability to use those versions. > > I will appreciate your comment on that. > > Thanks, > Ofir Roth. > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From andrew.hutton@siemens-enterprise.com Wed Oct 24 09:08:38 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 EB6D821F8C67 for ; Wed, 24 Oct 2012 09:08:38 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoG70QdDFEoA for ; Wed, 24 Oct 2012 09:08:38 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8C45421F8C56 for ; Wed, 24 Oct 2012 09:08:37 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id CC89F1EB8538 for ; Wed, 24 Oct 2012 18:08:35 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 18:08:35 +0200 From: "Hutton, Andrew" To: "siprec@ietf.org" Thread-Topic: SIPREC IETF 85 - Draft Agenda Thread-Index: Ac2yAdFCWDef5oaiRDij8sbvuHf0wg== Date: Wed, 24 Oct 2012 16:08:35 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF013159C2@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] SIPREC IETF 85 - Draft Agenda X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2012 16:08:39 -0000 Hi All, A draft agenda can be found at: http://www.ietf.org/proceedings/85/agenda/a= genda-85-siprec. Please send any comments on the agenda or proposals for changes to the list= . The final agenda has to be uploaded on the 29th of October. Regards Andy (SIPREC Co-Chair). From pkyzivat@alum.mit.edu Wed Oct 24 09:18: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 C28DC21F8C93 for ; Wed, 24 Oct 2012 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMJmvakTJxM0 for ; Wed, 24 Oct 2012 09:18:20 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 114EA21F8C81 for ; Wed, 24 Oct 2012 09:18:19 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id F15H1k00H1ei1Bg514JQmF; Wed, 24 Oct 2012 16:18:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id F4JJ1k00J3ZTu2S3k4JJla; Wed, 24 Oct 2012 16:18:18 +0000 Message-ID: <508814CA.4060906@alum.mit.edu> Date: Wed, 24 Oct 2012 12:18:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <002201cdb1c7$38b6ba40$aa242ec0$@co.in> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] Review of draft-ietf-siprec-metadata-08 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2012 16:18:20 -0000 Hi Ofir, Thanks for the examples! One question for you: Is there a reason why you have used the element when there is only one in it? While this is valid, I would have expected that the group would only be introduced when needed. Thanks, Paul On 10/24/12 8:22 AM, Ofir Roth wrote: > Hi, > > Attached please find are the new simple scenarios aligned with the > changes below. > > I will appreciate any comment. > > Thanks, > Ofir Roth. > > *From:*Ofir Roth > *Sent:* Wednesday, October 24, 2012 11:24 AM > *To:* 'Parthasarathi R'; siprec@ietf.org > *Subject:* RE: [siprec] Review of draft-ietf-siprec-metadata-08 > > Hi Partha, > > I will update the schema according to your comments below and will > resend the up to date metadata examples. > > Thanks, > > Ofir. > > *From:*Parthasarathi R [mailto:partha@parthasarathi.co.in] > *Sent:* Wednesday, October 24, 2012 11:09 AM > *To:* Ofir Roth; siprec@ietf.org > *Subject:* RE: [siprec] Review of draft-ietf-siprec-metadata-08 > > Hi Ofir, > > Thanks a lot for your review comments. Please read inline. > > Thanks > > Partha > > *From:*siprec-bounces@ietf.org > [mailto:siprec-bounces@ietf.org] *On Behalf Of *Ofir Roth > *Sent:* Wednesday, October 24, 2012 1:45 PM > *To:* siprec@ietf.org > *Subject:* [siprec] Review of draft-ietf-siprec-metadata-08 > > Hi, > > I have reviewed the updated draft: draft-ietf-siprec-metadata-08 and I > have some comments: regarding the metadata schema: > > 1.According to the metadata schema, *recording* element does not contain > any association elements: > > *1.**sessionrecordingassoc* > > *2.**participantsessionassoc* > > *3.**participantstreamassoc* > > As a result, there is no way to add those elements as child elements of > the recording element. > > Agreed, recording XML element in sec 8 will be updated in the > next revision to accommodate all these three > > elements > > > type="sessionrecordingassoc" > > minOccurs="0" maxOccurs="unbounded"/> > > > type="participantsessionassoc" > > minOccurs="0" maxOccurs="unbounded"/> > > > type="participantstreamassoc" > > minOccurs="0" maxOccurs="unbounded"/> > > > > 2.*Session* element does not contain start/stop time. > > Agreed. In Sec 8, Session XML element will be updated in the > next revision with the following two elements > > > minOccurs="0" maxOccurs="1"/> > > > minOccurs="0" maxOccurs="1"/> > > Hope the above proposed XML schema helps to close your review comments. > > > > Thanks, > Ofir Roth. > > > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From Ofir.Roth@nice.com Wed Oct 24 11:06: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 3017421F8830 for ; Wed, 24 Oct 2012 11:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+DkMqS7CqaK for ; Wed, 24 Oct 2012 11:06:21 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA521F8818 for ; Wed, 24 Oct 2012 11:06:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,642,1344200400"; d="scan'208";a="4732362" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 24 Oct 2012 20:06:19 +0200 From: Ofir Roth To: Paul Kyzivat , "siprec@ietf.org" Date: Wed, 24 Oct 2012 20:06:17 +0200 Thread-Topic: [siprec] Review of draft-ietf-siprec-metadata-08 Thread-Index: Ac2yA1VlxyX/KADSRb+Mv78MyHtFnQADjqqw Message-ID: References: <002201cdb1c7$38b6ba40$aa242ec0$@co.in> <508814CA.4060906@alum.mit.edu> In-Reply-To: <508814CA.4060906@alum.mit.edu> 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] Review of draft-ietf-siprec-metadata-08 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2012 18:06:22 -0000 Hi Paul,=20 I guess that when SRC creates the first complete metadata update, it does n= ot have the whole picture which might later contain more than one session.= =20 Thanks. -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Paul Kyzivat Sent: Wednesday, October 24, 2012 6:18 PM To: siprec@ietf.org Subject: Re: [siprec] Review of draft-ietf-siprec-metadata-08 Hi Ofir, Thanks for the examples! One question for you: Is there a reason why you have used the eleme= nt when there is only one in it? While this is valid, I would hav= e expected that the group would only be introduced when needed. Thanks, Paul On 10/24/12 8:22 AM, Ofir Roth wrote: > Hi, > > Attached please find are the new simple scenarios aligned with the=20 > changes below. > > I will appreciate any comment. > > Thanks, > Ofir Roth. > > *From:*Ofir Roth > *Sent:* Wednesday, October 24, 2012 11:24 AM > *To:* 'Parthasarathi R'; siprec@ietf.org > *Subject:* RE: [siprec] Review of draft-ietf-siprec-metadata-08 > > Hi Partha, > > I will update the schema according to your comments below and will=20 > resend the up to date metadata examples. > > Thanks, > > Ofir. > > *From:*Parthasarathi R [mailto:partha@parthasarathi.co.in] > *Sent:* Wednesday, October 24, 2012 11:09 AM > *To:* Ofir Roth; siprec@ietf.org > *Subject:* RE: [siprec] Review of draft-ietf-siprec-metadata-08 > > Hi Ofir, > > Thanks a lot for your review comments. Please read inline. > > Thanks > > Partha > > *From:*siprec-bounces@ietf.org =20 > [mailto:siprec-bounces@ietf.org] *On Behalf Of *Ofir Roth > *Sent:* Wednesday, October 24, 2012 1:45 PM > *To:* siprec@ietf.org > *Subject:* [siprec] Review of draft-ietf-siprec-metadata-08 > > Hi, > > I have reviewed the updated draft: draft-ietf-siprec-metadata-08 and I=20 > have some comments: regarding the metadata schema: > > 1.According to the metadata schema, *recording* element does not=20 > contain any association elements: > > *1.**sessionrecordingassoc* > > *2.**participantsessionassoc* > > *3.**participantstreamassoc* > > As a result, there is no way to add those elements as child elements=20 > of the recording element. > > Agreed, recording XML element in sec 8 will be updated in the=20 > next revision to accommodate all these three > > elements > > > type=3D"sessionrecordingassoc" > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > type=3D"participantsessionassoc" > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > type=3D"participantstreamassoc" > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > 2.*Session* element does not contain start/stop time. > > Agreed. In Sec 8, Session XML element will be updated in=20 > the next revision with the following two elements > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > > minOccurs=3D"0" maxOccurs=3D"1"/> > > Hope the above proposed XML schema helps to close your review comments. > > > > Thanks, > Ofir Roth. > > > > _______________________________________________ > siprec mailing 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 Oct 24 11:14: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 E7E4721F8522 for ; Wed, 24 Oct 2012 11:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyAKpzqPDAGE for ; Wed, 24 Oct 2012 11:14:21 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7521F8461 for ; Wed, 24 Oct 2012 11:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3325; q=dns/txt; s=iport; t=1351102461; x=1352312061; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=foyVqhBCgWe6oY27PObRewTeWJS9m5nwm2Uz7148ur0=; b=QESDrthP60J9WsbhD98QGHtfFPZYn4tv/sPEs8Vh+JHHI7DpZ3dZF6oF x8FHeGNtG91Th4qKsdIwsSCXZ7LUg77VbGghKC1+AjwY2TAQqKVZci8qq djSo+TuKANwQehJpx4hqasrr7J3BZiFiWsmq4qcyIGjArvpj/rmV4+/ZT A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIIviFCtJV2b/2dsb2JhbABEDsFrgQiCHgEBAQQBAQEPASc0FwQCAQgOAwQBAQEKFAkHJwsUCQgBAQQBEggah2EBC5w/oBUEi2GGDGEDpEGBa4IyPYIZ X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="134751375" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 24 Oct 2012 18:14:21 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9OIELP5018777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 18:14:21 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 13:14:21 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Metadata version indication Thread-Index: Ac2xuoKlnQ0d4/p1R2+UYYJTcCmk7QADLHTgABj1KoAABgNBwA== Date: Wed, 24 Oct 2012 18:14:20 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280EAC9A@xmb-aln-x08.cisco.com> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> In-Reply-To: <50881159.6050407@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--49.340100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata version indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 18:14:23 -0000 I'm not sure of the best mechanism either, but whatever it is should be hel= pful for future extensions as well as during our current standardization ef= fort.=20 Cheers, Charles > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, October 24, 2012 9:04 AM > To: siprec@ietf.org > Subject: Re: [siprec] Metadata version indication >=20 > I appreciate the problem here. There are a variety of ways to solve it. >=20 > The obvious one would be to keep changing the content-type, by > embedding > a version number in the mime-type name itself. This could present some > logistical difficulties as we transition from draft to RFC. I guess it > might also not be approved by mime gurus. It has the advantage that you > won't accidentally try to parse a syntax you aren't prepared for. >=20 > Another way is to change the xmlns urn for each draft. As long as every > version starts with the element that will be sufficient to > disambiguate without getting into parsing trouble. >=20 > Another would be to add another (optional?) attribute to the > element. >=20 > I don't know enough about XML to have a strong preference among these. >=20 > But it may be a little late for this. How many more changes to the > schema do we expect before RFC? >=20 > Thanks, > Paul >=20 > On 10/24/12 5:19 AM, Parthasarathi R wrote: > > Hi Ofir, > > > > This issues was raised earlier by Hadriel. I agree that it is good to > > have "version" element inside recording element to indicate the current > > version of the SIPREC metadata. This helps in case the metadata is > > extended from 1.0 to 2.0 by the update of RFC. > > > > I'm not very sure whether it is accepted in IETF draft to update the > > version of XML schema for each revision of the draft. For example, the > > current version for the metadata draft will be 0.8 and the next revisio= n > > of the draft will be updated as 0.9. Let us look more comments for the > > generic approach to solve this issue. > > > > Thanks > > > > Partha > > > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > > Behalf Of *Ofir Roth > > *Sent:* Wednesday, October 24, 2012 1:09 PM > > *To:* siprec@ietf.org > > *Subject:* [siprec] Metadata version indication > > > > Hi, > > > > From our experience in SIPREC implementations, we often come across > > vendors that use different versions of the SIPREC metadata versions > > (which are not necessarily aligned with the latest version of metadata)= . > > > > AFAIK, there is no way to indicate the metadata version as part of the > > XML/SIP headers. > > > > I think that having such indication will be very useful for SIPREC > > implementers as they can reject or handle the metadata according to > > their ability to use those versions. > > > > I will appreciate your comment on that. > > > > Thanks, > > Ofir Roth. > > > > > > > > _______________________________________________ > > 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 Wed Oct 24 11:30: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 8D23821F86C7 for ; Wed, 24 Oct 2012 11:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weNBKdjtYH+9 for ; Wed, 24 Oct 2012 11:30:41 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id CA86121F86B1 for ; Wed, 24 Oct 2012 11:30:40 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta09.westchester.pa.mail.comcast.net with comcast id F5Nv1k0010ldTLk596WlKR; Wed, 24 Oct 2012 18:30:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id F6WT1k0043ZTu2S3Q6WTEl; Wed, 24 Oct 2012 18:30:27 +0000 Message-ID: <508833CE.8080004@alum.mit.edu> Date: Wed, 24 Oct 2012 14:30:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ofir Roth References: <002201cdb1c7$38b6ba40$aa242ec0$@co.in> <508814CA.4060906@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] Review of draft-ietf-siprec-metadata-08 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 24 Oct 2012 18:30:41 -0000 On 10/24/12 2:06 PM, Ofir Roth wrote: > Hi Paul, > > I guess that when SRC creates the first complete metadata update, it does not have the whole picture which might later contain more than one session. Sure. But why not update to include the group then? Certainly either way can work. By asking I'm trying to ensure that it is understood that either is possible - important for the SRS to know that. Thanks, Paul > Thanks. > > > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, October 24, 2012 6:18 PM > To: siprec@ietf.org > Subject: Re: [siprec] Review of draft-ietf-siprec-metadata-08 > > Hi Ofir, > > Thanks for the examples! > > One question for you: Is there a reason why you have used the element when there is only one in it? While this is valid, I would have expected that the group would only be introduced when needed. > > Thanks, > Paul > > On 10/24/12 8:22 AM, Ofir Roth wrote: >> Hi, >> >> Attached please find are the new simple scenarios aligned with the >> changes below. >> >> I will appreciate any comment. >> >> Thanks, >> Ofir Roth. >> >> *From:*Ofir Roth >> *Sent:* Wednesday, October 24, 2012 11:24 AM >> *To:* 'Parthasarathi R'; siprec@ietf.org >> *Subject:* RE: [siprec] Review of draft-ietf-siprec-metadata-08 >> >> Hi Partha, >> >> I will update the schema according to your comments below and will >> resend the up to date metadata examples. >> >> Thanks, >> >> Ofir. >> >> *From:*Parthasarathi R [mailto:partha@parthasarathi.co.in] >> *Sent:* Wednesday, October 24, 2012 11:09 AM >> *To:* Ofir Roth; siprec@ietf.org >> *Subject:* RE: [siprec] Review of draft-ietf-siprec-metadata-08 >> >> Hi Ofir, >> >> Thanks a lot for your review comments. Please read inline. >> >> Thanks >> >> Partha >> >> *From:*siprec-bounces@ietf.org >> [mailto:siprec-bounces@ietf.org] *On Behalf Of *Ofir Roth >> *Sent:* Wednesday, October 24, 2012 1:45 PM >> *To:* siprec@ietf.org >> *Subject:* [siprec] Review of draft-ietf-siprec-metadata-08 >> >> Hi, >> >> I have reviewed the updated draft: draft-ietf-siprec-metadata-08 and I >> have some comments: regarding the metadata schema: >> >> 1.According to the metadata schema, *recording* element does not >> contain any association elements: >> >> *1.**sessionrecordingassoc* >> >> *2.**participantsessionassoc* >> >> *3.**participantstreamassoc* >> >> As a result, there is no way to add those elements as child elements >> of the recording element. >> >> Agreed, recording XML element in sec 8 will be updated in the >> next revision to accommodate all these three >> >> elements >> >> > >> type="sessionrecordingassoc" >> >> minOccurs="0" maxOccurs="unbounded"/> >> >> > >> type="participantsessionassoc" >> >> minOccurs="0" maxOccurs="unbounded"/> >> >> > >> type="participantstreamassoc" >> >> minOccurs="0" maxOccurs="unbounded"/> >> >> >> >> 2.*Session* element does not contain start/stop time. >> >> Agreed. In Sec 8, Session XML element will be updated in >> the next revision with the following two elements >> >> > >> minOccurs="0" maxOccurs="1"/> >> >> > >> minOccurs="0" maxOccurs="1"/> >> >> Hope the above proposed XML schema helps to close your review comments. >> >> >> >> Thanks, >> Ofir Roth. >> >> >> >> _______________________________________________ >> siprec mailing 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 Oct 25 09:52: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 DE38E21F8695 for ; Thu, 25 Oct 2012 09:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKt3yA5QLENa for ; Thu, 25 Oct 2012 09:52:00 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C421F8698 for ; Thu, 25 Oct 2012 09:51:56 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id B7B4A23F0C8E; Thu, 25 Oct 2012 18:51:55 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.76]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 18:51:55 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Metadata version indication Thread-Index: AQHNsgErfcwCqLA2ak6oWNdjWEsaBJfKPZ+w Date: Thu, 25 Oct 2012 16:51:54 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF01317333@MCHP04MSX.global-ad.net> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> In-Reply-To: <50881159.6050407@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata version indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:52:07 -0000 Also appreciate the issue here is anybody aware of a precedent for this bei= ng solved in other working groups? Regards Andy > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 24 October 2012 17:04 > To: siprec@ietf.org > Subject: Re: [siprec] Metadata version indication >=20 > I appreciate the problem here. There are a variety of ways to solve it. >=20 > The obvious one would be to keep changing the content-type, by > embedding > a version number in the mime-type name itself. This could present some > logistical difficulties as we transition from draft to RFC. I guess it > might also not be approved by mime gurus. It has the advantage that you > won't accidentally try to parse a syntax you aren't prepared for. >=20 > Another way is to change the xmlns urn for each draft. As long as every > version starts with the element that will be sufficient to > disambiguate without getting into parsing trouble. >=20 > Another would be to add another (optional?) attribute to the > > element. >=20 > I don't know enough about XML to have a strong preference among these. >=20 > But it may be a little late for this. How many more changes to the > schema do we expect before RFC? >=20 > Thanks, > Paul >=20 > On 10/24/12 5:19 AM, Parthasarathi R wrote: > > Hi Ofir, > > > > This issues was raised earlier by Hadriel. I agree that it is good to > > have "version" element inside recording element to indicate the > current > > version of the SIPREC metadata. This helps in case the metadata is > > extended from 1.0 to 2.0 by the update of RFC. > > > > I'm not very sure whether it is accepted in IETF draft to update the > > version of XML schema for each revision of the draft. For example, > the > > current version for the metadata draft will be 0.8 and the next > revision > > of the draft will be updated as 0.9. Let us look more comments for > the > > generic approach to solve this issue. > > > > Thanks > > > > Partha > > > > *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > > Behalf Of *Ofir Roth > > *Sent:* Wednesday, October 24, 2012 1:09 PM > > *To:* siprec@ietf.org > > *Subject:* [siprec] Metadata version indication > > > > Hi, > > > > From our experience in SIPREC implementations, we often come across > > vendors that use different versions of the SIPREC metadata versions > > (which are not necessarily aligned with the latest version of > metadata). > > > > AFAIK, there is no way to indicate the metadata version as part of > the > > XML/SIP headers. > > > > I think that having such indication will be very useful for SIPREC > > implementers as they can reject or handle the metadata according to > > their ability to use those versions. > > > > I will appreciate your comment on that. > > > > Thanks, > > Ofir Roth. > > > > > > > > _______________________________________________ > > 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 Oct 25 10:08: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 BA37021F89B1 for ; Thu, 25 Oct 2012 10:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQKYffU0QjCS for ; Thu, 25 Oct 2012 10:08:54 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5221F89B2 for ; Thu, 25 Oct 2012 10:08:53 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id FQxZ1k0060Fqzac5DV8yTL; Thu, 25 Oct 2012 17:08:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id FV8h1k0123ZTu2S3UV8hPL; Thu, 25 Oct 2012 17:08:41 +0000 Message-ID: <50897223.7040609@alum.mit.edu> Date: Thu, 25 Oct 2012 13:08:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> In-Reply-To: <50881159.6050407@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [siprec] Metadata version indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 17:08:54 -0000 I forgot: another alternative is a mime type parameter. Thanks, Paul On 10/24/12 12:03 PM, Paul Kyzivat wrote: > I appreciate the problem here. There are a variety of ways to solve it. > > The obvious one would be to keep changing the content-type, by embedding > a version number in the mime-type name itself. This could present some > logistical difficulties as we transition from draft to RFC. I guess it > might also not be approved by mime gurus. It has the advantage that you > won't accidentally try to parse a syntax you aren't prepared for. > > Another way is to change the xmlns urn for each draft. As long as every > version starts with the element that will be sufficient to > disambiguate without getting into parsing trouble. > > Another would be to add another (optional?) attribute to the > element. > > I don't know enough about XML to have a strong preference among these. > > But it may be a little late for this. How many more changes to the > schema do we expect before RFC? > > Thanks, > Paul > > On 10/24/12 5:19 AM, Parthasarathi R wrote: >> Hi Ofir, >> >> This issues was raised earlier by Hadriel. I agree that it is good to >> have “version” element inside recording element to indicate the current >> version of the SIPREC metadata. This helps in case the metadata is >> extended from 1.0 to 2.0 by the update of RFC. >> >> I’m not very sure whether it is accepted in IETF draft to update the >> version of XML schema for each revision of the draft. For example, the >> current version for the metadata draft will be 0.8 and the next revision >> of the draft will be updated as 0.9. Let us look more comments for the >> generic approach to solve this issue. >> >> Thanks >> >> Partha >> >> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On >> Behalf Of *Ofir Roth >> *Sent:* Wednesday, October 24, 2012 1:09 PM >> *To:* siprec@ietf.org >> *Subject:* [siprec] Metadata version indication >> >> Hi, >> >> From our experience in SIPREC implementations, we often come across >> vendors that use different versions of the SIPREC metadata versions >> (which are not necessarily aligned with the latest version of metadata). >> >> AFAIK, there is no way to indicate the metadata version as part of the >> XML/SIP headers. >> >> I think that having such indication will be very useful for SIPREC >> implementers as they can reject or handle the metadata according to >> their ability to use those versions. >> >> I will appreciate your comment on that. >> >> Thanks, >> Ofir Roth. >> >> >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From eckelcu@cisco.com Fri Oct 26 11:52: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 C367F21F8634 for ; Fri, 26 Oct 2012 11:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzLKmhBKFn32 for ; Fri, 26 Oct 2012 11:52:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B7F7821F8633 for ; Fri, 26 Oct 2012 11:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4480; q=dns/txt; s=iport; t=1351277537; x=1352487137; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ty7eQWcCOotwD8dBrqnuTLLlJRkxyi7mZzfk+xUd+Tg=; b=VRsSwTqAI9b8sYhTQOjm/7FY/jW4XLTwNG7XeQRuRgbcaeJ4bQUw89xf pisdrI14aWt9t1W8rabnXomRxeMxBgnXsA5IObbv+Z+i1OQrAOA2ZgS0J MIVGLqNY90Lai2+1Qm9bn3ogjPKWoE+F4LZdm0DeDSls9wgFNaXW5ULEy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFzailCtJV2Y/2dsb2JhbABEDsJCgQiCHgEBAQQBAQEPASc0CwwEAgEIDgMEAQEBChQJBycLFAkIAQEEAQ0FCBqHYwELnG6gEQSLcYYNYQOkRoFrgjI9ghk X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="135573086" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 26 Oct 2012 18:52:16 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9QIqGfv018752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 18:52:16 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 13:52:16 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] Metadata version indication Thread-Index: Ac2xuoKlnQ0d4/p1R2+UYYJTcCmk7QADLHTgABj1KoAANJHWgAArWiig Date: Fri, 26 Oct 2012 18:52:15 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280EE196@xmb-aln-x08.cisco.com> References: <002701cdb1c8$a1cbdc80$e5639580$@co.in> <50881159.6050407@alum.mit.edu> <50897223.7040609@alum.mit.edu> In-Reply-To: <50897223.7040609@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.103] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19310.001 x-tm-as-result: No--57.678100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] Metadata version indication X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 18:52:24 -0000 [Channeling recommendation from Matt] In the XMPP Standards Foundation (XSF), we started to include versioning in= to the XML namespace: urn:xmpp:{protocol-shortname}:{version} For instance, Message Carbons (specified in XEP-0280) uses the namespace "u= rn:xmpp:carbons:2". Now, the version number doesn't update with each revision of the specificat= ion. Instead, it updates with any change that is not compatible with the p= revious protocol version. Also, once the XEP moves from "Experimental" (ro= ughly analogous to internet-drafts; many changes possible) to "Draft" (roug= hly analogous to RFC; changes are very minimal, mostly clarifications), the= protocol version is *NOT CHANGED*. This seems to be working out well for us; it means that anyone that's up to= date from the experimental phase is current when we go draft/recommended-t= o-implement. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > -----Original Message----- > From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, October 25, 2012 10:09 AM > To: siprec@ietf.org > Subject: Re: [siprec] Metadata version indication >=20 > I forgot: another alternative is a mime type parameter. >=20 > Thanks, > Paul >=20 > On 10/24/12 12:03 PM, Paul Kyzivat wrote: > > I appreciate the problem here. There are a variety of ways to solve it. > > > > The obvious one would be to keep changing the content-type, by > embedding > > a version number in the mime-type name itself. This could present some > > logistical difficulties as we transition from draft to RFC. I guess it > > might also not be approved by mime gurus. It has the advantage that you > > won't accidentally try to parse a syntax you aren't prepared for. > > > > Another way is to change the xmlns urn for each draft. As long as every > > version starts with the element that will be sufficient to > > disambiguate without getting into parsing trouble. > > > > Another would be to add another (optional?) attribute to the > > element. > > > > I don't know enough about XML to have a strong preference among these. > > > > But it may be a little late for this. How many more changes to the > > schema do we expect before RFC? > > > > Thanks, > > Paul > > > > On 10/24/12 5:19 AM, Parthasarathi R wrote: > >> Hi Ofir, > >> > >> This issues was raised earlier by Hadriel. I agree that it is good to > >> have "version" element inside recording element to indicate the curren= t > >> version of the SIPREC metadata. This helps in case the metadata is > >> extended from 1.0 to 2.0 by the update of RFC. > >> > >> I'm not very sure whether it is accepted in IETF draft to update the > >> version of XML schema for each revision of the draft. For example, the > >> current version for the metadata draft will be 0.8 and the next revisi= on > >> of the draft will be updated as 0.9. Let us look more comments for the > >> generic approach to solve this issue. > >> > >> Thanks > >> > >> Partha > >> > >> *From:*siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] *On > >> Behalf Of *Ofir Roth > >> *Sent:* Wednesday, October 24, 2012 1:09 PM > >> *To:* siprec@ietf.org > >> *Subject:* [siprec] Metadata version indication > >> > >> Hi, > >> > >> From our experience in SIPREC implementations, we often come across > >> vendors that use different versions of the SIPREC metadata versions > >> (which are not necessarily aligned with the latest version of metadata= ). > >> > >> AFAIK, there is no way to indicate the metadata version as part of the > >> XML/SIP headers. > >> > >> I think that having such indication will be very useful for SIPREC > >> implementers as they can reject or handle the metadata according to > >> their ability to use those versions. > >> > >> I will appreciate your comment on that. > >> > >> Thanks, > >> Ofir Roth. > >> > >> > >> > >> _______________________________________________ > >> siprec mailing 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 Ofir.Roth@nice.com Fri Oct 26 15:42:03 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 E20F821F8566 for ; Fri, 26 Oct 2012 15:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo6JoVVMGT-a for ; Fri, 26 Oct 2012 15:42:03 -0700 (PDT) Received: from mailil.nice.com (mailil.nice.com [192.114.148.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7036121F84B9 for ; Fri, 26 Oct 2012 15:42:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,657,1344200400"; d="txt'?zip'48?scan'48,208,217,48";a="4758636" Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas02.nice.com ([172.18.253.6]) with mapi; Sat, 27 Oct 2012 00:42:00 +0200 From: Ofir Roth To: "siprec@ietf.org" Date: Sat, 27 Oct 2012 00:41:58 +0200 Thread-Topic: Metadata V8 - Consult Transfer Scenario Thread-Index: Ac2zynxdRKOUTh63RHKy7nJybQgSoA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC3725TLVMBX01nicec_" MIME-Version: 1.0 Subject: [siprec] Metadata V8 - Consult Transfer Scenario X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 26 Oct 2012 22:42:04 -0000 --_004_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC3725TLVMBX01nicec_ Content-Type: multipart/alternative; boundary="_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC3725TLVMBX01nicec_" --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC3725TLVMBX01nicec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have created a simple metadata consult transfer scenario (attached). The scenario is simple consult transfer scenario: 1. Alice calls to Bob, Bob answer (first metadata update) 2. Alice hold the call with Bob (second metadata update) 3. Alice consults with Joe (third metadata update) 4. Bob and Joe are talking (fourth metadata update) Will be happy to get comments on the metadata call flow. Note: I have dropped the SDP from the example for the sake of simplicity. O= nce confirmed as a valid metadata flow, I will update it with the SDP. Thanks, Ofir Roth. --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC3725TLVMBX01nicec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have cre= ated a simple metadata consult transfer scenario (attached).

 

The scenari= o is simple consult transfer scenario:

1.       Alice calls to Bob, Bob answer (first metadata update) &= nbsp;

2.    = ;   Alice hold the= call with Bob (second metadata update)

3.       Alice consults with Joe (third metadata update)

4.      = Bob and Joe are talking (fo= urth metadata update)

 <= /p>

Will be happy to get comments on the metadata call = flow.

Note: I have dropped the SDP from= the example for the sake of simplicity. Once confirmed as a valid metadata= flow, I will update it with the SDP.

 

Thanks,
Ofir Roth.

= --_000_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC3725TLVMBX01nicec_-- --_004_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC3725TLVMBX01nicec_ Content-Type: application/x-zip-compressed; name="ConsultTransferScenario.zip" Content-Description: ConsultTransferScenario.zip Content-Disposition: attachment; filename="ConsultTransferScenario.zip"; size=1140; creation-date="Fri, 26 Oct 2012 22:39:11 GMT"; modification-date="Fri, 26 Oct 2012 22:39:11 GMT" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAJxUWkFfIhuN3AMAAPMYAAAbAAAAQ29uc3VsdFRyYW5zZmVyU2NlbmFyaW8udHh0 5VjNcuJGEL5v1b7DhEMuKaERGCehBJsllrxmwY7EzLDhkhJibCka/ZQ0XvxuOeSR8goZRlrCGo9B +LeyHEBI3eqve76e/iTzO00DvscYmFO+pDQB71noU8BTMEjnQNP6b9/889ff5rubmIHPNC/CNOk1 jCZsAJr46SJMrnqNa36p/dR4J0zNnPppvjoLhENSdG+KsNcIOM+6ur5cLpvLdjPNr/QWhIb+aTya +AGNPS1MCu4lPm2svRa7vSpjET5PuiHll93My71YeMesK26yhtIQwAAwFx734nRB+34aZ4xyaurr U9LgKk+vMyC//wgFAETYKbaCMWauPbE6FwgOLeT0euX9hINXFKkfepxqPIxpvwWNlmZArXWMDNht H3c7neZRB/7Yabd/gK0uhKZ+y0OG1WXE8rigxarCoPqVMCZscIqjzoCQ2QWyBw6GnTP0fgOGqF3O 94awYV35y/haTi/7qowrjNKmxFwBLP+JuvPQDzMv4WDjWKKfRudDFwYDhyx+xywbOZh/cJYb6BMv pmcnwEvzXsNbce+XRHw1xSJ9MamM+pKZpi6PK2e99K5AbcTeDcy1bGtquwNk2GRCshNkE4QdBbB5 OlfCEn1SC1TBc+rFoPwpoUQBcS3jHEc/TxwjGyHIz/BqhevxgHlzyvqGqZcH1ULJMKrIImniGoGD IsOewOEnEg0HsgiHRG7dE7m827olZR/Ui/FIzXYnki22VFYlzL0p/SIJKVDXS0nZDK87Jcmwmou0 3jVpsuir+L/iibhcmQqyfO6rmtTU5eVt5P+BqwV8574kkanRbAFX57gPcGlVtor49/aNVvOz8jFX IqPUFQFlC8ADWmqO/6W8kKX02G11sefy7+TtI5Dx0dZUzmvgp0lxzXgBliEPwJ8p/abW9ZWqRidi I4TPBxPrhkytTEA6H5NaqtEQEI5eSDW6NkOEBCdTm11gaHgOCcZK1SgYpxRnw7SeYtyWSFOcfcTQ Jg52EYbuFEfZr/jq9mjcWe5SGbXriDMCFzOEhzNssDGy2UcUBSOypTP2jHz0EHG2M8ZenP6KUC8r zp4rob2VzL3iTNUMrzulhww5KWJU/L9D46iadGMePk0FDhV5u/Y3maE6q60CqGv1nAV4NGGxevf0 vZQSXk4B91gkbtn8pnTFgUM9ze5b29bXM/2LceX94JF+xwsGvPjgMhcRi82wNTydRsMzt/6DZTm6 OnWmJ2azE0LYzMH2ZAKD34hhO+jQlyrH6sh77+LP+IjdqtXCTzyYXl1KD374VlHrrodvBf8P2Jfr VeBJB5M6q60CqGv1nAXYHEz/AlBLAQIUABQAAAAIAJxUWkFfIhuN3AMAAPMYAAAbAAAAAAAAAAEA IAAAAAAAAABDb25zdWx0VHJhbnNmZXJTY2VuYXJpby50eHRQSwUGAAAAAAEAAQBJAAAAFQQAAAAA --_004_D6FF53BFD24F6F448C70DEF68DB4E6655A8BCC3725TLVMBX01nicec_-- From eckelcu@cisco.com Tue Oct 30 09:47:29 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 80B3121F8735 for ; Tue, 30 Oct 2012 09:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj1M949kr1Lp for ; Tue, 30 Oct 2012 09:47:28 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A644A21F871E for ; Tue, 30 Oct 2012 09:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1759; q=dns/txt; s=iport; t=1351615648; x=1352825248; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2HYiwKUKb2lhRwG2U2V4qNXalVIRYpIvtTz7ts1Rgbc=; b=iaOkivCk6CYQKwDaQkHxqjNlPAHMCyF942pkxQEubFobp6/kdKB7ZFjv ef0DlENb6e6IdNC6VmoSQ/EtJafeFsITiiF/619PpEJt5YJBmrPi1OEr8 iVWwDy8ZW6jHswfqXANf2/1SHhYZQaqkxGdtz3nthTQhbGQg7s4DT32dk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHkDkFCtJV2Z/2dsb2JhbABEw1CBCIIgAQQSAScuIwEqFEImAQQbGodjAZtsgSyPZ5A7kXNhA6RMgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,680,1344211200"; d="scan'208";a="137001119" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 30 Oct 2012 16:47:28 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9UGlSCm007157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Oct 2012 16:47:28 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 11:47:28 -0500 From: "Charles Eckel (eckelcu)" To: "siprec@ietf.org" Thread-Topic: support for multiple m-lines Thread-Index: Ac22vj5wBR3g0hdZTjWqjoea7ubQ9Q== Date: Tue, 30 Oct 2012 16:47:27 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280F3397@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--35.540800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] support for multiple m-lines X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2012 16:47:29 -0000 At IETF 84, we had some discussion about an SRC using multiple m-lines. As = a simple example, when recording an audio only point to point call, an SRC = may offer 2 audio m-lines to the SRS, using one m-line for each participant= audio stream. The current text in the protocol draft is as follows: When using multiple m-lines, an SRC includes each m-line in an SDP offer to the SRS. The SDP answer from the SRS MUST include all m-lines, with any rejected m-lines indicated with a zero port, per [RFC3264]. Having received the answer, the SRC starts sending media to the SRS as indicated in the answer. Alternatively, if the SRC deems the level of support indicated in the answer to be unacceptable, it may initiate another SDP offer/answer exchange in which an alternative RTP session usage is negotiated. The consensus from the room at the time was to add a requirement for the SR= S to support a minimum number of m-lines. Here are some options: a) SRS MUST support at least two audio m-lines (sufficient for audio only p= oint to point call without any mixing or multiplexing) b) SRS MUST support at least two audio m-lines and two video m-lines (suffi= cient for audio/video point to point call without any mixing or multiplexin= g) c) SRS MUST support at least two audio m-lines and three video m-lines (suf= ficient for audio/video point to point call without any mixing or multiplex= ing, plus a shared content video channel) =20 If we address recording of conferences without mixing or multiplexing, this= number of m-lines grows quickly. For the purpose of the SIPREC protocol document, do people favor adding an = SRS requirement for a, b, or c, or something else. Thanks, Charles From rajnish.jain@ipc.com Tue Oct 30 10:04:19 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 6C7F721F8716 for ; Tue, 30 Oct 2012 10:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNxxl8tIx0CP for ; Tue, 30 Oct 2012 10:04:18 -0700 (PDT) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) by ietfa.amsl.com (Postfix) with ESMTP id AC8F821F8719 for ; Tue, 30 Oct 2012 10:04:10 -0700 (PDT) Received: from unknown [213.235.62.206] (EHLO p01c12o145.mxlogic.net) by p01c12o145.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id a8800905.76d95940.114646.00-597.271336.p01c12o145.mxlogic.net (envelope-from ); Tue, 30 Oct 2012 11:04:10 -0600 (MDT) X-MXL-Hash: 5090088a639c8609-8c46e9984fa737e7ab1d72fb11525a8a5fbe79e2 Received: from unknown [213.235.62.206] by p01c12o145.mxlogic.net(mxl_mta-6.15.0-1) with SMTP id 88800905.0.114571.00-353.271315.p01c12o145.mxlogic.net (envelope-from ); Tue, 30 Oct 2012 11:04:10 -0600 (MDT) X-MXL-Hash: 5090088a0280e99e-660ca656342f2dc3d9322f930212b65533bd2d44 Received: from STSNYEXMBX2.corp.root.ipc.com ([fe80::157c:2ec6:ebe1:434b]) by STSNYEXHTCAS1.corp.root.ipc.com ([fe80::142:b161:c064:665b%12]) with mapi id 14.02.0309.002; Tue, 30 Oct 2012 13:03:59 -0400 From: "Jain, Rajnish" To: "Charles Eckel (eckelcu)" , "siprec@ietf.org" Thread-Topic: support for multiple m-lines Thread-Index: Ac22vj5wBR3g0hdZTjWqjoea7ubQ9QAAVL8g Date: Tue, 30 Oct 2012 17:03:58 +0000 Message-ID: <4C91F9B607136D48AE3411BDC594D2AE0F3B49A8@STSNYEXMBX2.corp.root.ipc.com> References: <92B7E61ADAC1BB4F941F943788C088280F3397@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280F3397@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.43.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [213.235.62.206] X-AnalysisOut: [v=2.0 cv=NPJiDTGg c=1 sm=0 a=Dm638S/ynaLBMu9ohoEvUg==:17 a] X-AnalysisOut: [=TI9zlQ3hUaoA:10 a=22jh1dAhzdYA:10 a=lCc8-jNt9F8A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=vvKfUcg] X-AnalysisOut: [jAAAA:8 a=Br-ZfiZ11twA:10 a=48vgC7mUAAAA:8 a=Lk0eRYayR2IDb] X-AnalysisOut: [0ZS79wA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=4xucoJ_JSz] X-AnalysisOut: [Y1U76b:21 a=RqbpwQFa7i0aidzL:21] Subject: Re: [siprec] support for multiple m-lines X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2012 17:04:19 -0000 I agree that specifying a MUST-level requirement on minimum number of m-lin= es for SRS to support for recording conferences that are not mixed is not p= ractical. SRS implementations can still choose to implement products that e= xceed a, b, or c. However, in terms of a must meet requirements specificati= on, I agree along the lines of a, b, or c.=20 Thanks, Raj -----Original Message----- From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of= Charles Eckel (eckelcu) Sent: Tuesday, October 30, 2012 12:47 PM To: siprec@ietf.org Subject: [siprec] support for multiple m-lines At IETF 84, we had some discussion about an SRC using multiple m-lines. As = a simple example, when recording an audio only point to point call, an SRC = may offer 2 audio m-lines to the SRS, using one m-line for each participant= audio stream. The current text in the protocol draft is as follows: When using multiple m-lines, an SRC includes each m-line in an SDP offer to the SRS. The SDP answer from the SRS MUST include all m-lines, with any rejected m-lines indicated with a zero port, per [RFC3264]. Having received the answer, the SRC starts sending media to the SRS as indicated in the answer. Alternatively, if the SRC deems the level of support indicated in the answer to be unacceptable, it may initiate another SDP offer/answer exchange in which an alternative RTP session usage is negotiated. The consensus from the room at the time was to add a requirement for the SR= S to support a minimum number of m-lines. Here are some options: a) SRS MUST support at least two audio m-lines (sufficient for audio only p= oint to point call without any mixing or multiplexing) b) SRS MUST support at least two audio m-lines and two video m-lines (suffi= cient for audio/video point to point call without any mixing or multiplexin= g) c) SRS MUST support at least two audio m-lines and three video m-lines (suf= ficient for audio/video point to point call without any mixing or multiplex= ing, plus a shared content video channel) =20 If we address recording of conferences without mixing or multiplexing, this= number of m-lines grows quickly. For the purpose of the SIPREC protocol document, do people favor adding an = SRS requirement for a, b, or c, or something else. Thanks, Charles _______________________________________________ siprec mailing list siprec@ietf.org https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Tue Oct 30 17:32: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 AC72321F866C for ; Tue, 30 Oct 2012 17:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkZXP361phYp for ; Tue, 30 Oct 2012 17:32:32 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E870621F8661 for ; Tue, 30 Oct 2012 17:32:31 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta02.westchester.pa.mail.comcast.net with comcast id Hc171k0051GhbT851cYcMX; Wed, 31 Oct 2012 00:32:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id HcZ51k00K3ZTu2S3TcZ53K; Wed, 31 Oct 2012 00:33:05 +0000 Message-ID: <5090719D.3070404@alum.mit.edu> Date: Tue, 30 Oct 2012 20:32:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <92B7E61ADAC1BB4F941F943788C088280F3397@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C088280F3397@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] support for multiple m-lines X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 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, 31 Oct 2012 00:32:32 -0000 On 10/30/12 12:47 PM, Charles Eckel (eckelcu) wrote: > At IETF 84, we had some discussion about an SRC using multiple m-lines. As a simple example, when recording an audio only point to point call, an SRC may offer 2 audio m-lines to the SRS, using one m-line for each participant audio stream. > The current text in the protocol draft is as follows: > > When using multiple m-lines, an SRC includes each m-line in an SDP > offer to the SRS. The SDP answer from the SRS MUST include all > m-lines, with any rejected m-lines indicated with a zero port, per > [RFC3264]. Having received the answer, the SRC starts sending media > to the SRS as indicated in the answer. Alternatively, if the SRC > deems the level of support indicated in the answer to be > unacceptable, it may initiate another SDP offer/answer exchange in > which an alternative RTP session usage is negotiated. > > The consensus from the room at the time was to add a requirement for the SRS to support a minimum number of m-lines. Here are some options: > > a) SRS MUST support at least two audio m-lines (sufficient for audio only point to point call without any mixing or multiplexing) > b) SRS MUST support at least two audio m-lines and two video m-lines (sufficient for audio/video point to point call without any mixing or multiplexing) > c) SRS MUST support at least two audio m-lines and three video m-lines (sufficient for audio/video point to point call without any mixing or multiplexing, plus a shared content video channel) > > If we address recording of conferences without mixing or multiplexing, this number of m-lines grows quickly. > For the purpose of the SIPREC protocol document, do people favor adding an SRS requirement for a, b, or c, or something else. I'm not sure there is anything useful that we can say. You talk about conferences as perhaps needing more m-lines. But there is also the case of an SRC that wants to record multiple independent CSs over the same RS. Regarding audio vs. video - I don't think we should require video support, because some plausible products may not want to support it. I suppose it is also possible to imagine a recorder product that is intended only to record video (e.g. surveillance) and not audio. Clearly there is a problem if the SRS can't record at least the media it supports for at least one CS. (Or CS-group?) For an SRC that is able to record multiple CSs in a single RS, I suppose we can assume that it will expect there to be *some* limit to how many, and so it might need to be prepared for rejection of an offer with too many m-lines. In that case it can have a fallback procedure of establishing another RS. But for a single CS, I the only fallback would be from unmixed streams to mixed streams. And I suspect many SRCs won't be flexible enough to make that change. So, while it would be nice to have some minimum to implement limit, in practice I think it might be impractical to impose one. I think this might be one of those "quality of implementation" issues. At most I think we might say that an SRS SHOULD be capable of accepting a separate stream for each participant, for each medium the SRS supports, for as many CSs and participants as it claims to support. Thanks, Paul