Subject: [siprec] More comments on draft-rehor-siprec-req-00

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 14 May 2010 16:12:52 +0200

Some more comments on draft-rehor-siprec-req-00.

1. Definitions - There are to definitions which are abbreviated to RS. In the arch draft we did not use the abbreviated form for the "Recording Session" and "Communication Session".
 
2. Definitions - In the arch draft we have a definition for a "Recording Aware UA". This is not a RC but a UA which is simply aware of recording and understands SIPREC extensions such as notifications that a session is being recorded. Maybe we should do the same in the requirements draft to indicate that SIPREC is not only about the interface between the RC and RS.
 
3. Section 4 - Example Deployment Architecture. I am not sure about the "Recording Control" mentioned in the text and the diagram I think this is just the Recording Session we have not determined if any type of control is necessary. Maybe this is why we get comments from the mediactrl people.
 
4. Use Case 4 - States "In some cases, more than one concurrent Communication Session (on a single end-user apparatus, e.g. trading floor turret) is mixed into one Recording Session::" I am not sure about using the term "mixed" in this case I don't think we really mean that the media is mixed but that could be one interpretation. Maybe we could say "A single Recording Session may be associated with multiple concurrent communication sessions" if this really is a requirement.

5. Use Case 5 - Can we be more explicit about the difference between "Pause/Resume" and "Mute/Unmute".

6. Requirements - 1st statement "The following are requirements for the Session Recording Protocol:". I don't like the use of the term "Session Recording Protocol" it implies a single protocol. Could we just say "The following are requirements for the SIP Based Session Recording".

7. REQ-028 Recorder MUST provide alarm notifications when a failure occurs. Is this really a SIPREC requirement or just a generic requirement on the RS which could be satisfied on other ways (E.g. SNMP) if so I think we should remove it.

Regards

Andy