1. 19 4月, 2014 7 次提交
  2. 17 4月, 2014 1 次提交
  3. 16 4月, 2014 3 次提交
    • Anthony Minessale's avatar
      update · 370230e3
      Anthony Minessale 提交于
      370230e3
    • Anthony Minessale's avatar
      FS-6462 --resolve · 41fa2c9c
      Anthony Minessale 提交于
      I found a problem here but it may not completely match your expectations.
      I reviewed the RFC 4028 and checked against the code and I discovered we should not be putting a Min-SE in any response at all besides a 422:
      
      section 5:
      
         The Min-SE header field MUST NOT be used in responses except for
         those with a 422 response code.  It indicates the minimum value of
         the session interval that the server is willing to accept.
      
      I corrected this problem and implemented the 422 response so if you request a value lower than the minimum specified for the profile.
      If the value is equal or higher to the minimum, it will be reflected in the Session-Expires header in the response and no Min-SE will be present.
      41fa2c9c
    • Anthony Minessale's avatar
      FS-5997 regression from commit 70accd9f this… · 264fd6ff
      Anthony Minessale 提交于
      FS-5997 regression from commit 70accd9f this caused some attended transfers to calls with multiple targets to get the abondoned channels to be stuck on write lock
      264fd6ff
  4. 15 4月, 2014 2 次提交
  5. 14 4月, 2014 3 次提交
  6. 10 4月, 2014 2 次提交
  7. 09 4月, 2014 3 次提交
    • Travis Cross's avatar
      Suppress spurious warning in phrase macro playback · 0a388d01
      Travis Cross 提交于
      Prior to this commit, if anything at all went wrong in
      switch_ivr_phrase_macro_event() we would generate a warning like this:
      
        [WARNING] switch_ivr_play_say.c:348 Macro [macro_name]: 'pattern_name' did not match any patterns
      
      This is clearly misleading.  The natural thing to do on seeing that
      message is to verify that the language files are there, and that the
      pattern really does exist in that macro.  But none of that was usually
      the problem.  The message would be generated if the language wasn't
      found, or if the channel had gone away, for example.
      
      With this commit, we verify that we actually tried looking for the
      pattern before displaying the warning about the pattern not matching.
      0a388d01
    • Travis Cross's avatar
      Avoid playback on dead channels in voicemail · 622a5d7e
      Travis Cross 提交于
      For years we've been generating spurious messages like:
      
        [WARNING] switch_ivr_play_say.c:348 Macro [voicemail_ack]: 'saved' did not match any patterns
      
      This would happen when the caller hangs up during the playback of
      certain prompts in the voicemail system where we weren't checking the
      return value of vm_macro_get().  Looking closely at the log, it's
      clear we were calling down into switch_ivr_phrase_macro() long after
      the channel was gone.
      
      The message above is also misleading -- switch_ivr_phrase_macro()
      would have been able to find that pattern just fine, but it never
      actually looked because the channel was gone.  We'll clean up that
      message in a follow on commit.
      622a5d7e
    • Travis Cross's avatar
      Avoid crash on event without content-type · 39bbcaff
      Travis Cross 提交于
      If we received an event without a content-type header we were
      dereferencing a null pointer leading to a seg fault.
      Reported-by: 's avatarIco <ico@voip-io.org>
      
      ESL-90 --resolve
      39bbcaff
  8. 07 4月, 2014 4 次提交
  9. 06 4月, 2014 1 次提交
  10. 05 4月, 2014 3 次提交
  11. 04 4月, 2014 2 次提交
  12. 03 4月, 2014 2 次提交
    • Anthony Minessale's avatar
      FS-6403 --resolve · 98365643
      Anthony Minessale 提交于
      This commit also reverts 2 previous attempts to fix this very rare race issue spanning back to 2009
      
      62ce8538 Patch from MOC
      3a85348c FS-2302 mutex added around switch_xml_toxml()
      
      The real problem was switch_xml_toxml_buf() was actually temporarily modifying the xml structure being searialized to make it appaer to be a root structure then serializing it and restoring the pointers.  This caused a non-threadsafe operation when some other thread was scanning the same xml structure.
      
      This patch removes the modification and instead passes a new arg to switch_xml_toxml_r indicating to treat the structure as if it were a root structure.
      
      This bug has been present since the induction of xml into FS.
      
      Conflicts:
      	src/switch_xml.c
      98365643
    • Brian West's avatar
      FS-6422: --resolve obvious copy and paste error · 1936bdd4
      Brian West 提交于
      1936bdd4
  13. 02 4月, 2014 1 次提交
  14. 31 3月, 2014 3 次提交
  15. 26 3月, 2014 2 次提交
  16. 19 3月, 2014 1 次提交