Uploaded image for project: 'FreeSWITCH'
  1. FreeSWITCH
  2. FS-9592

mod_httapi doesn't reset one_time_params on re-entry



    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.6.10
    • Fix Version/s: 1.8
    • Component/s: mod_httapi
    • Labels:
    • Environment:
      Debian Jessie 8.5 (Docker) on Ubuntu 16.04
      Kernel 4.4.0-21-generic
    • CPU Architecture:
    • Kernel:
    • uname:
      Linux ubuntu 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
    • Userland:
    • Distribution:
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
    • FreeSWITCH GIT Revision:
    • GIT Master Revision hash::


      I was hesitant on calling this a bug vs a feature improvement, because to be honest I'm not sure what the intended functionality is today.

      I'm using the following dialplan:

      <condition field="destination_number" expression=".*">
      <action application="httapi" data="{session_id=${create_uuid foo},url=$${http_endpoint},method=POST,full_channel_data_on_every_req=true}" />

      Essentially, I want every single call to just hit httapi. Each time the dialplan puts a call into httapi, it should create a new UUID as a "session_id" for that instance of httapi. This way, multiple calls within the same invocation of httapi can be correlated, but if the dialplan puts the call back into a separate httapi invocation, it essentially starts over with a fresh session id (more below).

      My intended behavior is:

      • Call enters dialplan
      • mod_httapi takes over, my application continues generating instructions until the call is ended

      This works fine, but when a call is transferred, I essentially want to start over again. That is to say, when a bridged call encounters a transfer, it starts a dialplan hunt, hits the catch-all entry, and starts a new instance of httpapi with a new session_id. All this is working correctly.

      The problem is that the state from the previous instance of httapi sticks around. This isn't really a problem for the "params" (I overwrite params where necessary). But it is a problem for one-time-params. Some of my httapi dialplan instructions generate a <continue temp-action="another_url" />. This one_time_param actually carries over to the next invocation of mod_httapi and overwrites the


      param specified in the dialplan.

      My general thought here is that two separate invocations of httapi should behavior entirely independently (that is to say, params shouldn't be shared between two invocations unless explicitly desired). However, given that would potentially be a dangerous breaking change, I would at least expect that one_time_params shouldn't cross the boundary between two separate invocations of httapi and/or there should be a way to clear them.




            • Assignee:
              mikej Mike Jerris
              colin.morelli@gmail.com Colin Morelli
            • Votes:
              0 Vote for this issue
              3 Start watching this issue


              • Created: