Skip to content
Snippets Groups Projects
  1. Jan 30, 2011
  2. 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
  3. 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
  4. Jan 14, 2011
  5. Jan 07, 2011
  6. Jan 06, 2011
  7. Dec 16, 2010
  8. Nov 15, 2010
  9. Oct 28, 2010
  10. Sep 30, 2010
  11. Sep 24, 2010
  12. 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
  13. Sep 10, 2010
  14. Sep 08, 2010
  15. Sep 07, 2010
  16. Sep 02, 2010
  17. Aug 24, 2010
  18. Aug 03, 2010
  19. Jul 21, 2010
  20. Jul 20, 2010
  21. 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
  22. Jul 13, 2010
  23. Jul 09, 2010
  24. Jun 08, 2010
  25. Jun 03, 2010
  26. May 30, 2010
  27. May 28, 2010
  28. May 17, 2010
    • Mark Michelson's avatar
      Enhancements to connected line and redirecting work. · b5d5cc56
      Mark Michelson authored
      From reviewboard:
      
      Digium has a commercial customer who has made extensive use of the connected party and
      redirecting information present in later versions of Asterisk Business Edition and which
      is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
      have come about. This patch adds several enhancements to maximize usage of the connected party
      and redirecting information functionality.
      
      First, Asterisk trunk already had connected line interception macros. These macros allow you to
      manipulate connected line information before it was sent out to its target. This patch adds the
      same feature except for redirecting information instead.
      
      Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
      tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
      mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
      that it can be set to whatever value the administrator likes. Later, when running connected line
      and redirecting macros, the admin can read the tag off the appropriate structure to determine what
      action to take. You can think of this sort of like a channel variable, except that instead of having
      the variable associated with a channel, the variable is associated with a specific identity within
      Asterisk.
      
      Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
      caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
      a specific calling presentation value on the outgoing channel.
      
      Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
      to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
      being transferred would not have the opportunity to run a connected line interception macro to
      possibly alter the transfer target's connected line information. The issue here was that during a
      blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
      update. The way this was corrected was to add this new control frame subclass. Now, we queue an
      AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
      be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
      associated with the specific read action the control frame describes. In this case, the action taken
      is to run the connected line interception macro on the transferee's channel.
      
      Review: https://reviewboard.asterisk.org/r/652/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      b5d5cc56
  29. May 07, 2010
  30. Apr 21, 2010
  31. Apr 19, 2010
  32. Apr 13, 2010
  33. Apr 09, 2010
Loading