Skip to content
Snippets Groups Projects
Select Git revision
  • asterisk_rdkb
  • 14600-wenpeng
  • 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
  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