Skip to content
Snippets Groups Projects
Select Git revision
  • 14600-wenpeng
  • asterisk_rdkb
  • fix_fallback
  • 16302-emergency-call-update
  • 14666_fxs_no_wideband_codec
  • fix_srv_records
  • wenpeng-test-250121
  • wenpeng-registration-test
  • fix_deadlock_in_bridge_peer_functions
  • devel default protected
  • securesip_pjproject_part1
  • PJ_Example_Review
  • fix_re_register_authorization_header
  • fix_internal_calls_auth
  • fix_internal_calls
  • Secure_SIPtelephony_part1
  • SIPtelephony_DECT_syslog
  • syslog_develop_phase1
  • merge-asterisk-20.8.1
  • asterisk_rdkb_temp
  • 22.0.0-pre1
  • 21.4.2
  • 20.9.2
  • 18.24.2
  • certified-20.7-cert2
  • certified-18.9-cert11
  • 21.4.1
  • 20.9.1
  • 18.24.1
  • 21.4.0
  • 20.9.0
  • 18.24.0
  • certified-20.7-cert1
  • certified-18.9-cert10
  • 21.4.0-rc1
  • 20.9.0-rc1
  • 18.24.0-rc1
  • 21.3.1
  • 20.8.1
  • 18.23.1
40 results
Search by author
  • Any Author
  • Adam Porteous Adam Porteous adam.porteous
  • Alex Hopkins Alex Hopkins 59hopper
  • Amin Ben Romdhane Amin Ben Romdhane amin.benromdhane
  • Andreas Gnau Andreas Gnau AGnau
  • Andrej Kucharik Andrej Kucharik andrej.kucharik
  • Andrii Pypa Andrii Pypa andrii.pypa
  • Anjan Chanda Anjan Chanda anjancx
  • Balalakshmi Arunachalam Rajendran Balalakshmi Arunachalam Rajendran arbala
  • Benjamin Larsson Benjamin Larsson benjamin
  • Charles Foster Charles Foster charles.foster_bt.com
  • Dariusz Iwanoczko Dariusz Iwanoczko dariusz.iwanoczko
  • Divya Chandrasekaran Divya Chandrasekaran divya.c
  • Dominic Lake Dominic Lake dominic.lake
  • Elena Vengerova Elena Vengerova helen
  • Erik Karlsson Erik Karlsson erik.karlsson
  • Filip Matusiak Filip Matusiak filmat
  • Filip Strelec Filip Strelec filip.strelec
  • Fredrik Östling Fredrik Östling fredrik.ostling
  • Geoff Elliott Geoff Elliott gdelliott
  • George Yang George Yang gyang
20 authors
  1. Jan 24, 2011
    • Matthew Nicholson's avatar
      According to section 19.1.2 of RFC 3261: · e706b570
      Matthew Nicholson authored 
        For each component, the set of valid BNF expansions defines exactly
  which characters may appear unescaped.  All other characters MUST be
  escaped.

This patch modifies ast_uri_encode() to encode strings in line with this recommendation.  This patch also adds an ast_escape_quoted() function which escapes '"' and '\' characters in quoted strings in accordance with section 25.1 of RFC 3261.  The ast_uri_encode() function has also been modified to take an ast_flags struct describing the set of rules it should use when escaping characters to allow for it to escape SIP URIs in addition to HTTP URIs and other types of URIs or variations of those two URI types in the future.

The ast_uri_decode() function has also been modified to accept an ast_flags struct describing the set of rules to use when decoding to enable decoding '+' as ' ' in legacy http URLs.

The unit tests for these functions have also been updated.

ABE-2705

Review: https://reviewboard.asterisk.org/r/1081/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      e706b570
    • Jason Parker's avatar
      Merged revisions 303467 via svnmerge from · 54f6c31a
      Jason Parker authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r303467 | qwell | 2011-01-24 11:20:03 -0600 (Mon, 24 Jan 2011) | 22 lines
  
  Merged revisions 303285 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r303285 | qwell | 2011-01-21 15:48:09 -0600 (Fri, 21 Jan 2011) | 15 lines
    
    Merged revisions 303284 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r303284 | qwell | 2011-01-21 15:45:34 -0600 (Fri, 21 Jan 2011) | 8 lines
      
      Reset configuration before parsing users.conf.
      
      Some values configured in chan_dahdi.conf were able to leak in to users.conf
      configuration.  This was surprising users, and potentially setting non-sane
      "defaults".
      
      ASTNOW-125
    ........
  ................
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303468 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      54f6c31a
  3. Jan 22, 2011
  5. Jan 21, 2011
    • Jason Parker's avatar
      Temporarily revert r303288 · 95f5dc66
      Jason Parker authored 
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      95f5dc66
    • Jason Parker's avatar
      Merged revisions 303286 via svnmerge from · 4272837e
      Jason Parker authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r303286 | qwell | 2011-01-21 15:50:11 -0600 (Fri, 21 Jan 2011) | 22 lines
  
  Merged revisions 303285 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r303285 | qwell | 2011-01-21 15:48:09 -0600 (Fri, 21 Jan 2011) | 15 lines
    
    Merged revisions 303284 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r303284 | qwell | 2011-01-21 15:45:34 -0600 (Fri, 21 Jan 2011) | 8 lines
      
      Reset configuration before parsing users.conf.
      
      Some values configured in chan_dahdi.conf were able to leak in to users.conf
      configuration.  This was surprising users, and potentially setting non-sane
      "defaults".
      
      ASTNOW-125
    ........
  ................
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      4272837e
    • Tilghman Lesher's avatar
      Really use llvm-gcc, when available. · bad92a47
      Tilghman Lesher authored 
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303235 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      bad92a47
    • Tilghman Lesher's avatar
      Add DB_KEYS. · 52dbebad
      Tilghman Lesher authored 
      Discussion on #asterisk on 2011-01-19:
