MODULEINFO is checked while buidling/linking the module.
AST_MODULE_INFO is checked while loading/running the module.

ASTERISK-28838

Change-Id: I4bb868532ca217fec1351885d99eb55c21b58042

ASTERISK-28838

Change-Id: I34724e799e1ffaf723eb2c358abe8934dbadcd52

ASTERISK-28838

Change-Id: Icb08304744ae3f34dce6ccb76f94379b8382a074

When the receive buffer was flushed by a received packet while it
already contained a packet with the same sequence number, Asterisk
never left the while loop which tried to order the packets.

This change makes it so if the packet is in the receive buffer it
is retrieved and freed allowing the buffer to empty.

ASTERISK-28827

Change-Id: Idaa376101bc1ac880047c49feb6faee773e718b3

When the ast_data_buffer_put rejects to add a packet, for example because
the buffer already contains a packet with the same sequence number, the
payload will never be freed, resulting in a memory leak.

The data buffer will now return an error if this situation occurs
allowing the caller to free the payload. The res_rtp_asterisk module
has also been updated to do this.

ASTERISK-28826

Change-Id: Ie6c49495d1c921d5f997651c7d0f79646f095cf1

When the first DTMF receive in RF2833 codec have TimeStamp at 0
is not processed.

ASTERISK-28812

Change-Id: I3196803a062dd2daee4938c9a778c3810cb7e504

Change-Id: Idba5151a3079f9dcc0076d635422c5df5845114f

Change-Id: I40c014c2cb88e943cf6f1b99a08c7c885e855b3a

By using pjproject to give us a list of candidates, and then filtering,
if the host has >32 addresses configured, then it is possible that we
end up filtering out all 32 of those, and ending up with no candidates
at all.  Instead, get getifaddrs (which pjsip is using underlying
anyway) to retrieve all local addresses, and iterate those, adding the
first 32 addresses not excluded by the ICE ACL.

In our setup at any point in time We've got between 6 and 328 addresses
on any given system.  The lower limit is the lower limit but the upper
limit is growing on a near daily basis currently.

Change-Id: I109eaffc3e2b432f00bf958e3caa0f38cacb4edb
Signed-off-by: Jaco Kroon <jaco@uls.co.za>

Change-Id: I7fa7c5c8a7ddb0bd525982f58bff3264ebbd9a1b

Change-Id: Ifc5059cd867e77b9c92ed9f4b895a9a91200d3ec

ASTERISK-28809

Change-Id: I269731715347c8e5ef7db1b6ffd3f8d15fc04be4

This reverts commit a3a2fbae.

Reason for revert: There is a lot of code that relies on the broken
behavior that this fixes.

Change-Id: I410c395a0168acbdaf89e616e3cb5e1312d190cb

When an AOR is modified endpoints are updated that reference
the AOR so they can start receiving updates and reflect the
correct state. If this is the case then we shouldn't change
the endpoint to be offline if it does not reference the AOR
but instead only when the endpoint is completely updated for
all its AORs.

ASTERISK-28056
patches:
  pjsip_options-aor.diff submitted by jhord (license 6978)

Change-Id: I3ee00023be2393113cd4e056599f23f3499ef164

This unit test runs through combinations of...
	* Local codecs
	* Remote Codecs
	* Codec Preference
	* Incoming/Outgoing

A few new APIs were created to make it easier to test
the functionality but didn't result in any actual
functional change.

ASTERISK_28777

Change-Id: Ic8957c43e7ceeab0e9272af60ea53f056164f164

Based on this new endpoint setting, a joint list of preferred codecs
between those received from the Asterisk core (remote), and those
specified in the endpoint's "allow" parameter (local) is created and
is used to create the outgoing SDP offer.

* Add outgoing_call_offer_pref to pjsip_configuration (endpoint)

* Add "call_direction" to res_pjsip_session.

* Update pjsip_session_caps.c to make the functions more generic
  so they could be used for both incoming and outgoing.

* Update ast_sip_session_create_outgoing to create the
  pending_media_state->topology with the results of
  ast_sip_session_create_joint_call_stream().

* The endpoint "preferred_codec_only" option now automatically sets
  AST_SIP_CALL_CODEC_PREF_FIRST in incoming_call_offer_pref.

* A helper function ast_stream_get_format_count() was added to
  streams to return the current count of formats.

ASTERISK-28777

