Subject: [dispatch] Comments on Session Recording Protocol

From: Gabor Moczar <[email-masked]>
Date: Fri, 19 Feb 2010 18:56:47 +0100

Dear Working Group Members,

I am new to this list and Leon Portman from Nice suggested to send my
comments on the Session Recording Protocol to here directly.
I have 8+ years experience with IP based call recording solutions as a
solution architect and product manager.
Let me know your opinion about my comments.

1. Meta data
SRP should provide a standard mechanism, which allows sending meta data in
addition to the media to the RS. An extendible set of fields could describe
the recorded call in a detailed way including calling party number, name,
agent id, etc.
Currently most implementations require implementing an additional interface
using standard or proprietary CTI to obtain such kind of information. These
implementations quite unique across the various platforms and considered to
add additional complexity, OAM overhead and failure point to the overall
solution.

2. Handling multiple media streams
SRP should allow RS to select, which media stream should be recorded or not
for a given session.
As unified communication emerge, more and more customers using voice, video,
instant messaging, etc. in their communication with their partners and
clients. Customers may would like to decide, which media or which direction
of the media should be recorded during the session. For compliance, probably
only the voice part of a video conversation is sufficient too.

3. Security and encryption
The draft very well describes the sensitivity of the topic from security
point of view, however the term "encryption" is missing from the
requirements part. I see that "eavesdropping protection" is used, but what
is the purpose of not using the most obvious solution for "eavesdropping
protection".
I would also add: SRP should also allow the recording of encrypted calls.

4. Redundancy
SRP should provide a mechanism to allow RCs to send the media to multiple
RSs at one time.
Probably endpoints with limited resources or networks with restricted
bandwidth will not able to provide this feature, but in mission critical
environments this could be a very nice way to provide redundancy. The
failover mechanism described in the draft (and used by some of the vendors)
is not protected from single point of failure.

5. Negotiating media handling capabilities
SRP should allow RC and RS to negotiate audio/video codec capabilities
(similar to SIP/SDP) and the RC should send media in the agreed codec.
In most cases the codec will be exactly the same as the one used in the
recorded session. However, high definition audio and video codecs are
getting used in more and more sessions, for recording, the requirement in
most cases allow to record the sessions in a lower resolution format. Either
the RC, either the RS should provide transcoding capabilities. I know
several video endpoints, which are able to send the video in 2 formats at
one time (HD and CIF) and I can also imagine devices with on-board
transcoding capabilities in the future (e.g. transcoding AAC-LD to G.729 for
the RS) and some of the current implementations also allow the transcoding
of the recording streams using network resources.

6. Others
There are some points, which are mentioned in the use cases section, but no
requirement is provided to support the given feature:
- Silent monitoring and real-time applications: the entire mechanism should
allow the users to implement a real-time monitoring functionality, which
means that the media has to be transmitted with considerably low delay, in a
real-time fashion to the RS.
- Handling complex calls: SRP should provide a mechanism to allow the RS to
link together certain call segments in a complex call scenario (e.g.
providing a global call identifier as a part of the meta data).

Best regards,
Gabor

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Feb 2010 12:55:41 +0100

Gabor,

Just addressing a few of your points below: 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gabor Moczar
> Sent: 19 February 2010 17:57
> To: [email-masked]
> Subject: [dispatch] Comments on Session Recording Protocol
> 
> I am new to this list and Leon Portman from Nice suggested to 
> send my comments on the Session Recording Protocol to here directly.
> I have 8+ years experience with IP based call recording 
> solutions as a solution architect and product manager.
> SRP should provide a standard mechanism, which allows sending 
> meta data in addition to the media to the RS. An extendible 
> set of fields could describe the recorded call in a detailed 
> way including calling party number, name, agent id, etc. 
> Currently most implementations require implementing an 
> additional interface using standard or proprietary CTI to 
> obtain such kind of information. These implementations quite 
> unique across the various platforms and considered to add 
> additional complexity, OAM overhead and failure point to the 
> overall solution. 
> 
> SRP should allow RS to select, which media stream should be 
> recorded or not for a given session. 
> As unified communication emerge, more and more customers 
> using voice, video, instant messaging, etc. in their 
> communication with their partners and clients. Customers may 
> would like to decide, which media or which direction of the 
> media should be recorded during the session. For compliance, 
> probably only the voice part of a video conversation is 
> sufficient too. 
> 
> The draft very well describes the sensitivity of the topic 
> from security point of view, however the term "encryption" is 
> missing from the requirements part. I see that "eavesdropping 
> protection" is used, but what is the purpose of not using the 
> most obvious solution for "eavesdropping protection". 
[JRE] Encryption does not necessarily give you protection against eavesdropping, e.g., if keys are too weak or are exchanged in inappropriate ways. I would say the requirement is for protection against eavesdropping.

