Skip to content
Snippets Groups Projects
  1. Feb 05, 2016
  2. Feb 04, 2016
  3. Feb 03, 2016
  4. Feb 02, 2016
    • Mark Michelson's avatar
    • Mark Michelson's avatar
      res_sorcery_realtime: Fix regex regression. · 65223618
      Mark Michelson authored
      A regression was introduced where searching for realtime PJSIP objects
      by regex by starting the regex with a leading "^" would cause no items
      to be returned.
      
      This was due to a change which attempted to drop the requirement for a
      leading "^" to be present due to how some CLI commands formulate their
      regexes. However, the change, rather than simply eliminating the
      requirement, caused any regexes that did begin with "^" to end up not
      returning the expected results.
      
      This change fixes the problem by inspecting the regex and formulating
      the realtime query differently depending on if it begins with "^".
      
      ASTERISK-25702 #close
      Reported by Nic Colledge
      
      Patches:
          realtime_retrieve_regex.patch submitted by Alexei Gradinari License #5691
      
      Change-Id: I055df608a6e6a10732044fa737a9fe8dca602693
      65223618
    • Karsten Wemheuer's avatar
      res_xmpp: Does not connect in component mode · 2a6f18cd
      Karsten Wemheuer authored
      The module res_xmpp does not accept usernames in the form used in component
      mode (XEP-0114). In component mode there is no @something in the name.
      In component mode the connection is now not dropped anymore.
      
      If the xmpp server sends out a "stream" tag before handshake is finished,
      the connection gets dropped in res_xmpp. Now this tag will be ignored and
      the connection will be established.
      
      After connecting there will be an exchange of presence states. This does
      not work as expected in component mode. The responsible function
      "xmpp_pak_presence" is left before the states get sent out. Sending
      presence states in component mode is now moved to the top of the function.
      
      ASTERISK-25735 #close
      
      Change-Id: I70e036f931c3124ebb2ad1e56f93ed35cfdd9d5c
      2a6f18cd
    • Joshua Colp's avatar
      c9a5f98e
    • George Joseph's avatar
      build_system: Fix some warnings highlighted by clang · 40da6434
      George Joseph authored
      Fix some warnings found with clang.
      
      Change-Id: I5195b6189b148c2ee3ed4a19d015a6d4ef3e77bd
      40da6434
  5. Feb 01, 2016
  6. Jan 31, 2016
    • StefanEng86's avatar
      chan_sip.c: AMI & CLI notify methods get different values of asterisk's own ip. · 55a7367a
      StefanEng86 authored
      When I ask asterisk to send a SIP NOTIFY message to a sip peer using either a)
      AMI action: SIPnotify or b) cli command: sip notify <cmd> <peer>, I expect
      asterisk to include the same value for its own ip in both cases a) and b),
      but it seems a) produces a contact header like Contact:
      <sip:asterisk@192.168.1.227:8060> whereas b) produces a contact header like
      <sip:asterisk@127.0.0.1:8060>. 0.0.0.0:8060 is my udpbindaddr in sip.conf
      
      My guess is that manager_sipnotify should call
      ast_sip_ouraddrfor(&p->sa, &p->ourip, p) the same way sip_cli_notify does,
      because after applying this patch, both cases a) and b) produce
      the contact header that I expect: <sip:asterisk@192.168.1.227:8060>
      
      Reported by: Stefan Engström
      Tested by: Stefan Engström
      
      Change-Id: I86af5e209db64aab82c25417de6c768fb645f476
      55a7367a
  7. Jan 29, 2016
  8. Jan 28, 2016
  9. Jan 27, 2016
Loading