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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 8 Jun 2016 09:43:54 +0000

Thanks a lot. Appreciate the good review. I will address these nits in the
next revision.

Regards,
Ram

From:  siprec <[email-masked]> on behalf of Charles Armitage
<[email-masked]>
Date:  Wednesday, 8 June 2016 at 2:35 PM
To:  "[email-masked]" <[email-masked]>
Cc:  Julian Churchill <[email-masked]>, Ian Burniston
<[email-masked]>
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
[email-masked]
 |  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.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 10 Jun 2016 18:16:55 +0000

Hi all,

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

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