check_via() already skips leading blanks where the sent-by address (with the
optional port) should be placed.

Since RFC 3261 allows for blanks between the port ant the Via parameters:
> https://tools.ietf.org/html/rfc3261#section-20.42
(actually it allows a lot of blanks more ;-)). I just switched from
ast_skip_blanks() to ast_strip() on the local copy of the string.

ASTERISK-21301 #close

Change-Id: Ie5b8fe5a07067b7c0dc9bcdd1707e99b23b02b06

Fix the reference leak introduced in the following commit:

c534bd58

ASTERISK-25849

Change-Id: I5cfefd5ee6c1c3a1715c050330aaa10e4d2a5e85

During a transfer involving direct media a race occurs between when the
transferer channel is swapped out, initiating rtp changes/updates, and the
subsequent reinvites.

When Alice, after speaking with Charlie (Bob is on hold), connects Bob and
Charlie invites are sent to each in order to establish the call between them.
Bob is taken off hold and Charlie is told to have his media flow through
Asterisk. However, if before those invites go out the bridge updates Bob's
and/or Charlie's rtp information with direct media data (i.e. address, port)
then the invite(s) will contain the remote data in the SDP instead of the
Asterisk data.

The race occurs in the native bridge glue code when updating the peer. The
direct_media_address can get set twice before sending out the first invite
during call connection. This can happen because the checking/setting of the
direct_media_address happened in one thread while the sending of the invite(s)
happened in another thread.

This fix removes the race condition by moving the checking/setting of the
direct_media_address to be in the same thread as the sending of the invites(s).
This serializes the checking/setting and sending so they can no longer happen
out of order.

ASTERISK-25849 #close

Change-Id: Idfea590175e74f401929a601dba0c91ca1a7f873

This patch is part of a series to resolve deadlocks in chan_sip.c.

Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event.  If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen.  The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event.  Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.

ASTERISK-25023 #close

Change-Id: I96d429c57a48861fd8bde63dd93db4e92dc3adb6

This patch is part of a series to resolve deadlocks in chan_sip.c.

Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event.  If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen.  The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event.  Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.

ASTERISK-25023

Change-Id: I2e40de89efc8ae6e8850771d089ca44bc604b508

This patch is part of a series to resolve deadlocks in chan_sip.c.

Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event.  If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen.  The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event.  Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.

* Made always run check_pendings() under the scheduler thread so scheduler
ids can be checked safely.

ASTERISK-25023

Change-Id: Ia834d6edd5bdb47c163e4ecf884428a4a8b17d52

This patch is part of a series to resolve deadlocks in chan_sip.c.

Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event.  If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen.  The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event.  Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.

ASTERISK-25023

Change-Id: If595e4456cd059d7171880c7f354e844c21b5f5f

This patch is part of a series to resolve deadlocks in chan_sip.c.

Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event.  If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen.  The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event.  Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.

ASTERISK-25023

Change-Id: I6d65269151ba95e0d8fe4e9e611881cde2ab4900

This patch is part of a series to resolve deadlocks in chan_sip.c.

Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event.  If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen.  The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event.  Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.

ASTERISK-25023

Change-Id: I9c11b9d597468f63916c99e1dabff9f4a46f84c1

This patch is part of a series to resolve deadlocks in chan_sip.c.

Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event.  If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen.  The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event.  Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.

* Fix clearing autokillid in __sip_autodestruct() even though we could
reschedule.

ASTERISK-25023

Change-Id: I450580dbf26e2e3952ee6628c735b001565c368f

This patch is part of a series to resolve deadlocks in chan_sip.c.

Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event.  If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen.  The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event.  Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.

* Fix retrans_pkt() to call check_pendings() with both the owner channel
and the private objects locked as required.

* Refactor dialog retransmission packet list to safely remove packet
nodes.  The list nodes are now ao2 objects.  The list has a ref and the
scheduled entry has a ref.

ASTERISK-25023

Change-Id: I50926d81be53f4cd3d572a3292cd25f563f59641

