Skip to content
Snippets Groups Projects
  1. Feb 15, 2016
    • George Joseph's avatar
      res_pjsip_caller_id: Fix segfault when replacing rpid or pai header · be811c4b
      George Joseph authored
      If the PJSIP_HEADER dialplan function adds a PAI or RPID header and send_rpid
      or send_pai is set, res_pjsip_caller_id attemps to retrieve, parse and modify
      the header added by the dialplan function.  Since the header added by the
      dialplan function is generic string, there are no virtual functions to parse
      the uri and we get a segfault when we try.  Since the modify, was really only
      an overwrite, we now just delete the old header if it was type PJSIP_H_OTHER
      and recreate it.
      
      This raises a question for another time though:  What should happen with
      duplicate headers?  Right now res_pjsip_header_funcs doesn't check for dups
      so if it's session supplement is loaded after res_pjsip_caller_id's (or any
      other module that adds headers), there'll be dups in the message.
      
      ASTERISK-25337 #close
      
      Change-Id: I5e296b52d30f106b822c0eb27c4c2b0e0f71c7fa
      be811c4b
    • zuul's avatar
      23b2b774
    • Mark Michelson's avatar
      Fix creation race of contact_status structures. · 13b6c029
      Mark Michelson authored
      It is possible when processing a SIP REGISTER request to have two
      threads end up creating contact_status structures in sorcery.
      contact_status is created using a "find or create" function. If two
      threads call into this at the same time, each thread will fail to find
      an existing contact_status, and so both will end up creating a new
      contact status.
      
      During testing, we would see sporadic failures because the
      PJSIP_CONTACT() dialplan function would operate on a different
      contact_status than what had been updated by res_pjsip/pjsip_options.
      
      The fix here is two-fold:
      1) The "find or create" function for contact_status now has a lock
      around the entire operation. This way, if two threads attempt the
      operation simultaneously, the first to get there will create the object,
      and the second will find the object created by the first thread.
      
      2) res_sorcery_memory has had its create callback updated so that it
      will not allow for objects with duplicate IDs to be created.
      
      Change-Id: I55b1460ff1eb0af0a3697b82d7c2bac9f6af5b97
      13b6c029
    • Joshua Colp's avatar
      res_pjsip_pubsub: Move where the subscription is stored to after initialized. · 5c400a0f
      Joshua Colp authored
      A problem arose when testing the AMI subscription listing actions where it
      was possible for a subscription that had not been fully initialized to be
      listed. This was problematic as the underlying listing code would crash.
      
      This change makes it so the subscription tree is fully set up before it is
      added to the list of subscriptions. This ensures that when the listing actions
      get the subscription it is valid.
      
      ASTERISK-25738 #close
      
      Change-Id: Iace2b13641c31bbcc0d43a39f99aba1f340c0f48
      5c400a0f
  2. Feb 12, 2016
  3. Feb 11, 2016
  4. Feb 10, 2016
  5. Feb 09, 2016
    • Corey Farrell's avatar
      Simplify and fix conditional in FD_SET. · 68643f83
      Corey Farrell authored
      FD_SET contains a conditional statement to protect against buffer
      overruns.  The statement was overly complicated and prevented use
      of the last array element of ast_fdset.  We now just verify the fd
      is less than ast_FDMAX.
      
      Change-Id: I41895c0b497b052aef5bf49d75c817c48b326f40
      68643f83
    • Joshua Colp's avatar
    • Joshua Colp's avatar
      tests/test_sorcery_memory_cache_thrash: Improve termination process. · e40fddbe
      Joshua Colp authored
      When terminating the threads thrashing a sorcery memory cache each
      would be told to stop and then we would wait on them. During at
      least one thrashing test this was problematic due to the specific
      usage pattern in use. It would take some time for termination of the
      thread to occur.
      
      This would occur due to contention between the threads retrieving
      and the threads updating the cache. As the retrieving threads are
      given priority it may be some time before the updating threads
      are able to proceed.
      
      This change makes it so all threads are told to stop and then each
      are joined to ensure they stop. This way all the threads should
      stop at around the same time instead of waiting for one to stop,
      the next to stop, then the next, and so on. As a result of this
      the execution time for each thrash test is much closer to their
      expected value than previously seen as well.
      
      Change-Id: I04a53470b0ea4170b8819180b0bd7475f3642827
      e40fddbe
    • George Joseph's avatar
      res_pjsip: Fix infinite recursion when loading transports from realtime · bbf3ace6
      George Joseph authored
      Attempting to load a transport from realtime was forcing asterisk into an
      infinite recursion loop.  The first thing transport_apply did was to do a
      sorcery retrieve by id for an existing transport of the same name. For files,
      this just returns the previous object from res_sorcery_config's internal
      container, if any.  For realtime, the res_sourcery_realtime driver looks in the
      database and finds the existing row but now it has to rehydrate it into a
      sorcery object which means calling... transport_apply.  And so it goes.
      
      The main issue with loading from realtime (apart from the loop) was that
      transport stores structures and pointers directly in the ast_sip_transport
      structure instead of the separate ast_transport_state structure.  This patch
      separates those items into the ast_sip_transport_state structure.  The pattern
      is roughly the same as res_pjsip_outbound_registration.
      
      Although all current usages of ast_sip_transport and ast_sip_transport_state
      were modified to use the new ast_sip_get_transport_state API, the original
      items are left in ast_sip_transport and kept updated to maintain ABI
      compatability for third-party modules.  They are marked as deprecated and
      noted that they're now in ast_sip_transport_state.
      
      ASTERISK-25606 #close
      Reported-by: Martin Moučka
      
      Change-Id: Ic7a836ea8e786e8def51fe3f8cce855ea54f5f19
      bbf3ace6
  6. Feb 08, 2016
  7. Feb 07, 2016
  8. Feb 05, 2016
  9. Feb 04, 2016
  10. Feb 03, 2016
Loading