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

mod_httapi doesn't reset one_time_params on re-entry

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.6.10
    • Fix Version/s: 1.8
    • Component/s: mod_httapi
    • Security Level: public
    • Labels:
      None
    • Environment:
      Debian Jessie 8.5 (Docker) on Ubuntu 16.04
      Kernel 4.4.0-21-generic
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • 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:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      e2928b8
    • GIT Master Revision hash::
      9698187cb8f

      Description

      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}" />
      </condition>

      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 {url=} 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.

        Activity

        Hide
        colin.morelli@gmail.com Colin Morelli added a comment -
        Sorry about the delay in response, Mike. I'll test the branch out this afternoon/evening and get back to you. Based on the change you added though, it seems like it'll be what I had expected.
        Show
        colin.morelli@gmail.com Colin Morelli added a comment - Sorry about the delay in response, Mike. I'll test the branch out this afternoon/evening and get back to you. Based on the change you added though, it seems like it'll be what I had expected.
        Hide
        mikej Mike Jerris added a comment -
        make sure to test a wide variety of call flows and make sure this doesn't break any expected behavior.
        Show
        mikej Mike Jerris added a comment - make sure to test a wide variety of call flows and make sure this doesn't break any expected behavior.
        Hide
        mikej Mike Jerris added a comment -
        any update?
        Show
        mikej Mike Jerris added a comment - any update?
        Hide
        colin.morelli@gmail.com Colin Morelli added a comment -
        Running tests now, sorry about the delay again. I have been having other issues with NAT64, IPv6, and STUN that might be resulting in another potential bug :(.

        It's building now and I'll provide updates shortly.
        Show
        colin.morelli@gmail.com Colin Morelli added a comment - Running tests now, sorry about the delay again. I have been having other issues with NAT64, IPv6, and STUN that might be resulting in another potential bug :(. It's building now and I'll provide updates shortly.
        Hide
        colin.morelli@gmail.com Colin Morelli added a comment - - edited
        Seems to be doing what I'd expect now. I don't have anything that assumes sessions will be preserved across two invocations of httapi, so I don't have much to test on that end. If the change feels safe to you, it works for me.

        If not, I can work around this and have for the time being, so if you think this might cause backwards compat issues I'd understand wanting to take a different approach.
        Show
        colin.morelli@gmail.com Colin Morelli added a comment - - edited Seems to be doing what I'd expect now. I don't have anything that assumes sessions will be preserved across two invocations of httapi, so I don't have much to test on that end. If the change feels safe to you, it works for me. If not, I can work around this and have for the time being, so if you think this might cause backwards compat issues I'd understand wanting to take a different approach.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development