This patch is part of a series to resolve deadlocks in chan_sip.c.

Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event.  If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen.  The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event.  Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.

ASTERISK-25023

Change-Id: I98a694fd42bc81436c83aa92de03226e6e4e3f48

This patch is part of a series to resolve deadlocks in chan_sip.c.

* Make dialog_unlink_all() unschedule all items at once in the sched
thread.

ASTERISK-25023

Change-Id: I7743072fb228836e8228b72f6dc46c8cc50b3fb4

This patch is part of a series to resolve deadlocks in chan_sip.c.

The reordering of chan_sip's shutdown is to handle any immediate events
that get put onto the scheduler so resources aren't leaked.  The typical
immediate events at this time are going to be concerned with stopping
other scheduled events.

ASTERISK-25023

Change-Id: I3f6540717634f6f2e84d8531a054976f2bbb9d20

This patch is part of a series to resolve deadlocks in chan_sip.c.

Delaying destruction of the chan_sip sip_pvt structures caused the
/channels/chan_sip/test_sip_rtpqos unit test to crash.  That test
registers a special test ast_rtp_engine with the rtp engine module.  When
the unit test completes it cleans up by unregistering the test
ast_rtp_engine and exits.  Since the delayed destruction of the sip_pvt
happens after the unit test returns, the destructor tries to call the rtp
engine destroy callback of the test ast_rtp_engine auto variable which no
longer exists on the stack.

* Change the test ast_rtp_engine auto variable to a static variable.  Now
the variable can still exist after the unit test exits so the delayed
sip_pvt destruction can complete successfully.

ASTERISK-25023

Change-Id: I61e34a12d425189ef7e96fc69ae14993f82f3f13

Remove destructor calling destroy_it calling really_destroy_it
for no benefit.  Just make the destructor the really_destroy_it
function.

Change-Id: Idea0d47b27dd74f2488db75bcc7f353d8fdc614a

Change-Id: I90f04208a089f95488a2460185a8dbc3f6acca12

Configurations like "aors = a, b, c" were either ignoring everything after "a"
or trying to look up " b".  Same for mailboxes,  ciphers, contacts and a few
others.

To fix, all the strsep(&copy, ",") calls have been wrapped in ast_strip.  To
facilitate this, ast_strip, ast_skip_blanks and ast_skip_nonblanks were
updated to handle null pointers.

In some cases, an ast_strlen_zero() test was added to skip consecutive commas.

There was also an attempt to ast_free an ast_strdupa'd string in
ast_sip_for_each_aor which was causing a SEGV.  I removed it.

Although this issue was reported for realtime, the issue was in the res_pjsip
modules so all config mechanisms were affected.

ASTERISK-25829 #close
Reported-by: Mateusz Kowalski

Change-Id: I0b22a2cf22a7c1c50d4ecacbfa540155bec0e7a2

Previous chan_sip behavior:

Before this patch chan_sip would always strip any quotes from an incoming
reason and pass that value up as the REDIRECTING(reason).  For an outgoing
reason value, chan_sip would check the value against known values and
quote any it didn't recognize.  Incoming 480 response message reason text
was just assigned to the REDIRECTING(reason).

Previous chan_pjsip behavior:

Before this patch chan_pjsip would always pass the incoming reason value
up as the REDIRECTING(reason).  For an outgoing reason value, chan_pjsip
would send the reason value as passed down.

With this patch:

Both channel drivers match incoming reason values with values documented
by REDIRECTING(reason) and values documented by RFC5806 regardless of
whether they are quoted or not.  RFC5806 values are mapped to the
equivalent REDIRECTING(reason) documented value and is set in
REDIRECTING(reason).  e.g., an incoming RFC5806 'unconditional' value or a
quoted string version ('"unconditional"') is converted to
REDIRECTING(reason)'s 'cfu' value.  The user's dialplan only needs to deal
with 'cfu' instead of any of the aliases.

