When channel format changes occurred as a result of an RTP
re-negotiation the bridge was not informed this had happened.
As a result the bridge technology was not re-evaluated and the
channel may have been in a bridge technology that was incompatible
with its formats. The bridge is now unbridged and the technology
re-evaluated when this occurs.
The chan_pjsip module also allowed asymmetric codecs for sending
and receiving. This did not work with all devices and caused one
way audio problems. The default has been changed to NOT do this
but to match the sending codec to the receiving codec. For users
who want asymmetric codecs an option has been added, asymmetric_rtp_codec,
which will return chan_pjsip to the previous behavior.
The codecs returned by the chan_pjsip module when queried by
the bridge_native_rtp module were also not reflective of the
actual negotiated codecs. The nativeformats are now returned as
they reflect the actual negotiated codecs.
ASTERISK-26423 #close
Change-Id: I6ec88c6e3912f52c334f1a26983ccb8f267020dc
This change adds support for dual stack automatically. No
configuration is required and the IP address and version
in the SIP messages and SDP will be automatically changed
based on the transport over which the message is being
sent. RTP usage has also been changed to listen on both
IPv4 and IPv6 simultaneously to allow media to flow, and
to allow ICE support on both simultaneously. This also
allows failover between IPv6 and IPv4 to work as expected.
ASTERISK-26309 #close
Change-Id: I235a421d8f9a326606d861b449fa6fe3a030572d
This implements the chan_sip legacy_useroption_parsing option but with a
better name.
* Made the caller-id number and redirecting number strings obtained from
incoming SIP URI user fields always truncated at the first semicolon.
People don't care about anything after the semicolon showing up on their
displays even though the RFC allows the semicolon.
ASTERISK-26316 #close
Reported by: Kevin Harwell
Change-Id: Ib42b0e940dd34d84c7b14bc2e90d1ba392624f62
The code was incorrectly invoking the unidentified logic when
an endpoint had actually been identified, causing log messages
to be output.
ASTERISK-26349 #close
Change-Id: Id8104fc9e3d138d5e8b6f6977ecc08765fd17d4f
The endpoint identification PJSIP module is intended to identify which
endpoint an incoming request is from. If an endpoint is not identified,
then an artificial endpoint is used in its place when proceeding.
The problem is that the ACK request type is an exception to the rule.
The artificial endpoint is not used when processing an ACK. This results
in the possibility of having a NULL endpoint being used further on.
The reason ACK is an exception is an attempt not to spam security logs
with unidentified requests. Presumably, you've already logged the
unidentified request on the preceeding INVITE.
Up until Asterisk 13.10, retrieving a NULL endpoint in this fashion
didn't cause an issue. A new change in 13.10 added endpoint ACL checking
shortly after endpoint identification. Because we are accessing a NULL
endpoint, this ACL check resulted in a crash.
The fix here is to be sure to retrieve the artificial endpoint for all
request types. ACKs still do not generate unidentified request security
events.
ASTERISK-26264 #close
Reported by nappsoft
AST-2016-006
Change-Id: Ie0c795ae2d72273decb972dd74b6a1489fb6b703
Currently when you add global headers from the dialplan both
the header in the dialplan and the globally configured header
are added to the resulting SIP INVITE. This change makes it
so the headers in the dialplan take precedence and are the
only ones added.
Change-Id: I36f864298f38db3632ad503edc11267cb8ffb3ad
If the PJSIP endpoint's AOR with the permanent contact
was deleted from the realtime storage the res_pjsip module
continues trying to qualify this contact.
The error 'Unable to find an endpoint to qualify contact'
appeares every 'qualify_frequency' seconds.
This patch deletes this contact in this case.
The PJSIP endpoint's AOR with the permanent contact
is never qualified if it is added to realtime storage
after asterisk started.
This patch adds qualifying for the AOR's permanent contacts
on the first handling of this AOR.
ASTERISK-26319 #close
Change-Id: Ib93dded9121edb113076903d1aa95402f799f8fe
We may check a global config option hundreds of times a second or more.
Asking sorcery for the global configuration from the config files backend
involves several allocations and container traversals. Using realtime
without a memory cache is a lot worse because you have to lookup in the
realtime database each time to reconstitute the sorcery object. With a
memory cache for realtime, there is about the same amount of overhead as
for config files. Either way, it is still fairly expensive to access the
sorcery object that much.
* Cache the global config options so we can access them faster. You must
now always perform a res_pjsip reload to change the global options.
Change-Id: Ice16c7a4cbca4614da344aaea21a072b86263ef7
A recent change attempted to optimize startup by not updating contact
status. Instead, code responsible for qualifying contacts updates the
status as it becomes known. The code even accounts for contacts/AORs
that are not set to be qualified.
The problem, though, is when there are no contacts associated with an
endpoint. A common case is when an endpoint is set to register its
contacts but has not done so yet. In this case, prior to registration,
the endpoint's device state will appear to be "not in use" and hints
associated with that device will appear to be "idle". In actuality, the
device state and hint should both appear as "unavailable". The reason
for the failure is that the optimization change made all persistent
endpoint states set to "unknown".
The fix here is to change the hard-coded "unknown" to be "offline"
instead. The default state will be offline until the qualifying code
determines that the contact is actually online. This way, if there are
no contacts at all, then the state stays as offline, and device state
and hints appear correctly.
ASTERISK-26269 #close
Reported by nappsoft
Change-Id: Ie99b84169393983453076f5e9c0d35ff313a456a
The compilation failed for devmode
--enable DONT_OPTIMIZE
--enable BETTER_BACKTRACES
--enable DO_CRASH
--enable TEST_FRAMEWORK
res_pjsip/pjsip_configuration.c: In function dtls_handler:
res_pjsip/pjsip_configuration.c:974:20: error:
back may be used uninitialized in this function [-Werror=maybe-uninitialized]
int size = strlen(front);
^
cc1: all warnings being treated as errors
Change-Id: I7f082ead0312792a577ec7c73015ba64dabca580
contact_user, when specified on an endpoint, will override the user
portion of the Contact header on outgoing requests.
Change-Id: Icd4ebfda2f2e44d3ac749d0b4066630e988407d4
If debug was specified in the global configuration but left blank,
the logger would treat it as a wildcard and log all hosts. If
default_from_user was empty, a crash would result.
The global apply handler now checks for empty strings.
ASTERISK-26239 #close
ASTERISK-26238 #close
Change-Id: Ie75727f5cd5808845d92cc81f5713842fb203336
* Eliminated RAII_VAR() usage in
ast_sip_persistent_endpoint_update_state().
* Added a missing allocation failure check to
persistent_endpoint_find_or_create().
* Made persistent_endpoint_find_or_create() create the new object without
a lock as it isn't needed.
* Cleaned up some ao2 container allocation idioms.
* Reordered res_pjsip_mwi.c load_module() and unload_module()
Change-Id: If8ce88fbd82a0c72a37a2388f74f77237a6a36a8
* Eliminated most RAII_VAR() usage.
* Added several missing allocation failure checks.
* Made ast_sip_for_each_contact() allocate the wrapper ao2 object without
a lock as it is not needed.
Change-Id: Ie20913365156c95dd79e5d471cfd25e99ae880bc
The named aor lock was always being locked for writes so a rwlock adds no
benefit and may be slower because rwlocks are biased toward read locking.
Change-Id: I8c5c2c780eb30ce5441832257beeb3506fd12b28
The PJSIP taskprocessors could be overflowed on startup
if there are many (thousands) realtime endpoints
configured with unsolicited mwi.
The PJSIP stack could be totally unresponsive for a few minutes
after boot completed.
This patch creates a separate PJSIP serializers pool for mwi
and makes unsolicited mwi use serializers from this pool.
This patch also adds 2 new global options to tune taskprocessor
alert levels: 'mwi_tps_queue_high' and 'mwi_tps_queue_low'.
This patch also adds new global option 'mwi_disable_initial_unsolicited'
to disable sending unsolicited mwi to all endpoints on startup.
If disabled then unsolicited mwi will start processing
on next endpoint's contact update.
ASTERISK-26230 #close
Change-Id: I4c8ecb82c249eb887930980a800c9f87f28f861a
The new endpoint option allows the PJSIP channel driver's fax_detect
endpoint option to timeout on a call after the specified number of
seconds into a call. The new feature is disabled if the timeout is set
to zero. The option is disabled by default.
ASTERISK-26214
Reported by: Richard Mudgett
Change-Id: Id5a87375fb2c4f9dc1d4b44c78ec8735ba65453d
aor_observer_deleted() needs to operate on all contacts found for the
deleted AOR instead of only the first one found. This is really only a
problem if there is more than one contact for the AOR.
Change-Id: Id24ac0d5e8c931330231fb45dd2a331a84339dc1
* Fix some whitespace in various routines.
* Rename i to iter in persistent_endpoint_update_state().
* Fix off-nominal copy/paste message wording in
persistent_endpoint_contact_deleted_observer()
Change-Id: Id8e34f5d09e7eebac3af22501c44c1110a3e29d8
The ASTERISK-25904 change-id I8fad8aae9305481469c38d2146e1ba3a56d3108f
patch introduced several regressions when the newly created "Updated"
state goes out for each endpoint registration refresh.
1) It restarted any OPTIONS RTT ping cycle.
2) It would interfere with a currently active ping and throw off that
ping's resulting RTT calculation.
3) It cleared the RTT time each time the endpoint was refreshed.
4) The cleared RTT time was sent out as a statsd update each time.
5) It created two AMI events for each update.
* Revert the original patch and reimplement it. Now the current contact
status state is re-sent instead of the state being momentarily toggled
every time the endpoint refreshes its registration. The statsd events are
not created for the re-sent refresh because they are sent after every
OPTIONS ping.
ASTERISK-26160 #close
Reported by: Matt Jordan
Change-Id: Ie072be790fbb2a8f5c1c874266e4143fa31f66d1
When using TCP transport with chan_pjsip, the TCP_NODELAY
option value was allocated on the stack, then passed as a
pointer to the tcp transport configuration structure, and
later re-used on subsequently created sockets when it was
no longer valid. This patch changes the allocation to be
a static.
ASTERISK-26180 #close
Reported by: Scott Griepentrog
Change-Id: I3251164c7f710dbdab031282f00e30a9770626a0
If specified, incoming SUBSCRIBE requests will be searched for the matching
extension in the indicated context. If no "subscribe_context" is specified,
then the "context" setting is used.
ASTERISK-25471 #close
Change-Id: I3fb7a15f5bc154079bd348c08b7ad1cdd2d5e514
A non-existent constraint was being referenced in the upgrade script.
This patch corrects the problem by removing the reference.
This patch fixes another realtime problem as well. Our Alembic scripts
store booleans as yes or no values. However, Sorcery tries to insert
"true" or "false" instead. This patch updates Sorcery to use "yes" and
"no"
ASTERISK-26128 #close
Change-Id: I366dbbf91418a9cb160b3ca74b0e59b5ac284bec
The patch removes updating all Endpoints' status on startup.
Instead, only non-qualified aors with static contact
and non-qualified non-expired contacts are retrieved from the realtime to
update the endpoint status to ONLINE.
The endpoint name was added to the contact object to simply find the endpoint
that created this contact.
The status of endpoints with qualified aors will be updated by 'qualify'
functions.
ASTERISK-26061 #close
Change-Id: Id324c1776fa55d3741e0c5457ecac0304cb1a0df
Sorcery creates taskprocessors for object types to process object observer
callbacks. An API call is needed to be able to set the congestion levels
of these taskprocessors for selected object types.
* Updated PJSIP's contact and contact_status sorcery object type observer
default congestion levels based upon stress testing. Increased the
congestion levels to reduce the potential for bursty register/unregister
and subscribe/unsubscribe activity from triggering the taskprocessor
overload alert.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I4542e83b556f0714009bfeff89505c801f1218c6
When taskprocessors get backed up, there is a good chance that we are
being overloaded and need to defer adding new work to the system.
* Implemented a high/low water alert mechanism for modules to check if the
system is being overloaded and take appropriate action. When a
taskprocessor is created it has default congestion levels set. A
taskprocessor can later have those congestion levels altered for specific
needs if stress testing shows that the taskprocessor is a symptom of
overloading or needs to handle bursty activity without triggering an
overload alert.
* Add CLI "core show taskprocessor" low/high water columns.
* Fixed __allocate_taskprocessor() to not use RAII_VAR(). RAII_VAR() was
never a good thing to use when creating a taskprocessor because of the
nature of how its references needed to be cleaned up on a partial
creation.
* Made res_pjsip's distributor check if the taskprocessor overload alert
is active before placing a message representing brand new work onto a
distributor serializer.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I182f1be603529cd665958661c4c05ff9901825fa
Incoming messages that are not part of a dialog or a recognized response
to one of our requests need to be sent to a consistent serializer. Under
load we may be queueing retransmissions before we can process the original
message. We don't need to throw these messages onto random serializers
and cause reentrancy and message sequencing problems.
* Created a pool of pjsip/distributor serializers that get picked by
hashing the call-id and remote tag strings of the received messages.
* Made ast_sip_destroy_distributor() destroy items in the reverse order of
creation.
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I2ce769389fc060d9f379977f559026fbcb632407
We should not be processing any incoming messages until we are fully
booted. We may not have dialplan or other needed configuration loaded
yet.
ASTERISK-26089 #close
Reported by: Scott Griepentrog
ASTERISK-26088
Reported by: Richard Mudgett
Change-Id: I584aefb4f34b885a8927e1f13a2c64babd606264
The pjproject doxygen for rdata->msg_info.info says to call
pjsip_rx_data_get_info() instead of accessing the struct member directly.
You need to call the function mostly because the function will generate
the struct member value if it is not already setup.
Change-Id: I4d519385a577f3e9d9193a88125e493cf17fa799
The pjproject doxygen for rdata->msg_info.info says to call
pjsip_rx_data_get_info() instead of accessing the struct member directly.
You need to call the function mostly because the function will generate
the struct member value if it is not already setup.
Change-Id: Iafe8b01242b7deb0ebfdc36685e21374a43936d2
As res_pjsip_nat rewrites contact's address, only the last Via header
can contain the source address of registered endpoint.
Also Call-Id header may contain the source address of registered
endpoint.
Added "via_addr", "via_port", "call_id" to contact.
Added new fields ViaAddress, CallID to AMI event ContactStatus.
ASTERISK-26011
Change-Id: I36bcc0bf422b3e0623680152d80486aeafe4c576
There are a lot of verbose messages about Endpoint and Contact status
changes if there are many dynamic endpoints.
The patch sets verbose level 2 for Endpoint status changes
and verbose level 3 for Contact status changes.
ASTERISK-26055 #close
Change-Id: Ie64e261ddbbc41bfff0f0190241152cc123fe6d7
When receiving an incoming response to a dialog-starting INVITE, we were
not matching the response to the INVITE dialog. Since we had not
recorded the to-tag to the dialog structure, the PJSIP-provided method
to find the dialog did not match.
Most of the time, this was not a problem, because there is a fall-back
that makes the response get routed to the same serializer that the
request was sent on. However, in cases where an asynchronous DNS lookup
occurs in the PJSIP core, the thread that sends the INVITE is not
actually a threadpool serializer thread. This means we are unable to
record a serializer to handle the incoming response.
Now, imagine what happens when an INVITE is sent on a non-serialized
thread, and an error response (such as a 486) arrives. The 486 ends up
getting put on some random threadpool thread. Eventually, a hangup task
gets queued on the INVITE dialog serializer. Since the 486 is being
handled on a different thread, the hangup task can execute at the same
time that the 486 is being handled. The hangup task assumes that it is
the sole owner of the INVITE session and channel, so it ends up
potentially freeing the channel and NULLing the session's channel
pointer. The thread handling the 486 can crash as a result.
This change has the incoming response match the INVITE transaction, and
then get the dialog from that transaction. It's the same method we had
been using for matching incoming CANCEL requests. By doing this, we get
the INVITE dialog and can ensure that the 486 response ends up being
handled by the same thread as the hangup, ensuring that the hangup runs
after the 486 has been completely handled.
ASTERISK-25941 #close
Reported by Javier Riveros
Change-Id: I0d4cc5d07e2a8d03e9db704d34bdef2ba60794a0