(02:07:03 PM) boch: i wonder how to cycle all entries in a tree
(02:07:11 PM) leifmadsen: use While()
(02:07:17 PM) leifmadsen: you need to know the tree structure already though
(02:07:36 PM) boch: what you mean?
(02:09:02 PM) leifmadsen: you need to know the structure prior to looping, because you can't just return the structure from the dialplan
(02:09:43 PM) leifmadsen: the only way I can think of doing that is via something like writing the output of:  asterisk -rx "database show" to a file, then looping through that to know the structure of the database and check everything
(02:09:59 PM) leifmadsen: but at that point you're better off just using either a relational database or an external script
(02:10:13 PM) boch: for example i need to know all entries in the tree
(02:10:15 PM) boch: got it
(02:10:20 PM) leifmadsen: exactly
(02:10:22 PM) leifmadsen: that's the problem
(02:10:22 PM) boch: thank you
(02:13:09 PM) mateu: yeah, i'm surprised there isn't something from the dialplan like 'database show family' so one can get all keys in a family to loop over.
(02:15:35 PM) leifmadsen: database shows everything
(02:16:22 PM) mateu: i mean something from the dial plan that mimics 'database show <family>'
(02:16:41 PM) leifmadsen: guess no one has found that important enough to program :)
(02:16:52 PM) leifmadsen: at that point you should probably just use a relational database...
(02:17:10 PM) mateu: i dunno
(02:17:16 PM) mateu: seems pretty basic to me.
(02:17:16 PM) leifmadsen: me either
(02:17:19 PM) leifmadsen: sure does
(02:17:24 PM) leifmadsen: no one has programmed it though
(02:17:28 PM) ***leifmadsen shrugs
(02:17:43 PM) mateu: ok, well at least we know how it currently stands.  thanks leifmadsen
(02:28:52 PM) Corydon76-home: leifmadsen: something like HASHKEYS() ?
(02:30:11 PM) leifmadsen: Corydon76-home: ummm, I was thinking more like DUNDI_QUERY() and DUNDI_RESULT()
(02:30:31 PM) leifmadsen: although HASHKEYS() might work
(02:30:58 PM) leifmadsen: actually ya, looking at it, similar to HASHKEYS()
(02:31:01 PM) leifmadsen: DBKEYS() I guess?
(02:31:45 PM) Corydon76-home: So with no argument, retrieves families, with an argument, retrieves keys of that family?
(02:34:02 PM) leifmadsen: ya
(02:34:16 PM) leifmadsen: how would you iterate through layers of them?
(02:34:30 PM) leifmadsen: i.e. family/key/key/key ?
(02:34:43 PM) Corydon76-home: Essentially, yes


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      52dbebad
  7. Jan 20, 2011
  9. Jan 19, 2011
  11. Jan 18, 2011
    • Richard Mudgett's avatar
      Merged revisions 302318 via svnmerge from · 8cd1ac53
      Richard Mudgett authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r302318 | rmudgett | 2011-01-18 16:04:14 -0600 (Tue, 18 Jan 2011) | 1 line
  
  Use the expanded format type instead of plain int.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8cd1ac53
    • Matthew Nicholson's avatar
      Merged revisions 302314 via svnmerge from · 785e3a14
      Matthew Nicholson authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r302314 | mnicholson | 2011-01-18 15:43:21 -0600 (Tue, 18 Jan 2011) | 18 lines
  
  Merged revisions 302313 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r302313 | mnicholson | 2011-01-18 15:40:03 -0600 (Tue, 18 Jan 2011) | 11 lines
    
    Merged revisions 302311 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r302311 | mnicholson | 2011-01-18 15:35:03 -0600 (Tue, 18 Jan 2011) | 4 lines
      
      URI encode the user part of the contact header.
      
      ABE-2705
    ........
  ................
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302315 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      785e3a14
    • Jeff Peeler's avatar
      Merged revisions 302266 via svnmerge from · b1f9f1e7
      Jeff Peeler authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r302266 | jpeeler | 2011-01-18 14:19:57 -0600 (Tue, 18 Jan 2011) | 34 lines
  
  Merged revisions 302265 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ........
    r302265 | jpeeler | 2011-01-18 14:13:52 -0600 (Tue, 18 Jan 2011) | 27 lines
    
    Convert device state callbacks to ao2 objects to fix a deadlock in chan_sip.
    
    Lock scenario presented here:
    Thread 1
     holds ast_rdlock_contexts &conlock
     holds handle_statechange hints
     holds handle_statechange hint
      waiting for cb_extensionstate
       Locked Here: chan_sip.c line 7428 (find_call)
    Thread 2
     holds handle_request_do &netlock
     holds find_call sip_pvt_ptr
      waiting for ast_rdlock_contexts &conlock
       Locked Here: pbx.c line 9911 (ast_rdlock_contexts)
    
    Chan_sip has an established locking order of locking the sip_pvt and then
    getting the context lock. So the as stated by the summary, the operations in
    thread 2 have been modified to no longer require the context lock.
    
    (closes issue #18310)
    Reported by: one47
    Patches: 
          statecbs_ao2.mk2.patch uploaded by one47 (license 23),
          modified by me
    
    Review: https://reviewboard.asterisk.org/r/1072/
  ........
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b1f9f1e7
    • Russell Bryant's avatar
      Merged revisions 302267 via svnmerge from · 519b766c
      Russell Bryant authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r302267 | russell | 2011-01-18 14:19:57 -0600 (Tue, 18 Jan 2011) | 5 lines
  
  Don't enable AO2_DEBUG by default if AST_DEVMODE is on.
  
  AO2_DEBUG is not important and is causing a false compiler warning to be
  generated on my Ubuntu Natty dev box.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      519b766c
    • Richard Mudgett's avatar
      Merged revisions 302174 via svnmerge from · a05aeff3
      Richard Mudgett authored 
      https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
  
  Merged revisions 302173 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
    
    Merged revisions 302172 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
      
      Issues with DTMF triggered attended transfers.
      
      Issue #17999
      1) A calls B. B answers.
      2) B using DTMF dial *2 (code in features.conf for attended transfer).
      3) A hears MOH. B dial number C
      4) C ringing. A hears MOH.
      5) B hangup. A still hears MOH. C ringing.
      6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
      For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
      
      Problem: When A and B hangup, C is still ringing.
      
      Issue #18395
      SIP call limit of B is 1
      1. A call B, B answered
      2. B *2(atxfer) call C
      3. B hangup, C ringing
      4. Timeout waiting for C to answer
      5. Recall to B fails because B has reached its call limit.
      
      Because B reached its call limit, it cannot do anything until the transfer
      it started completes.
      
      Issue #17273
      Same scenario as issue 18395 but party B is an FXS port.  Party B cannot
      do anything until the transfer it started completes.  If B goes back off
      hook before C answers, B hears ringback instead of the expected dialtone.
      
      **********
      Note for the issue #17273 and #18395 fix:
      
      DTMF attended transfer works within the channel bridge.  Unfortunately,
      when either party A or B in the channel bridge hangs up, that channel is
      not completely hung up until the transfer completes.  This is a real
      problem depending upon the channel technology involved.
      
      For chan_dahdi, the channel is crippled until the hangup is complete.
      Either the channel is not useable (analog) or the protocol disconnect
      messages are held up (PRI/BRI/SS7) and the media is not released.
      
      For chan_sip, a call limit of one is going to block that endpoint from any
      further calls until the hangup is complete.
      
      For party A this is a minor problem.  The party A channel will only be in
      this condition while party B is dialing and when party B and C are
      conferring.  The conversation between party B and C is expected to be a
      short one.  Party B is either asking a question of party C or announcing
      party A.  Also party A does not have much incentive to hangup at this
      point.
      
      For party B this can be a major problem during a blonde transfer.  (A
      blonde transfer is our term for an attended transfer that is converted
      into a blind transfer.  :)) Party B could be the operator.  When party B
      hangs up, he assumes that he is out of the original call entirely.  The
      party B channel will be in this condition while party C is ringing, while
      attempting to recall party B, and while waiting between call attempts.
      
      WARNING:
      The ATXFER_NULL_TECH conditional is a hack to fix the problem.  It will
      replace the party B channel technology with a NULL channel driver to
      complete hanging up the party B channel technology.  The consequences of
      this code is that the 'h' extension will not be able to access any channel
      technology specific information like SIP statistics for the call.
      
      ATXFER_NULL_TECH is not defined by default.
      **********
      
      (closes issue #17999)
      Reported by: iskatel
      Tested by: rmudgett
      JIRA SWP-2246
      
      (closes issue #17096)
      Reported by: gelo
      Tested by: rmudgett
      JIRA SWP-1192
      
      (closes issue #18395)
      Reported by: shihchuan
      Tested by: rmudgett
      
      (closes issue #17273)
      Reported by: grecco
      Tested by: rmudgett
      
      Review: https://reviewboard.asterisk.org/r/1047/
    ........
  ................
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a05aeff3
  13. Jan 17, 2011
  15. Jan 14, 2011