Re: [siprec] Comments on draft-ietf-siprec-callflows-06
"Ram Mohan R (rmohanr)" <rmohanr@cisco.com> Wed, 08 June 2016 09:44 UTC
Return-Path: <rmohanr@cisco.com>
X-Original-To: siprec@ietfa.amsl.com
Delivered-To: siprec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0985312D896 for <siprec@ietfa.amsl.com>; Wed, 8 Jun 2016 02:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okcWm77xBMKo for <siprec@ietfa.amsl.com>; Wed, 8 Jun 2016 02:43:59 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF8A12D8B7 for <siprec@ietf.org>; Wed, 8 Jun 2016 02:43:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10151; q=dns/txt; s=iport; t=1465379038; x=1466588638; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Ree24+9MT5W7+ciYeGqZa7ehg+5CcSAprLMIiLkSUD0=; b=W7Z2Iln7cchVeYSmMZmbBPS9fdQaf/yu9dp3uwQcqtWz9O5eZsmhLBJw ys7J/4PEMKIKleKmoJdFgu6ggcWKvCsaFxpbZ1CSXngXQsvVjXGZZyYnt UPXwD9by1AAhpIcxoxcS1YBBNBLQMCjo8IhOOqH5/tA9YW6ksUAeapb5x g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOBQD751dX/5BdJa1aAgGDPlZ9BrsDgXkXC4VxAoE6ORMBAQEBAQEBZSeERQEBAQQMPR8REgEIBwcDAwECGgJFHQoEAQkEBYgvDr0HAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIp0hBwOFiEmFgGBa0uCRgWGRIx3hRQBhRpoiCOBaYRSiGSPYAEfATSCBxyBS26IS0V/AQEB
X-IronPort-AV: E=Sophos;i="5.26,438,1459814400"; d="scan'208";a="116496452"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2016 09:43:57 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u589htfw032529 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jun 2016 09:43:55 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 8 Jun 2016 05:43:55 -0400
Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Wed, 8 Jun 2016 05:43:55 -0400
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: Charles Armitage <carmitage@redboxrecorders.com>, "siprec@ietf.org" <siprec@ietf.org>
Thread-Topic: [siprec] Comments on draft-ietf-siprec-callflows-06
Thread-Index: AQHRwWpF1R+X93XcN0W2sKGX3pTrXw==
Date: Wed, 08 Jun 2016 09:43:54 +0000
Message-ID: <D37DDE3F.5EE57%rmohanr@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.4.160422
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.196.105.184]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <5F2F4A8F9BBA88419B2DB6D3957F37B1@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/siprec/2CavIs9o-VhnKJNXgyxKcaHIFdU>
Cc: Julian Churchill <jchurchill@redboxrecorders.com>, Ian Burniston <iburniston@redboxrecorders.com>
Subject: Re: [siprec] Comments on draft-ietf-siprec-callflows-06
X-BeenThere: siprec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Recording Working Group Discussion List <siprec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/siprec>, <mailto:siprec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/siprec/>
List-Post: <mailto:siprec@ietf.org>
List-Help: <mailto:siprec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/siprec>, <mailto:siprec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2016 09:44:02 -0000
Thanks a lot. Appreciate the good review. I will address these nits in the next revision. Regards, Ram From: siprec <siprec-bounces@ietf.org> on behalf of Charles Armitage <carmitage@redboxrecorders.com> Date: Wednesday, 8 June 2016 at 2:35 PM To: "siprec@ietf.org" <siprec@ietf.org> Cc: Julian Churchill <jchurchill@redboxrecorders.com>, Ian Burniston <iburniston@redboxrecorders.com> Subject: [siprec] Comments on draft-ietf-siprec-callflows-06 Hi, Re: reviewing - draft-ietf-siprec-callflows-06 Mostly nits: Page 1: ³This document lists call flows that has snapshot of metadata sent from a Session Recording Client to Session Recording Server.² Try: ŒThis document lists call flows with metadata snapshots sent from a Session Recording Client to a Session Recording Server¹ Page 2: TOC: ³Turrent- Case: Multiple CS into single RS with mixed stream ³ Should be: ³Turret- Case: Multiple CS into single RS with mixed stream² 1. Overview: ³This document lists few examples and shows the snapshots of metadata sent from a Session Recording ClientŠ² Missing Œa¹: ³³This document lists few examples and shows the snapshots of metadata sent from a Session Recording ClientŠ² ³For the sake of simplicity the entire Session Initiation Protocol (SIP) [RFC3261] messages are not shown at various points , instead only snippets of the SIP and Session Description Protocol (SDP)[RFC4566] messages and the XML snapshot of metadata is shown.² Remove: ³at various points² I don¹t think there is an example in the document with a full SIP message (if there are there are very few). Page 3: 3.1. Sample Call flow ³The subsequent sections describes the snapshot of metadata sent from SRC to SRS for each of the above transactions² Try: ³The subsequent sections describe the snapshot of metadata sent from SRC to SRS for each of the above transactions² (note: describes to describe) ³There may be multiple UPDATES/RE-INVITES mid call to indicates snapshots of different CS changes. ³ Try: ³There may be multiple UPDATES/RE-INVITES mid call to indicate snapshots of different CS changes. ³ (note: indicates to indicate) ³The subsequent sections in this document tries to list some example metadata snapshots for three major categories.² Try: ³The subsequent sections in this document try to list some example metadata snapshots for three major categories.² (Note: tries to try) ³Special flows like Turrent flows.² Should be: ³Special flows like Turret flows.² 3.2. Call Scenarios with SRC recording streams with out mixing Should be: 3.2. Call Scenarios with SRC recording streams without mixing ³This section describes few example flows where SRC can be a SIP-UA or B2BUA as described in section 3 of [RFC7245]. ³ Remove Œfew¹ ³The SRCs records the streams of each participant to SRS with out mixing in this example .² With out should be without Also try: ³In this example the SRCs records the streams of each participant to SRS without mixing.² Page 7: 3.2.2. Example 2: Hold/resume ³A call between two participants Alice and Bob is established and a RS is created for recording as in example1 . ³ Example1 should be example 1. Page 13 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) ³Please note this is a optional message. An SRC may choose to just send a INVITE with a new session element to implicitly indicate that the participants are now part of a different CS with out sending disassociation from the old CS. ³ Try: ³Please note this is an optional message. An SRC may choose to just send an INVITE with a new session element to implicitly indicate that the participants are now part of a different CS without sending disassociation from the old CS. ³ (Note: changes from Œa¹ to Œan¹ and Œwith out¹ to Œwithout¹) Page 15 3.2.3. Example 3:Call Transfer (RE-INVITE and REFER based) ³The sipSessionID XML element in metadata snapshot now indicates Alice and Carol in the (local, remote) uuid pair.² Should Alice actually be Bob? Page 18 ³In this use case each participant call into a conference server (say, an MCU) to attend one of many conferences hosted on or managed by that servers . ³ Try: ³In this use case each participant calls into a conference server (say, an MCU) to attend one of many conferences hosted on or managed by that server . ³ Note: Œcall to Œcalls¹ and Œservers¹ to Œserver¹ ³Media streams sent by each participant is received by all the other participants in the conference. ³ Try: ³Media streams sent by each participant are received by all the other participants in the conference. ³ Note: Œis¹ to Œare¹ Page 21: 3.3.2. Example 2: Hold/resume with SRC recording by mixing streams ³Assume a call between two participants Alice and Bob is established and a RS is created for recording as in example 5. This is the continuation of above use-case. One of the participants Bob puts Alice hold and then resumes as part of the same CS. The send and recv XML elements of a participant is used to indicate whether a participant is contributing or not to a media stream. ³ Try: ³This is the continuation of above use-case. Given a call between two participants Alice and Bob is established and a RS is created for recording as in example 5. One of the participants, Bob puts Alice hold and then resumes as part of the same CS. The send and recv XML elements of a participant are used to indicate whether a participant is contributing or not to a media stream. ³ Also replace Œabove use-case. Œ with ŒExample 1: Basic call with SRC mixing streams¹ to remove the positional dependency Page 24: 3.3.3. Example 3: Metadata snapshot of joining/dropping of a participant to a session ³The below shows a snapshot sent from SRC to SRC in these case. Note the SRC here can be a focus or a participant in the conference. In case where the SRC is a participant it may learn the information required for metadata by subscribing to conference event package [RFC4575]. ³ Try: ³Below is a snapshot sent from SRC to SRC in this case. Note the SRC here can be a Focus or a participant in the conference. In the case where the SRC is a participant it may learn the information required for metadata by subscribing to conference event package [RFC4575]. ³ Note: Focus was capitalized in previous paragraphs. Page 25: ³ Assume Alice drops after some time from the conference. SRC generates a new snapshot showing Alice disassociating from the session² Try: ³ Given Alice drops after some time from the conference. SRC generates a new snapshot showing Alice disassociating from the session² Page 26: <associate-time>2010-12-16T23:41:07Z</associate-time> Should this be disassociate-time? Page 27: ³The section shows the snapshots of metadata for the cases there a persistent RS exists between SRC and SRS. ³ Try: ³The section shows the snapshots of metadata for the cases where a persistent RS exists between SRC and SRS. ³ ³Except disconnect case, the snapshot remains same as mentioned in previous sections.² Not sure what is meant here? Perhaps: ³Except in the disconnect case, the snapshot remains same as mentioned in previous sections.² Page 28: <disasociate -time>2010-12-16T23:41:07Z</disassociate-time> Should be: <disassociate -time>2010-12-16T23:41:07Z</disassociate-time> 3.5. Turrent -Case: Multiple CS into single RS with mixed stream Should be: 3.5. Turret -Case: Multiple CS into single RS with mixed stream Page 29: ³Lets take a example where there are two CS[CS1 and CS2]. ³ Try: ³Taking an example where there are two CS [CS1 and CS2]. ³ ³In of the CS(say CS1), SRC is Focus and in the other CS(say CS2), SRC is just one of the participant of the conference.² Try: ³One of the CS (e.g. CS1), SRC is Focus and the other CS (e.g. CS2), SRC is just one of the participant of the conference.² That¹s the lot. Like I say a lot of nits. Let me know if there is a better way of submitting comments. Charles Armitage Technical Lead <http://www.redboxrecorders.com/> Tel: +44 (0)115 937 7100 Bradmore Business Park, Loughborough Road, Bradmore, Nottingham, NG11 6QA, United Kingdom carmitage@redboxrecorders.com | www.redboxrecorders.com <http://www.redboxrecorders.com/> <https://www.facebook.com/redboxrecorders> <https://twitter.com/redboxrecorders> <https://www.linkedin.com/company/red-box-recorders> <https://www.youtube.com/channel/UC_Z7j15zwvKIGMOqFJz5ubA> This e-mail and any files transmitted with it contain information that may be confidential or privileged, and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the information is prohibited and you are required to delete it from your systems. If you have received this e-mail in error, please notify us by e-mail immediately. Any opinions expressed are those of the author and do not necessarily represent the views of Red Box Recorders Limited. Registered office: Red Box Recorders Limited, Bradmore Business Park, Loughborough Road, Bradmore, Nottinghamshire NG11 6QA. Registered in England No.4186453.
- [siprec] Comments on draft-ietf-siprec-callflows-… Charles Armitage
- Re: [siprec] Comments on draft-ietf-siprec-callfl… Ram Mohan R (rmohanr)
- Re: [siprec] Comments on draft-ietf-siprec-callfl… Ram Mohan R (rmohanr)