In the SIP channel driver chan_sip, the default is "auto_force_rport". When no
NAT was detected, for example in case of IPv6, Asterisk uses the IP address
from the headers within the SIP-REGISTER for subsequent SIP signaling. When
the remote party specifies support for Symmetric Response (RFC 3581) via the
parameter "rport", Asterisk should not extract the port from the SIP headers
but reuse the port of the transport. This did not happen because of a typo.

ASTERISK-26438 #close

Change-Id: If6e7891848aaf96666dee5305695f7c6667cd5a6

For the channel driver chan_sip, you specify externhost=example.com in sip.conf
when your Asterisk is behind a NAT and your IP address is assigned dynamically.
Or stated differently: You do not have a static IP address to use "externaddr"
directly. This NAT support is quite handy but just about IPv4. Previously,
Asterisk resolved "externhost" to any IP version. When the first DNS answer
resolved to an IPv6, Asterisk sent an IPv6 in SIP/SDP for origin (o=) and
connection (c=). This happened in outgoing SIP-REGISTER and while answering
SIP-INVITE. If the remote peer is IPv4-only, it might not handle o=/c= with an
IPv6. This change makes sure, no IPv6 is resolved anymore for "externhost".

ASTERISK-18232 #close
Reported by: Jacek Kowalski
Tested by: Alexander Traud
patches:
 changes.patch submitted by Alessandro Crespi

Change-Id: If68eedbeff65bd1c1d8a9ed921c02ba464b32dac

Users upgrading from asterisk 13.5 to a later version and who use
realtime with peers that have mailboxes were experiencing runaway
situations that manifested as a continuous stream of taskprocessor
congestion errors, memory leaks and an unresponsive chan_sip.

A related issue was that setting rtcachefriends=no NEVER worked in
asterisk 13 (since the move to stasis).  In 13.5 and earlier, when a
peer tried to register, all of the stasis threads would block and
chan_sip would again become unresponsive.  After 13.5, the runaway
would happen.

There were a number of causes...
* mwi_event_cb was (indirectly) calling build_peer even though calls to
  mwi_event_cb are often caused by build_peer.
* In an effort to prevent chan_sip from being unloaded while messages
  were still in flight, destroy_mailboxes was calling
  stasis_unsubscribe_and_join but in some cases waited forever for the
  final message.
* add_peer_mailboxes wasn't properly marking the existing mailboxes
  on a peer as "keep" so build_peer would always delete them all.
* add_peer_mwi_subs was unsubscribing existing mailbox subscriptions
  then just creating them again.

All of this was causing a flood of subscribes and unsubscribes on
multiple threads all for the same peer and mailbox.

Fixes...
* add_peer_mailboxes now marks mailboxes correctly and build_peer only
  deletes the ones that really are no longer needed by the peer.
* add_peer_mwi_subs now only adds subscriptions marked as "new" instead
  of unsubscribing and resubscribing everything.  It also adds the peer
  object's address to the mailbox instead of its name to the subscription
  userdata so mwi_event_cb doesn't have to call build_peer.

With these changes, with rtcachefriends=yes (the most common setting),
there are no leaks, locks, loops or crashes at shutdown.

rtcachefriends=no still causes leaks but at least it doesn't lock, loop
or crash.  Since making rtcachefriends=no work wasnt in scope for this
issue, further work will have to be deferred to a separate patch.

Side fixes...
 * The ast_lock_track structure had a member named "thread" which gdb
   doesn't like since it conflicts with it's "thread" command.  That
   member was renamed to "thread_id".

ASTERISK-25468 #close

Change-Id: I07519ef7f092629e1e844f855abd279d6475cdd0

HANGUPCAUSE not return 'SIP 200 Ok' when dialed channel answered.
This patch change the call order of ast_queue_control_data
and ast_queue_control in chan_pjsip_incoming_response.

ASTERISK-26396 #close
Reported by: AaronAn
Tested by: AaronAn

Change-Id: Ide2d31723d8d425961e985de7de625694580be61

