On Tue, 2008-05-27 at 16:11 -0400, M. Ranganathan wrote:
>
> There appear to be three ways to build a solution.
>
> 1. Build a general recording facility any service can use. Media
> recording can be achieved by putting the B2BUA in the path of the call
> but you would have to know apriori that a call needs to be recorded.
> Essentially you can incorporate a bridging service into the call setup
> path. This can reuse many of the features of sipxbridge such as the
> ability to anchor and relay media but not all features need to be
> implemented such as registration and call transfer. Essentially a
> phone would allocate a B2BUA and a symmitron bridge that would act as
> a straight media and signaling relay. It would be simpler than
> sipxbridge because the remote end understands call transfer (REFER,
> Replaces, Re-INVITE). It can simply relay the signaling and expect
> that far end understands what to do with it. Question : How do we tell
> this to start/stop recording? Is the control plane for this going to
> be sip? How do we store and retrieve the media? I think such a
> solution will take about 2-3 months to design, incorporate sipxconfig
> support for and build.
I like this approach because it centralizes the work and can be paired
with any endpoint (significant because our own services that handle
media are not all written in a way that allows them to share media
handling code).
If we had a general recorder that worked when added to the path, we
could:
* Provision certain endpoints to route through it with an
attribute that indicated whether or not recording could be
controlled by the endpoint. If endpoint control were allowed,
it could use RFC 2833 DTMF signals to turn on and off.
* Transfer a call through the recorder even if the phone had not
been configured to pass through it before.
Suppose my phone is 162 and I get a call from Martin, and he
wants me to do something new and stop the stuff he desperately
wanted next week (a purely hypothetical occurance :-) ). I want
a recording of him saying it's ok to not do the original job, so
I put him on hold and transfer the call to *99162. The *999
causes the call to be routed to the call recorder service, which
accepts it and then creates a new call to the 162 suffix. My
phone knows none of this - it just sees that it has transfered
one call away and then immediately gotten a new call (since the
recorder is a B2BUA, this new call has a new call-id).
I suspect that the recording service could be designed to store the
recordings in a file, and then put enough information in a database so
that the file could be found based on keys like caller, callee, and
time.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/
http://www.pingtel.com/
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