> I would also add: SRP should also allow the recording of 
[JRE] Can you please clarify whether you mean:
- recording of media in the clear, said media having been transported to/from the communications partner in encrypted form; or
- recording of encrypted media, so that it can be played back only with knowledge of the keys used for the original session?

> 
> 4. Redundancy 
> SRP should provide a mechanism to allow RCs to send the media 
> to multiple RSs at one time. 
> Probably endpoints with limited resources or networks with 
> restricted bandwidth will not able to provide this feature, 
> but in mission critical environments this could be a very 
> nice way to provide redundancy. The failover mechanism 
> described in the draft (and used by some of the vendors) is 
> not protected from single point of failure. 
> 
> SRP should allow RC and RS to negotiate audio/video codec 
> capabilities (similar to SIP/SDP) and the RC should send 
> media in the agreed codec. 
> In most cases the codec will be exactly the same as the one 
> used in the recorded session. However, high definition audio 
> and video codecs are getting used in more and more sessions, 
> for recording, the requirement in most cases allow to record 
> the sessions in a lower resolution format. Either the RC, 
> either the RS should provide transcoding capabilities. I know 
> several video endpoints, which are able to send the video in 
> 2 formats at one time (HD and CIF) and I can also imagine 
> devices with on-board transcoding capabilities in the future 
> (e.g. transcoding AAC-LD to G.729 for the RS) and some of the 
> current implementations also allow the transcoding of the 
> recording streams using network resources. 
[JRE] Yes, but bear in mind that some devices might not have resources to decode and re-encode. So although we could have a requirement that allows the possibility of different codecs, I think there also has to be a requirement to support devices that are unable to transcode.

> 
> 6. Others 
> There are some points, which are mentioned in the use cases 
> section, but no requirement is provided to support the given feature: 
> - Silent monitoring and real-time applications: the entire 
> mechanism should allow the users to implement a real-time 
> monitoring functionality, which means that the media has to 
> be transmitted with considerably low delay, in a real-time 
> fashion to the RS. 
[JRE] I think we need to be clear whether this is within scope, and if so I would agree that some sort of requirement on timing would be appropriate.

> - Handling complex calls: SRP should provide a mechanism to 
> allow the RS to link together certain call segments in a 
> complex call scenario (e.g. providing a global call 
> identifier as a part of the meta data). 
[JRE] This is a topic that has arisen in other contexts, and if a solution is to be provided I would imagine it would fall outside the scope of the SRP work.

John

---

From: "Scott Lawrence" <[email-masked]>
Date: Mon, 22 Feb 2010 09:06:04 -0500

> The draft very well describes the sensitivity of the topic from
> security point of view, however the term "encryption" is missing from
> the requirements part. I see that "eavesdropping protection" is used,
> but what is the purpose of not using the most obvious solution for
> "eavesdropping protection".

Part of what you're encountering here is just the difference in
preferred language.  This is a requirements document, not a solution
document - it is laying out what goals a solution much achieve, and it
is generally preferred that such a document _not_ specify any more than
needed about how the goals are met.

Encryption technologies can be used in many different ways to achieve
different ends, so saying "encryption" in the context of this document
would not actually specify which of those ends the encryption technology
was to be employed for.  By writing the requirement as "confidentiality
protection" that is made explicit, and there really isn't any other way
to meet that requirement (in the Internet) than encryption, but writing
it this way is actually more precise.

>  I would also add: SRP should also allow the recording of encrypted