Change-Id I1cd33453c77c56c8e1394cd60a6f17bb61c1d957 Enable Session-Timers for
SIP over TCP (and TLS) also disables SIP retransmits in chan_sip for non-UDP
connections, allowing the TCP layer to handle the retransmits. Unfortunately,
this caused sessions to be terminated with a retransmit timeout becasue it
stopped at the point of the first retrans call.

This patch waits for the 64*T1 timer to expire instead.

ASTERISK-19968

Change-Id: I844f26801aada10bc94e9bebe6e151f0a8443204

Previously, the Contact was stored only on initial INVITE and on any
18X and 200. That meant that after re-INVITEs from *us* the Contact
could get updated, but after re-INVITEs from the *peer*, it did not.

This changeset fixes this inconsistency, properly allowing target
refreshes through re-INVITES (RFC3261, 12.2).

If your strictrtp setting allows it, this change allows you to switch
the source IP of a connected/calling device mid-call with a simple
re-INVITE from the new IP.

ASTERISK-26358 #close

Change-Id: Ibb8512054ab27c8c3d2514022568fde943bf2435

In some scenarios dialog_initialize_rtp can be called multiple times on
the same dialog.  This can cause RTP instances to be leaked along with
multiple file descriptors for each instance.

This change makes it so the existing RTP instances are destroyed and
not overwritten, stopping the memory leak.

ASTERISK-26272 #close
patches:
  ASTERISK-26272-13.patch submitted by Corey Farrell (license 5909)

Change-Id: Id529de1184c68f2f4d254ab41a1f458dafdb5f73

Following the Encrypt-all-the-things paradigm:

The user enters his SIP-URI and password. Thanks to DNS-NAPTR, the phone
determines SIP-over-TLS as preferred transport. In SIP/SDP, the phone starts
the call with a crypto attribute, but not as RTP/sAVP but the RTP/AVP profile
(sRTP is preferred aka optional; not mandatory). If the VoIP server does not
support sRTP and TLS, the phone shows an open padlock icon.

This paradigm is supported by several VoIP/SIP clients on default. Some
implementations even cannot be changed to RTP/sAVP. Therefore here, this
change allows Preferred sRTP for ingress. For egress, please, create a dial
plan which starts with RTP/SAVP, and when rejected tries again with RTP/AVP.

ASTERISK-20234 #close
Reported by: tootai
Tested by: tootai, Alexander Traud
patches:
 srtp_patches.diff submitted by Matt Jordan

Change-Id: I42cb779df3a9c7b3dd03a629fb3a296aa4ceb0fd

Certain SNOM phones send so-called "optional crypto" in their SDP body.
Regular SRTP setup looks like this:

    m=audio 64620 RTP/SAVP 8 0 9 99 3 18 4 101
    a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:...

SNOM-style "optional crypto" looks like this:

    m=audio 61438 RTP/AVP 8 0 9 99 3 18 4 101
    a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:...

A crypto line is supplied, but the m-line does not have SAVP.

When res_srtp.so is *not* loaded, then chan_sip.so treats the optional
crypto as regular RTP, but when res_srtp.so *is* loaded, it refuses the
incoming call with the following message:

    WARNING: process_sdp: Failed to receive SDP offer/answer with
    required SRTP crypto attributes for audio

For platforms that want to start providing SRTP this presents a
compatibility problem.

This changeset lets chan_sip handle the SDP as if no crypto-line was
supplied: i.e. accept the call as regular RTP, just like it did before
res_srtp was loaded.

Now you'll get this informative warning instead:

    WARNING: Ignoring crypto attribute in SDP because RTP transport is
    insecure

ASTERISK-23989 #close
Reported by: Olle Johansson

Change-Id: I91a15ae05a0296e398d6b65f53bb11afde1d80e2

Starting from draft 2 of RFC 5456 (October 23, 2006) plaintext auth
is not supported in IAX2 protocol. Please refer to section 8.6.13 of
RFC 5456.

But plaintext auth is still supported by Asterisk implementation of IAX2.
This support should be dropped.

Patch, based on asterisk-dev discussion, adds deprecation warning on
startup if 'auth' is set to 'plaintext', changes default values of
'auth' from 'md5, plaintext' to 'md5'.

