Given the following request path and 2 handler paths...
Request: /channels/externalMedia
Handler: /channels/{channelId} "wildcard"
Handler: /channels/externalmedia "non-wildcard"
...if /channels/externalMedia was registered as a handler after
/channels/{channelId} as shown above, the request would automatically
match the wildcard handler and attempt to parse "externalMedia" into
the channelId variable which isn't what was intended. It'd work
if the non-wildard entry was defined in rest-api/api-docs/channels.json
before the wildcard entry but that makes the json files
order-dependent which isn't a good thing.
To combat this issue, the search loop saves any wildcard match but
continues looking for exact matches at the same level. If it finds
one, it's used. If it hasn't found an exact match at the end of
the current level, the wildcard is used. Regardless, after
searching the current level, the wildcard is cleared so it won't
accidentally match for a different object or a higher level.
BTW, it's currently not possible for more than 1 wildcard entry
to be defined for a level. For instance, there couldn't be:
Handler: /channels/{channelId}
Handler: /channels/{channelName}
We wouldn't know which one to match.
Change-Id: I574aa3cbe4249c92c30f74b9b40e750e9002f925
Somehow it's possible for the srtp session object to be NULL even though the
Asterisk srtp object itself is valid. When this happened it would cause a
crash down in the srtp code when attempting to protect or unprotect data.
After looking at the code there is at least one spot that makes this situation
possible. If Asterisk fails to unprotect the data, and after several retries
it still can't then the srtp->session gets freed, and set to NULL while still
leaving the Asterisk srtp object around. However, according to the original
issue reporter this does not appear to be their situation since they found
no errors logged stating the above happened (which Asterisk does for that
situation).
An issue was found however, where a possible race condition could occur between
the pjsip incoming negotiation, and the receiving of RTP packets. Both places
could attempt to create/setup srtp for the same rtp instance at the same time.
This potentially could be the cause of the problem as well.
Given the above this patch adds locking around srtp setup for a given rtp, or
rtcp instance. NULL checks for the session have also been added within the
protect and unprotect functions as a precaution. These checks should at least
stop Asterisk from crashing if it gets in this situation again.
This patch also fixes one other issue noticed during investigation. When doing
a replace the old object was freed before creating the replacement. If the new
replacement object failed to create then the rtp/rtcp instance would now point
to freed srtp data which could potentially cause a crash as well when the next
attempt to reference it was made. This is now fixed so the old srtp object is
kept upon replacement failure.
Lastly, more logging has been added to help diagnose future issues.
ASTERISK-28472
Change-Id: I240e11cbb1e9ea8083d59d50db069891228fe5cc
The code for gathering contacts could result in the same contact
being retrieved and added to the list multiple times. The container
which stores the contacts to display will now only allow a contact
to be added to it once instead of multiple times.
ASTERISK-28228
Change-Id: I805185cfcec03340f57d2b9e6cc43c49401812df
We now check that a body exists and it has a length > 0 before
attempting to process it.
ASTERISK-28447
Reported-by: Gil Richard
Change-Id: Ic469544b22ab848734636588d4c93426cc6f4b1f
This change adds support for larger TLS certificates by allowing
OpenSSL to fragment the DTLS packets according to the configured
MTU. By default this is set to 1200.
This is accomplished by implementing our own BIO method that
supports MTU querying. The configured MTU is returned to OpenSSL
which fragments the packet accordingly. When a packet is to be
sent it is done directly out the RTP instance.
ASTERISK-28018
Change-Id: If2d5032019a28ffd48f43e9e93ed71dbdbf39c06
According T.38 Gateway 'Use case 3'
https://wiki.asterisk.org/wiki/display/AST/T.38+Gateway
T.38 Gateway should send T.38 negotiation request to called endpoint
if FAX preamble (using V.21 detector) generated by called endpoint.
But it does not, because fax_gateway_detect_v21 constructs T.38
negotiation request, but forwards it only to other channel,
not to the channel on which FAX preamble is detected.
Some SIP endpoints could be improperly configured to rely on the other side
to initiate T.38 re-INVITEs.
With this patch the T.38 Gateway tries to negotiate with both sides
by sending T.38 negotiation request to both endpoints supported T.38.
Change-Id: I73bb24799bfe1a48adae9c034a2edbae54cc2a39
This patch adds a channel name to output of CLI 'fax show session'
and also expands the channel name field up to 30 characters on
CLI 'fax show sessions'
Change-Id: Id059c43ff41811f5e76712b83fb63b8f246da953
The change #10017 "Handle fax gateway being started more than once"
introdiced a bug which leads to segfault in res_fax_spandsp.
The res_fax_spandsp module does not support reserving sessions, so
fax_session_reserve returns a fax session with state AST_FAX_STATE_INACTIVE.
The fax_gateway_start does not create a real fax session if the fax session
is already present and the state is not AST_FAX_STATE_RESERVED.
But the "reserved" session created for res_fax_spandsp has state
AST_FAX_STATE_INACTIVE, so fax_gateway_start not starting.
Then when fax_gateway_framehook is called and gateway T.38 state is
NEGOTIATED the call of gateway->s->tech->write(gateway->s, f) leads to
segfault, because session tech_pvt is not set, i.e. the tech session
was not initialized/started.
This patch adds check also on AST_FAX_STATE_INACTIVE to the "reserved"
session created for res_fax_spandsp will start.
This patch also adds extra check and log ERROR if tech_pvt is not set
before call tech->write.
ASTERISK-27981 #close
Change-Id: Ife3e65e5f18c902db2ff0538fccf7d28f88fa803
Using timestamp with signed int will cause timestamps exceeding max value
to be negative.
This causes the jitterbuffer to do passthrough of the packet.
ASTERISK-28421
Change-Id: I9dabd0718180f2978856c50f43aac4e52dc3cde9
You can now add the "include_local_address" flag to an entry in
rtp.conf "[ice_host_candidates]" to include both the advertized
address and the local address in ICE negotiation:
[ice_host_candidates]
192.168.1.1 = 1.2.3.4,include_local_address
This causes both 192.168.1.1 and 1.2.3.4 to be advertized.
Change-Id: Ide492cd45ce84546175ca7d557de80d9770513db
This change fixes two bugs which both resulted in the packet loss
count exceeding 65,000.
The first issue is that the sequence number check to determine if
cycling had occurred was using the wrong variable resulting in the
check never seeing that cycling has occurred, throwing off the
packet loss calculation. It now uses the correct variable.
The second issue is that the packet loss calculation assumed that
the received number of packets in an interval could never exceed
the expected number. In practice this isn't true due to delayed
or retransmitted packets. The expected will now be updated to
the received number if the received exceeds it.
ASTERISK-28379
Change-Id: If888ebc194ab69ac3194113a808c414b014ce0f6
When multiple endpoints try to register close together using the same
AOR with qualify_frequency set, one contact would qualify immediately
while the other contacts would have to wait out the duration of the
timer before being able to qualify. Changing the conditional to check
the contact container count for a non-zero value allows all contacts to
qualify immediately.
Change-Id: I79478118ee7e0d6e76af7c354d66684220db9415
When we use early bridge with create and dial from stasis using Local channel
and the dialplan does not any entry the it is returned from core_local.c with
No such extension .
In such case asterisk locks up till the channel is not hangup with the error
Exceptionally long voice queue length
* Found that in such case app_control_dial fails on ast_call method and
return -1
* Since it is called from stasis_app_send_command_async and return -1 does
not cause resources to be freed and since no PBX exist it is not able to
read from channel causing exceptionally long queue
* After putting this code found that the channel was releasing immediately
and resources were freed.
ASTERISK-28399
Reported by: Abhay Gupta
Tested by: Abhay Gupta
Change-Id: I0a55c923fc6995559f808d63b9488762b4489318
Updated ast_sip_create_rdata_with_contact and registrar_find_contact
to check the return from pjsip_parse_uri before attempting to
use the uri returned.
ASTERISK-28402
Reported-by: Ross Beer
Change-Id: I9810b3b163c45ed5a56ec743586e5ce107f13ba7
The dial bridge is meant to hold channels which have been created
and dialed in stasis. It handles the frames coming from them and raises
the appropriate events.
It was possible for the code to mistakenly place calls which came
from the dialplan into the dial bridge if they were not in an
answered state. These channels are not outgoing channels and
should not be placed into the dial bridge.
The code now checks to ensure that only stasis created channels are
placed into the dial bridge by checking that a PBX does not exist
on the channel.
ASTERISK-27756
Change-Id: Ideee69ff06c9a0b31f7ed61165f5c055f51d21b6
The transport-cc draft is a mechanism by which additional information
about packet reception can be provided to the sender of packets so
they can do sender side bandwidth estimation. This is accomplished
by having a transport specific sequence number and an RTCP feedback
message. This change implements this in the receiver direction.
For each received RTP packet where transport-cc is negotiated we store
the time at which the RTP packet was received and its sequence number.
At a 1 second interval we go through all packets in that period of time
and use the stored time of each in comparison to its preceding packet to
calculate its delta. This delta information is placed in the RTCP
feedback message, along with indicators for any packets which were not
received.
The browser then uses this information to better estimate available
bandwidth and adjust accordingly. This may result in it lowering the
available send bandwidth or adjusting how "bursty" it can be.
ASTERISK-28400
Change-Id: I654a2cff5bd5554ab94457a14f70adb71f574afc
There is enough MWI functionality to warrant it having its own 'c' and header
files. This patch moves all current core MWI data structures, and functions
into the following files:
main/mwi.h
main/mwi.c
Note, code was simply moved, and not modified. However, this patch is also in
preparation for core MWI changes, and additions to come.
Change-Id: I9dde8bfae1e7ec254fa63166e090f77e4d3097e0
Added a new PJSIP global setting called norefersub.
Default is true to keep support working as before.
res_pjsip_refer: Configures PJSIP norefersub capability accordingly.
Checks the PJSIP global setting value.
If it is true (default) it adds the norefersub capability to PJSIP.
If it is false (disabled) it does not add the norefersub capability
to PJSIP.
This is useful for Cisco switches that do not follow RFC4488.
ASTERISK-28375 #close
Reported-by: Dan Cropp
Change-Id: I0b1c28ebc905d881f4a16e752715487a688b30e9
An earlier contributor apparently forgot to run 'make ari-stubs'
before committing after making ARI model changes.
Change-Id: I7813e5638e2821d11f4b968dc2aeab4f725190a6
Reset the internal counter that the AEL2 compiler uses for unique label
names before compiling. This keeps dialplan labels consistent across
reloads assuming the AEL2 has not changed.
ASTERISK-17799 #close
Reported by: Kirill Katsnelson
Change-Id: I30b3cc887d1ee0644d3f341e2fef16f525d7fae5
In AEL2, if a 'for' statement contains macro* calls, like:
for (&iterator(${TRY},A); "${A}" != ""; &iterate(A)) {
The AEL2 parser will translate these into calls to the deprecated Macro
dialplan application and use the antiquated pipe delimiter.
Instead, convert these into calls to the Gosub dialplan application and
use commas as argument separators.
ASTERISK-18593 #close
Reported by: Luke-Jr
* 'macro' in this context means AEL2 macros, not the 'Macro' application
Change-Id: I3d73716033b8e3e42e0209d355bf5f10c97045fc
When generating the regular expression that matches against existing
extensions, we need to escape literal characters that can also be
regular expression metacharacters. This was already being done for '*'
but we need to do the same for '+'.
In passing, remove some unreachable code - strcmp() is already run
immediately when entering extension_matches().
ASTERISK-14939 #close
Reported by: klaus3000
Change-Id: I8d2cccb3479168fba1b0a6704c52198b396468f1
It was difficult to check the channel's current application and
parameters using ARI for current channels. Added app_name, app_data
items to show the current application information.
ASTERISK-28343
Change-Id: Ia48972b3850e5099deab0faeaaf51223a1f2f38c
REMB's exponent is 6-bits (0..63) and has a mantissa of 18-bits. We were using
an unsigned integer to represent the bitrate. However, that type is not large
enough to hold all potential bitrate values. If the bitrate is large enough
bits were being shifted off the "front" of the mantissa, which caused the
wrong value to be sent to the browser.
This patch makes it so it now uses a float type to hold the bitrate. Using a
float allows for all bitrate values to be correctly represented.
ASTERISK-28255
Change-Id: Ice00fdd16693b16b41230664be5d9f0e465b239e
It looks like we're not properly calculating jitter values on received
video streams. This patch enables the code that does jitter calculations
for those streams.
Change-Id: Iaac985808829c8f034db8c57318789c4c8c11392
Added ARI resource for channel statistics.
GET /ari/channels/{channelId}/rtp_statistics : It returns given
channel's rtp statistics detail.
ASTERISK-28320
Change-Id: I4343eec070438cec13f2a4f22e7fd9e574381376
George Joseph
Kevin Harwell
Friendly Automation
Sean Bright
Joshua Colp
Alexei Gradinari
Morten Tryfoss
Ben Ford
agupta
Dan Cropp
sungtae kim
Matthew Fredrickson