My opinion is to bring it up on the dev list or on irc, then after you solicit enough information to move towards an enhancement in JIRA. It might be helpful to look over the previous requests in the JIRA to see if any movement had been taken and see if any information is useful. My only point is that if enough information can be obtained by discussion first, an easier roadmap to follow can be used by the dev team.
Additionally, in many regions, it is improper or illegal to record a conversation without altering the parties, so there should be an announcement of some kind that says, "This call may be recorded for quality assurance purposes". So I think #1 & #2 need this announcement, and perhaps the announcement can be mixed in. In the case of #3 it is probably not necessary since #3 means the user has to invoke it, so at least one party has agreed already. Actually the INFO stuff can be invoked by the phone via EFK and programmable key, but yes, sipx does need to understand to interpret it and what to do with it. There should be a secondary discussion about the filetypes (format: ogg, mp3, wav), how they are accessed, archived and whether they get auto deleted after a certain time period and are included in backups. 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. > > ------------------------------ > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Tony Graziano > *Sent:* Friday, October 15, 2010 10:15 PM > *To:* Discussion list for users of sipXecs software > *Subject:* Re: [sipx-users] trial call recording in sipx > > Nikolay - I had a discussion on this in irc last week. The discussion > surrounded around using a sip info alert (via function key on phone) to be > sent from the phone to the server>>> > > Press "record" button on the call, the server sends an alert to the phone, > essentially a transfer. This transfer will make then allow the call to be > recorded on the server. > > A good description off this would be to look at the few phones that support > it now (Snom) and using EFK can also be deployed on Polycom. > > This is not the same as "record every call", it is invoked by the local > user. > > http://wiki.snom.com/FAQ/What_does_the_'Record'_button_on_the_phone_do > > <http://wiki.snom.com/FAQ/What_does_the_'Record'_button_on_the_phone_do>I > don't know if this helps or not, it just seemed like a clean way to do it, > because it would act as a silent transfer and the recording would be stored > on the server. > > On Fri, Oct 15, 2010 at 1:53 PM, Michael Picher <[email protected]> wrote: > >> Sounds like a very useful addition Nikolay! >> >> Would this be set to record all calls for a particular user? Is there an >> indication to the user that the call is being recorded (other than if you >> were to capture SIP packets and really see what is going on)? >> >> Thanks, >> Mike >> >> On Thu, Oct 14, 2010 at 7:52 AM, Nikolay Kondratyev <[email protected]>wrote: >> >>> Hi all, >>> acording to my investigations in the tracker, call recording feature is >>> delayed for indefinite time. >>> Call recording function is highly anticipated. >>> Meanwhile FS gives a toolkit to record voice. >>> >>> So i tried to do something myself. >>> >>> My main idea is to route a call, that is to be recorded, through a >>> separate FS profile/dialplan. >>> The idea is based on >>> http://wiki.sipfoundry.org/display/xecsuserV4r2/Custom+FreeSWITCH+programming >>> >>> The main problem is: what is the creteria and how to route to that >>> special FS profile and then route the call back to the subscriber? >>> >>> At the moment i found a partial solution (or a draft for a partial >>> solution), i.e. how to record all _incoming_ calls for a specific >>> subscriber. >>> >>> Here is a test configuration, that works (that is all calls to specific >>> user are recorded in a wav file) for me: >>> >>> My sip domain is sip.nstel.ru, sipx hosthame is beaver.sip.nstel.ru >>> Ok, i created separate sofia profile, listening on port 15085. >>> For the 3800 user (i used this extension for testing, ) i set call >>> forwarding with the following destination: [email protected]. >>> sipxconfig does not allow to specify port in call forward destination, so >>> i had to create dns srv records for _sip._udp.record.sip.nstel.ru, >>> pointing to the same host, but port 15085, where recording FS profile is >>> listening. >>> I route the call back to >>> [email protected];sipx-noroute=VoiceMail;sipx-userforward=false. Thus >>> avoiding routing loop. >>> Here is the FS dialplan for it: >>> >>> <extension name="record_call"> >>> <condition field="destination_number" expression="^(3\d{3})$"> >>> <action application="set" data="RECORD_TITLE=Recording >>> ${destination_number} ${caller_id_number} ${strftime(%Y-%m-%d %H:%M)}"/> >>> <action application="set" data="RECORD_COPYRIGHT=(c) 1980 Factory >>> Records, Inc."/> >>> <action application="set" data="RECORD_SOFTWARE=FreeSwitch"/> >>> <action application="set" data="RECORD_ARTIST=Ian Curtis"/> >>> <action application="set" data="RECORD_COMMENT=Love will tear us >>> apart"/> >>> <action application="set" data="RECORD_DATE=${strftime(%Y-%m-%d >>> %H:%M)}"/> >>> <action application="set" data="RECORD_STEREO=true"/> >>> <action application="record_session" >>> data="/var/sipxdata/mediaserver/data/recorder/${strftime(%Y-%m-%d-%H-%M-%S)}_${destination_number}_${caller_id_number}.wav"/> >>> <action application="set" data="ringback=${us-ring}"/> >>> <action application="answer"/> >>> <action application="sleep" data="300"/> >>> <action application="bridge" data=" >>> sofia/recorder/[email protected];sipx-noroute=VoiceMail;sipx-userforward=false"/<sofia/recorder/[email protected];sipx-noroute=VoiceMail;sipx-userforward=false%22/> >>> > >>> </condition> >>> </extension> >>> Please find attached xml trace of a recorded call. >>> >>> So... a kind of recording works and looks to be acceptable for at list >>> further testing. >>> >>> I see two shortcomings in my method: >>> >>> 1. When the call is forwarded, it is not diverted, it is forked. That is >>> sipxproxy sends invite to both 3800's phone and "recorder". >>> Then when "FS recorder" answers a call, sipxproxy cancels "frame 31 >>> invite" branch (see attached xml). This canceled branch is excessive. >>> So the question: Is there a way to get rid of invite in frame 31? In >>> other words, is it possible to divert a call instead of forking it? >>> >>> 2. Looking at frame 57, i see that spesial creadentials (~~id~media) are >>> used by "FS recorder" to pass through "407 proxy authentication required. >>> This user is configured in >>> /etc/sipxpbx/freeswitch/conf/sip_profiles/sipX_profile.xml file. It is >>> configured for a different profile, listening on another port. >>> I don't understand why this user is used by "recorder" profile. >>> I think that after some careful FS configuration this can be overcomed, >>> though i don't think, this is the first problem in the queue. >>> >>> Next step: storing voice recordings in plain wav files will not be very >>> convinient. It'll be difficult to find required file after a couple of >>> months.... >>> So next step could be: create separate postgres database, and store >>> recording there... i guess this should be possible via mod_perl. >>> And then create a php driven web page for accessing those records. >>> >>> Some questions to the community to summarize my efforts: >>> 1. How do you find the idea? Do you think it can suite for a production >>> system? >>> 2. Can you foresee any problems? >>> 3. Is it possible to divert a call instead of forking? >>> 4. I did not managed to solve "route outgoing call from a specific user >>> through a recorder" task. The problem is that, user should dial the same >>> number, as usually. Any ideas? >>> >>> Thanks and regards, >>> NIkolay. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> >> >> -- >> There are 10 kinds of people in this world, those who understand binary >> and those who don't. >> >> [email protected] >> blog: http://www.sipxecs.info >> call: sip:[email protected] <sip%[email protected]> >> >> _______________________________________________ >> 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/ > -- ====================== 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/
