Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
0 authors
  1. Feb 25, 2015
  3. Feb 24, 2015
    • Richard Mudgett's avatar
      config.h: Use real parameter names for ast_variable_new() define. · 57525c3c
      Richard Mudgett authored 
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432220 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      57525c3c
    • Matthew Jordan's avatar
      channels/chan_sip: Fix crash when transmitting packet after thread shutdown · 8574c4d1
      Matthew Jordan authored 
      When the monitor thread is stopped, its pthread ID is set to a specific value
(AST_PTHREADT_STOP) so that later portions of the code can determine whether
or not it is safe to manipulate the thread. Unfortunately, __sip_reliable_xmit
failed to check for that value, checking instead only for AST_PTHREAD_STOP.
Passing the invalid yet very specific value to pthread_kill causes a crash.

This patch adds a check for AST_PTHREADT_STOP in __sip_reliable_xmit such that
it doesn't attempt to poke the thread if the thread has already been stopped.

ASTERISK-24800 #close
Reported by: JoshE
........

Merged revisions 432198 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 432199 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      8574c4d1
    • Matthew Jordan's avatar
      ARI/PJSIP: Apply requesting channel's format cap to created channels · a528dfc9
      Matthew Jordan authored 
      This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
  structure of SLIN and apply it to the new channel being created. This was
  originally done when the PBX core was used to create the channel, as there
  was a condition where a newly created channel could be created without any
  formats. Unfortunately, now that the Dial API is being used, this has two
  drawbacks:
  (a) SLIN, while it will ensure audio will flows, can cause a lot of
      needless transcodings to occur, particularly when a Local channel is
      created to the dialplan. When no format capabilities are available, the
      Dial API handles this better by handing all audio formats to the requsted
      channels. As such, we defer to that API to provide the format
      capabilities.
  (b) If a channel (requester) is causing this channel to be created, we
      currently don't use its format capabilities as we are passing in our own.
      However, the Dial API will use the requester channel's formats if none
      are passed into it, and the requester channel exists and has format
      capabilities. This is the "best" scenario, as it is the most likely to
      create a media path that minimizes transcoding.
  Fixing this simply entails removing the providing of the format capabilities
  structure to the Dial API.

* chan_pjsip: Rather than blindly picking the first format in the format
  capability structure - which actually *can* be a video or text format - we
  select an audio format, and only pick the first format if that fails. That
  minimizes the weird scenario where we attempt to transcode between video/audio.

* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
  Since ast_request already limits us down to one format capability once the
  format capabilities are passed along, there's no reason to squelch it here.

* channel: Fixed a comment. The reason we have to minimize our requested
  format capabilities down to a single format is due to Asterisk's inability
  to convey the format to be used back "up" a channel chain. Consider the
  following:

    PJSIP/A => L;1 <=> L;2 => PJSIP/B
    g,u,a     g,u,a    g,u,a      u

  That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
  PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
  channel has inherited those format capabilities down the line; PJSIP/B
  supports only ulaw. According to these format capabilities, ulaw is
  acceptable and should be selected across all the channels, and no
  transcoding should occur. However, there is no way to convey this: when L;2
  and PJSIP/B are put into a bridge, we will select ulaw, but that is not
  conveyed to PJSIP/A and L;1. Thus, we end up with:

    PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
      g          g   X   u        u

  Which causes g722 to be written to PJSIP/B.

  Even if we can convey the 'ulaw' choice back up the chain (which through
  some severe hacking in Local channels was accomplished), such that the chain
  looks like:

    PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
      u          u       u         u

  We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
  with only 'ulaw'. This results in all the channel structures being set up
  correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
  apart.

  There's a lot of difficulty just in setting this up, as there are numerous
  race conditions in the act of bridging, and no clean mechanism to pass the
  selected format backwards down an established channel chain. As such, the
  best that can be done at this point in time is clarifying the comment.

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

ASTERISK-24812 #close
Reported by: Matt Jordan
........

Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a528dfc9
    • Kevin Harwell's avatar
      bridge_softmix: G.729 codec license held · 91733b5d
      Kevin Harwell authored 
      When more than one call using the same codec type enters into a softmix bridge
