Created by Asterisk on 2011-09-30 and last modified on 2015-04-11
Get this branch:
bzr branch lp:asterisk

Branch merges

Related bugs

Related blueprints

Branch information


Import details

Import Status: Reviewed

This branch is an import of the Subversion branch from http://svn.asterisk.org/svn/asterisk/trunk.

The next import is scheduled to run in 4 hours.

Last successful import was 1 hour ago.

Import started 1 hour ago on alnitak and finished 1 hour ago taking 1 minute — see the log
Import started 7 hours ago on izar and finished 7 hours ago taking 1 minute — see the log
Import started 13 hours ago on izar and finished 13 hours ago taking 1 minute — see the log
Import started 19 hours ago on izar and finished 19 hours ago taking 1 minute — see the log
Import started on 2019-05-25 on alnitak and finished on 2019-05-25 taking 1 minute — see the log
Import started on 2019-05-25 on izar and finished on 2019-05-25 taking 1 minute — see the log
Import started on 2019-05-24 on alnitak and finished on 2019-05-24 taking 1 minute — see the log
Import started on 2019-05-24 on izar and finished on 2019-05-24 taking 1 minute — see the log
Import started on 2019-05-24 on alnitak and finished on 2019-05-24 taking 1 minute — see the log
Import started on 2019-05-24 on alnitak and finished on 2019-05-24 taking 1 minute — see the log

Recent revisions

26158. By mjordan on 2015-04-11

clang compiler warnings: Fix various warnings for tests

This patch fixes a variety of clang compiler warnings for unit tests. This
includes autological comparison issues, ignored return values, and
interestingly enough, one embedded function. Fun!

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

Reported by: dkdegroot
  rb4555.patch submitted by dkdegroot (License 6600)

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

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

26157. By mjordan on 2015-04-11

res/res_pjsip_t38: Add missing initialization of t38faxmaxdatagram

Prior to this patch, the far_max_datagram value on the UDPTL structure would
remain -1 if the remote endpoint fails to provide the SDP media attribute
T38FaxMaxDatagram. This can result in the INVITE request being rejected. With
this patch, we will now properly initialize the value with either the default
value or with the value provided by pjsip.conf's t38_udptl_maxdatagram

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

ASTERISK-24928 #close
Reported by: Juergen Spies
Tested by: Juergen Spies
  pjsipT38patch20150331.txt submitted by Juergen Spies (License 6698)

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

26156. By rmudgett on 2015-04-10

chan_pjsip/res_pjsip/bridge_softmix/core: Improve translation path choices.

With this patch, chan_pjsip/res_pjsip now sets the native formats to the
codecs negotiated by a call.

* The changes in chan_pjsip.c and res_pjsip_sdp_rtp.c set the native
formats to include all the negotiated audio codecs instead of only the
initial preferred audio codec and later the currently received audio

* The audio frame handling in channel.c:ast_read() is more streamlined and
will automatically adjust to changes in received frame formats. The new
policy is to remove translation and pass the new frame format to the
receiver except if the translation was to a signed linear format. A more
long winded version is commented in ast_read() along with some caveats.

* The audio frame handling in channel.c:ast_write() is more streamlined
and will automatically adjust any needed translation to changes in the
frame formats sent. Frame formats sent can change for many reasons such
as a recording is being played back or the bridged peer changed the format
it sends. Since it is a normal expectation that sent formats can change,
the codec mismatch warning message is demoted to a debug message.

* Removed the short circuit check in
channel.c:ast_channel_make_compatible_helper(). Two party bridges need to
make channels compatible with each other. However, transfers and moving
channels among bridges can result in otherwise compatible channels having
sub-optimal translation paths if the make compatible check is short
circuited. A result of forcing the reevaluation of channel compatibility
is that the asterisk.conf:transcode_via_slin and codecs.conf:genericplc
options take effect consistently now. It is unfortunate that these two
options are enabled by default and negate some of the benefits to the
changes in channel.c:ast_read() by forcing translation through signed
linear on a two party bridge.

