FreeSWITCH

add an event (or filter) for mod_localstream PLAYBACK_START and PLAYBACK_STOP

Details

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

Description

Currently in order to detect when localstream play starts/stops on a channel you must listen for PLAYBACK_START and PLAYBACK_STOP events which are triggered for any sound file playback. I only need to listen for localstream events and there is no way to filter the PLAYBACK_START and PLAYBACK_STOP for just localstream. As a result I must parse the 'Playback-File-Path' header of each PLAYBACK_START/PLAYBACK_STOP event for 'localstream'
This causes extra (and unnecessary) over head for the ESL script I've written.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Peter Olsson added a comment -
Even though it's a stream it's also still a playback, so I can't really understand why this would be a problem? Parsing a few bytes extra shouldn't make any noticable difference when it comes to performance?
Show
Peter Olsson added a comment - Even though it's a stream it's also still a playback, so I can't really understand why this would be a problem? Parsing a few bytes extra shouldn't make any noticable difference when it comes to performance?
Hide
Permalink
E. Schmid added a comment -
Would firing an EVENT or adding a filter for type of PLAYBACK be extremely difficult? The problem I can see is in a large scale system, PLAYBACK_START/STOP for everything voicemail, ivr, playback, etc could add up to a ton of events being fired at my script. Sending way more events then needed will undoubtedly cost CPU usage.
Show
E. Schmid added a comment - Would firing an EVENT or adding a filter for type of PLAYBACK be extremely difficult? The problem I can see is in a large scale system, PLAYBACK_START/STOP for everything voicemail, ivr, playback, etc could add up to a ton of events being fired at my script. Sending way more events then needed will undoubtedly cost CPU usage.
Hide
Permalink
Peter Olsson added a comment -
It's probably not very difficult, but I think it's not very useful for most people (and for most implementations it would compilicate stuff, instead of the oposite). That's why I think it's better to handle this kind of "fine grained" filtering in the client, not in the FS core. I've been using ESL quite allot, and I'm using it for IVR (100% controlled via ESL) on pretty loaded systems (at least during testing phases), and I've never had any performance issues in the client code.

Having that said. When I first started using ESL I was also thinking about these things, but after a while I noticed it wasn't really a problem to handle the events, even though there were lots of them.

/Peter
Show
Peter Olsson added a comment - It's probably not very difficult, but I think it's not very useful for most people (and for most implementations it would compilicate stuff, instead of the oposite). That's why I think it's better to handle this kind of "fine grained" filtering in the client, not in the FS core. I've been using ESL quite allot, and I'm using it for IVR (100% controlled via ESL) on pretty loaded systems (at least during testing phases), and I've never had any performance issues in the client code. Having that said. When I first started using ESL I was also thinking about these things, but after a while I noticed it wasn't really a problem to handle the events, even though there were lots of them. /Peter
Hide
Permalink
Peter Olsson added a comment -
Closing this issue, I think it's too specific to one user's need, and as mentioned in the comments, it should be handled in the client side instead.
Show
Peter Olsson added a comment - Closing this issue, I think it's too specific to one user's need, and as mentioned in the comments, it should be handled in the client side instead.
Hide
Permalink
E. Schmid added a comment -
Added event-header to address this issue. Please see git-diff
Show
E. Schmid added a comment - Added event-header to address this issue. Please see git-diff
Hide
Permalink
E. Schmid added a comment -
Adds event-header Playback-File-Type for local_stream and tone_stream
Show
E. Schmid added a comment - Adds event-header Playback-File-Type for local_stream and tone_stream
Hide
Permalink
Git added a comment -
Repository: freeswitch
Branch: refs/heads/master
Commit: d3fcfa8 http://fisheye.freeswitch.org/changelog/freeswitch.git/?cs=d3fcfa8
Closed By: anthm@freeswitch.org

Comment:
FS-4273 --resolve


FreeSWITCH Support Contracts and Consulting Services available!

Contact us:
Email: consulting@freeswitch.org
Web: http://www.freeswitch.org
Phone: +1-918-420-9266
Tollfree: +1-877-742-2583
Fax: +1-918-420-9267
iNum: +883 5100 1420 9266


Come To ClueCon in August to learn more about FreeSWITCH and Internet Telephony!
http://www.cluecon.com

Show
Git added a comment - Repository: freeswitch Branch: refs/heads/master Commit: d3fcfa8 http://fisheye.freeswitch.org/changelog/freeswitch.git/?cs=d3fcfa8 Closed By: anthm@freeswitch.org Comment: FS-4273 --resolve FreeSWITCH Support Contracts and Consulting Services available! Contact us: Email: consulting@freeswitch.org Web: http://www.freeswitch.org Phone: +1-918-420-9266 Tollfree: +1-877-742-2583 Fax: +1-918-420-9267 iNum: +883 5100 1420 9266 Come To ClueCon in August to learn more about FreeSWITCH and Internet Telephony! http://www.cluecon.com

People

  • Assignee:
    Anthony Minessale II
    Reporter:
    E. Schmid
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: