The escalator works by creating a set of startup commands in cli.conf
that set up logger channels and issue the debug commands for the
subsystems specified.  If asterisk is running when it is executed,
the same commands will be issued to the running instance.  The original
cli.conf is saved before any changes are made and can be restored by
executing '$prog --reset'.

The log output will be stored in...
$astlogdir/message.$uniqueid
$astlogdir/debug.$uniqueid
$astlogdir/dtmf.$uniqueid
$astlogdir/fax.$uniqueid
$astlogdir/security.$uniqueid
$astlogdir/pjsip_history.$uniqueid
$astlogdir/sip_history.$uniqueid

Some minor tweaks were made to chan_sip, and res_pjsip_history
so their history output could be send to a log channel as packets
are captured.

A minor tweak was also made to manager so events are output to verbose
when "manager set debug on" is issued.

Change-Id: I799f8e5013b86dc5282961b27383d134bf09e543

Change-Id: I0a5d56c7dcf327d60f86a4c25a23571733709fd0

After a SIP_CODEC_INBOUND in the dialplan, do not continue with cached formats
but remember the joint format. Cached formats contain default parameters,
often create an empty fmtp line. However, a joint format might have passed
format_get_joint(.) in a res_format_attr_* module (like Opus Codec) and
contain the resulting format parameters from a SDP negotiation.

ASTERISK-26691 #close

Change-Id: I35712d98a793d4c3efdd156cec57deab9014b1dc

The CHANNEL() dialplan function implementation for PJSIP allows
querying of PJSIP specific information. This used the channel
passed in to get the PJSIP session and associated information.
It is possible for this channel to be masqueraded and end
up as a different channel type by the time the information
request is actually acted upon.

This change retrieves the PJSIP session safely and accesses
data from it (including channel). This provides a guarantee
that the session and channel will not be altered when the
request is being acted upon.

ASTERISK-26673

Change-Id: I335e12b89e1820cafdd92b3e7526b8ba649eb7e6

unicast_rtp_request() could pass an uninitialized 'us' parameter to
ast_ouraddrfor().  If ast_ouraddrfor() returns an error then the 'us'
parameter may not get initialized.  Thus when the code tries to save the
'us' parameter to the local address we could try to copy a ridiculous
sized memory buffer and segfault.

* Made pass an initialized 'us' parameter to ast_ouraddrfor() and abort
the UnicastRTP channel request if it fails.

ASTERISK-26672

Change-Id: I1ef7a7c09f4da4f15dcb6de660d2bcac5f2a95c0

In some situations TCP threads may become frozen.  This creates the
possibility that Asterisk could segfault if they become unfrozen after
chan_sip has been dlclose'd.  This reorders the unload_module process to
allow abort if threads do not exit within 5 seconds.

High level order as follows:
1) Unregister from the core to stop new requests.
2) Signal threads to stop
3) Clear config based tables (but do not free the table itself).
4) Verify that threads have shutdown, cancel unload if not.
5) Clean all remaining resources.

ASTERISK-26586

Change-Id: Ie23692041d838fbd35ece61868f4c640960ff882

Caused by ASTERISK-25494

Change-Id: I1fc408c1a083745ff59da5c4113041bbfce54bcb

The conditional expressions of the 'if' operators
situated alongside each other are identical.

Change-Id: I652b6dcddb3be007e669a6aa8107edb31a1ddafb

P is always true. We check it before

Change-Id: Iee61cda002a9f61aee26b9f66c5f9b59e3389efb

The conditional expressions of the 'if' operators situated
alongside each other are identical.

Change-Id: I2cf7c317b106ec14440c7f1b5dcfbf03639f748a

RFC says SIP headers look like:

    HCOLON  =  *( SP / HTAB ) ":" SWS
    SWS     =  [LWS]                    ; sep whitespace
    LWS     =  [*WSP CRLF] 1*WSP        ; linear whitespace
    WSP     =  SP / HTAB                ; from rfc2234

chan_sip implemented this:

    HCOLON  =  *( LOWCTL / SP ) ":" SWS
    LOWCTL  = %x00-1F                   ; CTL without DEL