The incoming 480 response reason text supported by chan_sip checks for
known reason values and if not matched then puts quotes around the reason
string and assigns that to REDIRECTING(reason).

Both channel drivers send outgoing known REDIRECTING(reason) values as the
unquoted RFC5806 equivalent.  User custom values are either sent as is or
with added quotes if SIP doesn't allow a character within the value as
part of a RFC3261 Section 25.1 token.  Note that there are still
limitations on what characters can be put in a custom user value.  e.g.,
embedding quotes in the middle of the reason string is silly and just
going to cause you grief.

* Setting a REDIRECTING(reason) value now recognizes RFC5806 aliases.
e.g., Setting REDIRECTING(reason) to 'unconditional' is converted to the
'cfu' value.

* Added missing malloc() NULL return check in res_pjsip_diversion.c
set_redirecting_reason().

* Fixed potential read from a stale pointer in res_pjsip_diversion.c
add_diversion_header().  The reason string needed to be copied into the
tdata memory pool to ensure that the string would always be available.
Otherwise, if the reason string returned by reason_code_to_str() was a
user's reason string then the string could be freed later by another
thread.

Change-Id: Ifba83d23a195a9f64d55b9c681d2e62476b68a87

chan_sip could not handle AST_T38_TERMINATED frames being sent to it when
the channel left the bridge.  The action resulted in overlapping outgoing
reINVITEs.  The testsuite tests/fax/sip/directmedia_reinvite_t38 was not
happy.

* Force T.38 to be remembered as locally bridged.  Now when the channel
leaves the native RTP bridge after T.38, the channel remembers that it has
already reINVITEed the media back to Asterisk.  It just needs to terminate
T.38 when the AST_T38_TERMINATED arrives.

* Prevent redundant AST_T38_TERMINATED from causing problems.  Redundant
AST_T38_TERMINATED frames could cause overlapping outgoing reINVITEs if
they happen before the T.38 state changes to disabled.  Now the T.38 state
is set to disabled before the reINVITE is sent.

ASTERISK-25582 #close

Change-Id: I53f5c6ce7d90b3f322a942af1a9bcab6d967b7ce

Use the correct comparison function since we only care if the address
without the port is the same.

Change-Id: Ibf6c485f843a1be6dee58a47b33d81a7a8cbe3b0

Previously you could add [!dnid] to the SIP dial string to alter the To:
header. This change allows you to alter the From header as well.

SIP dial string extra options now look like this:

    [![touser[@todomain]][![fromuser][@fromdomain]]]

INCOMPATIBLE CHANGE: If you were using an exclamation mark in your To:
header, that is no longer possible.

ASTERISK-25803 #close

Change-Id: I2457e9ba7a89eb1da22084bab5a4d4328e189db7

Change-Id: I54b48c24d7ca88ed80496fdfd142d08772a7ab98

Setting the sip.conf timert1 value to a value higher than 1245 can cause
an integer overflow and result in large retransmit timeout times.  These
large timeout times hold system file descriptors hostage and can cause the
system to run out of file descriptors.

NOTE: The default sip.conf timert1 value is 500 which does not expose the
vulnerability.

* The overflow is now detected and the previous timeout time is
calculated.

ASTERISK-25397 #close
Reported by: Alexander Traud

Change-Id: Ia7231f2f415af1cbf90b923e001b9219cff46290

Fix some warnings found with clang.

Change-Id: I5195b6189b148c2ee3ed4a19d015a6d4ef3e77bd

When I ask asterisk to send a SIP NOTIFY message to a sip peer using either a)
AMI action: SIPnotify or b) cli command: sip notify <cmd> <peer>, I expect
asterisk to include the same value for its own ip in both cases a) and b),
but it seems a) produces a contact header like Contact:
<sip:asterisk@192.168.1.227:8060> whereas b) produces a contact header like
<sip:asterisk@127.0.0.1:8060>. 0.0.0.0:8060 is my udpbindaddr in sip.conf

