In 13, the new ast_string_field_header structure had to be dynamically
allocated and assigned to a pointer in ast_string_field_mgr to preserve ABI
compatability. In master, it can be converted to being a structure-in-place in
ast_string_field_mgr to eliminate the extra alloc and free calls.
Change-Id: Ia97c5345eec68717a15dc16fe2e6746ff2a926f4
From the patch submitted to Teluu on 4/12/2016
<<<<<<<<<
The wholesale stripping of '[]' from header parameters causes issues if
something (like a port) occurs after the final ']'.
'[2001🅰️:b]' will correctly parse to '2001🅰️:b'
'[2001🅰️:b]:8080' will correctly parse to '2001🅰️:b' but the scanner is left
with ':8080' and parsing stops with a syntax error.
I can't even find a case where stripping the '[]' is a good thing anyway. Even
if you continued to parse and resulted in a string that looks like this...
'2001🅰️🅱️8080', it's not valid.
This came up in Asterisk because Kamailio sends us a Contact with an alias
URI parameter that has an IPv6 address in it like this:
Contact: <sip:1171@127.0.0.1:5080;alias=[2001:1:2::3]~43691~6>
which should be legal but causes a syntax error because of the characters
after the final ']'. Even if it didn't, the '[]' should still not be stripped.
I've run the Asterisk Test Suite for PJSIP (252 tests) many of which are IPv6
enabled. No issues were caused by removing the code that strips the '[]'.
>>>>>>>>>>>
ASTERISK-25123 #close
Reported-by: Anthony Messina
Change-Id: I5cb33f4ebf07ee1f2b26d07caae715e2ec65595a
The test_voicemail_notify_endl test checks the end-of-line
characters of an email message to confirm that they are consistent.
The test wrongfully assumed that reading from the email message
into a buffer will always result in more than 1 character being
read. This is incorrect. If only 1 character was read the test
would go outside of the buffer and access other memory causing
a crash.
The test now checks to ensure that 2 or more characters are read
in ensuring the test stays within the buffer.
ASTERISK-25874 #close
Change-Id: Ic2c89cea6e90f2c0bc2d8138306ebbffd4f8b710
If try to move message to Cust1 (number 5)
the function 'save_to_folder' tries to create Greeting folder instead of Cust1.
This patch fixed it by setting GREETINGS_FOLDER = -1
ASTERISK-24927 #close
Change-Id: I03d1a761894bcc2d130ec9b003bbcddc28e25c51
* Added Useragent and RegExpire headers to AMI Event
ContactStatusDetail with associated documentation.
ASTERISK-25903 #close
Change-Id: If3d121e943e588d016ba51d4eb9c6a421a562239
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
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
There's a bug in pjproject's sip_parser where the ":" wasn't correctly
interpreted. This is causing IPv6 addresses in the "received" parameter of the
Via header to cause a syntax check failure.
This patch was submitted to Teluu on 4/10/2016.
ASTERISK-25910 #close
Reported-by: Anthony Messina
Change-Id: Ic7e4c4aa14ded61860401ec349f5177568c4d922
Locking some objects like sorcery objects can be tricky because the underlying
ao2 object may not be the same for all callers. For instance, two threads that
call ast_sorcery_retrieve_by_id on the same aor name might actually get 2
different ao2 objects if the underlying wizard had to rehydrate the aor from a
database. Locking one ao2 object doesn't have any effect on the other even if
those objects had locks in the first place.
Named locks allow access control by keyspace and key strings. Now an "aor"
named "1000" can be locked and any other thread attempting to lock "aor" "1000"
will wait regardless of whether the underlying ao2 object is the same or not.
Mutex and rwlocks are supported.
This capability will initially be used to lock an aor when multiple threads may
be attempting to prune expired contacts from it.
Change-Id: If258c0b7f92b02d07243ce70e535821a1ea7fb45
Sometimes uw-imap function 'mail_fetchbody' returns huge len
which then pass to uw-imap function 'rfc822_base64'.
uw-imap tries to allocate huge memory and abort() on fail.
This patch check the len.
If the len more than max size (128 Mbytes) log error.
This patch also set variables len, newlen to avoid uninizialezed len.
This patch also check pointer returned by rfc822_base64.
ASTERISK-25899 #close
Change-Id: I4a0e7d655f11abef6a5224e2169df6d5c1f1caca
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
This eliminates some casts that I made a note saying v10 and above
would no longer need them.
Better late than never :)
Change-Id: I346cdb3032b6478ceb40eb6fe732978b54035572
Because SQLite doesn't support full ALTER capabilities, alembic scripts
require batch operations. However, that capability wasn't available until
0.7.0 which some distributions haven't reached yet. Therefore, the batch
operations introduced in commit 86d6e44cc (review 2319) have been reverted
and SQLite is unsupported again, for now anyway.
Tested the full upgrade and downgrade on MySQL/Mariadb and Postgresql.
ASTERISK-25890 #close
Reported-by: Harley Peters
Change-Id: I82eba5456736320256f6775f5b0b40133f4d1c80
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
The problem is ast_frdup() does not copy whole frame.subclass for voice,
video and image frames, only the format is copied. For video frames, the
subclass structure contains the .frame_ending flag used to put the RTP
marker where it needs to be.
ASTERISK-25894 #close
Change-Id: I812ca90e84ed5d4f473b997d0dd0d3c5a915fe33
This adds a new ARI method that allows for you to dial a channel that
you previously created in ARI.
By combining this with the create method for channels, it allows for a
workflow where a channel can be created, manipulated, and then dialed.
The channel is under control of the ARI application during all stages of
the Dial and can even be manipulated based on channel state changes
observed within an ARI application.
The overarching goal for this is to eventually be able to add a dialed
channel to a Stasis bridge earlier than the "Up" state. However, at the
moment more work is needed in the Dial and Bridge APIs in order to
facilitate that.
ASTERISK-25889 #close
Change-Id: Ic6c399c791e66c4aa52454222fe4f8b02483a205
This adds a new ARI method to the channels resource that allows for the
creation of a new channel. The channel is created and then placed into
the specified Stasis application.
This is different from the existing originate method that creates a
channel, dials it, and then places the answered channel into the
dialplan or a Stasis application. This method does not attempt to call
the channel at all. Dialing is left as a later step after channel
creation. This allows for pre-dialing channel manipulation if desired.
ASTERISK-25889
Change-Id: I3c96a0aba914b08e39f6256371a5bd4c92cbded8
This change introduces the concept of autohints. These are hints
which are created as a result of device state changes occurring within
the core. When this happens a hint will be created (if it does not
exist already) using the device name as the extension.
For example if a device state change is received for "PJSIP/bob"
and autohints are enabled on a context then a hint will exist in
that context for "bob" with a device of "PJSIP/bob".
For virtual or custom device states the name after the type will
be used. For example if the device state of "Custom:bob" changes
then a hint will exist in that context for "bob" with a device of
"Custom:bob".
This functionality can be enabled in extensions.conf by placing
"autohints=yes" in a context.
ASTERISK-25881 #close
Change-Id: I7e444c7da41b7b7d33374420fec658beeb18584e
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
The Dial API takes responsiblity for creating an outbound channel when
calling ast_dial_append(). This commit adds a new function,
ast_dial_append_channel(), which allows us to create the channel outside
the Dial API and then to append the channel to the ast_dial structure.
This is useful for situations where the channel's creation and dialing
are distinct operations. Upcoming ARI early bridge work will illustrate
its usage.
ASTERISK-25889
Change-Id: Id8179f64f8f99132f80dead8d5db2030fd2c0509
In sorcery based config files where there are multiple categories with the same
name, you can't use the (+) operator to reliably append to a category because
config.c stops looking when it finds the first one with the same name.
Example:
[1000]
type = endpoint
[1000]
type = aor
[1000](+)
authenticate_qualify = yes
This config will fail because config.c appends authenticate_qualify to the
first category it finds, the endpoint, and that's not valid for endpoint.
Solution:
The capability to find a category that contains a certain variable already
exists so the only real change was to parse anything after the '+' that's not a
comma, as a filter string.
[1000]
type = endpoint
[1000]
type = aor
[1000](+type=aor)
authenticate_qualify = yes
This now works as expected.
Although the following example doesn't make any sense for pjsip, you can even
specify multiple filters:
[1000](+type=aor&qualify_frequency=10)
ASTERISK-25868 #close
Reported-by: Nick Repin
Change-Id: I10773da4c79db36fbf1993961992af63d3441580
String fields are great, except that you can't add new ones without breaking
ABI compatibility because it shifts down everything else in the structure.
The only alternative is to add your own char * field to the end of the
structure and manage the memory yourself which isn't ideal, especially since
you then can't use the OPT_STRINGFIELD_T type.
Background:
The reason string fields had to be declared inside the
AST_DECLARE_STRING_FIELDS block was to facilitate iteration over all declared
fields for initialization, compare and copy. Since AST_DECLARE_STRING_FIELDS
declared the pool, then the fields, then the manager, you could use the offsets
of the pool and manager and iterate over the sequential addresses in between to
access the fields. The actual pool, field allocation and field set operations
don't actually care where the field is. It's just iteration over the fields
that was the problem.
Solution: Extended String Fields
An extended string field is one that is declared outside the
AST_DECLARE_STRING_FIELDS block but still (anywhere) inside the parent
structure. Other than using AST_STRING_FIELD_EXTENDED instead of
AST_STRING_FIELD, it looks the same as other string fields. It's storage comes
from the pool and it participates in string field compare and copy operations
peformed on the parent structure. It's also a valid target for the
OPT_STRINGFIELD_T aco option type.
Implementation:
To keep track of the extended fields and make sure that ABI isn't broken, the
existing embedded_pool pointer in the manager structure was repurposed to be a
pointer to a separate header structure that contains the embedded_pool pointer
plus a vector of fields. The length of the manager structure didn't change and
the embedded_pool pointer isn't used in the macros, only the stringfields C
code. A side benefit of this is that changing the header structure in the
future won't break ABI.
ast_string_fields_init initializes the normal string fields and appends them to
the vector, and subsequent calls to ast_string_field_init_extended initialize
and append the extended fields. Cleanup, ast_string_fields_cmp, and
ast_string_fields_copy can now work on the vector instead of sequentially
traversing the addresses between the pool and manager.
The total size of a structure using string fields didn't change, whether using
extended fields or not, nor have the offsets of any structure members, either
inside the original block or outside. Adding an extended field to the end of a
structure is the same as adding a char *.
Details:
The stringfield C code was pulled out from utils.c and into stringfields.c.
It just made sense.
Additional work was done in ast_string_field_init and
ast_calloc_with_stringfields to handle the allocation of the new header
structure and the vector, and the associated cleanup. In the process some
additional NULL pointer checking was added.
A lot of work was done in stringfields.h since the logic for compare and copy
is there. Documentation was added as well as somne additional NULL checking.
The ability to call ast_calloc_with_stringfields with a number of structures
greater than 1 never really worked. Well, the calloc worked but there was no
way to access the additional structures or clean them up. It was agreed that
there was no use case for requesting more than 1 structure so an ast_assert
was added to prevent it and the iteration code removed.
Testing:
The stringfield unit tests were updated to test both normal and extended
fields. Tests for ast_string_field_ptr_set_by_fields and
ast_calloc_with_stringfields were also added.
As an ABI test, 13 was compiled from git and the res_pjsip_* modules, except
res_pjsip itself, saved off. The patch was then added and a full compile and
install was performed. Then the older res_pjsip_* moduled were copied over the
installed versions so res_pjsip was new and the rest were old. No issues.
contact->aor, which is a char * at the end of contact, was then changed to an
extended string field and a recompile and reinstall was performed, again
leaving stock versions of the the res_pjsip_* modules. Again, no issues with
the res_pjsip_* modules using the old stringfield implementation and with
contact->aor as a char *, and res_pjsip itself using the new stringfield
implementation and contact->aor being an extended string field.
Finally, several existing string fields were converted to extended string
fields to test OPT_STRINGFIELD_T. Again, no issues.
Change-Id: I235db338c5b178f5a13b7946afbaa5d4a0f91d61
I forgot the new voicemail_extension wasn't a stringfield and didn't check
for NULL where I should have.
Change-Id: I029482d5c2ab72474838750461bd46b0809c90fb