Change-Id: Id4ec0b4a906c2ae5885bf947f101c59059935437

This change provides functions that take in a JSON payload, verify that
the contents contain all the mandatory fields and required values (if
any), and signs the payload with the private key. Four fields are added
to the payload: x5u, attest, iat, and origid. As of now, these are just
placeholder values that will be set to actual values once the logic is
implemented for what to do when an actual payload is received, but the
functions to add these values have all been implemented and are ready to
use. Upon successful signing and the addition of those four values, a
ast_stir_shaken_payload is returned, containing other useful information
such as the algorithm and signature.

Change-Id: I74fa41c0640ab2a64a1a80110155bd7062f13393

RFC5621 requires any content type with a Content-Disposition
with handling=required to be rejected with a 415 response

ASTERISK-28782 #close

Change-Id: Iad969df75936730254b95c1a8bc3b48497070bb4

When an outgoing channel is created a list of formats may
optionally be provided which is used as a request that the
formats be used if possible. If an endpoint is not configured
for any of the formats we ignore this request and use what is
configured. This has the side effect of also including other
stream types (such as video) that were not present in the
requested formats.

This change makes it so that the intention of the request is
preserved - that is if only an audio format is requested then
even if there is no joint audio format between the request and
the configuration we will still only place an audio stream in
the outgoing call.

ASTERISK-28787

Change-Id: Ia54c0c63e94aca176169b9bae4bb8a8380ea245f

ASTERISK-28790

Change-Id: I10df52f98b19ed62575f25dab36e82d136dccd99

This commit sets up some of the initial framework for the module and
adds a way to read the private key from the specified file, which will
then be appended to the certificate object. This works fine for now, but
eventually some other structure will likely need to be used to store all
this information. Similarly, the caller_id_number is specified on the
certificate config object, but in the end we will want that information
to be tied to the certificate itself and read it from there.

A method has been added that will retrieve the private key associated
with the caller_id_number passed in. Tab completion for certificates and
stores has also been added.

Change-Id: Ic4bc1416fab5d6afe15a8e2d32f7ddd4e023295f

When examining a stream to determine hold/unhold information we
only care about the default audio stream. Other streams aren't
used for hold/unhold.

ASTERISK-28784

Change-Id: I7a1f10f07822c4aee1f98a38b9628849b578afe4

When the Asterisk receives 200 OK with invalid SDP,
the Asterisk/PJPROJECT terminating the session.
But if the channel was in the Bridge, Asterisk tries send
the Re-Invite before terminating the session.
And when the Asterisk sending the Re-Invite, it doesn't check
the SDP is NULL or not. This crashes the Asterisk.

Fixed it to close the session correctly if the UAS sends the
200 OK with wrong SDP.

ASTERISK-28743

Change-Id: Ifa864e0e125b1a7ed2f3abd4164187e1dddc56da

The state of the default audio stream is used for hold/unhold so we
restrict it to sendrecv as the core does not handle when it changes as
a result of hold/unhold.

This restriction does not apply to other media types though so we now
only restrict it to audio. This allows the other default streams to
store their state at all values, and not just sendrecv and removed.

ASTERISK-28783

Change-Id: I139740f38cea7f7d92a876ec2631ef50681f6625

Do not hang up a PJSIP channel on RTP timeout if that channel is in
a direct-media bridge. Also reset the time of the last received RTP packet when
direct-media ends (wait full rtp_timeout period before checking first time after
audio came back to Asterisk).

ASTERISK-28774
Reported-by: Michael Neuhauser

Change-Id: I8b62012be7685849e8fb2b1c5dd39d35313ca2d1

A pure blacklist is not good enough, we need a whitelist mechanism as
well, and the simplest way to do that is to re-use existing ACL
infrastructure.

This makes it simpler to blacklist say an entire block (/24) except a
smaller block (eg, a /29 or even a /32).  Normally you'd need to
recursively split the block, so if you want to blacklist a /24 except
for a /29 you'd end up with a blacklit for a /25, /26, /27 and /28.  I
feel that having an ACL instead of a blacklist only is clearer.

Change-Id: Id57a8df51fcfd3bd85ea67c489c85c6c3ecd7b30
Signed-off-by: Jaco Kroon <jaco@uls.co.za>

bridge_p2p_rtp_write will forward rtp to the bridged rtp instance
without modifying the ssrc.  However, it is not updating the SSRC
in the bridged rtp.  Thus, when SSRC packets are generated, they
have the correct SSRC for the sender.

