* Added Useragent and RegExpire headers to AMI Event
ContactStatusDetail with associated documentation.
ASTERISK-25903 #close
Change-Id: If3d121e943e588d016ba51d4eb9c6a421a562239
Contact expiration can occur in several places: res_pjsip_registrar,
res_pjsip_registrar_expire, and automatically when anyone calls
ast_sip_location_retrieve_aor_contact. At the same time, res_pjsip_registrar
may also be attempting to renew or add a contact. Since none of this was locked
it was possible for one thread to be renewing a contact and another thread to
expire it immediately because it was working off of stale data. This was the
casue of intermittent registration/inbound/nominal/multiple_contacts test
failures.
Now, the new named lock functionality is used to lock the aor during contact
expire and add operations and res_pjsip_registrar_expire now checks the
expiration with the lock held before deleting the contact.
ASTERISK-25885 #close
Reported-by: Josh Colp
Change-Id: I83d413c46a47796f3ab052ca3b349f21cca47059
The first available transport of the appropriate type is used now.
This patch adds new config option 'transport' for outbound-publish.
If transport is set then outbound PUBLISH requests will use this transport.
ASTERISK-25901 #close
Change-Id: Ib389130489b70e36795b0003fa5fd386e2680151
BLF pickup isn't working on Cisco SPA and Snom phones
if the direction="recipient" attribute is missing in 'dialog' tag.
This patch adds direction="recipient" if extension state is
Ringing.
ASTERISK-24601 #close
Change-Id: I5b2c097ca29fd59e92ba237ca5d397cb1b0bcd8c
When shutting down, the PJSIP sorcery is destroyed. The registrar
expiration module queries the PJSIP sorcery to determine what
to expire. As there was no synchronization between termination
of the expiration thread and the unloading of the module it was
possible for the thread to try to access the PJSIP sorcery after
it had been destroyed.
This change ensures that the thread is shut down before allowing
the module to be considered unloaded.
Change-Id: I69fd239edbaaf160c2d37ae00d3ac06e5596fe8b
Some SIP devices indicate hold/unhold using deferred SDP reinvites. In
other words, they provide no SDP in the reinvite.
A typical transaction that starts hold might look something like this:
* Device sends reinvite with no SDP
* Asterisk sends 200 OK with SDP indicating sendrecv on streams.
* Device sends ACK with SDP indicating sendonly on streams.
At this point, PJMedia's SDP negotiator saves Asterisk's local state as
being recvonly.
Now, when the device attempts to unhold, it again uses a deferred SDP
reinvite, so we end up doing the following:
* Device sends reinvite with no SDP
* Asterisk sends 200 OK with SDP indicating recvonly on streams
* Device sends ACK with SDP indicating sendonly on streams
The problem here is that Asterisk offered recvonly, and by RFC 3264's
rules, if an offer is recvonly, the answer has to be sendonly. The
result is that the device is not taken off hold.
What is supposed to happen is that Asterisk should indicate sendrecv in
the 200 OK that it sends. This way, the device has the freedom to
indicate sendrecv if it wants the stream taken off hold, or it can
continue to respond with sendonly if the purpose of the reinvite was
something else (like a session timer refresher).
The fix here is to alter the SDP negotiator's state when we receive a
reinvite with no SDP. If the negotiator's state is currently in the
recvonly or inactive state, then we alter our local state to be
sendrecv. This way, we allow the device to indicate the stream state as
desired.
ASTERISK-25854 #close
Reported by Robert McGilvray
Change-Id: I7615737276165eef3a593038413d936247dcc6ed
I forgot the new voicemail_extension wasn't a stringfield and didn't check
for NULL where I should have.
Change-Id: I029482d5c2ab72474838750461bd46b0809c90fb
The only caller of ari_bridges_play_found() has this note:
If ari_bridges_play_found fails because the channel is unavailable for
playback, The channel will be removed from the playback list soon. We can
keep trying to get channels from the list until we either get one that
will work or else there isn't a channel for this bridge anymore, in which
case we'll revert to ari_bridges_play_new.
Change-Id: Ib068141b367ccaa17be0dab4181c98e26c5127d6
The stasis_app_playback and stasis_app_recording structs need to have a
struct stasis_app_control ref. Other threads can get a reference to the
playback and recording structs from their respective global container.
These other threads can then use the control pointer they contain after
the control struct has gone.
* Add control ref to stasis_app_playback and stasis_app_recording structs.
With the refs added, the control command queue can now have a circular
control reference which will cause the control struct to never get
released if the control's command queue is not flushed when the channel
leaves the Stasis application. Also the command queue needs better
protection from adding commands if the control->is_done flag is set.
* Flush the control command queue on exit.
ASTERISK-25882 #close
Change-Id: I3cf1fb59cbe6f50f20d9e35a2c07ac07d7f4320d
* Give the struct stasis_app_control ao2 object a ref to the channel held
in the object. Now the channel will still be around if a thread needs to
post a stasis message instead of crash because the topic was destroyed.
* Moved stopping any lingering silence generator out of the struct
stasis_app_control destructor and made it a part of exiting the Stasis
application. Who knows which thread the destructor will be called under
so it cannot affect the channel's silence generator. Not only was the
channel unprotected when the silence generator was stopped, stasis may no
longer even control the channel.
ASTERISK-25882
Change-Id: I21728161b5fe638cef7976fa36a605043a7497e4
Background:
If your extension is 1000 and the voicemail access extension is 1571 and you
dial 1571, usually a dialplan rule calls voicemailmain with your extension and
you are placed directly in your mailbox. Therefore most admins program the
voicemail (or other speed dial) button on their phones to the access extension.
Some phones (Snom at least) use whatever is programmed there to also subscribe
for MWI and so can't dial one number and subscribe to another. This works fine
in chan_sip because chan_sip completely ignores the user portion of the
SUBSCRIBE message request URI. If it can match the peer, is subscribes to the
peer's mailbox. The user could be set to anything or nothing and you'd still
get subscribed to your mailbox.
Issue:
chan_pjsip actually uses the user portion of the URI to find an aor and its
mailboxes. Therefore a subscribe to 1571 results in a 404. Sure, you can
create an aor for 1571 but you certainly can't add your entire voicemail
system's mailboxes to it and everyone would get notified of every MWI.
Solution:
When an MWI subscribe comes in and an aor can't be found that matches the
resource directly, check the resource against the endpoint's aors. If an aor
is found that has a voicemail_extension that matches the resource, use it.
ASTERISK-25865
Reported-by: Ross Beer
Change-Id: I770ea185f751f1ada888fafb4b452115f1c06e9e
res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds
the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes
on endpoints for unsolicited mwi and on aors for subscriptions required
that the admin know in advance which the client wanted. If you specified
mailboxes on the endpoint, subscriptions were rejected even if you also
specified mailboxes on the aor.
Voicemail extension:
* Added a global default_voicemail_extension which defaults to "".
* Added voicemail_extension to both endpoint and aor.
* Added ast_sip_subscription_get_dialog for support.
* Added ast_sip_subscription_get_sip_uri for support.
When an unsolicited NOTIFY is constructed, the From header is parsed, the
voicemail extension from the endpoint is substituted for the user, and the
result placed in the Message-Account field in the body.
When a subscribed NOTIFY is constructed, the subscription dialog local uri
is parsed, the voicemail_extension from the aor (looked up from the
subscription resource name) is substituted for the user, and the result
placed in the Message-Account field in the body.
If no voicemail extension was defined, the Message-Account field is not added
to the NOTIFY body.
mwi_subscribe_replaces_unsolicited:
* Added mwi_subscribe_replaces_unsolicited to endpoint.
The previous behavior was to reject a subscribe if a previous internal
subscription for unsolicited MWI was found for the mailbox. That remains the
default. However, if there are mailboxes also set on the aor and the client
subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal
subscription is removed and replaced with the external subscription. This
allows an admin to configure mailboxes on both the endpoint and aor and allows
the client to select which to use.
ASTERISK-25865 #close
Reported-by: Ross Beer
Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
Commit 1bce690ccb was incrementing txcount
for rtcp packets as well as rtp packets and that was causing sender reports
to be generated instead of receiver reports in cases where no rtp was actually
being sent.
Moved the txcount increment from __rtp_sento, which handles both rtp and rtcp,
to rtp_sento which only handles rtp packets.
Discovered by the hep/rtcp-receiver test.
Change-Id: Ie442e4bb947a68847a676497021ba10ffaf376d5
Added the ability to show channel statistics to chan_pjsip (cli_functions.c)
Moved the existing 'pjsip show channel(s)' functionality from
pjsip_configuration to cli_functions.c. The stats needed chan_pjsip's
private header so it made sense to move the existing channel commands as well.
Now using stasis_cache_dump to get the channel snapshots rather than retrieving
all endpoints, then getting each one's channel snapshots. Much more efficient.
Change-Id: I03b114522126d27434030b285bf6d531ddd79869
No one seemed to notice but every time an OPTIONS goes out, it goes
out with a From of "asterisk" (or whatever the default from_user is set to),
even if you specify an endpoint.
The issue had several causes...
qualify_contact is only called with an endpoint if called from the CLI.
If the endpoint is NULL, qualify_contact only looks up the endpoint if
authenticate_qualify=yes. Even then, it never passes it on to
ast_sip_create_request where the From header is set. Therefore From
is always "asterisk" (or whatever the default from_user is set to).
Even if ast_sip_create_request were to get an endpoint, it only sets
the From if endpoint->from_user is set.
The fix is 4 parts...
First, create_out_of_dialog_request was modified to use the endpoint id
if endpoint was specified and from_user is not set.
Second, qualify_contact was modified to always look up an endpoint if
one wasn't specified regardless of authenticate_qualify. It then passes
the endpoint on to create_out_of_dialog_request.
Third (and most importantly), find_an_endpoint was modified to find
an endpoint by using an "aors LIKE %contact->aor%" predicate with
ast_sorcery_retrieve_by_fields. As such, this patch will only work
if the sorcery realtime optimizations patch goes in. Otherwise we'd
be pulling the entire endpoints database every time we send an OPTIONS.
Since we already know the contact's aor, the on_endpoint callback was also
modified to just check if the contact->aor is an exact match to one of
the endpoint's.
Finally, since we now have an endpoint for every OPTIONS request,
res_pjsip/endpt_send_request (which handles out-of-dialog reqests) was
updated to get the transport from the endpoint and set it on tdata.
Now the correct transport is used.
Change-Id: I2207e12bb435e373bd1e03ad091d82e5aba011af
Asterisk uses separate UDP ports for RTP and RTCP traffic and RFC 5764
explicitly states:
There MUST be a separate DTLS-SRTP session for each distinct pair of
source and destination ports used by a media session
This means RTP keying material cannot be used for DTLS RTCP, which was
the reason why RTCP encryption would fail.
ASTERISK-25642
Change-Id: I7e8779d8b63e371088081bb113131361b2847e3a
rxcount, txcount, rxoctetcount and txoctetcount weren't being calculated
for bridged streams because the calulations were being done after the
bridged short-circuit. Actually, rxoctetcount wasn't ever being calculated.
Moved the calculations so they occur for all valid received packets and
all transmitted packets. Also added rxoctetcount and txoctetcount to
ast_rtp_instance_stat.
Change-Id: I08fb06011a82d38c3b4068867a615068fbe59cbb
Blind transfers to a recognized parking extension need to use the parker's
channel variable values to create the dynamic parking lot. This is
because there is always only one parker while the parkee may actually be a
multi-party bridge. A multi-party bridge can never supply the needed
channel variables to create the dynamic parking lot. In the multi-party
bridge blind transfer scenario, the parker's CHANNEL(parkinglot) value and
channel variables are inherited by the local channel used to park the
bridge.
* In park_common_setup(), make use the parker instead of the parkee to
supply the dynamic parking lot channel variable values. In all but one
case, the parkee is the same as the parker. However, in the recognized
parking extension blind transfer scenario for a two party bridge they are
different channels. For consistency, we need to use the parker channel.
* In park_local_transfer(), pass the CHANNEL(parkinglot) value to the
local channel when blind transferring a multi-party bridge to a recognized
parking extension.
* When a local channel starts a call, the Local;2 side needs to inherit
the CHANNEL(parkinglot) value from Local;1.
The DTMF one-touch parking case wasn't even trying to create dynamic
parking lots before it aborted the attempt.
* In parking_park_call(), add missing code to create a dynamic parking
lot.
A DTMF bridge hook is documented as returning -1 to remove the hook.
Though the hook caller is really coded to accept non-zero. See the
ast_bridge_hook_callback typedef.
* In feature_park_call(), don't remove the DTMF one-touch parking hook
because of an error.
ASTERISK-24605 #close
Reported by: Philip Correia
Patches:
call_park.patch (license #6672) patch uploaded by Philip Correia
Change-Id: I221d3a8fcc181877a1158d17004474d35d8016c9
There were a number of places in the res_pjsip stack that were getting
all endpoints or all aors, and then filtering them locally.
A good example is pjsip_options which, on startup, retrieves all
endpoints, then the aors for those endpoints, then tests the aors to see
if the qualify_frequency is > 0. One issue was that it never did
anything with the endpoints other than retrieve the aors so we probably
could have skipped a step and just retrieved all aors. But nevermind.
This worked reasonably well with local config files but with a realtime
backend and thousands of objects, this was a nightmare. The issue
really boiled down to the fact that while realtime supports predicates
that are passed to the database engine, the non-realtime sorcery
backends didn't.
They do now.
The realtime engines have a scheme for doing simple comparisons. They
take in an ast_variable (or list) for matching, and the name of each
variable can contain an operator. For instance, a name of
"qualify_frequency >" and a value of "0" would create a SQL predicate
that looks like "where qualify_frequency > '0'". If there's no operator
after the name, the engines add an '=' so a simple name of
"qualify_frequency" and a value of "10" would return exact matches.
The non-realtime backends decide whether to include an object in a
result set by calling ast_sorcery_changeset_create on every object in
the internal container. However, ast_sorcery_changeset_create only does
exact string matches though so a name of "qualify_frequency >" and a
value of "0" returns nothing because the literal "qualify_frequency >"
doesn't match any name in the objset set.
So, the real task was to create a generic string matcher that can take a
left value, operator and a right value and perform the match. To that
end, strings.c has a new ast_strings_match(left, operator, right)
function. Left and right are the strings to operate on and the operator
can be a string containing any of the following: = (or NULL or ""), !=,
>, >=, <, <=, like or regex. If the operator is like or regex, the
right string should be a %-pattern or a regex expression. If both left
and right can be converted to float, then a numeric comparison is
performed, otherwise a string comparison is performed.
To use this new function on ast_variables, 2 new functions were added to
config.c. One that compares 2 ast_variables, and one that compares 2
ast_variable lists. The former is useful when you want to compare 2
ast_variables that happen to be in a list but don't want to traverse the
list. The latter will traverse the right list and return true if all
the variables in it match the left list.
Now, the backends' fields_cmp functions call ast_variable_lists_match
instead of ast_sorcery_changeset_create and they can now process the
same syntax as the realtime engines. The realtime backend just passes
the variable list unaltered to the engine. The only gotcha is that
there's no common realtime engine support for regex so that's been noted
in the api docs for ast_sorcery_retrieve_by_fields.
Only one more change to sorcery was done... A new config flag
"allow_unqualified_fetch" was added to reg_sorcery_realtime.
"no": ignore fetches if no predicate fields were supplied.
"error": same as no but emit an error. (good for testing)
"yes": allow (the default);
"warn": allow but emit a warning. (good for testing)
Now on to res_pjsip...
pjsip_options was modified to retrieve aors with qualify_frequency > 0
rather than all endpoints then all aors. Not only was this a big
improvement in realtime retrieval but even for config files there's an
improvement because we're not going through endpoints anymore.
res_pjsip_mwi was modified to retieve only endpoints with something in
the mailboxes field instead of all endpoints then testing mailboxes.
res_pjsip_registrar_expire was completely refactored. It was retrieving
all contacts then setting up scheduler entries to check for expiration.
Now, it's a single thread (like keepalive) that periodically retrieves
only contacts whose expiration time is < now and deletes them. A new
contact_expiration_check_interval was added to global with a default of
30 seconds.
Ross Beer reports that with this patch, his Asterisk startup time dropped
from around an hour to under 30 seconds.
There are still objects that can't be filtered at the database like
identifies, transports, and registrations. These are not going to be
anywhere near as numerous as endpoints, aors, auths, contacts however.
Back to allow_unqualified_fetch. If this is set to yes and you have a
very large number of objects in the database, the pjsip CLI commands
will attempt to retrive ALL of them if not qualified with a LIKE.
Worse, if you type "pjsip show endpoint <tab>" guess what's going to
happen? :) Having a cache helps but all the objects will have to be
retrieved at least once to fill the cache. Setting
allow_unqualified_fetch=no prevents the mass retrieve and should be used
on endpoints, auths, aors, and contacts. It should NOT be used for
identifies, registrations and transports since these MUST be
retrieved in bulk.
Example sorcery.conf:
[res_pjsip]
endpoint=config,pjsip.conf,criteria=type=endpoint
endpoint=realtime,ps_endpoints,allow_unqualified_fetch=error
ASTERISK-25826 #close
Reported-by: Ross Beer
Tested-by: Ross Beer
Change-Id: Id2691e447db90892890036e663aaf907b2dc1c67
res/parking/parking_applications.c:
* Add malloc fail checks in setup_park_common_datastore().
* Fix playing parking failed announcement to only happen on non-blind
transfers in park_app_exec(). It could never go out before because a test
was provedly always false.
res/parking/parking_bridge.c:
* Fix NULL tolerance in generate_parked_user() because
bridge_parking_push() can theoretically pass a NULL parker channel if the
parker channel went away for some reason.
* Clarify some weird code dealing with blind_transfer in
bridge_parking_push().
res/parking/parking_bridge_features.c:
* Made park_local_transfer() set BLINDTRANSFER on the Local;1 channel
which will be bulk copied to the Local;2 channel on the subsequent
ast_call(). The additional advantage is if the parker channel has the
BLINDTRANSFER and ATTENDEDTRANSFER variables set they are now guaranteed
to be overridden.
res/parking/parking_manager.c:
* Fix AMI Park action input range checking of the Timeout header in
manager_park().
* Reduced locking scope to where needed in manager_park().
res/res_parking.c:
* Fix some off nominal missing unlocks by eliminating the returns.
Change-Id: Ib64945bc285acb05a306dc12e6f16854898915ca
The configuration unsigned integer option handler sets flags for the
parser as if the option should be a signed integer (PARSE_INT32),
leading to errors on "out of range" values. Fix flags (PARSE_UINT32).
A fix to res_pjsip is also present which stops invalid flags from
being passed when registering sorcery object fields for qualify
status.
ASTERISK-25612 #close
Change-Id: I96b539336275e0e72a8e8033487d2c3344debd3e
The log message when a MusicOnHold music class was not found was changed
from debug level to WARNING level in Asterisk 11.19 and 13.5. For those
using realtime musiconhold, this message is wrong because it warns
before checking the database.
This changeset delays the warning until after the database has been
checked.
Reported-by: Conrad de Wet
ASTERISK-25444 #close
Change-Id: I6cfb2db2f9cfbd2bb3d30566ecae361c4abf6dbf
The "Refer-to" header of an incoming REFER request is parsed by
pjsip_parse_uri(). That function requires the URI parameter to be NULL
terminated. Unfortunately, the previous code added the NULL terminator by
overwriting memory that may not be safe. The overwritten memory results
could be benign, memory corruption, or a segmentation fault. Now the URI
is NULL terminated safely by copying the URI to a new chunk of memory with
the correct size to be NULL terminated.
ASTERISK-25814 #close
Change-Id: I32565496684a5a49c3278fce06474b8c94b37342
Older versions of PJSIP do not have the proto field on the TLS transport
setting structure. This change adds a configure check so even if it is
not present we will still be able to build.
Change-Id: Ibf3f47befb91ed1b8194bf63888baa6fee05aba9
Per RFC3325, the 'From' header is now anonymized on outgoing calls when
caller id presentation is prohibited.
TID = trust_id_outbound
PRO = Set(CALLERID(pres)=prohib)
USR = endpoint/from_user
DOM = endpoint/from_domain
PAI = YES(privacy=off), NO(not sent), PRI(privacy=full) (assumes send_pai=yes)
Conditions |Result
--------------------|----------------------------------------------------
TID PRO USR DOM |PAI FROM
--------------------|----------------------------------------------------
Y Y abc def.ghi |PRI "Anonymous" <sip:abc@def.ghi>
Y Y abc |PRI "Anonymous" <sip:abc@anonymous.invalid>
Y Y def.ghi |PRI "Anonymous" <sip:anonymous@def.ghi>
Y Y |PRI "Anonymous" <sip:anonymous@anonymous.invalid>
Y N abc def.ghi |YES <sip:abc@def.ghi>
Y N abc |YES <sip:abc@<ip_address>>
Y N def.ghi |YES "Caller Name" <sip:<caller_exten>@def.ghi>
Y N |YES "Caller Name" <sip:<caller_exten>@<ip_address>>
N Y abc def.ghi |NO "Anonymous" <sip:abc@def.ghi>
N Y abc |NO "Anonymous" <sip:abc@anonymous.invalid>
N Y def.ghi |NO "Anonymous" <sip:anonymous@def.ghi>
N Y |NO "Anonymous" <sip:anonymous@anonymous.invalid>
N N abc def.ghi |YES <sip:abc@def.ghi>
N N abc |YES <sip:abc@<ip_address>>
N N def.ghi |YES "Caller Name" <sip:<caller_exten>@def.ghi>
N N |YES "Caller Name" <sip:<caller_exten>@<ip_address>>
ASTERISK-25791 #close
Reported-by: Anthony Messina
Change-Id: I2c82a5ca1413c2c00fb62ea95b0ae8e97af54dc9
During the transfer process, some phones (okay it was the Jitsi softphone,
but maybe others are out there) send a "bye" immediately after receiving a
SIP Notify. When a "bye" is received early for some types of transfers the
transferer channel may no longer be available during late stage transfer
processing.
For instance, during an attended transfer involving stasis bridging at one
point the created local channel looks for an associated swap channel in
order to retrieve the stasis application name. If the transferer has hung
up then the local channel will fail to find it. The local channel then has
no way to know which stasis app to enter, so it fails and hangs up as well.
Thus the transfer does not complete as expected.
This patch delays the sending of the initial notify in order to give the
transfer process enough time to gather the necessary data for a successful
transfer.
ASTERISK-25771
Change-Id: I09cfc9a5d6ed4c007bc70625e0972b470393bf16
PJSIP does not ensure that when printing the message body the
buffer will be NULL terminated. This is problematic when searching
for the signal and duration values of the DTMF.
This change ensures the buffer is always NULL terminated.
Change-Id: I52653a1a60c93092d06af31a27408d569cc98968
ast_sip_get_transport_states was returning a container of internal_state
objects instead of ast_sip_transport_state objects. This was causing
transport lookups to fail, most noticably in res_pjsip_nat, which
couldn't find the correct external addresses. This was causing contacts
to go out with internal ip addresses.
ASTERISK-25830 #close
Reported-by: Sean Bright
Change-Id: I1aee6a2fd46c42e8dd0af72498d17de459ac750e
In message.c, if msg_alloc fails to init the string field,
vars may be null, so use a null tolerant cleanup.
In res_pjsip_messaging.c, if msg_data_create fails, mdata
will be null, so use a null tolerant cleanup.
ASTERISK-25323
Change-Id: Ic2d55c2c3750d5616e2a05ea92a19c717507ff56
Previous chan_sip behavior:
Before this patch chan_sip would always strip any quotes from an incoming
reason and pass that value up as the REDIRECTING(reason). For an outgoing
reason value, chan_sip would check the value against known values and
quote any it didn't recognize. Incoming 480 response message reason text
was just assigned to the REDIRECTING(reason).
Previous chan_pjsip behavior:
Before this patch chan_pjsip would always pass the incoming reason value
up as the REDIRECTING(reason). For an outgoing reason value, chan_pjsip
would send the reason value as passed down.
With this patch:
Both channel drivers match incoming reason values with values documented
by REDIRECTING(reason) and values documented by RFC5806 regardless of
whether they are quoted or not. RFC5806 values are mapped to the
equivalent REDIRECTING(reason) documented value and is set in
REDIRECTING(reason). e.g., an incoming RFC5806 'unconditional' value or a
quoted string version ('"unconditional"') is converted to
REDIRECTING(reason)'s 'cfu' value. The user's dialplan only needs to deal
with 'cfu' instead of any of the aliases.
The incoming 480 response reason text supported by chan_sip checks for
known reason values and if not matched then puts quotes around the reason
string and assigns that to REDIRECTING(reason).
Both channel drivers send outgoing known REDIRECTING(reason) values as the
unquoted RFC5806 equivalent. User custom values are either sent as is or
with added quotes if SIP doesn't allow a character within the value as
part of a RFC3261 Section 25.1 token. Note that there are still
limitations on what characters can be put in a custom user value. e.g.,
embedding quotes in the middle of the reason string is silly and just
going to cause you grief.
* Setting a REDIRECTING(reason) value now recognizes RFC5806 aliases.
e.g., Setting REDIRECTING(reason) to 'unconditional' is converted to the
'cfu' value.
* Added missing malloc() NULL return check in res_pjsip_diversion.c
set_redirecting_reason().
* Fixed potential read from a stale pointer in res_pjsip_diversion.c
add_diversion_header(). The reason string needed to be copied into the
tdata memory pool to ensure that the string would always be available.
Otherwise, if the reason string returned by reason_code_to_str() was a
user's reason string then the string could be freed later by another
thread.
Change-Id: Ifba83d23a195a9f64d55b9c681d2e62476b68a87
* Fix double unref of other_party channel in off nominal path.
* This is unlikely to be a real problem. However, for safety,
in handle_incoming_request() keep the datastore ref with the
other_party channel ref until we are finished with the other_party
channel.
Change-Id: I78f22547bf0bb99fb20814ceab75952bd857f821
This backs out item 4 of the 4875e5ac32
commit. Item 4 added the t38_bye_supplement. Unfortunately, the frame
that it puts into the bridge may or may not be processed by the time the
bridged peer is kicked out of the bridge. If it is processed then all is
well. However, if it is not processed then that channel is stuck in fax
mode until it hangs up or maybe if it joins another bridge for T.38
faxing.
ASTERISK-25582
Change-Id: Ib20a03ecadf1bf8a0dcadfadf6c2f2e60919a9f7
There are a few cases where we're emitting notices or warnings
for things that really need neither, like a client retrying to subscribe
to mwi when they're not conifgured for it. They get a 404 so there's no
need for non-debug messages.
Change-Id: I05e38a7ff6c2f2521146f4be6a79731b9864e61f
Introduced realloaction of ast_str buf in sqlite3_escape functions in case
the returned buffer from threadstorage was actually too small.
Change-Id: I3c5eb43aaade93ee457943daddc651781954c445
The 'reload' mechanism actually involves closing the underlying
socket and calling the appropriate udp, tcp or tls start functions
again. Only outbound_registration, pubsub and session needed work
to reset the transport before sending requests to insure that the
pjsip transport didn't get pulled out from under them.
In my testing, no calls were dropped when a transport was changed
for any of the 3 transport types even if ip addresses or ports were
changed. To be on the safe side however, a new transport option was
added (allow_reload) which defaults to 'no'. Unless it's explicitly
set to 'yes' for a transport, changes to that transport will be ignored
on a reload of res_pjsip. This should preserve the current behavior.
Change-Id: I5e759850e25958117d4c02f62ceb7244d7ec9edf
Warnings and errors in the pjproject libraries are generally handled by
Asterisk. In many cases, Asterisk wouldn't even consider them to be warnings
or errors so the messages emitted by pjproject directly are either superfluous
or misleading. A good exampe of this are the level-0 errors pjproject emits
when it can't open a TCP/TLS socket to a client to send an OPTIONS. We don't
consider a failure to qualify a UDP client an "ERROR", why should a TCP/TLS
client be treated any differently?
A config file for res_pjproject has bene added (pjproject.conf) and a new
log_mappings object allows mapping pjproject levels to Asterisk levels
(or nothing). The defaults if no pjproject.conf file is found are the same
as those that were hard-coded into res_pjproject initially: 0,1 = LOG_ERROR,
2 = LOG_WARNING, 3,4,5 = LOG_DEBUG<level>
Change-Id: Iba7bb349c70397586889b8f45b8c3d6c6c8c3898
When Asterisk receives a 412 (Conditional Request Failed) response
it has to recreate publish session.
There is bug in res_pjsip_outbound_publish.c
The function sip_outbound_publish_client_alloc is called with wrong object
while processing 412 (Conditional Request Failed) response.
This patch fixes it.
ASTERISK-25229 #close
Change-Id: I3b62f2debf6bb1e5817cde7b13ea39ef2bf14359
res_statsd.export.in was missing the _va variations of the log
functions causing Asterisk to crash in res_pjsip if OPTIONAL_API
wasn't enabled.
ASTERISK-25727 #close
Reported-by: Gergely Dömsödi
Change-Id: I395729f9f51bdd33c5ca757f5f96ebedad74077b
A new command (pjsip export config_wizard primitives) has been added that
will export all the pjsip objects it created to the console or a file
suitable for reuse in a pjsip.conf file.
ASTERISK-24919 #close
Reported-by: Ray Crumrine
Change-Id: Ica2a5f494244b4f8345b0437b16d06aa0484452b
If the PJSIP_HEADER dialplan function adds a PAI or RPID header and send_rpid
or send_pai is set, res_pjsip_caller_id attemps to retrieve, parse and modify
the header added by the dialplan function. Since the header added by the
dialplan function is generic string, there are no virtual functions to parse
the uri and we get a segfault when we try. Since the modify, was really only
an overwrite, we now just delete the old header if it was type PJSIP_H_OTHER
and recreate it.
This raises a question for another time though: What should happen with
duplicate headers? Right now res_pjsip_header_funcs doesn't check for dups
so if it's session supplement is loaded after res_pjsip_caller_id's (or any
other module that adds headers), there'll be dups in the message.
ASTERISK-25337 #close
Change-Id: I5e296b52d30f106b822c0eb27c4c2b0e0f71c7fa
It is possible when processing a SIP REGISTER request to have two
threads end up creating contact_status structures in sorcery.
contact_status is created using a "find or create" function. If two
threads call into this at the same time, each thread will fail to find
an existing contact_status, and so both will end up creating a new
contact status.
During testing, we would see sporadic failures because the
PJSIP_CONTACT() dialplan function would operate on a different
contact_status than what had been updated by res_pjsip/pjsip_options.
The fix here is two-fold:
1) The "find or create" function for contact_status now has a lock
around the entire operation. This way, if two threads attempt the
operation simultaneously, the first to get there will create the object,
and the second will find the object created by the first thread.
2) res_sorcery_memory has had its create callback updated so that it
will not allow for objects with duplicate IDs to be created.
Change-Id: I55b1460ff1eb0af0a3697b82d7c2bac9f6af5b97
A problem arose when testing the AMI subscription listing actions where it
was possible for a subscription that had not been fully initialized to be
listed. This was problematic as the underlying listing code would crash.
This change makes it so the subscription tree is fully set up before it is
added to the list of subscriptions. This ensures that when the listing actions
get the subscription it is valid.
ASTERISK-25738 #close
Change-Id: Iace2b13641c31bbcc0d43a39f99aba1f340c0f48
load_module was just too hairy with every step having to clean up all
previous steps on failure.
Some of the pjproject init calls have now been moved to a separate
load_pjsip function and the unload_pjsip function was enhanced to clean
up everything if an error happened at any stage of the load process.
In the process, a bunch of missing pj_shutdowns, serializer_pool_shutdowns
and ast_threadpool_shutdowns were also corrected.
Change-Id: I5eec711b437c35b56605ed99537ebbb30463b302
* heap-use-after-free happens when we free "cfg"
but then use "value" which refers to it
* A memory leak occurs because in some cases
it is not released "defaults"
ASTERISK-25721 #close
Reported by: Badalyan Vyacheslav
Tested by: Badalyan Vyacheslav
Change-Id: I3807d3f4726df6864430ec144cf6265d3f538469
Pjproject has deprecated pjsip_dlg_create_uas in 2.5 and replaced it with
pjsip_dlg_create_uas_and_inc_lock which, as the name implies, automatically
increments the lock on the returned dialog. To account for this, configure.ac
now detects the presence of pjsip_dlg_create_uas_and_inc_lock and res_pjsip.c
has an #ifdef HAVE_PJSIP_DLG_CREATE_UAS_AND_INC_LOCK to decide whether to use
the original call or the new one. If the new one was used, the ref count is
decremented before returning.
ASTERISK-25751 #close
Reported-by Josh Colp
Change-Id: I1be776b94761df03bd0693bc7795a75682615ca8
Attempting to load a transport from realtime was forcing asterisk into an
infinite recursion loop. The first thing transport_apply did was to do a
sorcery retrieve by id for an existing transport of the same name. For files,
this just returns the previous object from res_sorcery_config's internal
container, if any. For realtime, the res_sourcery_realtime driver looks in the
database and finds the existing row but now it has to rehydrate it into a
sorcery object which means calling... transport_apply. And so it goes.
The main issue with loading from realtime (apart from the loop) was that
transport stores structures and pointers directly in the ast_sip_transport
structure instead of the separate ast_transport_state structure. This patch
separates those items into the ast_sip_transport_state structure. The pattern
is roughly the same as res_pjsip_outbound_registration.
Although all current usages of ast_sip_transport and ast_sip_transport_state
were modified to use the new ast_sip_get_transport_state API, the original
items are left in ast_sip_transport and kept updated to maintain ABI
compatability for third-party modules. They are marked as deprecated and
noted that they're now in ast_sip_transport_state.
ASTERISK-25606 #close
Reported-by: Martin Moučka
Change-Id: Ic7a836ea8e786e8def51fe3f8cce855ea54f5f19
Device state subscription lifetimes were governed by when the
subscription was established and unsubscribed from. However, it is
possible that at the time of unsubscription, there could be device state
events still in flight. When those device state events occur, the device
state callback could attempt to dereference a freed pointer. Crash.
This change ensures that the lifetime of the device state subscription
does not end until the underlying stasis subscription has confirmed that
its final message has been sent.
Change-Id: I25a0f1472894c1a562252fb7129671478e25e9b2
During ICE negotiation the IPs of the local interfaces are sent to the remote
peer as host candidates. In many cases Asterisk is behind a static one-to-one
NAT, so these host addresses will be internal IP addresses.
To help in hiding the topology of the internal network, this patch adds the
ability to override the host candidates by matching them against a
user-defined list of replacements.
Change-Id: I1c9541af97b83a4c690c8150d19bf7202c8bff1f
test_dlinklists doesn't need to NOTICE everyone that every macro worked.
res_phoneprov doesn't need to VERBOSE everyone that a phoneprov extension or
provider was registered.
res_odbc was missing a newline at the end of one message.
Change-Id: I6c06361518ef3711821795e535acd439782a995e
A regression was introduced where searching for realtime PJSIP objects
by regex by starting the regex with a leading "^" would cause no items
to be returned.
This was due to a change which attempted to drop the requirement for a
leading "^" to be present due to how some CLI commands formulate their
regexes. However, the change, rather than simply eliminating the
requirement, caused any regexes that did begin with "^" to end up not
returning the expected results.
This change fixes the problem by inspecting the regex and formulating
the realtime query differently depending on if it begins with "^".
ASTERISK-25702 #close
Reported by Nic Colledge
Patches:
realtime_retrieve_regex.patch submitted by Alexei Gradinari License #5691
Change-Id: I055df608a6e6a10732044fa737a9fe8dca602693
The module res_xmpp does not accept usernames in the form used in component
mode (XEP-0114). In component mode there is no @something in the name.
In component mode the connection is now not dropped anymore.
If the xmpp server sends out a "stream" tag before handshake is finished,
the connection gets dropped in res_xmpp. Now this tag will be ignored and
the connection will be established.
After connecting there will be an exchange of presence states. This does
not work as expected in component mode. The responsible function
"xmpp_pak_presence" is left before the states get sent out. Sending
presence states in component mode is now moved to the top of the function.
ASTERISK-25735 #close
Change-Id: I70e036f931c3124ebb2ad1e56f93ed35cfdd9d5c
zuul
Alexei Gradinari
George Joseph
Joshua Colp
Mark Michelson
Richard Mudgett
Jacek Konieczny
Philip Correia
Gianluca Merlo
Walter Doekes
Sergio Medina Toledo
Kevin Harwell
Scott Griepentrog
Christof Lauber
Badalyan Vyacheslav
Sean Bright
Karsten Wemheuer