........
res_rtp_asterisk: Add SHA-256 support for DTLS and perform DTLS negotiation on RTCP.
This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip and chan_pjsip have also been added to
allow behavior to be tweaked (such as forcing the AVP type media transports in SDP).
ASTERISK-22961 #close
Reported by: Jay Jideliov
Review: https://reviewboard.asterisk.org/r/3679/
Review: https://reviewboard.asterisk.org/r/3686/
........
Merged revisions 417678 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the abstraction effort, this bit of logic got messed up. We
want to recreate the persistence if things go well, not if things
fail.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A number of various PJSIP AMI actions were failing to parse out and place the
ActionID into their responses. This patch updates the various PJSIP actions
such that the passed in ActionID is emitted on any event list complete events,
as well as any intermediate events created as a result of the action.
#ASTERISK-23947 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3675/
........
Merged revisions 417460 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417461 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a client takes a long time to process information received from Asterisk,
a write operation using fwrite may fail to write all information. This causes
the underlying file stream to be in an unknown state, such that the socket
must be disconnected. Unfortunately, there are two problems with this in
Asterisk's existing websocket code:
1. Periodically, during the read loop, Asterisk must write to the connected
websocket to respond to pings. As such, Asterisk maintains a reference to
the session during the loop. When ast_http_websocket_write fails, it may
cause the session to decrement its ref count, but this in and of itself
does not break the read loop. The read loop's write, on the other hand,
does not break the loop if it fails. This causes the socket to get in a
'stuck' state, preventing the client from reconnecting to the server.
2. More importantly, however, is that the fwrite in ast_http_websocket_write
fails with a large volume of data when the client takes awhile to process
the information. When it does fail, it fails writing only a portion of
the bytes. With some debugging, it was shown that this was failing in a
similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
with a long enough timeout solved the problem.
Note that this version of the patch, unlike r417310 in Asterisk 11, exposes
configuration options beyond just chan_sip's sip.conf. Configuration options
to configure the write timeout have also been added to pjsip.conf and ari.conf.
#ASTERISK-23917 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3624/
........
Merged revisions 417310 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417317 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This helps to pave the way for RLS work that is to come.
Since this is a self-contained change and subscription
tests still pass, this work is being committed directly
to trunk instead of a working branch.
ASTERISK-23865 #close
Review: https://reviewboard.asterisk.org/r/3628
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417233 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added ast_sockaddr_cidr_bits() to count the 1 bits in an ast_sockaddr.
* Added ast_ha_join_cidr() which uses ast_sockaddr_cidr_bits() for the netmask
instead of ast_sockaddr_stringify_addr.
* Changed res_pjsip_endpoint_identifier_ip to call ast_ha_join_cidr() instead
of ast_ha_join() for the CLI output.
This is a CLI change only. AMI was not affected.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3652/
........
Merged revisions 416737 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pjpidf_print() does not return < 0 if there is not enough
room for the document to be printed. Rather, it returns
39, the length of the XML prolog.
The algorithm also had a bug in that it would return if
it attempted to grow the string larger.
........
Merged revisions 416442 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416444 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, music on hold will stop and then start again from the
beginning if ast_moh_start() is called multiple times. This can happen
if a call is put on hold repeatedly (the channel receives multiple
HOLD control frames) and can be triggered from ARI by starting MoH on a
channel multiple times. This is fairly jarring/annoying to users.
This change prevents MoH from being restarted if the requested music
class is the same as the one currently playing.
This includes an extra check to prevent the errors previously
experienced in the testsuite and has 100+ test runs behind it.
Review: https://reviewboard.asterisk.org/r/3615/
........
Merged revisions 416439 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 416440 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 416441 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a problem when reading a string from the websocket. It assumed the
received data had a null terminator and tried to write the data to an ast_str.
This of course could/would read past the end of the given buffer while
writing the data to the internal buffer of ast_str. Modified the the code to
correctly place a null terminator on the result string.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416394 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
* AGI execution
* Returning objects for ARI commands
* During some Local channel operations
* During some dialling operations
* During variable setting
* During some bridging operations
And more.
This patch does the following:
- It removes a number of fields from channel snapshots. These fields were
rarely used, were expensive to have on the snapshot, and hurt performance.
This included formats, translation paths, Log Call ID, callgroup, pickup
group, and all channel variables. As a result, AMI Status,
"core show channel", "core show channelvar", and "pjsip show channel" were
modified to either hit the live channel or not show certain pieces of data.
While this is unfortunate, the performance gain from this patch is worth
the loss in behaviour.
- It adds a mechanism to publish a cached snapshot + blob. A large number of
publications were changed to use this, including:
- During Dial begin
- During Variable assignment (if no AMI variables are emitted - if AMI
variables are set, we have to make snapshots when a variable is changed)
- During channel pickup
- When a channel is put on hold/unhold
- When a DTMF digit is begun/ended
- When creating a bridge snapshot
- When an AOC event is raised
- During Local channel optimization/Local bridging
- When endpoint snapshots are generated
- All AGI events
- All ARI responses that return a channel
- Events in the AgentPool, MeetMe, and some in Queue
- Additionally, some extraneous channel snapshots were being made that were
unnecessary. These were removed.
- The result of ast_hashtab_hash_string is now cached in stasis_cache. This
reduces a large number of calls to ast_hashtab_hash_string, which reduced
the amount of time spent in this function in gprof by around 50%.
#ASTERISK-23811 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3568/
........
Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection. Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.
A similar problem exists if a HTTP request is started but never finished.
* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything. Defaults to 30000 ms.
* Removed the undocumented manager.conf block-sockets option. It
interferes with TCP/TLS inactivity timeouts.
* AMI and SIP TLS connections now have better authentication timeout
protection. Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.
* chan_sip can now handle SSL certificate renegotiations in the middle of
a session. It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.
* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.
The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability. This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.
This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.
ASTERISK-23673 #close
Reported by: Richard Mudgett
........
Merged revisions 415841 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 415854 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 415896 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A remotely exploitable crash vulnerability exists in the PJSIP channel driver's
pub/sub framework. If an attempt is made to unsubscribe when not currently
subscribed and the endpoint's "sub_min_expiry" is set to zero, Asterisk tries
to create an expiration timer with zero seconds, which is not allowed, so an
assertion raised.
The fix was to reject a subscription that is attempting to unsubscribe when not
being already subscribed. Asterisk now checks for this situation appropriately
and responds with a 400 instead of crashing.
AST-2014-005
ASTERISK-23489 #close
........
Merged revisions 415812 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415813 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP transaction timeouts are handled in the PJSIP monitor thread. When
this happens on a subscription, and the subscription is destroyed, the
subscription destruction is dispatched synchronously to the threadpool.
The issue is that the PJSIP dialog is locked by the monitor thread,
and then the dispatched task attempts to lock the dialog. This leads
to a deadlock that causes SIP traffic to no longer be accepted on the
Asterisk server.
The fix here is to treat the monitor thread as if it were a threadpool
thread when it attempts to dispatch synchronous tasks. This way, the
dispatched task turns into a simple function call within the same thread,
and the locking issue is averted.
AST-2014-008
ASTERISK-23802 #close
........
Merged revisions 415794 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes res_pjsip_pubsub persist inbound subscriptions in sorcery. By default
this uses the local astdb but it can also be configured to store within an outside
database. When Asterisk is started these subscriptions are recreated if they have not
expired. Notifications are sent to the devices which have subscribed and they are none
the wiser that the system has restarted.
Review: https://reviewboard.asterisk.org/r/3598/
........
Merged revisions 415766 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Documentation for how to add custom headers/content to notifies created
with the PJSIPNotify manager action was a little sparse and it also
wasn't vetting application of Content-length headers like its chan_sip
equivalent was (so two Content-length headers could be applied... and
PJSIP determines the content length anyway, so it just opens people up
for error). This patch also flips the variable order so that the
variables are interpreted in the same order as they are put in the AMI
action.
Review: https://reviewboard.asterisk.org/r/3587/
........
Merged revisions 415658 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415659 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using PJSIP_HEADER() to add custom headers to outgoing INVITE requests, certain
situations could result in the headers being duplicated. For instance, if the request
were retransmitted, or if the INVITE were re-sent with authentication credentials,
the custom headers would be re-added to the request.
The fix here is to, after adding the custom headers to the outbound INVITE, remove
the datastore that holds the custom headers to add. This way, there is no risk in
accidentally adding them if the session supplement is called into a second or third
time.
........
Merged revisions 415579 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, there are situations that can occur when using chan_pjsip
and certain dialplan applications (notably ChanSpy()) that can cause
the channel to get no audio with scrolling warnings about format
mismatches. This is caused by a failure to update translation paths on
a mid-call native format update since the raw formats have already
been updated by res_pjsip_sdp_rtp.c in set_caps(). Removing the
premature raw format updates allows the translation paths to be setup
correctly and the raw read and write formats with them.
AFS-63 #close
........
Merged revisions 415342 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a websocket server client in Asterisk. Asterisk has a websocket server,
but not a client. The ability to have Asterisk be able to connect to a websocket
server can potentially be useful for future work (for instance this could allow
ARI to connect back to some external system, although more work would be needed
in order to incorporate that).
Also a couple of things to note - proxy connection support has not been
implemented and there is limited http response code handling (basically, it is
connect or not).
Also added an initial new URI handling mechanism to core. Internet type URI's
are parsed into a data structure that contains pointers to the various parts of
the URI.
(closes issue ASTERISK-23742)
Reported by: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/3541/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new channel function TALK_DETECT that, when set on a
channel, causes events indicating the start/stop of talking on a channel to be
emitted to both AMI and ARI clients.
The function allows setting both the silence threshold (the length of silence
after which we decide no one is talking) as well as the talking threshold (the
amount of energy that counts as talking). Parameters can be updated on a channel
after talk detection has been enabled, and talk detection can be removed at
any time.
The events raised by the function use a nomenclature similar to existing AMI/ARI
events.
For AMI: ChannelTalkingStart/ChannelTalkingStop
For ARI: ChannelTalkingStarted/ChannelTalkingFinished
Review: https://reviewboard.asterisk.org/r/3563/
#ASTERISK-23786 #close
Reported by: Matt Jordan
........
Merged revisions 414934 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414935 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses some aesthetic issues in Asterisk. These are all just
minor tweaks to improve the look of the CLI when used in a variety of
settings. Specifically:
* A number of chatty verbose messages were removed or demoted to DEBUG
messages. Verbose messages with a verbosity level of 5 or higher were -
if kept as verbose messages - demoted to level 4. Several messages
that were emitted at verbose level 3 were demoted to 4, as announcement
of dialplan applications being executed occur at level 3 (and so the
effects of those applications should generally be less).
* Some verbose messages that only appear when their respective 'debug'
options are enabled were bumped up to always be displayed.
* Prefix/timestamping of verbose messages were moved to the verboser
handlers. This was done to prevent duplication of prefixes when the
timestamp option (-T) is used with the CLI.
* Verbose magic is removed from messages before being emitted to
non-verboser handlers. This prevents the magic in multi-line verbose
messages (such as SIP debug traces or the output of DumpChan) from
being written to files.
* _Slightly_ better support for the "light background" option (-W) was
added. This includes using ast_term_quit in the output of XML
documentation help, as well as changing the "Asterisk Ready" prompt to
bright green on the default background (which stands a better chance of
being displayed properly than bright white).
Review: https://reviewboard.asterisk.org/r/3547/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Simply enabling PJSIP to negotiage a video codec (e.g., h264) would leak
video RTP ports if the codec were not negotiated by an incoming call.
* Made add_sdp_streams() associate the handler with the media stream if
the handler handled the media stream. Otherwise, when the
ast_sip_session_media object was destroyed it didn't know how to clean up
the RTP resources.
* Fixed sdp_requires_deferral() associating the handler with the media
stream when deciding if the SDP processing needs to be deferred for T.38.
Like the leaked video RTP ports, the T.38 handler needs to clean up
allocated resources from deciding if SDP processing needs to be deffered.
* Cleaned up some dead code in handle_incoming_sdp() and
sdp_requires_deferral().
ASTERISK-23721 #close
Reported by: cervajs
Review: https://reviewboard.asterisk.org/r/3571/
........
Merged revisions 414749 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414750 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ODBC realtime driver uses ^NN parameter encoding to cope with the
special meaning of the semi-colon. A semi-colon in a field is
interpreted as if the key was supplied twice, something which isn't
otherwise possible with fixed database columns. E.g. allow=alaw;ulaw
is parsed as allow=alaw and allow=ulaw. A literal semi-colon is
rewritten to ^3B when stored in the database.
The module uses a stringfield to efficiently store the encoded
parameters. However, this stringfield wasn't always freed in some
off-nominal cases.
Commit r413241 fixed initialization so the encoding for INSERT and
DELETE queries wouldn't crash. (Only SELECTs and UPDATEs worked
apparently.) But that commit forgot the frees. This change cleans
that up.
Review: https://reviewboard.asterisk.org/r/3555/
........
Merged revisions 414564 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 414565 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 414566 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414567 65c4cc65-6c06-0410-ace0-fbb531ad65f3
User events can now be generated from ARI. Events can be signalled with
arbitrary json variables, and include one or more of channel, bridge, or
endpoint snapshots. An application must be specified which will receive
the event message (other applications can subscribe to it). The message
will also be delivered via AMI provided a channel is attached. Dialplan
generated user event messages are still transmitted via the channel, and
will only be received by a stasis application they are attached to or if
the channel is subscribed to.
This change also introduces the multi object blob mechanism used to send
multiple snapshot types in a single message. The dialplan app UserEvent
was also changed to use multi object blob, and a new stasis message type
created to handle them.
ASTERISK-22697 #close
Review: https://reviewboard.asterisk.org/r/3494/
........
Merged revisions 414405 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes res_corosync such that it works with Asterisk 12. This
restores the functionality that was present in previous versions of
Asterisk, and ensures compatibility with those versions by restoring the
binary message format needed to pass information from/to them.
The following changes were made in the core to support this:
* The event system has been partially restored. All event definition and
event types in this patch were pulled from Asterisk 11. Previously, we had
hoped that this information would live in res_corosync; however, the
approach in this patch seems to be better for a few reasons:
(1) Theoretically, ast_events can be used by any module as a binary
representation of a Stasis message. Given the structure of an ast_event
object, that information has to live in the core to be used universally.
For example, defining the payload of a device state ast_event in
res_corosync could result in an incompatible device state representation
in another module.
(2) Much of this representation already lived in the core, and was not
easily extensible.
(3) The code already existed. :-)
* Stasis message types now have a message formatter that converts their
payload to an ast_event object.
* Stasis message forwarders now handle forwarding to themselves. Previously
this would result in an infinite recursive call. Now, this simply creates a
new forwarding object with no forwards set up (as it is the thing it is
forwarding to). This is advantageous for res_corosync, as returning NULL
would also imply an unrecoverable error. Returning a subscription in this
case allows for easier handling of message types that are published directly
to an aggregate topic that has forwarders.
Review: https://reviewboard.asterisk.org/r/3486/
ASTERISK-22912 #close
ASTERISK-22372 #close
........
Merged revisions 414330 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While load testing an ARI application, I noticed asterisk was returning HTTP 500
internal server errors on channels/:id/answer. After talking to #asterisk-dev,
the issue appeared to be a lack of media flowing after __ast_answer() was
called. So now, we call ast_raw_answer instead and no longer wait for media.
ASTERISK-23758 #close
Review: https://reviewboard.asterisk.org/r/3549/
........
Merged revisions 414195 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes issues with direct media bridges that occur after a blind
transfer. These issues were caught by the (currently failing)
pjsip/transfers/blind_transfer/caller_direct_media test.
The test currently fails primarily for two reasons:
(1) When Bob and Charlie (the transfer target and the transfer destination)
enter a bridge together, the framehook remains on the transfer target
channel until both channels are in the bridge. As it consumes voice frames,
the initial bridge type is a simple bridge. The framehook is removed when
both channels are in the bridge; however, this does not currently cause the
bridging framework to re-evaluate the bridge. This patch adds a
AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a
framehook is removed so the bridge can re-evaluate itself.
(2) When a channel leaves a native RTP bridge, it may be leaving due to being
hung up. Sending a re-INVITE to a channel that is about to be hung up is
not nice - in fact, there's a good chance we'll send the BYE request before
the channel has had a chance to send back a 200 OK. To be somewhat nicer,
this patch adds a function to channel.h that allows the bridging framework
to query for exactly why a channel is leaving a bridge via the channel's
soft hangup flags. This allows it to only send the re-INVITE if there's a
chance the channel will survive the native bridging experience.
Review: https://reviewboard.asterisk.org/r/3535/
........
Merged revisions 414122 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414123 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Embedded carriage return line feed combinations may appear in presence subtypes
and messages since they may be derived from user input in an instant messenger
client. As such, they need to be properly escaped so that XML parsers do not
vomit when the messages are received.
........
Merged revisions 413372 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413381 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was an underlying issue in a realtime backend where database updates
would fail. Since we were not checking for failure, we would end up in a
strange state where the old database entry was still present but Asterisk
thought that it had been updated. Now when an entry fails to update, we
print a warning and delete the old contact from sorcery so there is no
mismatch between foreground and backend state.
Patches:
res_pjsip_registrar.patch by John Hardin (License #6512)
........
Merged revisions 413358 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The realtime API specifies that the store callback is supposed to return the number
of rows affected. res_config_pgsql was instead returning an Oid cast as an int, which
during any nominal execution would be cast to 0. Returning 0 when more than 0 rows were
inserted causes problems to the function's callers.
To give an idea of how strange code can be, this is the necessary code change to fix
a device state issue reported against chan_pjsip in Asterisk 12+. The issue was that
the registrar would attempt to insert contacts into the database. Because of the 0
return from res_config_pgsql, the registrar would think that the contact was not successfully
inserted, even though it actually was. As such, even though the contact was query-able
and it was possible to call the endpoint, Asterisk would "think" the endpoint was unregistered,
meaning it would report the device state as UNAVAILABLE instead of NOT_INUSE.
The necessary fix applies to all versions of Asterisk, so even though the bug reported
only applies to Asterisk 12+, the code correction is being inserted into 1.8+.
Closes issue ASTERISK-23707
Reported by Mark Michelson
........
Merged revisions 413224 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 413225 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 413226 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per rfc3892, the Referred-By header in a REFER must be copied into the
referenced request (IE. The outgoing INVITE to the transfer target).
* Automatically put the Referred-By header in the outgoing INVITE message
if the SIPREFERREDBYHDR channel variable is defined with a value.
* Made chan_sip.c:get_refer_info() set SIPREFERREDBYHDR for inheritance so
chan_pjsip has a better chance to interoperate.
* Fixed refer_blind_callback() and refer_incoming_refer_request() to not
modify the data in the pointer returned by pjsip_msg_find_hdr_by_name().
It seems wrong to modify that data since the calling routine doesn't own
the buffer.
ASTERISK-23501 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/3514/
........
Merged revisions 413210 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The PBX core already takes care of ensuring that repeated state changes
are not communicated to exten state consumers. Because the check in res_pjsip_exten_state
was incomplete, it was causing valid presence state changes not to be sent out. For instance,
if the presence state did not change but the message or subtype did, then no presence-related
NOTIFY request would be sent out.
closes issue ASTERISK-23672
Reported by Mark Michelson
........
Merged revisions 413173 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed early exit in sip_msg_send() not destroying the message iterator.
* Made ast_msg_var_iterator_next() and ast_msg_var_iterator_destroy()
tolerant of a NULL iter parameter in case ast_msg_var_iterator_init()
fails.
* Made ast_msg_var_iterator_destroy() clean up any current message data
ref.
* Made struct ast_msg_var_iterator, ast_msg_var_iterator_init(),
ast_msg_var_iterator_next(), ast_msg_var_unref_current(), and
ast_msg_var_iterator_destroy() use iter instead of i.
* Eliminated RAII_VAR usage in res_pjsip_messaging.c:vars_to_headers().
........
Merged revisions 413139 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 413142 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes a bug where if an SDP with media address and sendonly was
received twice the underlying call would go off hold, instead of remaining on hold.
This occured because the code did not properly take into account that the SDP
may contain both a valid media address and the sendonly attribute.
The code now examines the sendonly attribute and media address first, so if the
SDP is received again no change will occur.
ASTERISK-23558 #comment Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/3472/
........
Merged revisions 413119 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For some odd reason, loading app_mixmonitor was fine, but res_monitor was not.
This patch fixes a set of issues related to func_periodic_hook exporting the
beep functions that gets res_monitor working again.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This changes fixes a crash that occurs when stasis determines if it
should send a message out to an application or not. The code
incorrectly assumed that a bridge snapshot would always be present
when in reality for failure cases it may not be.
ASTERISK-23573 #close
........
Merged revisions 412882 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes a problem where permanent contacts being qualified were not
being updated. This was caused by the permanent contacts getting a uuid and not a
known identifier, causing an inability to look them up when updating in the
qualify code. A bug also existed where the new configuration may not be available
immediately when updating qualifies.
(closes issue ASTERISK-23514)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/3448/
........
Merged revisions 412551 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds a tones URI type to the playback resource. The tone can be specified by
name (from indications.conf) or by a tone pattern. In addition, tonezone can
be specified in the URI (by appending ;tonezone=<zone>). Tones must be
stopped manually in order for a stasis control to move on from playback of
the tone. Tones may be paused, resumed, restarted, and stopped. They may
not be rewound or fast forwarded (tones can't be controlled in a way that
lets you skip around from note to note and pausing and resuming will also
restart the tone from the beginning). Tests are currently in development
for this feature (https://reviewboard.asterisk.org/r/3428/).
(closes issue ASTERISK-23433)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3427/
........
Merged revisions 412535 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add an option to enable a periodic beep to be played into a call if it
is being recorded. If enabled, it uses the PERIODIC_HOOK() function
internally to play the 'beep' prompt into the call at a specified
interval. This option is provided for both Monitor() and
MixMonitor().
Review: https://reviewboard.asterisk.org/r/3424/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Remove unused RAII_VAR() declarations. The compiler cannot catch these
because the cleanup function "references" the unused variable. Some
actually allocated and released resources that were never used.
* Fixed some whitespace issues in stasis_bridges.c.
........
Merged revisions 412399 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This app is pretty ancient, so it was never converted to use the
option parsing helper code. I'd like to add an option to this app
that takes an argument, and that's a pain to do when not using this
helper, so start by doing this conversion.
Review: https://reviewboard.asterisk.org/r/3429/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412102 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During discussions with Alexandr Dubovikov at Kamailio World, it became
apparent that while the SIP call ID is a useful identifier prior to an Asterisk
channel being created, it is far more preferable to use the channel name (or
some channel based identifier) when the channel is available. Homer is smart
enough to tie the various messages together. This patch opts to use the channel
name when it is available, falling back to the call ID otherwise.
........
Merged revisions 412088 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes it so if a transport is configured on an endpoint that is a WebSocket
type the option will be ignored. In practice this is fine because the WebSocket
transport can not create outgoing connections, it can only reuse existing ones. By
ignoring the option the existing PJSIP logic for using the existing connection will
be invoked and stuff will proceed.
(closes issue ASTERISK-23584)
Reported by: Rusty Newton
........
Merged revisions 411927 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The change that fixed the pubsub test event's use of a dangling pointer
also changed when it was processed relative to the pjsip subscription
state change processing. This change corrects the order of events while
holding a reference to the pointer that was previously dangling.
........
Merged revisions 411883 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Stasis() dialplan application monitors what bridge a channel is in
and so necessarily holds on to a bridge pointer. This change ensures
that it also holds on to a reference for that bridge to prevent the
bridge pointer from becoming a dangling pointer.
........
Merged revisions 411804 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Assert if a channel is destroyed but has the snapshot staging flag set.
In this case the final channel destruction snapshot would never get taken.
* Assert if what we just got out of the stasis cache is not what we were
looking for. This assert would have saved several days searching for a
bug and a lot of my hair.
* Assert if the music on hold message posts could not find the associated
channel. A crash will happen later when manager tries to send the MOH AMI
message. This assert catches the problem when the stasis message is
posted instead of by the thread processing the defective message.
* Always generate a backtrace when an ast_assert() fails.
Review: https://reviewboard.asterisk.org/r/3411/
........
Merged revisions 411701 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Parts of res_hep properly checked for a valid configuration object before
attempting to access the configuration. A check, however, was missed when
a packet is sent. This patch fixes the crash caused by not checking if the
configuration object is valid.
........
Merged revisions 411668 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411669 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit contains several changes to sorcery:
1) Application of sorcery configuration based on module name is automatically performed
when sorcery is opened for a module.
2) Sorcery will not attempt to apply the same wizard to an object type more than once.
3) Sorcery gives more exact results when attempting to apply a wizard, whether as the
default or based on configuration.
Sorcery unit tests still pass for me after making these changes.
Review: https://reviewboard.asterisk.org/r/3326
........
Merged revisions 411159 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411656 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Use ast_bridge_channel_lock()/ast_bridge_channel_unlock() instead of
ao2_lock()/ao2_unlock() for struct ast_bridge_channel variables.
* Use ast_copy_string() instead of inlining it.
* Remove an already done TODO comment.
* Some whitespace tweaks.
........
Merged revisions 411638 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the following:
(1) A new module, res_hep, which implements a generic packet capture agent for
the Homer Encapsulation Protocol (HEP) version 3. Note that this code is based
on a patch provided by Alexandr Dubovikov; I basically just wrapped it up,
added configuration via the configuration framework, and threw in a
taskprocessor.
(2) A new module, res_hep_pjsip, which forwards all SIP message traffic that
passes through the res_pjsip stack over to res_hep for encapsulation and
transmission to a HEPv3 capture server.
Much thanks to Alexandr for his Asterisk patch for this code and for a *lot*
of patience waiting for me to port it to 12/trunk. Due to some dithering on
my part, this has taken the better part of a year to port forward (I still
blame CDRs for the delay).
ASTERISK-23557 #close
Review: https://reviewboard.asterisk.org/r/3207/
........
Merged revisions 411534 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411556 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes setting nullable integer columns to NULL instead of an empty
string, which fails for PostgreSQL, for example. The current code is supposed
to do so, but the check is broken. The patch also allows the first column in
the list to be a nullable integer.
Also, the check for existence of a mandatory column checked for the first
column in the list instead of the key field lookup column. This patch fixes
that issue as well.
Finally, the compatibility option allow_empty_string_in_nontext, which was
added to previous revisions to allow for some database backends with certain
schemas to function, has been removed.
Review: https://reviewboard.asterisk.org/r/3335
ASTERISK-23459 #close
ASTERISK-23351 #close
(closes issue ASTERISK-23459)
Reported by: zvision
patches:
res_config_odbc.diff uploaded by zvision (License 5755)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411515 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed bad use of ao2_find() in on_endpoint().
* Replaced use of find_endpoints() with find_an_endpoint() since only the
first found endpoint is ever needed.
* Fixed qualify_contact_cb() to update the contact with the aor
authenticate_qualify setting. Otherwise, permanent contacts in the aor
type sections would have a config line order dependancy.
* Fixed off nominal path contact ref leak in qualify_contact(). The
comment saying the unref is not needed was wrong.
* Fixed off nominal path use of the endpoint parameter if it is NULL in
send_out_of_dialog_request().
* Added missing off nominal path unref of pjsip tdata in
send_out_of_dialog_request().
* Fixed off nominal path failing to call the callback in send_request_cb()
when the request is challenged for authentication.
* Eliminated silly RAII_VAR() use in qualify_contact_cb().
* Updated ast_sip_send_request() doxygen to better reflect reality.
(closes issue ASTERISK-23254)
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/3381/
........
Merged revisions 411141 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411142 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix memory leak in ast_unreal_new_channels(). Made it generate the ;2
uniqueid on a stack variable instead of mallocing it.
* Made send error response to ARI and AMI requests instead of just logging
excessive uniqueid length and allowing truncation. action_originate() and
ari_channels_handle_originate_with_id().
* Fixed minor truncating uniqueid hole when generating the ;2 uniqueid
string length. Created public and internal lengths of uniqueid. The
internal length can handle a max public uniqueid plus an appended ;2.
* free() and ast_free() are NULL tolerant so they don't need a NULL test
before calling.
* Made use better struct initialization format instead of the position
dependent initialization format. Also anything not explicitly initialized
in the struct is initialized to zero by the compiler.
* Made ast_channel_internal_set_fake_ids() use the safer
ast_copy_string() instead of strncpy().
Review: https://reviewboard.asterisk.org/r/3371/
........
Merged revisions 410949 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
"identify" is a special type of configuration object in PJSIP because
unlike the other objects, it is not provided by the base res_pjsip module.
Instead, it is provided by the res_pjsip_endpoint_identifier_ip module. If
using the default sorcery wizard (config,criteria=type=identify) then things
work because the module that applies the default wizard is the correct module.
However, if attempting to use sorcery.conf to apply an alternate wizard, it
was not possible. If you attempted to specify the identify object type in the
res_pjsip section, then the object could not be registered since the object
was undocumented for the res_pjsip module. There was no alternate configuration
section defined for it, so you were out of luck if you wanted to override the
default wizard.
With this change, the identify section will properly have a sorcery.conf-based
wizard applied when the identify definition is within the res_pjsip_endpoint_identifier_ip
section.
........
Merged revisions 410933 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change turns the bridge type field into a comma separated list of attributes.
These attributes include: mixing, holding, dtmf_events, and proxy_media. By setting
the various attributes a user can control the type of bridge created with the
behavior they need for their application.
(closes issue ASTERISK-23437)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3359/
........
Merged revisions 410904 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change enables DNS client support within PJSIP. System
nameservers are automatically discovered using res_init or
res_ninit. If this fails then PJSIP will resort to using
gethostbyname for resolution.
By enabling this support we gain SRV support, failover, and
weight support.
(closes issue ASTERISK-23435)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3343/
........
Merged revisions 410795 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Playing back a file to a channel in an ARI bridge would attempt to wait until
the playback concluded before returning. The method used involved signaling the
waiting thread in the ARI custom playback function.
The problem with this is that there were some corner cases that were not accounted for:
* If a bridge channel could not be found, then we never would attempt the playback but
would still attempt to wait for the playback to complete.
* If the bridge playfile action failed to queue, we would still attempt to wait for the
playback to complete.
* If the bridge playfile action were queued but some circumstance caused the playback
not to occur (the bridge dies, the channel is removed from the bridge), then we would
never be notified.
The solution to this is to move the waiting logic into the bridge code. A new bridge
API function is added to queue a synchronous action on a bridge. The waiting thread
is notified when the queued frame has been freed, either due to an error occurring
or due to successful playback. As a failsafe, the waiting thread has a 10 minute
timeout just in case there is a frame leak somewhere.
Review: https://reviewboard.asterisk.org/r/3338
........
Merged revisions 410673 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410684 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Events are sent to a connected ARI application based on the things that ARI
application cares about. These subscriptions can be set up implicitly - such
as when that ARI application creates a new object - or explicitly, via the
application resource's subscription operations. Debugging *why* something was
being sent to an application - or why something was not being sent to an
application - was a bit tricky, as there was no debug information for the
subscriptions.
This patch adds some debug level 3 statements that show the subscription counts
for applications. (Level 3 was chosen as it matches the verbose level 3
statements elsewhere)
........
Merged revisions 410650 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Realtime backends' update and store callbacks return the number of rows affected,
or -1 if there was a failure. There were a couple of issues:
* The config API was treating 0 as a successful return, and positive values as
a failure. Now the config API treats anything >= 0 as a success.
* res_sorcery_realtime was treating 0 as a successful return from the store
procedure, and any positive values as a failure. Now sorcery treats anything
> 0 as a success. It still considers 0 a "failure" since there is no change
to report to observers.
Review: https://reviewboard.asterisk.org/r/3341
........
Merged revisions 410592 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes an issue where a Stasis application running over ARI and
subscribed to ari/events could miss the ChannelEnteredBridge event
because it did not subscribe to the new bridge fast enough.
To accomplish this, it subscribes the application controlling the
channel to the new bridge before adding it to that bridge which
required the stasis_app_control structure to maintain a reference to
the stasis_app.
(closes issue ASTERISK-23295)
Review: https://reviewboard.asterisk.org/r/3336/
........
Merged revisions 410527 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made res_musiconhold.c always post the MusicOnHoldStart/MusicOnHoldStop
events when it actually starts/stops the music streams. This allows the
events to always happen when MOH starts/stops. The event posting code was
moved to the MOH alloc/release routines.
* Made channel_do_masquerade() stop any MOH on the original channel before
masquerading so the original channel will get a stop event with correct
information.
* Cleaned up a couple odd codings in moh_files_alloc() and moh_alloc()
dealing with the music state variable.
(issue ASTERISK-23311)
Reported by: Benjamin Keith Ford
Review: https://reviewboard.asterisk.org/r/3306/
........
Merged revisions 410493 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410494 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes a bug where the code which changes the transport did not check whether
the message is going out over UDP or not before changing it. For TCP and TLS transports
we don't need to change the transport as the correct one is already chosen.
........
Merged revisions 410471 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410472 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to how messages are handled within PJSIP it is not until a message is actually
sent that the destination is reliably known. This means that the addresses placed
within the message may not be of the interface the message is being sent out on.
This module determines what interface a message is being sent on and updates the
message to contain the correct address if applicable.
This module was tested by myself in a virtualized environment with multiple interfaces
and also by Kinsey Moore in the following configuration:
Networks:
* 10.24.16.0/21
** hard phone
** default gateway
* 10.24.64.0/21
** softphone with pjsip-based stack
Transport details:
bind address: 0.0.0.0
protocol: UDP
All endpoints were tested with explicitly configured transports and unconfigured transports.
This was tested with inbound and outbound calls, both of which were experiencing detrimental
effects from incorrect IP addresses in SIP messages. These effects were only experienced by the
soft phone on the 10.24.64.0 network since the messages to the hard phone on the 10.24.16.0
network had the correct IP address.
(closes issue ASTERISK-23020)
Reported by: xrobau
Review: https://reviewboard.asterisk.org/r/3102/
........
Merged revisions 410451 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Created the 'pjsip show channel' and 'pjsip show contact' commands.
Refactored out the hated ast_hashtab. Replaced with ao2_container.
Cleaned up function naming. Internal only, no public name changes.
Cleaned up whitespace and brace formatting in cli code.
Changed some NULL checking from "if"s to ast_asserts.
Fixed some register/unregister ordering to reduce deadlock potential.
Fixed ast_sip_location_add_contact where the 'name' buffer was too short.
Fixed some self-assignment issues in res_pjsip_outbound_registration.
(closes issue ASTERISK-23276)
Review: http://reviewboard.asterisk.org/r/3283/
........
Merged revisions 410287 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The one touch recording options have several see-also links between the
various configuration options. These were 'broken' by the snake casing
of those options. This patch corrects the see-also links such that they
reference the correct option names.
........
Merged revisions 410194 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410208 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to prevent confusion over the allow and disallow
list of codecs being the same an option for registering a
field as an alias is added. The alias field will be read
from the configuration file, but afterwards is not listed
as a known field. With disallow set as an alias, the CLI
command pjsip show endpoint # will list the allow= field,
but not the disallow field.
(closes issue ASTERISK-23092)
Review: https://reviewboard.asterisk.org/r/3193/
........
Merged revisions 410190 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410191 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I observed a crash in res_musiconhold on an Asterisk 11 system using realtime
MOH. Investigation of the backtrace showed a corrupt mohclass, implying that
it got destroyed before the code expected it to. I went looking for reference
counting errors that could have caused this crash and this patch this result.
It contains 2 changes.
1) Remove a usless block of code that was impossible to reach. There was even
a comment indicating that it was impossible to reach. The conditional includes
"!ast_test_flag(global_flags, MOH_CACHERTCLASSES)" and it's inside of an if
block with the opposite check "ast_test_flag(global_flags,
MOH_CACHERTCLASSES)". There's no good reason to keep it around.
2) A similar block to #1 contained a reference counting error. It stores
state->class in the local variable mohclass without increasing its reference
count. The reference count on mohclass is decremented at the end of the
function. This block of code probably very rarely runs, which would help
explain why this system was working fine for many months before experiencing a
crash.
Review: https://reviewboard.asterisk.org/r/3282/
........
Merged revisions 410043 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 410044 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 410090 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch creates the AST_SORCERY dialplan function which allows someone to
retrieve any value from a sorcery-based config file. It's similar to
AST_CONFIG.
The creation of the function itself was fairly straightforward but it required
changes to the underlying sorcery infrastructure that rippled into individual
sorcery objects. The changes stemmed from inconsistencies in how sorcery
created ast_variable objectsets from sorcery objects and the inconsistency
in how individual objects used that feature especially when it came to
parameters that can be specified multiple times like contact in aor and match
in identify. You can read more here...
http://lists.digium.com/pipermail/asterisk-dev/2014-February/065202.html
So, what this patch does, besides actually creating the AST_SORCERY function,
is the following...
* Creates ast_variable_list_append which is a helper to append one ast_variable
list to another.
* Modifies the ast_sorcery_object_field_register functions to accept the
already-defined sorcery_fields_handler callback.
* Modifies ast_sorcery_objectset_create to accept a parameter indicating return
type preference...a single ast_variable with all values concatenated or an
ast_variable list with multiple entries. Also fixed a few bugs.
* Modifies individual sorcery object implementations to use the new function
definition of the ast_sorcery_object_field_register functions.
* Modifies location.c and res_pjsip_endpoint_identifier_ip.c to implement
sorcery_fields_handler handlers so they return multiple occurrences as an
ast_variable_list.
* Added a whole bunch of tests to test_sorcery.
(closes issue ASTERISK-22537)
Review: http://reviewboard.asterisk.org/r/3254/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Transport TOS values were interpreted as DSCP values without being documented
as such. Endpoint TOS values (tos_audio/tos_video) behaved normally as TOS
values have historically. This patch makes the transport TOS values behave as
TOS values and makes all TOS values readable as string values (e.g. AF11).
In addition, alembic scripts have been updated to use the proper field types
for all TOS/COS values.
(issue ASTERISK-23235)
Reported by: George Joseph
Review: https://reviewboard.asterisk.org/r/3304/
........
Merged revisions 410028 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When acting as a T.38 fax gateway, res_fax_spandsp would at times cause a crash
in libspandsp. This would occur when, during fax tone detection, a ulaw/alaw
frame would be passed to modem_connect_tones_rx. That particular routine
expects the data to be in slin format. This patch looks at the frame type and,
if the data is ulaw/alaw, converts the format to slin before passing it to
modem_connect_tones_rx.
Review: https://reviewboard.asterisk.org/r/3296
(closes issue ASTERISK-20149)
Reported by: Alexandr Gordeev
Tested by: Michal Rybarik
patches:
spandsp_g711decode.diff uploaded by Michal Rybarik (license 6578)
........
Merged revisions 409990 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 409991 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409996 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Several fixes for the WebSockets implementation in res/res_http_websocket.c
* Flush the websocket session FILE* as fwrite() may not actually guarantee sending
the data to the network. If we do not flush, it seems that buffering on the SSL
socket for outbound messages causes issues
* Refactored ast_websocket_read to take into account that SSL file descriptors
may be ready to read via fread() but poll() will not actually say so because
the data was already read from the network buffers and is now in the libc buffers
(closes issue ASTERISK-23099)
(closes issue ASTERISK-21930)
Review: https://reviewboard.asterisk.org/r/3248/
........
Merged revisions 409681 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 409697 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r409129 | jrose | 2014-02-27 13:19:02 -0600 (Thu, 27 Feb 2014) | 15 lines
res_rtp_asterisk: Fix checklist creating problems in ICE sessions
Prior to this patch, local candidate lists including SRFLX would fail to start
properly when building ICE candidate check lists. This patch fixes that problem
by making sure that each SRFLX candidate is associated with the proper
base address so that the check list can create matches properly.
This patch was written by jcolp. The issue will be left open to await testing
by the issue participants.
(issue ASTERISK-23213)
Reported by: Andrea Suisani
Review: https://reviewboard.asterisk.org/r/3256/
........
r409130 | jrose | 2014-02-27 13:38:10 -0600 (Thu, 27 Feb 2014) | 8 lines
res_rtp_asterisk: correct build error from r409129
Accidentally placed a declaration below functional code
(issue ASTERISK-23213)
Reported by: Andrea Suisani
Review: https://reviewboard.asterisk.org/r/3256/
........
Merged revisions 409129-409130 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 409131 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The setting 'use_ptime' is supposed to tell Asterisk to honour the ptime
attribute in an offer, preferring it to whatever packetization
preferences have been set internally. Currently, however, something
rather quirky will happen:
(1) The SDP answer will be constructed in create_outgoing_sdp_stream.
This will use the preferences from the endpoint, such that the 200 OK
response will add the packetization preferences from the endpoint, and
not what was offered.
(2) When the 200 response is issued, apply_negotiated_sdp_stream is called.
This will call apply_packetization, which will use the ptime attribute
from the offer internally.
We end up telling the offerer to use the internal ptime attribute, but we end
up using the offered ptime attribute. Hilarity ensues.
This patch modifies the behaviour by calling apply_packetization from
negotiate_incoming_sdp_stream, which is called prior to
create_outgoing_sdp_stream. This causes the format preferences on the
session's media object to be set to the inbound ptime value (if 'use_ptime'
is enabled), such that the construction of the answer gets the right value
immediately.
Review: https://reviewboard.asterisk.org/r/3244/
........
Merged revisions 408999 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409000 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is currently possible for an ast_sip_session to exist without an
associated channel as is the case when a new invite is coming in or
just after a hangup is issued on a chan_pjsip channel. Part of the
attended transfer code assumed the channel would be non-NULL and used
it as such causing a crash. This bug was exposed thanks to the attended
transfer ARI test in the test suite.
(closes issue ASTERISK-23287)
Reported by: Matt Jordan
........
Merged revisions 408941 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the ability for transferring directly to voicemail on digium phones.
Added a new module that checks for the presence of a custom header and/or
diversion header within a sip REFER. If either is found and they specify
a sending to voicemail action then variables are added to the channel
allowing the user access to them in the dialplan. Dialplan can then be
written that branches based upon these values allowing, for instace, for
a single number to be used for dialing and/or accessing voicemail directly.
Also fixed a problem where the PJSIP_HEADER function was allowing non pjsip
channels through (checked to make sure it has the correct channel type before
proceeding).
Review: https://reviewboard.asterisk.org/r/3245/
........
Merged revisions 408880 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed off-nominal json ref counting issue with using the following API
calls: ast_json_object_set() and ast_json_array_append().
* Fixed off-nominal error reporting in ast_ari_endpoints_list().
* Fixed some miscellaneous off-nominal json ref counting issues in
report_receive_fax_status() and dial_to_json().
........
Merged revisions 408713 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408714 65c4cc65-6c06-0410-ace0-fbb531ad65f3