Asterisk
  1. Asterisk
  2. ASTERISK-4723

[patch] [post 1.2] make the 'RECORD' button on the snom phones work

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: None
    • Labels:
      None
    • Mantis ID:
      4845
    • Regression:
      No

      Description

      this patch enables the recording of a current call, by hitting the 'RECORD' button on some snom phones (e.g. snom360).

        Activity

        Hide
        Frank Sautter added a comment -

        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?
        Show
        Frank Sautter added a comment - 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?
        Hide
        dbruce added a comment -

        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.

        Show
        dbruce added a comment - 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.
        Hide
        Olle Johansson added a comment -

        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.

        Show
        Olle Johansson added a comment - 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.
        Hide
        cmayfield added a comment -

        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.

        Show
        cmayfield added a comment - 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.
        Hide
        Frank Sautter added a comment -

        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.

        Show
        Frank Sautter added a comment - 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.
        Hide
        Michael Jerris added a comment -

        re-open when this is ready, thanks.

        Show
        Michael Jerris added a comment - re-open when this is ready, thanks.

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development