Subject: Re: [dispatch] dispatch Digest, Vol 11, Issue 33

From: zhipeng zhou <[email-masked]>
Date: Sat, 20 Feb 2010 16:46:05 +0800

Hi Gabor and all,
I like to share my viewpoint for this excellent comment email.
Gabor has listed many valuable features related to the Recording device and
service.
 IMO, absolutely the major feature for recording is focused on the Media
interaction. For example the security can be an independent solution.
So from my point of view, it can focus on the media architecture and
related content flow.

 What is your opinion.
Thanks.
Zhipeng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Saturday, February 20, 2010 4:00 AM
To: [email-masked]
Subject: dispatch Digest, Vol 11, Issue 33

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/dispatch

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or
Plain Text Digests?" to MIME.  You can set this option globally for all the
list digests you receive at this point.

Send dispatch mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/dispatch
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of dispatch digest..."

Today's Topics:

   1. Comments on Session Recording Protocol (Gabor Moczar)

----------------------------------------------------------------------

Message: 1
Date: Fri, 19 Feb 2010 18:56:47 +0100
From: Gabor Moczar <[email-masked]>
Subject: [dispatch] Comments on Session Recording Protocol
To: [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/dispatch/attachments/20100219/aedc39f0
/attachment.htm>

------------------------------

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

End of dispatch Digest, Vol 11, Issue 33
****************************************