Subject: [siprec] Comments on draft-rehor-siprec-req-00

From: Alan Johnston <[email-masked]>
Date: Thu, 13 May 2010 14:19:44 -0500

A few minor comments on the requirements draft are listed below.

- Alan -

- - - -

Under Use Case 10, I would like to see the scenario added where two
separate RS are used for a single RC, with the same media sent to each
of them.  This way, a failure in either RS would not result in an
interruption of recording.  There may not be any specific protocol
mechanisms needed to support this, but we need to make sure that nothing
prevents this

Under Use Case 12, there is a non-capitalized must - if it isn't a
normative statement, reword.

I'm not certain I understand:

"   o REQ-013 The mechanism MUST support the ability to deliver multiple
   media streams for a given Communication Session over separate
   Recording Sessions to the RS."

Are the multiple media streams from a single Communications Session, or
from different Communication Sessions?

For:

"   o REQ-019 The mechanism MUST support the ability to transport the
   metadata in the same SIP dialog as the Recording Session."

We need to be careful about this - noting the pitfalls of dialog reuse
pointed out in RFC 5057.

For:

"   o REQ-021 Metadata format must be agnostic of the transport
   protocol."

Do we really mean transport layer (TCP or UDP) or do we mean SIP vs
non-SIP transport of metadata?

Perhaps REQ-025 and REQ-026 could be reworded and combined.

REQ #15 and #16 are reused.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 May 2010 09:22:33 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan Johnston
> Sent: 13 May 2010 20:20
> To: [email-masked]
> Subject: [siprec] Comments on draft-rehor-siprec-req-00
> 
[JRE] I think the requirements is clear that they are from a single CS. But it doesn't make sense to me why we would want to deliver them over separate RSs when they relate to the same CS.

> We need to be careful about this - noting the pitfalls of dialog reuse
[JRE] In addition, I am concerned that this requirement strays into solution space, by talking about SIP dialogs. I am not sure of the intention of the requirement, but can we try to reword it in more general terms. Clearly the metadata has to be associated in some way with the RS. Or more precisely, the metadata has to be associated with the CS, which in turn has to be associated with an RS.

> Perhaps REQ-025 and REQ-026 could be reworded and combined.
[JRE] In fact they relate closely to REQ-01->REQ-04. Perhaps all 5 requirements can be rationalised into a fewer number somehow. For example, a single requirement along the lines of "The mechanism MUST support flexibility in relationships between RSs and CSs, including 1 RS per CS, 1 RS for part of a CS, and 1 RS for multiple CSs in series or in parallel."

The "in parallel" case perhaps needs further consideration. I have heard there is a requirement for recording two simultaneous calls at an agent's turret using a single RS, and this might be feasible. But I am not sure we require the mechanism to be infinitely scalable. For example, if the mechanism involves 1 or more SDP m-lines per CS, then we soon reach very large SDPs if a B2BUA, say, tries to use a single RS to recorded 1000 simultaneous CSs.

John (as individual)

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 14 May 2010 15:37:04 +0200

See below.

Regards
Andy 

> [JRE] I think the requirements is clear that they are from a 
> single CS. But it doesn't make sense to me why we would want 
> to deliver them over separate RSs when they relate to the same CS.
> 
[AndyH] I agree maybe this was meant to cover the requirement for delivering the media in separate streams (i.e. not mixed) but to say this means separate sessions is wrong.