My guess is that manager_sipnotify should call
ast_sip_ouraddrfor(&p->sa, &p->ourip, p) the same way sip_cli_notify does,
because after applying this patch, both cases a) and b) produce
the contact header that I expect: <sip:asterisk@192.168.1.227:8060>

Reported by: Stefan Engström
Tested by: Stefan Engström

Change-Id: I86af5e209db64aab82c25417de6c768fb645f476

sip_sipredirect uses sscanf to copy up to 256 characters to a stacked buffer
of 256 characters.  This patch reduces the copy to 255 characters to leave
room for the string null terminator.

ASTERISK-25722 #close

Change-Id: Id6c3a629a609e94153287512c59aa1923e8a03ab

In the sample sip.conf this is written with regard to notifyringing:
;notifyringing = no ; Control whether subscriptions already INUSE get sent
RINGING when another call is sent (default: yes)

However, this setting changes whether or not any RINGING indications are sent
to subscriptions. There is no separate configurable setting that allows
to control whether INUSE subscriptions also get sent RINGING. This is however
a useful option, to see (using BLF) if somebody else is able to handle an
incoming call or if everybody is busy.

This patch corrects the documentation for notifyringing (so the documentation
matches the functionality) and make notifyringing a tri-state option, by adding
the value 'notinuse' (in addition to 'yes' and 'no'). When notifyringing =
notinuse, only subscriptions that are not INUSE are sent the RINGING signal.

The default setting for notifyringing remains set to yes, so the default
behaviour is not affected.

ASTERISK-25558

Change-Id: I88f7036ee084bb3f43b74f15612695c6708f74aa

websocket_write_timeout was not being set to its default value
during sip config reload, which meant that prior to this commit,
1) the default value of 100 was not used, unless an invalid value
(or 1) was specified in sip.conf for websocket_write_timeout, and
2) if the websocket_write_timeout directive was removed from sip.conf
without a full restart of asterisk, then the previous value would
continue to be used indefinitely.

This essentially lead to a 0ms write timeout (the first write attempt
in ast_careful_fwrite must have succeeded) in websocket write requests
from chan_sip, unless websocket_write_timeout was explicitely set in sip.conf.

Changes to websocket_write_timeout still only apply to new websocket
sessions, after the sip reload -- timeouts on existing sessions are
not adjusted during sip reload.

Change-Id: Ibed3816ed29cc354af6564c5ab3e75eab72cb953

Per the documentation the WebSocket support in chan_sip is
supposed to be enabled by default but is not. This change
corrects that.

Change-Id: Icb02bbcad47b11a795c14ce20a9bf29649a54423

Adds the TCP Keep Alive option to TCP and TLS server sockets. Previously
this option was only being set on session sockets.
http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/
According to the link above, the SO_KEEPALIVE option is useful for knowing
when a TCP connected endpoint has severed communication without indicating
it or has become unreachable for some reason. Without this patch, keep
alive is not set on the socket listening for incoming TCP sessions and
in Komatsu's report this resulted in the thread listening for TCP becoming
stuck in a waiting state.

ASTERISK-25364 #close
Reported by: Hiroaki Komatsu

Change-Id: I7ed7bcfa982b367dc64b4b73fbd962da49b9af36

The current logic for ICE negotiation starts it
when receiving an SDP with ICE candidates. This is
incorrect as ICE negotiation can only start when each 
call party have at least one pair of local and remote 
candidate. Starting ICE negotiation early would result 
in negotiation failure and ultimately no audio.

This change makes it so ICE negotiation is only started
when a response with SDP is received or when a response
with SDP is sent.

ASTERISK-24146

Change-Id: I55a632bde9e9827871b09141d82747e08379a8ca

Asterisk may crash when calling ast_channel_get_t38_state(c)
on a locked channel which is being hung up.

ASTERISK-25609 #close

Change-Id: Ifaa707c04b865a290ffab719bd2e5c48ff667c7b

