Skip to content
Snippets Groups Projects
  1. May 03, 2011
  2. May 02, 2011
  3. Apr 20, 2011
  4. Apr 19, 2011
  5. Mar 14, 2011
  6. Mar 12, 2011
  7. Mar 10, 2011
  8. Mar 04, 2011
    • Richard Mudgett's avatar
      Merged revisions 309445 via svnmerge from · 928ec2b9
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r309445 | rmudgett | 2011-03-04 09:22:04 -0600 (Fri, 04 Mar 2011) | 46 lines
        
        Get real channel of a DAHDI call.
        
        Starting with Asterisk v1.8, the DAHDI channel name format was changed for
        ISDN calls to: DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
        
        There were several reasons that the channel name had to change.
        
        1) Call completion requires a device state for ISDN phones.  The generic
        device state uses the channel name.
        
        2) Calls do not necessarily have B channels.  Calls placed on hold by an
        ISDN phone do not have B channels.
        
        3) The B channel a call initially requests may not be the B channel the
        call ultimately uses.  Changes to the internal implementation of the
        Asterisk master channel list caused deadlock problems for chan_dahdi if it
        needed to change the channel name.  Chan_dahdi no longer changes the
        channel name.
        
        4) DTMF attended transfers now work with ISDN phones because the channel
        name is "dialable" like the chan_sip channel names.
        
        For various reasons, some people need to know which B channel a DAHDI call
        is using.
        
        * Added CHANNEL(dahdi_span), CHANNEL(dahdi_channel), and
        CHANNEL(dahdi_type) so the dialplan can determine the B channel currently
        in use by the channel.  Use CHANNEL(no_media_path) to determine if the
        channel even has a B channel.
        
        * Added AMI event DAHDIChannel to associate a DAHDI channel with an
        Asterisk channel so AMI applications can passively determine the B channel
        currently in use.  Calls with "no-media" as the DAHDIChannel do not have
        an associated B channel.  No-media calls are either on hold or
        call-waiting.
        
        (closes issue #17683)
        Reported by: mrwho
        Tested by: rmudgett
        
        (closes issue #18603)
        Reported by: arjankroon
        Patches:
              issue17683_18603_v1.8_v2.patch uploaded by rmudgett (license 664)
        Tested by: stever28, rmudgett
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      928ec2b9
  9. Mar 01, 2011
  10. Feb 28, 2011
  11. Feb 22, 2011
    • David Vossel's avatar
      Media Project Phase2: SILK 8khz-24khz, SLINEAR 8khz-192khz, SPEEX 32khz, hd... · d760e81f
      David Vossel authored
      Media Project Phase2: SILK 8khz-24khz, SLINEAR 8khz-192khz, SPEEX 32khz, hd audio ConfBridge, and other stuff
      
      -Functional changes
      1. Dynamic global format list build by codecs defined in codecs.conf
      2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
      3. Negotiation of SILK attributes in chan_sip.
      4. SPEEX 32khz with translation
      5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
         using codec_resample.c
      6. Various changes to RTP code required to properly handle the dynamic format list
         and formats with attributes.
      7. ConfBridge now dynamically jumps to the best possible sample rate.  This allows
         for conferences to take advantage of HD audio (Which sounds awesome)
      8. Audiohooks are no longer limited to 8khz audio, and most effects have been
         updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
      9. codec_resample now uses its own code rather than depending on libresample.
      
      -Organizational changes
      Global format list is moved from frame.c to format.c
      Various format specific functions moved from frame.c to format.c
      
      Review: https://reviewboard.asterisk.org/r/1104/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d760e81f
  12. Feb 15, 2011
  13. Feb 07, 2011
  14. Feb 03, 2011
  15. Feb 02, 2011
  16. Jan 30, 2011
  17. 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
  18. Jan 21, 2011
    • 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
  19. Jan 14, 2011
  20. Jan 07, 2011
  21. Jan 06, 2011
  22. Dec 16, 2010
  23. Nov 15, 2010
  24. Oct 28, 2010
  25. Sep 30, 2010
  26. Sep 24, 2010
  27. Sep 20, 2010
    • David Vossel's avatar
      Merged revisions 287647 via svnmerge from · 2f3dee23
      David Vossel authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r287647 | dvossel | 2010-09-20 17:09:16 -0500 (Mon, 20 Sep 2010) | 21 lines
        
        Addition of the FrameHook API (AKA AwesomeHooks)
        
        So far all our tools for viewing and manipulating media streams
        within Asterisk have been entirely focused on audio.  That made
        sense then, but is not scalable now.  The FrameHook API lets us
        tap into and manipulate _ANY_ type of media or signaling passed
        on a channel present today or in the future.  This tool is a step
        in the direction of expanding Asterisk's boundaries and will help
        generate some rather interesting applications in the future.
        
        In addition to the FrameHook API, a simple dialplan function
        exercising the api has been included as well.  This function
        is called FRAME_TRACE().  FRAME_TRACE() allows for the internal
        ast_frames read and written to a channel to be output.  Filters
        can be placed on this function to debug only certain types of frames.
        This function could be thought of as an internal way of doing
        ast_frame packet captures.
        
        Review: https://reviewboard.asterisk.org/r/925/
      ........
      
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2f3dee23
  28. Sep 10, 2010
  29. Sep 08, 2010
  30. Sep 07, 2010
  31. Sep 02, 2010
  32. Aug 24, 2010
  33. Aug 03, 2010
  34. Jul 21, 2010
  35. Jul 20, 2010
  36. Jul 14, 2010
    • Richard Mudgett's avatar
      Expand the caller ANI field to an ast_party_id · cf7bbcc4
      Richard Mudgett authored
      Expand the ani field in ast_party_caller and ast_party_connected_line to
      an ast_party_id.
      
      This is an extension to the ast_callerid restructuring patch in review:
      https://reviewboard.asterisk.org/r/702/
      
      Review: https://reviewboard.asterisk.org/r/744/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276393 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      cf7bbcc4
    • Richard Mudgett's avatar
      ast_callerid restructuring · ec37ffbd
      Richard Mudgett authored
      The purpose of this patch is to eliminate struct ast_callerid since it has
      turned into a miscellaneous collection of various party information.
      
      Eliminate struct ast_callerid and replace it with the following struct
      organization:
      
      struct ast_party_name {
      	char *str;
      	int char_set;
      	int presentation;
      	unsigned char valid;
      };
      struct ast_party_number {
      	char *str;
      	int plan;
      	int presentation;
      	unsigned char valid;
      };
      struct ast_party_subaddress {
      	char *str;
      	int type;
      	unsigned char odd_even_indicator;
      	unsigned char valid;
      };
      struct ast_party_id {
      	struct ast_party_name name;
      	struct ast_party_number number;
      	struct ast_party_subaddress subaddress;
      	char *tag;
      };
      struct ast_party_dialed {
      	struct {
      		char *str;
      		int plan;
      	} number;
      	struct ast_party_subaddress subaddress;
      	int transit_network_select;
      };
      struct ast_party_caller {
      	struct ast_party_id id;
      	char *ani;
      	int ani2;
      };
      
      The new organization adds some new information as well.
      
      * The party name and number now have their own presentation value that can
      be manipulated independently.  ISDN supplies the presentation value for
      the name and number at different times with the possibility that they
      could be different.
      
      * The party name and number now have a valid flag.  Before this change the
      name or number string could be empty if the presentation were restricted.
      Most channel drivers assume that the name or number is then simply not
      available instead of indicating that the name or number was restricted.
      
      * The party name now has a character set value.  SIP and Q.SIG have the
      ability to indicate what character set a name string is using so it could
      be presented properly.
      
      * The dialed party now has a numbering plan value that could be useful to
      have available.
      
      The various channel drivers will need to be updated to support the new
      core features as needed.  They have simply been converted to supply
      current functionality at this time.
      
      
      The following items of note were either corrected or enhanced:
      
      * The CONNECTEDLINE() and REDIRECTING() dialplan functions were
      consolidated into func_callerid.c to share party id handling code.
      
      * CALLERPRES() is now deprecated because the name and number have their
      own presentation values.
      
      * Fixed app_alarmreceiver.c write_metadata().  The workstring[] could
      contain garbage.  It also can only contain the caller id number so using
      ast_callerid_parse() on it is silly.  There was also a typo in the
      CALLERNAME if test.
      
      * Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
      number string.  ast_callerid_parse() alters the given buffer which in this
      case is the channel's caller id number string.  Then using
      ast_shrink_phone_number() could alter it even more.
      
      * Fixed caller ID name and number memory leak in chan_usbradio.c.
      
      * Fixed uninitialized char arrays cid_num[] and cid_name[] in
      sig_analog.c.
      
      * Protected access to a caller channel with lock in chan_sip.c.
      
      * Clarified intent of code in app_meetme.c sla_ring_station() and
      dial_trunk().  Also made save all caller ID data instead of just the name
      and number strings.
      
      * Simplified cdr.c set_one_cid().  It hand coded the ast_callerid_merge()
      function.
      
      * Corrected some weirdness with app_privacy.c's use of caller
      presentation.
      
      Review:	https://reviewboard.asterisk.org/r/702/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      ec37ffbd
Loading