On Mon, Oct 18, 2010 at 1:36 PM, Flatfender <[email protected]> wrote:
> On Mon, Oct 18, 2010 at 6:19 AM, Nikolay Kondratyev <[email protected]> wrote: > > Tony, > > i would say that call recording task could be divided into 3 parts: > > 1. Recoding of all incoming calls to a particular user. > > 2. Recording of all outgoing calls from a particular user. > > 3. On demand recording. > > All three must be fullfilled. > > I was talking about the first one. It does work now, albeit with some > > shorcomings, i mentioned in my first message. > > You are talking about the third one. As far as i understand, it will > require > > some additional programming - all that INFO stuff must be coded into > sipx. > > > > Anyway, i posted my message to attract attention to the call recording > task. > > May be some (may be even substantial) coding is required to fullfill the > > task, but all necessary instruments are present. > > And i see many, Many, MANY people chose different product (mainly *) > because > > of the lack of call recording. > > Should i revive "recording" issue in the tracker? > > Or should i post this on the dev-list? > > > > Rgds, > > Nikolay. > > > > I would want the ability to capture calls to an ACD queue for use in a > call center environment, haven't looked at the new ACD stuff from > freeswitch yet, so maybe that is the same as recording to a user? > > Matt P. > I think an ACD recording system needs to be its own beast for recording... simply because it will likely have different code in how it accesses the media to capture it. Has anyone looked at what resources will be required to "anchor" the media and record it? If I record all my calls at the server to (or from) me, it means either I have to send an INVITE (via sip-info or other) in order to record the call and have it bridged or connected at the recording application/service. This also means a local intranet call that went peer-to-peer is either anchored at the server to be recorded by looping back to itself or the media is bridged into the recording service. In all instances it is a 3 leg call. This is why I suggested the sip-info header so that it could bridge the call via a "transfer" and leave the actual conversation as peer-to-peer. If the recording service was not working, the call would still work. > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.326.5325 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
