If faxing fails at a very early stage, then it is possible for
us to pass a NULL t30 state pointer to spandsp, which spandsp
is none too pleased with.
This patch ensures that we pass the correct pointer to spandsp
in the situation where we have not yet set our local t30 state
pointer.
ASTERISK-24301 #close
Reported by Matt Jordan
Patches:
ASTERISK-24301-fax.diff Uploaded by Mark Michelson (License #5049)
........
Merged revisions 423360 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423365 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423372 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When no transport is associated to an endpoint, the AMI output for
PJSIPShowEndpoint indicates an error instead of silently ignoring the
missing transport.
This patch causes the error to appear only if a transport was specified
on the endpoint and the transport doesn't exist. It also fixes an issue
with counting the objects that were actually found.
ASTERISK-24161 #close
ASTERISK-24331 #close
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3998/
........
Merged revisions 423282 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423284 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423152 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422851 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422542 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422504 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422239 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421956 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change enforces the transport in the Contact header for Websocket clients.
Previously a client may provide a transport of 'ws' when it is actually using
a transport of 'wss'. This would cause outgoing calls to fail as the existing
connection could not be found.
........
Merged revisions 421931 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Using the hostname in the SDP origin line may not satisfy the requirement
of RFC 4566 that we use a FQDN or IP address. This change has us use the
same information from the SDP connection line if possible. If not possible,
we'll use the configured media address. And if that's not possible, we use
the result of a PJLIB call to get the IP address of ourself.
ASTERISK-23994 #close
Reported by Private Name
Review: https://reviewboard.asterisk.org/r/3925
........
Merged revisions 421796 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Because of the departable state of channels that enter Stasis bridges, Stasis has to
take responsibility for directing the channel to its intended after-bridge destination
if the channel moves from a Stasis bridge to a non-Stasis bridge. This change ensures
that when such a move occurs, when the channel leaves the bridging system, any after
bridge gotos are honored.
Review: https://reviewboard.asterisk.org/r/3920
........
Merged revisions 421792 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421794 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Trivial patch to add new lines to several files missing them. This fixes
warnings when compiling with gcc 4.1.2 on CentOS 5.
ASTERISK-24245 #close
Reported by: Shaun Ruffell
patches:
0002-Trivial-addition-of-newlines-at-end-of-three-files.patch uploaded by Shaun Ruffell (License 5417)
........
Merged revisions 421677 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421678 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421645 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was causing the AMI show_subscriptions test in
the testsuite to fail since all subscriptions were being
seen as subscribers instead of notifiers.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421585 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421538 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A calls B
B answers
B SIP attended transfers to C
C answers, B and C can see each other's connected line information
B completes the transfer
A has number but no name connected line information about C
while C has the full information about A
I examined the incoming and outgoing party id information handling of
chan_pjsip and found several issues:
* Fixed ast_sip_session_create_outgoing() not setting up the configured
endpoint id as the new channel's caller id. This is why party A got
default connected line information.
* Made update_initial_connected_line() use the channel's CALLERID(id)
information. The core, app_dial, or predial routine may have filled in or
changed the endpoint caller id information.
* Fixed chan_pjsip_new() not setting the full party id information
available on the caller id and ANI party id. This includes the configured
callerid_tag string and other party id fields.
* Fixed accessing channel party id information without the channel lock
held.
* Fixed using the effective connected line id without doing a deep copy
outside of holding the channel lock. Shallow copy string pointers can
become stale if the channel lock is not held.
* Made queue_connected_line_update() also update the channel's
CALLERID(id) information. Moving the channel to another bridge would need
the information there for the new bridge peer.
* Fixed off nominal memory leak in update_incoming_connected_line().
* Added pjsip.conf callerid_tag string to party id information from
enabled trust_inbound endpoint in caller_id_incoming_request().
AFS-98 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3913/
........
Merged revisions 421400 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421403 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a function fails to execute, it is most likely due to one of two reasons:
(1) The function doesn't exist or can't be read from
(2) The function is dangerous and is restricted based on the user's permissions
Currently we return allocation failure, which is incorrect. This updates the
reason code to more accurately reflect why the request failed.
ASTERISK-24215
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_hep_rtcp module was incorrectly including <pjsip.h>. This didn't need
to be included, as the module does not using PJPROJECT any fashion.
Unfortunately, because res_hep_rtcp did not include pjsip in its MODULEINFO as
a dependency, this also meant that res_hep_rtcp will fail to compile on a
system without PJPROJECT.
This patch removes the include.
Thanks to Damien Wedhorn for pointing this out in #asterisk-dev.
ASTERISK-24236 #close
Reported by: Damien Wedhorn, Matt Jordan
Tested by: Damien Wedhorn
........
Merged revisions 421064 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421065 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made use ast_copy_string() instead of strcpy() for snoop uniqueid for
safety. There is no guarantee that the max channel uniqueid length will
remain the same as the snoop uniqueid space.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a few issues:
1) The order of Dial events have been changed when performing a call forward.
The order has now been altered to
1) Dial begins dialing channel A.
2) When A forwards the call to B, we issue the dial end event to channel
A, indicating the dial is being canceled due to a forward to B.
3) When the call to channel B occurs, we then issue a new dial begin to
channel B.
2) Call forwards are now reported on the calling channel, not the peer channel.
3) AMI DialEnd events have been altered to display the extension the call is
being forwarded to when relevant.
4) You can now get the values of channel variables for channels that are not
currently in the Stasis application. This brings the retrieval of channel
variables more in line with the rest of channel read operations since they
may be performed on channels not in Stasis.
ASTERISK-24134 #close
Reported by Matt Jordan
ASTERISK-24138 #close
Reported by Matt Jordan
Patches:
forward-shenanigans.diff uploaded by Matt Jordan (License #6283)
Review: https://reviewboard.asterisk.org/r/3899
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The unit tests require a sorcery.conf file that has been
set up to store resource lists in memory rather than retrieving
from configuration.
With a setup that is not conducive to running the tests, a fault
in sorcery currently causes Asterisk to crash when attempting to
run any of the tests.
To get around the crash, this adds a function that verifies the
current environment and marks the tests as "not run" if the setup
is not correct.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420779 65c4cc65-6c06-0410-ace0-fbb531ad65f3
