|Summary:||ASTERISK-04723: [patch] [post 1.2] make the 'RECORD' button on the snom phones work|
|Reporter:||Frank Sautter (xylome)||Labels:|
|Date Opened:||2005-07-28 17:21:29||Date Closed:||2011-06-07 14:02:38|
|Environment:||Attachments:||( 0) snomrec.r797.txt|
|Description:||this patch enables the recording of a current call, by hitting the 'RECORD' button on some snom phones (e.g. snom360).|
|Comments:||By: Frank Sautter (xylome) 2005-07-28 17:26:16|
this patch needs some further developement, based on your feedback.
* currently the calls are recorded to the filesystem with the path hardcoded to "/var/spool/asterisk/monitor/EXTENNAME/DATE.wav" (which should be able to configure)
* i don't know what to answer to the snom phone, so that it knows, it's in recording state. (it's not 200 OK or 202 Accepted)
* currently each keypress on the record button starts and stops recording
* what to do with the file when recording has finished? email?
By: dbruce (dbruce) 2005-07-28 18:42:31
The SIP INFO rfc, rfc 2976, specifies the a response to an INFO request should be 200 or 202... That being said, the Snom may be expecting something more... although the Snom employee on Asterisk-users indicates that any affirmative response will do...
The ast_monitor_start function is contained in res_monitor... If res_monitor.so is not loaded, pressing the record button will cause a segfault. the pbx_findapp function should be used to determine the availability of the ast_start_monitor function.
As for the patch... A few comments... (please don't interpret my comment(s) as criticism... they are meant for discussion only!)
The automon function coded into res_features requires explicit configuration in order to function, as does monitoring in app_queue. This patch does not require configuration and bypasses the requirement for monitoring to be explicitly enabled as per res_features. Is this a valid consideration? Is the ability to record with a phone button but not with a feature code a concern? Should there be a need to explicitly enable one touch recording on a global or per-peer basis?
The implimentations in app_queue and res_features require a bridged call in order to perform monitoring... This patch will monitor the the single channel... is this desired behaviour?
If the ast_monitor_start or ast_monitor_stop function calls fail, there will be not response to the INFO request.
Also, the function prototypes for ast_monitor_start and ast_monitor_stop are contained in the header file for res_monitor, so an #include "asterisk/monitor.h" is needed.
By: Olle Johansson (oej) 2005-07-29 01:29:16
There has to be a configuration setting in [general] to allow this. Don't hardcode directory paths, use paths from asterisk.conf. We should not accept this from unauthenticated callers.
If the info is sent from a peer with voicemail enabled, maybe we could store this in a folder in his voicemail. Otherwise a directory per user/peer, but then we're suddenly building a new voice storage separate from voicemail...
This requires some more thought, even though it is a cool feature.
By: cmayfield (cmayfield) 2005-08-01 11:06:03
I agree with not wanting to recreate the wheel...
It would be great to have the recording in their directory available from the voicemail system.
Also having the snom recordings appear as a new voicemail is another idea.
By: Frank Sautter (xylome) 2005-08-01 11:23:51
i will rework this, so it uses much of the voicemail functionality... but it will take some days until i find enough time to realize this.
By: Michael Jerris (mikej) 2005-08-07 23:56:14
re-open when this is ready, thanks.