A crash happens sometimes when performing a CLI "sip reload".  The bogus
peer gets refreshed while it is in use by a new call which can cause the
crash.

* Protected the global bogus peer object with an ao2 global object
container.

ASTERISK-25610 #close

Change-Id: I5b528c742195681abcf713c6e1011ea65354eeed

Current support for reason header did work only in SIP responses.
According to RFC3336 the reason header might appear in any SIP request.
But it seems to make most sence in BYE and CANCEL so parasing is done
there too (if use_q850_reason=yes).

Change-Id: Ib6be7b34c23a76d0e98dfd0816c89931000ac790

chan_sip.c:
* Initialize mwi subscription scheduler ids earlier because of ASTOBJ to
ao2 conversion.

* Initialize register scheduler ids earlier because of ASTOBJ to ao2
conversion.

chan_skinny.c:
* Fix more scheduler usage for the valid 0 id value.

ASTERISK-25476

Change-Id: If9f0e5d99638b2f9d102d1ebc9c5a14b2d706e95

channels/chan_iax2.c:
* Initialize struct chan_iax2_pvt scheduler ids earlier because of
iax2_destroy_helper().

channels/chan_sip.c:
channels/sip/config_parser.c:
* Fix initialization of scheduler id struct members.  Some off nominal
paths had 0 as a scheduler id to be destroyed when it was never started.

chan_skinny.c:
* Fix some scheduler id comparisons that excluded the valid 0 id.

channel.c:
* Fix channel initialization of the video stream scheduler id.

pbx_dundi.c:
* Fix channel initialization of the packet retransmission scheduler id.

ASTERISK-25476

Change-Id: I07a3449f728f671d326a22fcbd071f150ba2e8c8

When a channel is in a direct media bridge, a re-INVITE may arrive that forces
Asterisk to re-negotiate the media to a T.38 fax. When this occurs, the bridge
must change its technology to a simple bridge, and re-INVITE the media back
to Asterisk.

Generally, this logic mostly already exists in Asterisk. However, prior to this
patch, there were a few bugs:
(1) The T.38 framehook currently prevents a channel capable of T.38 faxes from
    ever entering into a direct media bridge. This applies even when the only
    media being passed over the channel is audio. This patch fixes this bug
    by having the framehook specify that it defers caring about any frame type.
    This allows the channels to enter into a direct media bridge, which will
    be broken when a re-INVITE is received.
(2) When a re-INVITE is received, nothing instructed the bridging layer to
    re-inspect the allowed bridging technology. This now occurs when either
    a re-INVITE is received from a peer, or when a response is received from
    the far end (that is, when the T.38 state changes to either
    T38_PEER_REINVITE or T38_LOCAL_REINVITE).
(3) chan_pjsip needs to do a small amount of work to prevent a direct media
    bridge from being chosen when a T.38 session is in progress. When a T.38
    session supplement has a t38 datastore - which is added when we detect
    we should start thinking about T.38 on a channel - we now refuse a native
    RTP bridge.
(4) When a BYE request is received, we don't terminate the T.38 session. If
    the other side of a T.38 fax survives the hangup (due to the 'g' flag
    in Dial, for example), we don't currently re-INVITE the media on the
    other channel back to audio. This patch now has res_pjsip_t38 intercept
    BYE requests and inform the far side that the T.38 session is terminated.
    This naturally causes the correct re-INVITEs to be sent.

ASTERISK-25582

Change-Id: Iabd6aa578e633d16e6b9f342091264e4324a79eb

When ASTERISK-25449 was closed, a number of scheduler issues mentioned in
the comments were missed. These have since beed raised in ASTERISK-25476
and elsewhere.

This patch attempts to collect all of the scheduler issues discovered so
far and address them sensibly.

ASTERISK-25476 #close

Change-Id: I87a77d581e2e0d91d33b4b2fbff80f64a566d05b

ASTERISK-25533 #close

Change-Id: Ie1a9d1a6511b3f1a56b93d04475fbf8a4e40010a