ASTERISK-28773 #close

Change-Id: I39f923bde28ebb4f0fddc926b92494aed294a478

If ICE support is enabled but not negotiated, the rtp->ice structure is
not being destroyed. This leads to Asterisk waiting for ICE to complete
instead of immediately starting the DTLS handshake, resulting in the
call leg having no RTP.

ASTERISK-28769 #close

Change-Id: I17c137546dc9ecfb9583c24dcf4c2ced8bbd7a27

This change introduce a CLI command for the RTP to display the general
configuration.

In the first step add the follow fields of the configurations:
  - rtpstart
  - rtpend
  - dtmftimeout
  - rtpchecksum
  - strictrtp
  - learning_min_sequential
  - icesupport

Change-Id: Ibe5450898e2c3e1ed68c10993aa1ac6bf09b821f

ASTERISK-28766 #close

Change-Id: I5ce2210062f9325db762edbf6e46075079bb2cd1

Add a new option, incoming_call_offer_pref, to res_pjsip endpoints that
specifies the preferred order of codecs after receiving an offer.

This patch does the following:

  Adds a new enumeration, ast_sip_call_codec_pref, used by the the new
configuration option that's added to the endpoint media structure.

  Adds a new ast_sip_session_caps structure that's set for each session media
object.

  Creates a new file, res_pjsip_session_caps that "implements" the new
structure and option, and is compiled into the res_pjsip_session library.

ASTERISK-28756 #close

Change-Id: I35e7a2a0c236cfb6bd9cdf89539f57a1ffefc76f

The receive buffer will now grow if we end up flushing the
receive queue after not receiving the expected packet in time.
This is done in hopes that if this is encountered again the
extra buffer size will allow more time to pass and any missing
packets to be received.

The send buffer will now grow if we are asked for packets and
can't find them. This is done in hopes that the packets are
from the past and have simply been expired. If so then in
the future with the extra buffer space the packets should be
available.

Sequence number cycling has been handled so that the
correct sequence number is calculated and used in
various places, including for sorting packets and
for determining if a packet is old or not.

NACK sending is now more aggressive. If a substantial number
of missing sequence numbers are added a NACK will be sent
immediately. Afterwards once the receive buffer reaches 25%
a single NACK is sent. If the buffer continues to grow and
reaches 50% or greater a NACK will be sent for each received
future packet to aggressively ask the remote endpoint to
retransmit.

ASTERISK-28764

Change-Id: I97633dfa8a09a7889cef815b2be369f3f0314b41

When a text message was received any associated variable was not written to
the ARI TextMessageReceived event. This occurred because Asterisk only wrote
out "send" variables. However, even those "send" variables would fail ARI
validation due to a TextMessageVariable formatting bug.

Since it seems the TextMessageReceived event has never been able to include
actual variables it was decided to remove the TextMessageVariable object type
from ARI, and simply return a JSON object of key/value pairs for variables.
This aligns more with how the ARI sendMessage handles variables, and other
places in ARI.

ASTERISK-28755 #close

Change-Id: Ia6051c01a53b30cf7edef84c27df4ed4479b8b6f

Update the state of remote_hold immediately on receipt of remote
SDP so that the information is available when building the SDP
answer

ASTERISK-28754 #close

Change-Id: I7026032a807e9c95081cb8f060400b05deb4836f

This change extends the Sorcery API to allow a wizard to be
told to explicitly reload objects or a specific object type
even if the wizard believes that nothing has changed.

This has been leveraged by res_pjsip and res_pjsip_acl to
reload endpoints and PJSIP ACLs when a named ACL changes.

ASTERISK-28697

Change-Id: Ib8fee9bd9dd490db635132c479127a4114c1ca0b

In order to retry outbound registrations for some situations, we
need access to the tdata from the original request.  For instance,
for 401/407 responses we need it to properly construct the
subsequent request with the authentication.  We also need it if
we're iterating over a DNS SRV response record set so we can skip
entries we've already tried.

We've been getting the tdata from the server response rdata and
transaction but that only works for the failures where there was
actually a response (4XX, 5XX, etc).  For timeouts there's no
response and therefore no rdata or transaction from which to get
the tdata.  When processing a single A/AAAA record for a server,
this wasn't an issue as we just retried that same server after the
retry timer expired.  If we got an SRV record set for the server
though, without the state from the tdata, we just kept trying the
first entry in the set repeatedly instead of skipping to the next
one in the list.

