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
Testing has shown that our usage of UnixODBC is problematic
due to bugs within UnixODBC itself as well as the heavy weight
cost of connecting and disconnecting database connections, even
when pooling is enabled.
For users of UnixODBC 2.3.1 and earlier crashes would occur due
to insufficient protection of the disconnect operation. This was
fixed in UnixODBC 2.3.2 and above.
For users of UnixODBC 2.3.3 and higher a slow-down would occur
under heavy database use due to repeated connection establishment.
A regression is present where on each connection the database
configuration is cached again, with the cache growing out of
control.
The connection pool implementation present in this change helps
to mitigate these issues by reducing how much we connect and
disconnect database connections. We also solve the issue of
crashes under UnixODBC 2.3.1 by defaulting the maximum number of
connections to 1, returning us to the previous working behavior.
For users who may have a fixed version the maximum concurrent
connection limit can be increased helping with performance.
The connection pool works by keeping a list of active connections.
If the connection limit has not been reached a new connection is
established. If the connection limit has been reached then the
request waits until a connection becomes available before
continuing.
ASTERISK-26074 #close
ASTERISK-26054 #close
Change-Id: I6774bf4bac49a0b30242c76a09c403d2e856ecff
Since libSRTP 1.5, its Random Number Generator (RNG) is not maintained anymore.
Therefore, the symbol RAND_bytes is used instead of crypto_get_random.
ASTERISK-24436 #close
Change-Id: Iea0bae4d4e3c9aa0926ea442b6484b5159789d96
If you create a local channel and don't specify an originator channel
to take capabilities from, we automatically add all audio formats to
the new channel's capabilities. When we try to make the channel
compatible with another, the "best format" functions pick the best
format available, which in this case will be slin192. While this is
great for preserving quality, it's the worst for performance and
overkill for the vast majority of applications.
In the absense of any other information, adding all formats is the
correct thing to do and it's not always possible to supply an
originator so a new parameter 'formats' has been added to the channel
create/originate functions. It's just a comma separated list of formats
to make availalble for the channel. Example: "ulaw,slin,slin16".
'formats' and 'originator' are mutually exclusive.
To facilitate determination of format names, the format name has been
added to "core show codecs".
ASTERISK-26070 #close
Change-Id: I091b23ecd41c1b4128d85028209772ee139f604b
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
Re-ordered the body items so Message-Account is second.
Messages-Waiting: no
Message-Account: sip:1571@<IP Removed>:5060
Voice-Message: 0/0 (0/0)
ASTERISK-26065 #close
Reported-by: Ross Beer
Change-Id: If5d35a64656eac98c2dd5e490cc0b2807bed80c3
Added notes about when you can read or write headers. Specifically
about being able to read on the inbound channel and write on an
outbound channel.
ASTERISK-26063 #close
Reported by: Private Name
Tested by: Rusty Newton
Change-Id: Ibeb64af17d1f6451028b3c29855a3f151a01d8c5
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
This change introduces the same filtering that is done in res_sorcery_realtime
to the res_sorcery_astdb module. This allows persisted sorcery objects
that may contain unknown fields to still be read in from the AstDB
and used. This is particularly useful when switching between different
versions of Asterisk that may have introduced additional fields.
ASTERISK-26014 #close
Change-Id: Ib655130485a3ccfd635b7ed5546010ca14690fb2
Some SBCs require responses to empty SIP INFO packets
after establishing call via INVITE, if not responded to
they may drop your call after unspecified timeout of X minutes.
They are identified by having no Content-Type, check for this
and respond with 200 - OK message.
ASTERISK-24986 #close
Reported-by: Ilya Trikoz, Federico Santulli
Change-Id: Ib27e4f07151e5aef28fa587e4ead36c5b87c43e0
Nothing was cleaning up the registration state object when ast_sorcery_delete
was called on a registration. So, the registration was deleted from sorcery
but the state object went right on refreshing the registration (or failing
to refresh the registration) with the peer.
* Added a 'deleted' observer on registration that removes the state object.
ASTERISK-25964 #close
Reported-by Matt Jordan
Change-Id: I2db792145cdb1f72ebbf57dd9099596dbbf12c23
Although it's perfectly legal to place multiple SIP messages in the same packet,
it can cause problems because the Linux default is to enable Path MTU Discovery
which sets the Don't Fragment bit on the packets. If adding a second message to
the packet causes the MTU to be exceeded, and the destination isn't equipped to
send a FRAGMENTATION NEEDED response to a large packet, the packet will just be
dropped.
We can't specifically tell the stack to send only 1 message per packet, but we
can turn on TCP_NODELAY when we create the transport. This will at least tell
the stack to send packets as soon as possible.
ASTERISK-26005 #close
Reported-by: Ross Beer
Change-Id: I820f23227183f2416ca5e393bec510e8fe1c8fbd
When bound to an 'any' address, e.g., 0.0.0.0, PJSIP reports as its
local address the 'any' address, as opposed to the IP address we
actually received the packet on. This can cause some confusion in Homer,
as it will dutifully report what we send it.
This patch uses the PJSIP inspection routines to determine which IP
address we probably received the packet on based on the remote party's
IP address. In the event that this fails, it falls back to the IP
address natively reported by the transport.
Change-Id: I076f835d2aef489e1ee1d01595b211eb2ce62da3
The Location headers returned by:
* /bridges/{bridgeId}/play
* /bridges/{bridgeId}/record
* /channels/{channelId}/play
* /channels/{channelId}/record
Did not have the '/ari' prefix, and in the case of the 'play' resources, were
using 'playback' instead of 'playbacks.'
Change-Id: I957c58a3a1471bf477dae7c67faa1b74fcd9241c
With the old SIP module we can use IP access controls per peer.
PJSIP module missing this feature.
This patch added next configuration Endpoint options:
"acl" - list of IP ACL section names in acl.conf
"deny" - List of IP addresses to deny access from
"permit" - List of IP addresses to permit access from
"contact_acl" - List of Contact ACL section names in acl.conf
"contact_deny" - List of Contact header addresses to deny
"contact_permit" - List of Contact header addresses to permit
This patch also better logging failed request:
add custom message instead of "No matching endpoint found"
add SIP method to logging
ASTERISK-25900
Change-Id: I456dea3909d929d413864fb347d28578415ebf02
At one point in time, it seemed like a good idea to use the Asterisk
channel name as the HEP correlation UUID. In particular, it felt like
this would be a useful identifier to tie PJSIP messages and RTCP
messages together, along with whatever other data we may eventually send
to Homer. This also had the benefit of keeping the correlation UUID
channel technology agnostic.
In practice, it isn't as useful as hoped, for two reasons:
1) The first INVITE request received doesn't have a channel. As a
result, there is always an 'odd message out', leading it to be
potentially uncorrelated in Homer.
2) Other systems sending capture packets (Kamailio) use the SIP Call-ID.
This causes RTCP information to be uncorrelated to the SIP message
traffic seen by those capture nodes.
In order to support both (in case someone is trying to use res_hep_rtcp
with a non-PJSIP channel), this patch adds a new option, uuid_type, with
two valid values - 'call-id' and 'channel'. The uuid_type option is used
by a module to determine the preferred UUID type. When available, that
source of a correlation UUID is used; when not, the more readily available
source is used.
For res_hep_pjsip:
- uuid_type = call-id: the module uses the SIP Call-ID header value
- uuid_type = channel: the module uses the channel name if available,
falling back to SIP Call-ID if not
For res_hep_rtcp:
- uuid_type = call-id: the module uses the SIP Call-ID header if the
channel type is PJSIP and we have a channel,
falling back to the Stasis event provided
channel name if not
- uuid_type = channel: the module uses the channel name
ASTERISK-25352 #close
Change-Id: Ide67e59a52d9c806e3cc0a797ea1a4b88a00122c
There are two types of SIP URIs indicating a secure transport:
* sips:user@example.org
* sip:user@example.org;transport=tls
When using a sips URI, Asterisk checks incoming INVITEs and answers from
the other side for sips URIs, and rejects the packet if there are only
sip URIs. So Asterisk should only generate a sips Contact URI if the
other side supports it.
This patch makes Asterisk generate either a sip or sips Contact URI
depending on the format of the server URI.
If you want a sip URI, use:
server_uri=sip:example.org\;transport=tls
If you want a sips URI, use:
server_uri=sips:example.org
ASTERISK-25990 #close
Reported-by: Sebastian Damm
Change-Id: I5ae57d6531ce940b5fc64d5cd2673e60db0f9ba2
When reloading, or fetching realtime data, if the "apply" failed for any
numerous reasons the current state object would not be maintained. This
potentially resulted in publishes being stopped for some states/clients when
they should not have been.
This patch makes it so the current state object is kept upon any type of reload/
fetch failures.
Change-Id: Iab6020c116d628ed2ae81183e987e2eaa3c90b30
It was possible for the explicit publish destroy function to be called without
the pjsip client ever being initialized. This fix checks to make sure there is
a client to destroy before attempting.
Change-Id: I8eea1bfa3bd472149bfc255310be2a6248688f5c
The same thing was happening in res_pjsip_publish_asterisk. When the library
was unloaded it did not unregister the object type from sorcery. Subsequent
loads resulted in a failed load due to the sorcery type already existing.
Change-Id: Ifdc25e94e4cd40bc5a19eb4d0a00b86c2e9fedc9
There were a few spots where the client object's reference was being leaked in
sip_outbound_publish_callback. This patch cleans up those leaks.
Change-Id: I485d0bc9335090f373026f77c548042e258461df
When res_pjsip_outbound_publish unloads it has to wait for all current
publishing objects to get done. However if the wait condition times out
then it does not fail the unload. This sometimes results in an infinite
loop check while unloading. This patch now fails the unload operation if
the condition times out.
Change-Id: Id57b8cbed9d61222690fcba1e4f18e259df4c7ec
From the issue reporter:
"res_pjsip_outbound_authenticator_digest builds a nonce that is a hash of
the timestamp, the source address, the source port, a server UUID that is
calculated at startup, and the authentication realm.
Rather than caching nonces that we create, we instead attempt to re-calculate
the nonce when receiving an incoming request with authentication. We then
compare the re-calculated nonce to the incoming nonce, and if they don't match,
then authentication has failed early.
The problem is that it is possible, especially when using TCP, to receive two
requests from the same endpoint but have differing source ports for those
requests. Asterisk itself commonly will use different source ports for
outbound TCP requests."
This patch removes the source port dependency when building the nonce.
ASTERISK-25978 #close
Change-Id: I871b5f4adce102df1c4988066283095ec509dffe
The default tls settings for pjproject only allow TLS 1, TLS 1.1 and TLS 1.2.
SSL is not allowed. So, even if you specify "sslv3" for a transport method,
it's silently ignored and one of the TLS protocols is used. This was a new
behavior of pjsip_tls_setting_default() in 2.4 (when tls.proto was added) that
we never caught.
Now we need to set tls.proto = 0 after we call pjsip_tls_setting_default().
This tells pjproject to set the socket protocol to match the method.
ASTERISK-26004 #close
Change-Id: Icfb55c1ebe921298dedb4b1a1d3bdc3ca41dd078
The res_pjsip_authenticator_digest, res_pjsip_endpoint_identifier_*
and res_pjsip_registrar modules should load ASAP
to avoid "No matching endpoint found" for legitimate endpoint.
ASTERISK-25994
Change-Id: Iac95d95ad031e0be104189d29e923a2ad7c24a1b
This patch modified pjsip_options to retrieve only
permament contacts for aor if the qualify_frequency is > 0
and persisted contacts if the qualify_frequency is > 0.
This patch also fixed a bug in res_sorcery_astdb.
res_sorcery_astdb doesn't save object data retrived from astdb.
ASTERISK-25826
Change-Id: I1831fa46c4578eae5a3e574ee3362fddf08a1f05
With the old SIP module AMI sends PeerStatus event on every
successfully REGISTER requests, ie, on start registration,
update registration and stop registration.
With PJSIP AMI sends ContactStatus only when status is changed.
Regarding registration:
on start registration - Created
on stop registration - Removed
but on update registration nothing
This patch added contact.updated event.
ASTERISK-25904
Change-Id: I8fad8aae9305481469c38d2146e1ba3a56d3108f