* Improved the softmix bridge technology to better control the translation
of frames to the bridge. All of the incoming translation is now normally
handled by ast_read() instead of splitting any translation steps between
ast_read() and the slin factory. If any frame comes in with an unexpected
format then the translation path in ast_read() is updated for the next
frame and the slin factory handles the current frame translation.

This is the final patch in a series of patches aimed at improving
translation path choices. The other patches are on the following reviews:

ASTERISK-24841 #close
Reported by: Matt Jordan

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

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

26155. By kharwell on 2015-04-10

chan_sip: make progressinband default to no

After the "progressinband" value setting of "never" was updated to never send a
183 this separated its use from the "no" value. Since "never" was the default,
but most users probably expect "no" this patch updates the default for the
"progressinband" setting to "no."

ASTERISK-24835 #close
Reported by: Andrew Nagy
Review: https://reviewboard.asterisk.org/r/4606/

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

26154. By mjordan on 2015-04-10

res_pjsip: Add an 'auto' option for DTMF Mode

This patch adds support for automatically detecting the type of DTMF that a
PJSIP endpoint supports. When the 'dtmf_mode' endpoint option is set to 'auto',
the channel created for an endpoint will attempt to determine if RFC 4733
DTMF is supported. If so, it will use that DTMF type. If not, the DTMF type
for the channel will be set to inband.

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

ASTERISK-24706 #close
Reported by: yaron nahum
  yaron_patch_3_Feb.diff submitted by yaron nahum (License 6676)

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

26153. By gtjoseph on 2015-04-10

res_pjsip_config_wizard: Cleanup load unload

While investigating other unload issues I realized that the load/unload process
for the config wizard was pretty ugly so I've refactored it as follows...

When the res_pjsip sorcery instance is created the config_wizard bumps it's own
module reference to prevent it from unloading while the sorcery instance is
still active. When res_pjsip unloads and it's sorcery instance is destroyed,
the config wizard unrefs itself which then allows itself to unload cleanly.
Since the config wizard now can't load after res_pjsip or unload before it
(which should have been the correct behavior all along), I was able to remove
the chunks of code in both load_module and unload_module that handled that case.

Ran the testsuite tests to insure there were no functional changes and REF_DEBUG
to insure that Asterisk was shutting down cleanly with no FRACKs or leaks.

Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4610/

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

26152. By rmudgett on 2015-04-10

bridge_softmix.c,channel.c: Minor code simplification and cleanup.

* Made code easier to follow in bridge_softmix.c:analyse_softmix_stats()
and made some debug messages more helpful.

* Made some debug and warning messages more helpful in

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

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

26151. By rmudgett on 2015-04-10

translate.c: Only select audio codecs to determine the best translation choice.

Given a source capability of h264 and ulaw, a destination capability of
h264 and g722 then ast_translator_best_choice() would pick h264 as the
best choice even though h264 is a video codec and Asterisk only supports
translation of audio codecs. When the audio starts flowing, there are
warnings about a codec mismatch when the channel tries to write a frame to
the peer.

* Made ast_translator_best_choice() only select audio codecs.

* Restore a check in channel.c:set_format() lost after v1.8 to prevent
trying to set a non-audio codec.

This is an intermediate patch for a series of patches aimed at improving
translation path choices for ASTERISK-24841.

This patch is a complete enough fix for ASTERISK-21777 as the v11 version
of ast_translator_best_choice() does the same thing. However, chan_sip.c
still somehow tries to call ast_codec_choose() which then calls
ast_best_codec() with a capability set that doesn't contain any audio
formats for the incoming call. The remaining warning message seems to be
a benign transient.

ASTERISK-21777 #close
Reported by: Nick Ruggles

ASTERISK-24380 #close
Reported by: Matt Jordan

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

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

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

26150. By mjordan on 2015-04-10

res/ari: Fix model validation for ChannelHold event

When the ChannelHold event was added, the 'musicclass' parameter was
erroneously removed. This caused the ChannelHold events to be rejected as
they failed model validation. This patch updates the Swagger schema such that
it now properly reflects the event that is being created.

Hooray for tests that catch things like this.

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

26149. By file on 2015-04-10

dns: Fix build when TEST_FRAMEWORK is not defined.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.