On Tue, May 27, 2008 at 4:35 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > 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 realize we are not at the point of discussing implementation strategies as yet so excuse me if this is mis-timed: As a matter of implementation one can implement what you suggest above in the same process as sipxbridge. In that way, sipxbridge becomes a generic b2bua service - a specialization of which is bridging to ITSPs. It also provides media bridging services ( now ) and can provide call recording services. Note what I am suggesting is an implementation strategy that can simplify the implementation and not #2. We already have an impressive number of processes fire up on startup. I would prefer to have a single B2BUA service provider process in the system rather than two. Through careful design we can factor the commonalities and save on implementation/ maintainability. > > 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/ > > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
