Re: [siprec] Comments on draft-ietf-siprec-callflows-06

["Ram Mohan R (rmohanr)" <[e-mail]>]

Hi all,

Please find the diffs that addresses the WGLC comments received so far.

Regards,
Ram
 
-----Original Message-----
From: Cisco Employee <[e-mail]>
Date: Wednesday, 8 June 2016 at 3:13 PM
To: Charles Armitage <[e-mail]>, "[e-mail]"
<[e-mail]>
Cc: Julian Churchill <[e-mail]>, Ian Burniston
<[e-mail]>
Subject: Re: [siprec] Comments on draft-ietf-siprec-callflows-06

>Thanks a lot. Appreciate the good review. I will address these nits in the
>next revision.
>
>Regards,
>Ram
>
>From:  siprec <[e-mail]> on behalf of Charles Armitage
><[e-mail]>
>Date:  Wednesday, 8 June 2016 at 2:35 PM
>To:  "[e-mail]" <[e-mail]>
>Cc:  Julian Churchill <[e-mail]>, Ian Burniston
><[e-mail]>
>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:
>[phone]
>Bradmore Business Park, Loughborough Road, Bradmore, Nottingham, NG11 6QA,
>United Kingdom
>[e-mail]
> |  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.
>
>
>
> 
>