Patch is safe in terms of backwards compatibility, will work even if
remote peers have auth=plaintext and we have defaults.

auth=plaintext setting will remain deprecated in Asterisk 14 and 15,
and IAX2 plaintext support will be removed in Asterisk 16.

ASTERISK-22820 #close

Change-Id: I5d2f3830cb57645604818f87518916e8a5c317bf

Historically, Asterisk has always specified annexb=no for the g729 format.
However, when using res_pjsip no format attribute was specified. This patch
makes it so the SDP now contains a format attribute line with annexb=no.

Note, that this means only g729a is negotiated. Even for pass through support.
According to rfc7261 the type of annex used (a or b) is dependent upon the
answerer. However, Asterisk being a back to back user agent makes this tricky
to support at this time, thus we only allow annex 'a' for now.

ASTERISK-26228 #close
patches:
  res_format_attr_g729.c submitted by Jason Parker (license 4993)

Change-Id: I76bc20cc0a01af01536e9915afef319c269c22d0

This updates func_channel.c and main/message.c to use a generic xpointer
include instead of including info from each channel driver.  Now the
name attribute of info is CHANNEL or CHANNEL_EXAMPLES to be included in
documentation for func_channel.  Setting the name attribute of info to
MessageToInfo or MessageFromInfo causes it to be included in the
MessageSend application and AMI action.

Change-Id: I89fd8276a3250824241a618009714267d3a8d1ea

Packets are read regulary, when there is no data in buffer fr->frametype
is AST_FRAME_NULL. There was no check of frametype and lastrtprx always 
updated and, therefore, rtptimeout did not work at all.

ASTERISK-25270 #close

Change-Id: If3b5ca0dbb822582a86eb7d01dcae4e83448c41d

* Following the example of the PJSIP channel driver, the channel
  technology specific documentation has been moved to the respective
  channel drivers that provide that functionality. This has the benefit
  of locating the documentation of items with those modules that provide
  it.

* Examples of using the CHANNEL function for both standard items as well
  as for PJSIP have been added.

* The 'max_forwards' standard item has been documented.

Change-Id: Ifaa79a232c8ac99cf8da6ef6cc7815d398b1b79b

This patch adds a new PJSIP specific dialplan function,
PJSIP_SEND_SESSION_REFRESH. When invoked on a PJSIP channel, the media
session will be refreshed via either an UPDATE or re-INVITE request.
When used in conjunction with the PJSIP_MEDIA_OFFER dialplan function,
the formats in use on a PJSIP channel can be re-negotiated and changed
dynamically after call setup.

ASTERISK-26277 #close

Change-Id: Ib98fe09ba889aafe26d58d32f0fd1323f8fd9b1b
(cherry picked from commit eec60dd7)

Asterisk defaults to timers=accept/refresher=uas. In that scenario, only in that
scenario, Sessions-Timers (RFC 4028) had no effect via TCP. This change enables
Session-Timers for SIP over TCP (and for SIP over TLS).

However with longer international calls via TCP, the SIP channel might break,
because all hops on the Internet route must stay online (have not a single power
outage, for example). Therefore with Session-Timers enabled (which are enabled
at default), you might see dropped calls. Consequently even with this change,
you might be better-off going for session-timers=refuse in your sip.conf.

ASTERISK-19968 #close

Change-Id: I1cd33453c77c56c8e1394cd60a6f17bb61c1d957

sip_show_channels locks the dialogs container first then locks each
sip_pvt so it can spit out the details.  The rest of sip dialog
processing locks the sip_pvt first then locks the dialogs container
if it needs to.  Both lock in the order they need but deadlocks can
result.  To fix, sip_show_channels and sip_show_channelstats have
been converted to use an iterator rather than ao2_callback.  This way
the container is locked only while getting the next entry and is
unlocked when the callback is called.

ASTERISK-23013 #close

Change-Id: Id9980419909e811f89484950ed46ef117b9eb990

ASTERISK-26190 #close

Change-Id: I11326d80edd656524a51a19450e586c583aa0a0b