This discrepancy meant that SIP proxies in front of Asterisk with
chan_sip could pass on unknown headers with \x00-\x1F in them, which
would be treated by Asterisk as a different (known) header.  For
example, the "To\x01:" header would gladly be forwarded by some proxies
as irrelevant, but chan_sip would treat it as the relevant "To:" header.

Those relying on a SIP proxy to scrub certain headers could mistakenly
get unexpected and unvalidated data fed to Asterisk.

This change fixes so chan_sip only considers SP/HTAB as valid tokens
before the colon, making it agree on the headers with other speakers of
SIP.

ASTERISK-26433 #close
AST-2016-009

Change-Id: I78086fbc524ac733b8f7f78cb423c91075fd489b

The sending codec is switched to the receiving codec and then
is switched back to the best native codec on EVERY receiving RTP packets.
This is because after call of ast_channel_set_rawwriteformat there is call
of ast_set_write_format which calls set_format which sets rawwriteformat
to the best native format.

This patch adds a new function ast_set_write_format_path which set
specific write path on channel and uses this function to switch
the sending codec.

ASTERISK-26603 #close

Change-Id: I5b7d098f8b254ce8f45546e6c36e5d324737f71d

Per RFC 7118 5.2, the SIP URI 'transport' parameter should advertise
'ws' when WebSockets are to be used as the transport. This applies to
both secure and insecure WebSockets.

There were two bugs in Asterisk with respect to this:

(1) The most egregious occurs in res_pjsip. There, we advertise 'ws' for
    insecure websockets and 'wss' for secure websockets. While this
    would seem to make sense - since 'WS' and 'WSS' are used for the Via
    Transport parameter - this is not the case for the SIP URI. This
    patch corrects that by registering the secure websockets with
    pjproject using the shorthand 'WS', and by returning 'ws' when asked
    for the transport parameter. Note that in pjproject, it is perfectly
    valid to have multiple transports use the same shorthand.

(2) In chan_sip, we return an upper-case version of the transport 'WS'
    instead of 'ws'. Since we should be strict in what we send and
    liberal in what we accept (within reason), this patch lower-cases
    the transport before appending it to the parameter.

ASTERISK-24330 #close
Reported by: cervajs, Inaki Baz Castillo

Change-Id: Iff77b645f8cc3b7cd35168a6676c26b147f22f42

If a TCP/TLS connection was pending (not accepted and not timed out) during
unload of chan_sip, Asterisk would segfault when trying to send a signal to
a thread whose thread ID hadn't been recorded yet. This commit fixes that by
recording the thread ID before calling the blocking connect() syscall.
This was a regression introduced by 776a1438.

The above wasn't enough to fix the segfault, which was now delayed to the
point where connect() timed out. Therefore, it was necessary to also remove
the SA_RESTART flag from the SIGURG sigaction so that pthread_kill() could be
used to interruput the connect() syscall.
This was a regression introduced by 5d313f51.

ASTERISK-26586 #close

Change-Id: I76fd9d47d56e4264e2629bce8ec15fecba673e7b

fopencookie/funclose is a non-standard API and should not be used
in portable software. Additionally, the way FILE's fd is used in
non-blocking mode is undefined behaviour and cannot be relied on.

This introduces internal abstraction for io streams, that allows
implementing the desired virtualization of read/write operations
with necessary timeout handling.

ASTERISK-24515 #close
ASTERISK-24517 #close

Change-Id: Id916aef418b665ced6a7489aef74908b6e376e85

Fix ASTERISK-26565 by adding ast_rtp_instance_stop before
rtp instance destroy for chan_unistim. Also several fixes
for displayed text translation.

Change-Id: If42a03eea09bd1633471406bdc829cf98bf6affc

Correct typo of end-pints to end-points
Re-wrap session timer parameter docs to max 80 chars wide; this
eases reading on terminals with lower resolution, commonly the case
for those with visual impairments.

ASTERISK-26573

Change-Id: I22c94459f4bb6b8a2f6713cfd22e87c32f204e6b
Signed-off-by: C.J. Collier <cjcollier@linuxfoundation.org>

This reverts commit 93332cb1.

Unfortunately, the aforementioned commit caused a regression (incoming calls
would eventually disconnect). Thus it is being removed.

ASTERISK-26523 #close
ASTERISK-25270

Change-Id: Ibf5586adc303073a8eac667a4cbfdb6be184a64d

Added missing account to AMI event of sip show peers

ASTERISK-26176 #close

Change-Id: Ieb6c2c80a838a1b59c82103eba4c63ba238dc482

If in sip.conf (general section) set option register_retry_403=no,
the command "sip show settings" return value:
Outbound reg. retry 403:0
If in sip.conf (general section) set option register_retry_403=yes,
the command "sip show settings" return value:
Outbound reg. retry 403:-1

* In static char "sip show settings" for "Outbound.reg. retry 403"
option use AST_CLI_YESNO

ASTERISK-26476 #close

Change-Id: I3c14272f05f1067bd2aeaa8b3ef9cf8fcb12dcf9

Support for referring to DAHDI channels by logical names was added in
(FIXME: when? Asterisk 11? 1.8?) and was intended to be part of support
of refering to channels by name.

While technically usable, it has never been properly supported in
dahdi-tools, as using it would require many changes at the Asterisk
level. Instead logical mapping was added at the kernel level.

Thus it seems that refering to DAHDI channels by name is not really used
by anyone, and therefore should probably be removed.

Change-Id: I7d50bbfd9d957586f5cd06570244ef87bd54b485

ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.

Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename

This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled.  This variable was only used in lock.c so it
is now initialized in that file only.

ASTERISK-26480 #close

Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966

When channel format changes occurred as a result of an RTP
re-negotiation the bridge was not informed this had happened.
As a result the bridge technology was not re-evaluated and the
channel may have been in a bridge technology that was incompatible
with its formats. The bridge is now unbridged and the technology
re-evaluated when this occurs.

The chan_pjsip module also allowed asymmetric codecs for sending
and receiving. This did not work with all devices and caused one
way audio problems. The default has been changed to NOT do this
but to match the sending codec to the receiving codec. For users
who want asymmetric codecs an option has been added, asymmetric_rtp_codec,
which will return chan_pjsip to the previous behavior.

The codecs returned by the chan_pjsip module when queried by
the bridge_native_rtp module were also not reflective of the
actual negotiated codecs. The nativeformats are now returned as
they reflect the actual negotiated codecs.

ASTERISK-26423 #close

Change-Id: I6ec88c6e3912f52c334f1a26983ccb8f267020dc

On heavy loaded system the TCP/TLS incoming calls could be
disconnected by pjproject while these calls are being
processed by asterisk.

This patch uses functions pjsip_inv_add_ref/pjsip_inv_dec_ref
to inform pjproject that an INVITE session is in use.

ASTERISK-26482 #close

Change-Id: Ia2e3e2f75358cdb530252a9ce158af3d5d9fdf33

ASTERISK-26439

Change-Id: I7f5ee2eeba8906e9ecb3293dbe3a747770bb5011

Previously, the settings videosupport=always and videosupport=yes behaved
identically and unconditionally caused a video offer to be sent in the SDP on
an outgoing call. This was a regression introduced with commit
5a1d90e1 in Asterisk 1.6.1.

This commit restores correct behavior: videosupport=always causes a video offer
to be sent unconditionally, while videosupport=yes will only offer video on an
outbound channel if the incoming channel it is bridged to also supports video.
That way, the device receiving the outgoing call can display the correct user
interface elements for audio or video and will not unnecessarily show a blank
video window on an audio-only call.

ASTERISK-17470 #close

Change-Id: I782f4409d436114dbc97061c3570c0cd24f7c3ae

In the SIP channel driver chan_sip, auto_comedia was expected to be used in
tandem with auto_force_rport. Or stated differently: Only when auto_force_rport
was chosen (the default), auto_comedia worked. This change allows auto_comedia
to be set independently of the state of (auto_)force_rport. For example,
nat=force_rport,auto_comedia is useful for IPv4/IPv6 Dual Stack deployments
when IPv6 clients are behind a Firewall.

ASTERISK-26457 #close

Change-Id: Ib29d66c6dbb61648e371e01fc36c6978ddae5bc2

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