and no audio is present for a channel the bridge optimizes the out frame by
using the same one for all channels with the same codec type. Unfortunately,
when that number (channels with same codec type) dropped to <= 1 the codec
was not dereferenced. At least not until all parties left the bridge. Thus in
the case of G.729 the license was not released. This patch ensures that the
codec is dereferenced immediately when the optimization no longer applies.

ASTERISK-24797 #close
Reported by: Luke Hulsey
Review: https://reviewboard.asterisk.org/r/4429/
........

Merged revisions 432174 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 432175 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      91733b5d
  5. Feb 21, 2015
  7. Feb 20, 2015
  9. Feb 19, 2015
  11. Feb 17, 2015
    • Richard Mudgett's avatar
      res_pjsip_refer: Fix crash from a REFER and BYE collision. · 09bfe4b2
      Richard Mudgett authored 
      Analyzing a one-off crash on a busy system showed that processing a REFER
request had a NULL session channel pointer.  The only way I can think of
that could cause this is if an outgoing BYE transaction overlapped the
incoming REFER transaction in a collision.  Asterisk sends a BYE while the
phone sends a REFER to complete an attended transfer.

* Made check the session channel pointer before processing an incoming
REFER request in res_pjsip_refer.

* Fixed similar crash potential for res_pjsip supplement incoming request
processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE,
res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER
messages.

* Made res_pjsip_messaging respond to a message body too large with a 413
instead of ignoring it.

ASTERISK-24700 #close
Reported by: Zane Conkle

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

Merged revisions 431898 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      09bfe4b2
  13. Feb 16, 2015
  15. Feb 15, 2015
  17. Feb 14, 2015
  19. Feb 13, 2015
    • Richard Mudgett's avatar
      res_pjsip_session: Fix double re-INVITE collision crash. · f00ebf0a
      Richard Mudgett authored 
      A multi-asterisk box setup with direct media enabled would occasionally
crash when two re-INVITE collisions on a call leg happen in a row.

The re-INVITE logic only had one timer struct to defer the re-INVITE.
When the second collision happens the timer struct is overwritten and put
into the timer heap again.  Resources for the first timer are leaked and
the heap has two positions occupied by the same timer struct.  Now the
heap ordering is potentially corrupted, the timer will fire twice, and any
resources allocated for the second timer will be released twice.

* The solution is to put the collided re-INVITE into the delayed requests
queue with all the other delayed requests and cherry pick the next request
that can come off the queue when an event happens.

* Changed to put delayed BYE requests at the head of the delayed queue.
There is no sense in processing delayed UPDATEs and re-INVITEs when a BYE
has been requested.

* Made the start of a BYE request flush the delayed requests queue to
prevent a delayed request from overlapping the BYE transaction.  I saw a
few cases where a delayed re-INVITE got started after the BYE transaction
started.

* Changed the delayed_request struct to use an enum instead of a string
for the request method.  Cherry picking the queue is easier with an enum
than string comparisons and the compiler can warn if a switch statement
does not cover all defined enum values.

* Improved the debug output to give more information.  It helps to know
which channel is involved with an endpoint.  Trunks can have many channels
associated with the endpoint at the same time.

ASTERISK-24727 #close
Reported by: Mark Michelson

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

Merged revisions 431734 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      f00ebf0a
  21. Feb 12, 2015
    • Matthew Jordan's avatar
      ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app · 29f66b04
      Matthew Jordan authored 
      This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.

*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.

*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
    only transfer channels to a SIP URI, i.e., you had to pass
    'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
    still supported, it is somewhat unintuitive - particularly in a world full
    of endpoints. As such, we now also support specifying the PJSIP endpoint to
    transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
    updating its Contact header. Alas, that resulted in the forwarding
    destination set by the dialplan application/ARI resource/whatever being
    rewritten with very incorrect information. Hence, we now don't bother
    updating an outgoing response if it is a 302. Since this took a looong time
    to find, some additional debug statements have been added to those modules
    that update the Contact headers.

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

ASTERISK-24015 #close
Reported by: Private Name

ASTERISK-24703 #close
Reported by: Matt Jordan
........

Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      29f66b04
  23. Feb 11, 2015