The dahdi_handle_dtmf() and my_handle_dtmf() have the potential to
deadlock if an incoming fax happens during the Playback or similar
application.

* Fixed the potential deadlock by not calling ast_async_goto() with the
channel lock held.

ASTERISK-26216 #close
Reported by: Richard Mudgett

Change-Id: I9144b84ade5f96690996624ec8a2d40c56af40aa

The sip_read() has the potential to deadlock if an incoming fax happens
during the Playback or similar application.

* Fixed the potential deadlock by not calling ast_async_goto() with the
channel lock held.

* Made always eat the fax detection frame whether there is a fax extension
or not.

ASTERISK-26216
Reported by: Richard Mudgett

Change-Id: I6d3f5cccd4b77c3aa6ffc1a54c0f6bde61c9278e

The chan_pjsip_cng_tone_detected() has the potential to deadlock if an
incoming fax happens during the Playback or similar application.

* Fixed the potential deadlock by not calling ast_async_goto() with the
channel lock held.

* Made always eat the fax detection frame whether there is a fax extension
or not.

ASTERISK-26216
Reported by: Richard Mudgett

Change-Id: I32aecbb4818af646dc5a619f0dc040e9b1f222e5

The new option allows the channel driver's faxdetect option to timeout on
a call after the specified number of seconds into a call.  The new feature
is disabled if the timeout is set to zero.  The option is disabled by
default.

* Don't clear dsp_features after passing them to the dsp code in
my_pri_ss7_open_media().  We should still remember them especially for the
new faxdetect_timeout option.

ASTERISK-26214
Reported by: Richard Mudgett

Change-Id: Ieffd3fe788788d56282844774365546dce8ac810

The new endpoint option allows the PJSIP channel driver's fax_detect
endpoint option to timeout on a call after the specified number of
seconds into a call.  The new feature is disabled if the timeout is set
to zero.  The option is disabled by default.

ASTERISK-26214
Reported by: Richard Mudgett

Change-Id: Id5a87375fb2c4f9dc1d4b44c78ec8735ba65453d

If AST_TEST_DEFINE is not conditional to TEST_FRAMEWORK it produces dead
code.  This places all existing unit tests into a conditional block if
they weren't already.

ASTERISK-26211 #close

Change-Id: I8ef83ee11cbc991b07b7a37ecb41433e8c734686

Cleanup the peer reference when stasis_subscription_final_message is
true.  Also free peer_name even if peer exists, after reload a new
peer_name will be allocated.

ASTERISK-26193 #close

Change-Id: If7ecd52facdc5c227f701c760841e3f6ca53cc69

* get_sip_pvt_from_replaces leaks sip_pvt_ptr on any error.
* build_peer leaks peer on failure to allocate the endpoint.

This patch fixes get_sip_pvt by using an RAII_VAR, build_peer is fixed
with an unref in the appropriate place.

ASTERISK-26184 #close

Change-Id: I728b424648ad041409f7d90880f4c28b3ce2ca12

Some T.38 implementations may send another re-invite after the initial
one which adds additional negotiation details (such as the max bitrate).
Currently this will fail when passthrough is being done in chan_sip as we
do nothing if T.38 is already active.

Other handlers of T.38 inside of Asterisk (such as res_fax) handle this
scenario so this change adds support for it to chan_sip and res_pjsip_t38.
If a request to negotiate is received while T.38 is already enabled a
new re-INVITE is sent and negotiation is done again.

ASTERISK-26179 #close

Change-Id: I0298494d3da6df3219bbfa4be9aa04015043145c

pjsip_inv_end_session() is documented as being able to return the
passed in tdata parameter set to NULL on success.

Change-Id: I09d53725c49b7183c41bfa1be3ff225f3a8d3047

gcc 6.1.1 caught a few more issues.
Made sure the unit tests still pass for the func_env and stdtime
issues.

ASTERISK-26157 #close

Change-Id: I6664d8f34a45bc1481d2a854481c7878b0c1cf8e

This change removes hardcoded SDP parsing and generation for
Siren7 and Siren14 from chan_sip and moves it to format attribute
modules so it can also be used by chan_pjsip.

With this the fmtp lines for both are added with the bitrate
information.

ASTERISK-26021

Change-Id: Ibb004eda37a14c0a35ef0613f6237977fc800037

A code block only enabled when HAVE_PKTINFO is not defined (FreeBSD)
was using a pointer to a pointer as the destination of a memcpy and a
'&' instead of '*' in the sizeof.

ASTERISK-26138 #close

Change-Id: Id4927ff256c0e470bdf7bcfc025146a2f656e708

bridge_native_rtp can call into an RTP-capable channel driver in order
for the driver to update information about who the channel is
communicating with. For SIP channel drivers, this means deactivating
RTCP and sending a reinvite so that the endpoints can communicate
directly.

bridge_native_rtp does the right thing and has the channel locked when
calling into the channel driver. chan_pjsip can't alter session
properties in this thread, though. chan_pjsip queues a task on the
session serializer in order to update properties there.

The problem is that this queued task was not locking the channel. This
meant that the queued task could attempt to deactivate RTCP at the same
time that the channel thread was attempting to process an incoming RTCP
packet. This could lead to a crash.

This patch fixes the issue by locking the channel in the queued task
when altering RTP properties.

ASTERISK-26092 #close
Reported by Niklas Larsson

Change-Id: I3464e226a3c41f6b915f97891e07fa1599e2a159

A change to glibc 2.22 changed the order of the sockadddr_storage
members which caused the places where we do an initialization of
ast_sockaddr with '{ { 0, 0, } }' to fail compilation.  Those
initializers (which we shouldn't have been using anyway) have been
replaced with memsets.

Change-Id: Idd1b3b320903d8771bfe221f0b015685de628fa4

POSIX defines signal.h. sys/signal.h should not be used as it is
c-library internal header which may or may not exist. Notably with
musl it generates warning of being incorrect.

Change-Id: Ia56b0aa1d84b5c590114867b1b384a624f39a6fc

This saves around 100 bytes when G.711, G.722, G.729, and GSM are advertised in
SDP. This reduces the chance to hit the MTU bearer of 1300 bytes for SIP over
UDP, if many codecs are allowed in Asterisk. This new feature is enabled
together with the optional feature compactheaders=yes via the file sip.conf.

ASTERISK-25578 #close

Change-Id: I16491b1937862de26f84fa0ffe679a6bab925044

Currently chan_sip can give weird messages if the contacts don't
fit in the From: or To: headers. This fix changes the from,to and
invite variables to use ast_str, allocates and deallocates them and
resizes them if needed.

ASTERISK-26069 #close

Change-Id: I1b68fcbddca6f6cc7d7a92fe1cb0d5430282b2b3

Change the awkward and not as flexible UnicastRTP options format
From:
Dial(UnicastRTP/127.0.0.1[/[<engine>][/[<codec>]]])
To:
Dial(UnicastRTP/127.0.0.1[/[<options>]])

Where <options> can be standard Asterisk flag options:
c(<codec>) - Specify which codec/format to use such as 'ulaw'.
e(<engine>) - Specify which RTP engine to use such as 'asterisk'.

More option flags can be easily added later such as the codec's RTP
payload type to use when the codec does not have a static payload type
defined.

Change-Id: I0c297aaf09e2ee515536cb7437bb8042ff8ff3c9

ASTERISK-20527 #close

Change-Id: I659cf7f00836a09d09d146ad226a40477d731239

This adds a new parameter to the end of a multicast RTP dialing string.
This parameter defines the following options:

* i: Set the interface from which multicast RTP is sent
* l: Set whether multicast packets are looped back to the sender
* t: Set the TTL for multicast packets
* c: Set the codec to use for RTP

ASTERISK-26068 #close
Reported by Mark Michelson

Change-Id: I033b706b533f0aa635c342eb738e0bcefa07e219

* Fixed NULL crash potential if parameters are missing.

* Reordered some operations so further diagnostic messages can be
more helpful.

Change-Id: Ibbdc67a2496508cbfbfef0cf19c35177ae2fbd70