Subject: [siprec] Comments on draft-ietf-siprec-protocol-02

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 12 Nov 2011 15:33:48 +0100

Some comments on this draft.

1. The introduction & abstract states "The Session
   Recording Protocol specifies the use of SIP, SDP, and RTP to
   establish a Recording Session (RS) from the Session Recording Client
   (SRC), which is on the path of the CS, to a Session Recording Server
   (SRS) at the recording device."

This is incorrect as the RS can be established in both directions so change the "from" to "between" and the "to a.." to "and".

2. Section 5.1 states "Participants information is not recorded in the From or To
header; they are included in the m
etadata".

I don't think this adds anything and I think should be removed.

3. Section 5.1 "SRC Procedures" 2nd Para. "An SRS uses the presence of the 'src'..." . This paragraph details what the SRS makes use of the feature tag and therefore does not belong in this section but in the SRS section. We also need a discussion as whether this is valid use of the feature tag by the SRS and the SRC.

4. Section 5.1 3rd paragraph. Maybe we should change "when initiating a Recording Session" to "when generating an INVITE to initiate a recording session". To make it clear that the "siprec" option tag is included in the initial invite.

5. Section 5.2 2nd Para. I think the sentence "Other SIP Recording extensions and behaviors can be triggered by the presence of this feature tag" should be removed as it does not add anything.

6. Section 5.2 last para. "An SRS SHOULD include the "siprec" option tag in the Require header as per [RFC3261] when initiating a Recording Session so that other types of user agents can simply reject the INVITE request with a 420 Bad Extension".  The "other types of users agents" is too vague and not strictly correct as a SRC is another type of UA and would not reject the INVITE. Probably should say that "UA's that don't support the Session Recording Protocol extensions will reject the INVITE...".

7. Section 6.1 2nd Para. "Note that a recorded stream is different than a CS stream;". Not sure what this note is trying to say and should either be removed or expanded with more explanation.

Will provide comments on section 8 very soon assuming I have some.

Regards
Andy (as an individual).

---

From: Leon Portman <[email-masked]>
Date: Sun, 13 Nov 2011 20:47:02 -0500

Andy Hi.

Thank you for the comments.

Please see below

Leon

> This is incorrect as the RS can be established in both directions so change the "from" to "between" and the "to a.." to "and".
[Leon] Correct

> I don't think this adds anything and I think should be removed.

[Leon] It emphasizes  the point that we should put there SRS anf SRS identities however i am ok to remove
> 3. Section 5.1 "SRC Procedures" 2nd Para. "An SRS uses the presence of the 'src'..." . This paragraph details what the SRS makes use of the feature tag and therefore does not belong in this section…

[Leon] i have added it to open items
> 4. Section 5.1 3rd paragraph. Maybe we should change "when initiating a Recording Session" to "when generating an INVITE to initiate a recording session". To make it clear that the "siprec" option…
[Leon] But we also should have for reinvites and updates, correct?

> 5. Section 5.2 2nd Para. I think the sentence "Other SIP Recording extensions and behaviors can be triggered by the presence of this feature tag" should be removed as it does not add anything.
[Leon] Ok

> 6. Section 5.2 last para. "An SRS SHOULD include the "siprec" option tag in the Require header as per [RFC3261] when initiating a Recording Session so that other types of user agents can simply rej…
[Leon] ok

> 7. Section 6.1 2nd Para. "Note that a recorded stream is different than a CS stream;". Not sure what this note is trying to say and should either be removed or expanded with more explanation.

[Leon] Ok
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec