FreeSWITCH

mod_spandsp event variable additions

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: mod_spandsp
  • Labels:
    None
  • Platform:
    Linux x86/gcc
  • FreeSWITCH GIT Revision:
    f35a68141e59aa525b6633bf64e13199c14757fd
  • Reproduced with GIT HEAD?:
    yes

Description

The spandsp::rxfaxresult and spandsp::txfaxresult events on mod_spandsp fired off in mod_spandsp_fax.c did not send all variables that are also set on the channel when the app finishes executing.

This patch adds those (fax-ecm-requested, fax-v17-disabled, fax-ecm-used and fax-filename) plus Unique-ID, Caller-ANI and Caller-RDNIS to aid in processing when using these events for event_socket connections. I also changed a log printing line that is the ONLY line not being prefixed with the channel UUID, so I changed that to make them uniform.

Thanks Math, bkw_ and

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Elisamuel Resto added a comment -
Patch file adding mentioned changes
Show
Elisamuel Resto added a comment - Patch file adding mentioned changes
Hide
Permalink
Anthony Minessale II added a comment -
you might want to consider a single call to

switch_channel_event_set_data(channel, event);


right after event is created.
This will add every variable and other useful info to the events.


Show
Anthony Minessale II added a comment - you might want to consider a single call to switch_channel_event_set_data(channel, event); right after event is created. This will add every variable and other useful info to the events.
Hide
Permalink
Elisamuel Resto added a comment -
Will check that out, yes. This is my first stab at C, so I'm in a trial & error basis here. I found out that the events are firing off the data for rxfaxresult but txfaxresult events have incomplete data... I will have to look into this too, now that I got the faxing modules working like I wanted to.
Show
Elisamuel Resto added a comment - Will check that out, yes. This is my first stab at C, so I'm in a trial & error basis here. I found out that the events are firing off the data for rxfaxresult but txfaxresult events have incomplete data... I will have to look into this too, now that I got the faxing modules working like I wanted to.
Hide
Permalink
Elisamuel Resto added a comment -
Revised, following anthm's suggestion and used switch_channel_event_set_data() -- and the UUID prefix to the channel to the first line like the rest of them
Show
Elisamuel Resto added a comment - Revised, following anthm's suggestion and used switch_channel_event_set_data() -- and the UUID prefix to the channel to the first line like the rest of them
Hide
Permalink
Jeff Lenk added a comment -
Tony I might be wrong here but even if the redundant switch_event_add_header_string calls get removed after the switch_channel_event_set_data was added the names of the event data is being changed here.
ex.
"fax-success" is changed to "variable_fax-success"

Is that a problem?
Show
Jeff Lenk added a comment - Tony I might be wrong here but even if the redundant switch_event_add_header_string calls get removed after the switch_channel_event_set_data was added the names of the event data is being changed here. ex. "fax-success" is changed to "variable_fax-success" Is that a problem?
Hide
Permalink
Anthony Minessale II added a comment -
Some of the params that are not already channel variables may want to either be added as channel variables or added to the event.
Yes they will be prefixed with variable_
Show
Anthony Minessale II added a comment - Some of the params that are not already channel variables may want to either be added as channel variables or added to the event. Yes they will be prefixed with variable_
Hide
Permalink
Jeff Lenk added a comment -
are you concerned with any backward compatibility here? not sure how many users are dependant on the already existing names??
Show
Jeff Lenk added a comment - are you concerned with any backward compatibility here? not sure how many users are dependant on the already existing names??
Hide
Permalink
Anthony Minessale II added a comment -
The patch does not seem to remove anything does it ?
It just adds more info to the event.
Show
Anthony Minessale II added a comment - The patch does not seem to remove anything does it ? It just adds more info to the event.
Hide
Permalink
Jeff Lenk added a comment -
no it does not. I was just concerned about the duplication of data with both names being added ex. fax-success and variable_fax-success. Thats mostly a potential size(event header) issue but if you think thats ok then so do I:)
Show
Jeff Lenk added a comment - no it does not. I was just concerned about the duplication of data with both names being added ex. fax-success and variable_fax-success. Thats mostly a potential size(event header) issue but if you think thats ok then so do I:)
Hide
Permalink
Anthony Minessale II added a comment -
I guess we are stuck with it for legacy purposes if we want to accept this patch.
it's negligible any *shrug*
 
Show
Anthony Minessale II added a comment - I guess we are stuck with it for legacy purposes if we want to accept this patch. it's negligible any *shrug*  
Hide
Permalink
Git added a comment -
Repository: freeswitch
Branch: refs/heads/master
Commit: 0555b70 http://fisheye.freeswitch.org/changelog/freeswitch.git/?cs=0555b70
Closed By: jeff@jefflenk.com

Comment:
FS-3345 --resolve add more fax event information
Show
Git added a comment - Repository: freeswitch Branch: refs/heads/master Commit: 0555b70 http://fisheye.freeswitch.org/changelog/freeswitch.git/?cs=0555b70 Closed By: jeff@jefflenk.com Comment: FS-3345 --resolve add more fax event information
Hide
Permalink
Auto Admin added a comment -
Due to a long period of inactivity (13 or more days), this issue is due to be automatically close within 24 hours.
If this issue is not actually resolved, please reopen it and add appropriate comments to help developers fix the issue.

Thanks,
  Jira Admin
Show
Auto Admin added a comment - Due to a long period of inactivity (13 or more days), this issue is due to be automatically close within 24 hours. If this issue is not actually resolved, please reopen it and add appropriate comments to help developers fix the issue. Thanks,   Jira Admin
Hide
Permalink
Auto Admin added a comment -
Since there has been no change to the status of this issue, it is being closed for inactivity

Thanks,
  Jira Admin
Show
Auto Admin added a comment - Since there has been no change to the status of this issue, it is being closed for inactivity Thanks,   Jira Admin

People

  • Assignee:
    Anthony Minessale II
    Reporter:
    Elisamuel Resto
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: