On Tue, May 27, 2008 at 8:14 PM, Scott Lawrence <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-05-27 at 16:37 -0400, Andy Spitzer wrote: >> Woof! >> >> On Tue, 27 May 2008 16:11:12 -0400, M. Ranganathan <[EMAIL PROTECTED]> wrote: >> >> > Please add your thoughts to the above so we can discuss the issues >> > involved. >> >> The best idea I've come across with regards to an on-demand recording >> service, was to have a service that can accept a three-way call from a >> phone. When a user wants to record a call, she "conferences" in the >> recording service, as if it were a third party to the call. The phone >> acts as the conference locus, and so does the mixing, and sends the >> mixed audio of the other parties to the recording service, which does >> nothing but record 'em. The details are in what happens to that >> recording when done, which are not insignificant. > > That is indeed an elegant solution for on-demand (simpler than the > transfer-to-self-via-recorder that I proposed), but it wouldn't work for > situations in which all calls to some address(es) need to be recorded > from the beginning. >
Woof brings up another point -- the media retrieved for the recorded call must do media mixing. It can be stored as two streams but must be mixed when played back. What complications lurk for compressed codecs? Ranga > -- > 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
