On Fri, 2010-02-26 at 13:59 -0500, M. Ranganathan wrote:
> On Fri, Feb 26, 2010 at 1:37 PM, Scott Lawrence <[email protected]>
> wrote:
> > On Fri, 2010-02-26 at 13:15 -0500, M. Ranganathan wrote:
> >> I have been experimenting a bit with freeSWITCH conference as a way of
> >> doing call recording.
> >
> >> Any comments? What is the right approach to follow?
> >
> > Before getting into the level of detail in your note, let's start with
> > what the user interaction for the service needs to be.
>
>
> I will answer based on what my current thinking on the matter is:
>
> >
> > How does a user (or an administrator?) determine which calls are to be
> > recorded?
>
> it would be determined on a per ITSP basis or bridge wide basis. You
> can set a check box for an itsp account indicating that all calls to
> or from the given ITSP will be recorded.
>
>
> >
> > Where do recordings go?
>
>
> Into files stored locally or we have a voice mailbox option that posts
> recordings to a specified mail address so as to be able to remove them
> from the file system.
>
> >
> > How is access to those recordings controlled?
>
> Depends upon how they are stored. If they are stored in files and
> accessed through HTTP, then standard HTTP access protection. If they
> are sent to mailbox, then user name and password.
>
>
>
> >
> > What are the storage requirements for recordings?
>
> I do not know. It depends upon how many recordings you make and what
> the sample rate of the speech is and what compression you apply.
>
>
> >
> > What happens if there is not sufficient storage for a recording (how is
> > the user informed)?
>
>
> Same mechanism as is used for any other critical resource situation.
>
> Send an alarm.
I think that from a product planing point of view those answers are not
really sufficient.
As Peters post illustrated, there are a number of different views of how
a call recording service should be used. A service that unconditionally
records all of every call into the system is probably not what anyone
expects (or wants). Do we really want to record every call to an
auto-attendant? to voicemail? to a conference bridge (which may be
doing its own recording - 4 callers from outside into a bridge results
in 5 recordings of the same call)?
I also think that putting this functionality in the bridge, just because
it's an existing B2BUA, is not the right approach.
I think that's what's needed is a call recording service (for which we
have the building blocks) that supports accepting signaling such that it
can be inserted into a call either:
* At call setup time by normal addressing. A dial plan or other
call target (users, hunt groups, aliases) could have a flag that
says "record calls". Internally, that generates addressing that
causes the insertion of a Route through the recorder.
* Through phone-based conferencing - if I want to begin recording,
I put the existing call on hold, call a recorder number (*xx),
and then use the conferencing in the phone (most of our phones
can act as a three-party conference mixer) to connect the legs.
* Through a transfer-based function at an endpoint - if i want to
start recording a call, I transfer that call to a fixed special
code (*xx); that triggers a routing decision that routes the
call to the recorder and then back to my phone.
For any conferencing feature, we need to create an authorization model
that allows the administrators and/or the users to control who has
access to recordings. We also need a proactive storage management
strategy that is better than "when you run out of disk things break".
On the technology front, I'd like to find out if we can extend the
functionality of sipXrelay for this: rather than making every recording
go through a full blown B2BUA, can we just get something that clones the
RTP streams and diverts a copy to a recording service?
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
