Skip to content
Snippets Groups Projects
  1. May 13, 2016
  2. May 12, 2016
    • Mark Michelson's avatar
      Use doubles instead of floats for conversions when comparing strings. · fd3f7059
      Mark Michelson authored
      In 13.9.0, there was an issue where PJSIP contacts added to an AOR would
      be deleted at seemingly random times.
      
      One reason this was happening was because of an operation to retrieve
      the contacts whose expiration time was less than or equal to the current
      time. When retrieving existing contacts, the contact's expiration time
      and the current time were converted from a string to a float, and those
      two floats were compared.
      
      On some systems, including mine, this conversion was horribly off. For
      instance, I could regularly see the string "1463079214" get converted
      into 1463079168.000000. When switching from using a float to using a
      double, the conversion was as expected.
      
      Why was the conversion to float off? My best guess is that the
      conversion to float was attempting to store the entire value in the 23
      bit significand of the IEEE-754 floating point number. In particular, if
      you take only the 23 most significant bits of 1463079214, you get the
      messed up 1463079168 that we were seeing in the conversion. It likely
      was possible to get a more precise value by composing the number using
      an exponent, but the conversion did not work that way. With a double,
      you have a 52 bit significand, allowing the entire value to fit there,
      and thereby allowing an accurate conversion.
      
      ASTERISK-26007 #close
      Reported by Greg Siemon
      
      Change-Id: I83ca7944aae8b7cd994b254c78ec02411d321070
      fd3f7059
    • zuul's avatar
    • George Joseph's avatar
      pjsip_distributor: Add missing newline to NOTICE · 4f8cfa02
      George Joseph authored
      There was a newline missing from the end of the "no matching endpoint" notice.
      
      Change-Id: Idc11fe5bc0354072291663dbffe648c471e39181
      4f8cfa02
    • Sebastian Damm's avatar
      res_pjsip_outbound_registration: generate correct Contact URI for TLS · d14d1ba8
      Sebastian Damm authored
      There are two types of SIP URIs indicating a secure transport:
      * sips:user@example.org
      * sip:user@example.org;transport=tls
      
      When using a sips URI, Asterisk checks incoming INVITEs and answers from
      the other side for sips URIs, and rejects the packet if there are only
      sip URIs. So Asterisk should only generate a sips Contact URI if the
      other side supports it.
      
      This patch makes Asterisk generate either a sip or sips Contact URI
      depending on the format of the server URI.
      
      If you want a sip URI, use:
      server_uri=sip:example.org\;transport=tls
      
      If you want a sips URI, use:
      server_uri=sips:example.org
      
      ASTERISK-25990 #close
      Reported-by: Sebastian Damm
      
      Change-Id: I5ae57d6531ce940b5fc64d5cd2673e60db0f9ba2
      d14d1ba8
  3. May 11, 2016
  4. May 10, 2016
  5. May 09, 2016
  6. May 06, 2016
  7. May 05, 2016
    • Kevin Harwell's avatar
      res_pjsip_outbound_publish: state potential dropped on reloads/realtime fetches · 64e058f7
      Kevin Harwell authored
      When reloading, or fetching realtime data, if the "apply" failed for any
      numerous reasons the current state object would not be maintained. This
      potentially resulted in publishes being stopped for some states/clients when
      they should not have been.
      
      This patch makes it so the current state object is kept upon any type of reload/
      fetch failures.
      
      Change-Id: Iab6020c116d628ed2ae81183e987e2eaa3c90b30
      64e058f7
    • Kevin Harwell's avatar
      res_pjsip_outbound_publishing: After unloading the library won't load again · adc82a22
      Kevin Harwell authored
      The same thing was happening in res_pjsip_publish_asterisk. When the library
      was unloaded it did not unregister the object type from sorcery. Subsequent
      loads resulted in a failed load due to the sorcery type already existing.
      
      Change-Id: Ifdc25e94e4cd40bc5a19eb4d0a00b86c2e9fedc9
      adc82a22
Loading