Due to the architecture of how media streams are handled each individual
handler adds connection details (IP address) for it. The first media stream
is then used as the top level SDP connection line. In practice each
line ends up being the same so to reduce the SDP size stream-level connection
information is also added to the SDP if it differs from the top level SDP
connection line.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424077 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This gets rid of most old libc free/malloc/realloc and replaces them
with ast_free and friends. When compiling with MALLOC_DEBUG you'll
notice it when you're mistakenly using one of the libc variants. For
the legacy cases you can define WRAP_LIBC_MALLOC before including
asterisk.h.
Even better would be if the errors were also enabled when compiling
without MALLOC_DEBUG, but that's a slightly more invasive header
file change.
Those compiling addons/format_mp3 will need to rerun
./contrib/scripts/get_mp3_source.sh.
ASTERISK-24348 #related
Review: https://reviewboard.asterisk.org/r/4015/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new option 'preferchannelclass' is added to musiconhold.conf. If yes
(the default) the CHANNEL(musicclass) is preferred when choosing the
hold music. If it is no, the class suggested by the application that
calls the MoH (e.g. the Queue() app) gets preferred (new behaviour).
This way you set a different hold-music from the Queue-music by setting
both the CHANNEL(musicclass) and the queue-context musicclass.
ASTERISK-24276 #close
Reported by: Kristian Høgh
Patches:
app_override_channel_moh.patch uploaded by Kristian Høgh (License #6639)
Review: https://reviewboard.asterisk.org/r/4010/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The crash on the issues is a result of an invalid transport configuration
change when asterisk is restarted. The attempt to send the qualify
request fails and we cleaned up. However, the callback is also called
which results in a double unref of the objects involved.
* Put a wrapper around pjsip_endpt_send_request() to detect when the
passed in callback is called because of an error so callers can know to
not cleanup.
* Made send_request_cb() able to handle repeated challenges (Up to 10).
* Fix periodic endpoint qualify OPTIONS sched deletion race by avoiding
it. The sched entry will no longer self stop and must be externally
stopped.
* Added REF_DEBUG description tags to struct sched_data in
pjsip_options.c.
* Fix some off-nominal ref leaks in schedule_qualify(),
qualify_and_schedule().
* Reordered pjsip_options.c module start/stop code to cleanup better on
error.
ASTERISK-24295 #close
Reported by: Rogger Padilla
Review: https://reviewboard.asterisk.org/r/3954/
........
Merged revisions 423866 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423867 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When unloading the module did not unregister the CLI commands causing a crash upon
load when they were registered again.
When reloading the module the return value from the config options framework was not
checked to determine if an error occurred or not. This caused a message to be output
saying the module did not exist when reloading if no changes were present.
AST-1433 #close
AST-1434 #close
........
Merged revisions 423579 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423580 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Outgoing PJSIP calls can result in non-negotiated formats listed in the
channel's native formats if video formats are listed in the endpoint's
configuration. The resulting call could then use a non-negotiated format
resulting in one way audio.
* Simplified the update of session->req_caps in set_caps(). Why do
something in five steps when only one is needed?
AFS-162 #close
Review: https://reviewboard.asterisk.org/r/4000/
........
Merged revisions 423561 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change gives framehooks a reverse-direction masquerade callback in
addition to chan_fixup_cb similar to the callback added to datastores
to handle the same situation. The new callback provides the same
parameters as the fixup callback, but is called on the new channel's
framehooks before moving framehooks from the old channel to the new
channel. This gives the framehooks an oppurtunity to decide whether
they should remain on the new channel or be removed.
This new callback is used to prevent the PJSIP T.38 framehook from
remaining on a masqueraded channel if the new channel is not also a
PJSIP channel. This was causing a crash when a local channel was
masqueraded into a PJSIP channel and the framehook was executed on the
local channel since the channel's tech private data was not structured
as expected.
Review: https://reviewboard.asterisk.org/r/4001/
........
Merged revisions 423503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res_pjsip_pubsub has two separate checks that it makes when a SUBSCRIBE
arrives.
* It checks that there is a subscription handler for the Event
* It checks that there are body generators for the types in the Accept header
The problem is, there's nothing that ensures that these two things will
actually mesh with each other. For instance, Asterisk will accept a subscription
to MWI that accepts pidf+xml bodies. That doesn't make sense.
With this commit, we add some type information to the mix. Subscription
handlers state they generate data of type X, and body generators state
that they consume data of type X. This way, Asterisk doesn't end up in
some hilariously mismatched situation like the one in the previous paragraph.
ASTERISK-24136 #close
Reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/3877
Review: https://reviewboard.asterisk.org/r/3878
........
Merged revisions 423344 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423348 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. The number of file descriptors an ioqueue instance can handle is fixed, so we
now spawn the required number to handle the load.
2. Our transport identifiers were exceeding the range supported by pjnath.
3. The TURN client did not set up client binding causing needless bandwidth usage.
4. The code no longer updates address information on each packet.
5. STUN traffic was getting looped back to Asterisk instead of going through the
TURN server.
6. Synchronization now ensures things are completely setup or destroyed.
7. Logging now reflects the target the TURN server is sending to/receiving from
on our behalf.
ASTERISK-23577 #close
Reported by: Jay Jideliov
ASTERISK-23634 #close
Reported by: Roman Skvirsky
Review: https://reviewboard.asterisk.org/r/3982/
........
Merged revisions 423150 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423151 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423152 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- adds sort=randstart (next to sort=, sort=random, sort=alpha)
- combines duplicate moh option parsing code into a single function
- adds deprecationwarnings for application=r to sort randomly
- adds deprecationwarnings for random=yes to sort randomly
- removes invisible code that was supposed to stay until 1.8
The sort=randstart works like sort=alpha, except we start at a random
position.
Review: https://reviewboard.asterisk.org/r/3991/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423065 65c4cc65-6c06-0410-ace0-fbb531ad65f3
PJSIP, unless a constant is modified at compilation time, limits
SIP requests to 4000 bytes. Full-state RLS notifications can easily
exceed this limit with moderately small lists.
This changeset allows for Asterisk to work around this size limit by
performing its own allocation of the transmission data buffer. This
way, Asterisk can allocate a buffer that exceeds the built-in maximum.
We still impose our own limit of 64000 bytes, mainly because making
allocations larger than that is a bit absurd.
ASTERISK-24181 #close
Reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/3977
........
Merged revisions 422851 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422852 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Testsuite tests will occasionally fail because on reception of a 200 OK SIP response,
an AST_CONTROL_ANSWER frame is queued prior to when media has finished being
negotiated. This is because session supplements are called into before PJSIP's
inv_session code has told us that media has been updated. Sometimes the queued answer
frame is handled by the PBX thread before the ensuing media negotiations occur, causing
a test failure.
As it turns out, there is another place that session supplements could be called into, which is
after media has finished getting negotiated. What this commit introduces is a means for session
supplements to indicate when they wish to be called into when handling an incoming SIP response.
By default, all session supplements will be run at the same point that they were prior to this
commit. However, session supplements may indicate that they wish to be handled earlier than
normal on redirects, or they may indicate they wish to be handled after media has been negotiated.
In this changeset, two session supplements have been updated to indicate a preference for when
they should be run: res_pjsip_diversion executes before handling redirection in order to get
information from the Diversion header, and chan_pjsip now handles responses to INVITEs after
media negotiation to fix the race condition mentioned previously.
ASTERISK-24212 #close
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/3930
........
Merged revisions 422536 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422542 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When ARI manipulates a bridge, it generally doesn't care what the mixing
technology is. Operations on a bridge initiated through ARI should perform
their action in generally the same way, regardless of the bridge's mixing
technology. While the mixing technology may determine how media flows to
channels, the actual operations on a bridge themselves should be the same.
Currently, this isn't the case with holding bridges. When a channel joins
without a role, MoH is started on that channel automatically. Subsequent bridge
operations that would stop MoH would fail (as there is no Announcer channel
playing MoH to the bridge). Starting MoH on the bridge will also create two
MoH streams: one from the MoH being played on the participant channel, and one
from the announcer channel. From the perspective of ARI users, this is
counter-intuitive - I would not expect MoH to be started for me. The mixing
technology determines how media is shared between participants, not the
application experience.
This patch does the following:
* The Stasis bridge class now inspects channels as they are going into a
bridge. If the bridge has a holding capability, and the channel has no
roles, we give it a participant role and mark the default behaviour to have
no entertainment. This allows addChannel operations to continue to set a
participant role with an entertainment option if it felt like it (or could
do it).
* The music on hold channel is now Stasis approved (tm)
Review: https://reviewboard.asterisk.org/r/3929/
ASTERISK-24264 #close
Reported by: Samuel Galarneau
Tested by: Samuel Galarneau
........
Merged revisions 422503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A misunderstanding of how the scheduler worked caused further batched notifications
beyond the first not to get scheduled. Now we reset our scheduler ID to -1 after
the batched notification is sent. This way, further notifications can be scheduled
when they arise.
........
Merged revisions 422239 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to alter the Contact header on in-dialog requests and responses the
Websocket module must be attached on outgoing INVITEs. The Contact header is
modified so that the PJSIP transport layer can find and use the existing
Websocket connection based on the source IP address, port, and transport.
ASTERISK-24143 #close
Reported by: Aleksei Kulakov
........
Merged revisions 421955 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421956 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The packet structure used to receive messages was using the transport
pool. This meant that for each parsing the pool would grow accordingly.
Since memory can not be reclaimed without resetting it this would
cause the memory pool to grow and grow.
This change uses a specific memory pool for the packet structure and
resets it to a fresh state after the message has been received and
handled.
........
Merged revisions 421939 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421945 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this change, the Remote-Party-ID header took the position of
"If caller name and number are not explicitly allowed, then they are private"
and P-Asserted-Identity took the position of
"Caller name and number are only private if marked explicitly so"
Now both mechanisms of conveying party identification use the former approach.
........
Merged revisions 421778 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421783 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On a SIP reinvite that changes media strams, the PJSIP channel driver was
flooding the log with "Asked to transmit frame type %s, while native
formats is %s" warnings.
* Fixes PJSIP not setting up translation paths when the formats change on
a reinvite. AFS-63 was effectively reintroduced because of the media
formats work. res_pjsip_sdp_rtp.c:set_caps()
* Improved the unexpected frame format WARNING message to include more
information.
* Added protective locking while altering formats on a channel. Reworked
set_format() to simplify and protect the formats under manipulation.
* Restored some code that got lost in the media_formats work.
(channel.c:set_format() and res_pjsip_sdp_rtp.c:set_caps())
AFS-137 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3906/
........
Merged revisions 421645 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a blind transfer occurs that is forced to create a local channel
pair to satisfy the transfer request, information about the local
channel pair is not published. This adds a field to describe that
channel to the blind transfer message struct so that this information
is conveyed properly to consumers of the blind transfer message.
This also fixes a bug in which Stasis() was unable to properly identify
the channel that was replacing an existing Stasis-controlled channel
due to a blind transfer.
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3921/
........
Merged revisions 421537 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421538 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If /channels/{channelID}/continue is called on a channel that was originated
without a PBX (such as the ARI command POST channel with a stasis application
argument), the channel will not start dialplan execution. This patch will now
run the PBX out of the stasis execution if the channel doesn't currently have
an active PBX upon continuing.
ASTERISK-24043 #close
Reported by: Krandon Bruse
Review: https://reviewboard.asterisk.org/r/3917/
Patches:
stasis-continue.diff submitted by Krandon Bruse (license 6631)
........
Merged revisions 421416 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421423 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Joshua Colp
Richard Mudgett
Walter Doekes
Kinsey Moore
Sean Bright
Mark Michelson
Jonathan Rose
George Joseph
Matthew Jordan