* Added a "last_tdata" member to the client state structure to keep
  track of the sent tdata.

* Updated registration_client_send() to save the tdata it used into
  the client_state.

* Updated sip_outbound_registration_response_cb() to use the tdata
  saved in client_state when we don't get a response from the
  server. We still use the tdata from the transaction when we DO
  get a response from the server so we can properly handle 4XX
  responses where our new request depends on it.

General note on timeouts:

Although res_pjsip_outbound_registration skips to the next record
immediately when a timeout occurs during SRV set traversal, it's
pjproject that determines how long to wait before a timeout is
declared.  As with other SIP message types, pjproject will continue
trying the same server at an interval specified by "timer_t1" until
"timer_b" expires.  Both of those timers are set in the pjsip.conf
"system" section.

ASTERISK-28746

Change-Id: I199b8274392d17661dd3ce3b4d69a3968368fa06

This change adds support to bridge_softmix to allow the addition
and removal of additional video source streams. When such a change
occurs each participant is renegotiated as needed to reflect the
update. If another video source is added then each participant
gets another source. If a video source is removed then it is
removed from each participant. This functionality allows you to
have both your webcam and screenshare providing video if you
desire, or even more streams. Mapping has been changed to use
the topology index on the source channel as a unique identifier
for outgoing participant streams, this will never change and
provides an easy way to establish the mapping.

The bridge_simple and bridge_native_rtp modules have also been
updated to renegotiate when the stream topology of a party changes
allowing the same behavior to occur as added to bridge_softmix.
If a screen share is added then the opposite party is renegotiated.
If that screen share is removed then the opposite party is
renegotiated again.

Some additional fixes are also included in here. Stream state is
now conveyed in SDP so sendonly/recvonly/inactive streams can
be requested. Removed streams now also remove previous state
from themselves so consumers don't get confused.

ASTERISK-28733

Change-Id: I93f41fb41b85646bef71408111c17ccea30cb0c5

When handling ICE negotiations, it's possible that there can be a delay
between STUN binding requests which in turn will cause a delay in ICE
completion, preventing media from flowing. It should be possible to send
media when there is at least one valid pair, preventing this scenario
from occurring.

A change was added to PJPROJECT that adds an optional callback
(on_valid_pair) that will be called when the first valid pair is found
during ICE negotiation. Asterisk uses this to start the DTLS handshake,
allowing media to flow. It will only be called once, either on the first
valid pair, or when ICE negotiation is complete.

ASTERISK-28716

Change-Id: Ia7b68c34f06d2a1d91c5ed51627b66fd0363d867

When moh_passthrough is used, asterisk is only generating invites
of type sendonly and sendrecv instead of taking fully into account
the on hold state of the local and remote parties

ASTERISK-28738 #close

Change-Id: Iaaad9fbc033cb14803d433b8a4071bc337047761

There was a race condition between client initiated DTLS setup, and handling
of server side ice completion that caused the underlying SSL object to get
cleared during DTLS initialization. If this happened Asterisk would be left
in a partial DTLS setup state. RTP packets were sent and received, but were
not being encrypted and decrypted. This resulted in no audio, or static.

Specifically, this occurred when '__rtp_recvfrom' was processing the handshake
sequence from the client to the server, and then 'ast_rtp_on_ice_complete'
gets called from another thread and clears the SSL object when calling the
'dtls_perform_setup' function. The timing had to be just right in the sense
that from the external SSL library perspective SSL initialization completed
(rtp recv), Asterisk clears/resets the SSL object (ice done), and then checks
to see if SSL is intialized (rtp recv). Since it was cleared, Asterisk thinks
it is not finished, thus not completing 'dtls_srtp_setup'.

This patch removes calls to 'dtls_perform_setup', which clears the SSL object,
in 'ast_rtp_on_ice_complete'. When ice completes, there is no reason to clear
the underlying SSL object. If an ice candidate changes a full protocol level
renegotiation occurs. Also, in the case of bundled ICE candidates are reused
when a stream is added. So no real reason to have to clear, and reset in this
instance.

Also, this patch adds a bit of extra logging to aid in diagnosis of any future
problems.

ASTERISK-28742 #close

Change-Id: I34c9e6bad5a39b087164646e2836e3e48fe6892f