There are a bunch of potential landmines in this area in that the IETF
is very careful not to specify anything that allows an intermediate
party to penetrate end-to-end confidentiality (there's that word again)
without the knowledge and cooperation of the parties.  That's not to say
that at least some interpretations of your requirement can't be met, but
it does mean that the requirement must be carefully constructed to avoid
creating problems.

---

From: Gabor Moczar <[email-masked]>
Date: Tue, 23 Feb 2010 17:47:57 +0100

THX John
See my answers below.

On Mon, Feb 22, 2010 at 12:55 PM, Elwell, John <
[email-masked]> wrote:

> [JRE] Encryption does not necessarily give you protection against
> eavesdropping, e.g., if keys are too weak or are exchanged in inappropriate
> ways. I would say the requirement is for protection against eavesdropping.
>
Ok. I was thinking on similar mechanism like the one used in SIP with TLS
and SRTP.

> - recording of media in the clear, said media having been transported
> to/from the communications partner in encrypted form; or
> - recording of encrypted media, so that it can be played back only with
> knowledge of the keys used for the original session?
>
> The second one. After reading Scott's comment, probably it cannot be easily
incorporated into the standard, but the requirements is a real one. We had
several customers asking for this feature...

> [JRE] Yes, but bear in mind that some devices might not have resources to
> decode and re-encode. So although we could have a requirement that allows
> the possibility of different codecs, I think there also has to be a
> requirement to support devices that are unable to transcode.
>
> Agree.

> [JRE] I think we need to be clear whether this is within scope, and if so I
> would agree that some sort of requirement on timing would be appropriate.
>
> [JRE] This is a topic that has arisen in other contexts, and if a solution
> is to be provided I would imagine it would fall outside the scope of the SRP
> work.
>
I think, it is a very important feature, but I am aware of
the differences among the various platforms/vendors, so probably not all of
them can meet this requirement. If this feature is not included in the
standard, recorder vendors will be forced to implement or use existing
TAPI/JTAPI/DMCC/etc. interfaces, which should be avoided in my opinion...

---

From: Gabor Moczar <[email-masked]>
Date: Tue, 23 Feb 2010 17:54:02 +0100

THX Scott for the detailed clarification and I am now fully aware of
the appropriate terminology required at this stage.
I agree that the "recording of encrypted calls" topic is a very sensitive
one, but as I previously wrote to John, the requirement is from real
customers...

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 23 Feb 2010 18:09:39 +0100

Gabor,

More on a couple of topics:

> From: Gabor Moczar [mailto:[email-masked]] 
> Sent: 23 February 2010 16:48
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [dispatch] Comments on Session Recording Protocol
> 
> 	>
> 	[JRE] Encryption does not necessarily give you 
> protection against eavesdropping, e.g., if keys are too weak 
> or are exchanged in inappropriate ways. I would say the 
> requirement is for protection against eavesdropping.
> 	
> 
> Ok. I was thinking on similar mechanism like the one used in 
> SIP with TLS and SRTP.
[JRE] Sure, that might be a solution, but the requirement is prevention of eavesdropping.

> 	- recording of media in the clear, said media having 
> been transported to/from the communications partner in 
> encrypted form; or
> 	- recording of encrypted media, so that it can be 
> played back only with knowledge of the keys used for the 
> original session?
> 	
> 
> 
> The second one. After reading Scott's comment, probably it 
> cannot be easily incorporated into the standard, but the 
> requirements is a real one. We had several customers asking 
> for this feature...
[JRE] There are actually 3 points at which media can be encrypted:
- during transmission as part of the original communication session;
- during transmission as part of the media replication session from recording client to recording server;
- during storage on the recording server (and subsequent retrieval for playback purposes, although this is getting somewhat beyond the scope of the proposed charter).

I think you are asking that it be encrypted once and remain encrypted for all three stages.

If we are talking real-time media transported with SRTP, there is a problem, because SRTP is tightly coupled to the RTP transport for the session concerned. This makes it unsuitable for store and forward use, as discussed in draft-mattsson-srtp-store-and-forward. Similarly, it makes it unsuitable for use across two separate RTP sessions. It seems to me to be necessary to decrypt SRTP from the communication session at the recording client, and then re-encrypt for transmission  to the recording server, and then decrypt and re-encrypt again for storage, and so on. Possibly the 2nd and 3rd stages could be dealt with in one go using a technique such as in draft-naslund-srtp-saf, but it is unlikely that the first stage could be combined, since this would requiring cooperation of the remote party's UA.

John

---

From: Gabor Moczar <[email-masked]>
Date: Tue, 23 Feb 2010 18:27:08 +0100

On Tue, Feb 23, 2010 at 6:09 PM, Elwell, John <
[email-masked]> wrote:

> - during storage on the recording server (and subsequent retrieval for
> playback purposes, although this is getting somewhat beyond the scope of the
> proposed charter).
>
> If we are talking real-time media transported with SRTP, there is a
> problem, because SRTP is tightly coupled to the RTP transport for the
> session concerned. This makes it unsuitable for store and forward use, as
> discussed in draft-mattsson-srtp-store-and-forward. Similarly, it makes it
> unsuitable for use across two separate RTP sessions. It seems to me to be
> necessary to decrypt SRTP from the communication session at the recording
> client, and then re-encrypt for transmission  to the recording server, and
> then decrypt and re-encrypt again for storage, and so on. Possibly the 2nd
> and 3rd stages could be dealt with in one go using a technique such as in
> draft-naslund-srtp-saf, but it is unlikely that the first stage could be
> combined, since this would requiring cooperation of the remote party's UA.
>

You are right. The implementations, I am aware, do exactly the same thing
you described: re-encrypt for transmission to the RS with new keys.
Storing recordings in an encrypted format is a kind of must have feature on
the market, but I agree, it is out of scope of this work.