Skip to content
Snippets Groups Projects
  1. Sep 06, 2012
  2. Jul 16, 2012
  3. Feb 28, 2012
  4. Nov 14, 2011
  5. Nov 01, 2011
  6. Sep 19, 2011
    • Richard Mudgett's avatar
      Merged revisions 336659 via svnmerge from · 5c71a502
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/10
      
      ................
        r336659 | rmudgett | 2011-09-19 13:51:19 -0500 (Mon, 19 Sep 2011) | 38 lines
        
        Merged revisions 336658 via svnmerge from 
        https://origsvn.digium.com/svn/asterisk/branches/1.8
        
        ........
          r336658 | rmudgett | 2011-09-19 13:46:40 -0500 (Mon, 19 Sep 2011) | 31 lines
          
          Made Dial d and H options no longer immediately auto-answer the calling leg.
          
          The Dial d and H options break DTMF attended transfer atxferdropcall
          option.
          
          1) Party A calls party B.
          2) Party B does a DTMF attended transfer to Party C.
          
          If the dialplan uses the Dial d or H options to call Party C then the Dial
          application answers the call immediately before initiating the call leg to
          Party C.  The premature answer causes the transfer code to not invoke the
          atxferdropcall=no behavior for a blonde transfer since Party C has
          "answered".  The transfer code thinks that Party B has "consulted" with
          Party C when Party B hangs up and completes the transfer to Party A.
          Party A now hears ringback until Party C actually answers.
          
          ASTERISK-13294 Dial d option.
          ASTERISK-11067 Dial H option to disconnect before answer.
          
          The referenced issues made Dial answer with the d and H options because
          many SIP and ISDN phones cannot send DTMF before the call is connected.
          
          * Made require the dialplan to control when or if the call needs to be
          answered to use the Dial application d and H options.  (The call is no
          longer surprise answered when using the Dial d or H options.)
          
          Review: https://reviewboard.asterisk.org/r/1381/
          
          JIRA AST-623
          JIRA AST-666
        ........
      ................
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@336662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      5c71a502
  7. Sep 16, 2011
  8. Jul 20, 2011
  9. May 25, 2011
    • Richard Mudgett's avatar
      Merged revisions 320823 via svnmerge from · 0096238b
      Richard Mudgett authored
      https://origsvn.digium.com/svn/asterisk/branches/1.8
      
      ........
        r320823 | rmudgett | 2011-05-25 12:06:38 -0500 (Wed, 25 May 2011) | 18 lines
        
        The AMI Newstate event contains different information between v1.4 and v1.8.
        
        The addition of connected line support in v1.8 changes the behavior of the
        channel caller ID somewhat.  The channel caller ID value no longer time
        shares with the connected line ID on outgoing call legs.  The timing of
        some AMI events/responses output the connected line ID as caller ID.
        These party ID's are now separate.
        
        * The ConnectedLineNum and ConnectedLineName headers were added to many
        AMI events/responses if the CallerIDNum/CallerIDName headers were also
        present.
        
        (closes issue #18252)
        Reported by: gje
        Tested by: rmudgett
        
        Review: https://reviewboard.asterisk.org/r/1227/
      ........
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@320825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      0096238b
  10. 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
  11. Nov 10, 2010
  12. Sep 16, 2010
  13. Aug 24, 2010
  14. Aug 13, 2010
  15. Aug 10, 2010
  16. Jul 26, 2010
  17. Jul 23, 2010
  18. Jul 21, 2010
  19. Jul 14, 2010
    • 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
  20. Jul 06, 2010
  21. Jun 08, 2010
  22. Jun 03, 2010
  23. Jun 01, 2010
  24. May 28, 2010
  25. May 07, 2010
  26. Apr 21, 2010
  27. Feb 12, 2010
  28. Jan 18, 2010
  29. Dec 09, 2009
  30. Dec 02, 2009
  31. Nov 13, 2009
  32. Nov 02, 2009
    • Richard Mudgett's avatar
      DAHDI ISDN channel names will not allow device state to work. (Interim solution.) · 6406f395
      Richard Mudgett authored
      Since ISDN works like SIP and not analog ports in regard to devices, the
      device state based on the ISDN channel number could not work.  This has
      not been an issue until the advent of PTMP NT mode.  Previously, ISDN
      lines were used as trunks and did not have to keep track of specific
      devices.
      
      As an interim solution until device states are properly implemented, the
      channel name is being changed to the following format to use the generic
      device state support:
      DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
      
      Dialplan hints would thus be:
      exten => xxx,hint,DAHDI/i2/5551212
      
      This will work with the following restrictions:
      *  The number of devices/phones cannot exceed the number of B channels.
      (i.e., BRI has 2)
      *  Each device/phone can only have one number.  No shared MSN's.
      *  The phones/devices probably should not use subaddressing.
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226882 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      6406f395
  33. Oct 05, 2009
    • Kevin P. Fleming's avatar
      Allow non-compliant T.38 endpoints to be supportable via configuration option. · 20743ec0
      Kevin P. Fleming authored
      Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept
      as the T38FaxMaxDatagram value in their SDP, when in fact this value is
      supposed to be the maximum UDPTL payload size (datagram size) they can accept.
      If the value they supply is small enough (a commonly supplied value is '72'),
      T.38 UDPTL transmissions will likely fail completely because the UDPTL packets
      will not have enough room for a primary IFP frame and the redundancy used for
      error correction. If this occurs, the Asterisk UDPTL stack will emit log messages
      warning that data loss may occur, and that the value may need to be overridden.
      
      This patch extends the 't38pt_udptl' configuration option in sip.conf to allow
      the administrator to override the value supplied by the remote endpoint and
      supply a value that allows T.38 FAX transmissions to be successful with that
      endpoint. In addition, in any SIP call where the override takes effect, a debug
      message will be printed to that effect. This patch also removes the
      T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not
      actually had any effect for a number of releases.
      
      In addition, this patch cleans up the T.38 documentation in sip.conf.sample
      (which incorrectly documented that T.38 support was passthrough only).
      
      (issue #15586)
      Reported by: globalnetinc
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      20743ec0
  34. Oct 01, 2009
  35. Sep 24, 2009
Loading