git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387974 65c4cc65-6c06-0410-ace0-fbb531ad65f3

An endpoint is an external device/system that may offer/accept
channels to/from Asterisk. While this is a very useful concept for end
users, it is surprisingly not a core concept within Asterisk itself.

This patch defines ast_endpoint as a separate object, which channel
drivers may use to expose their concept of an endpoint. As the channel
driver creates channels, it can use ast_endpoint_add_channel() to
associate channels to the endpoint. This updated the endpoint
appropriately, and forwards all of the channel's events to the
endpoint's topic.

In order to avoid excessive locking on the endpoint object itself, the
mutable state is not accessible via getters. Instead, you can create a
snapshot using ast_endpoint_snapshot_create() to get a consistent
snapshot of the internal state.

This patch also includes a set of topics and messages associated with
endpoints, and implementations of the endpoint-related RESTful
API. chan_sip was updated to create endpoints with SIP peers, but the
state of the endpoints is not updated with the state of the peer.

Along for the ride in this patch is a Stasis test API. This is a
stasis_message_sink object, which can be subscribed to a Stasis
topic. It has functions for blocking while waiting for conditions in
the message sink to be fulfilled.

(closes issue ASTERISK-21421)
Review: https://reviewboard.asterisk.org/r/2492/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3

RFC6665 4.2.2: ... after a failed State NOTIFY transaction remove the subscription

The problem is that the State Notify requests rely on the 200OK reponse for pacing control
and to not confuse the notify susbsystem.
The issue is, the pendinginvite isn't cleared if a response isn't received,
thus further notify's are never sent.

The solution, follow RFC 6665 4.2.2's 'SHOULD' and remove the subscription after failure.
  
(closes issue ASTERISK-21677)

Reported by: Dan Martens
Tested by: alecdavis
alecdavis (license 585)

Review https://reviewboard.asterisk.org/r/2475/
........

Merged revisions 387875 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387880 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387885 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The \example tags marks an entire file as an example, not a code snippet.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387825 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The \example tags marks an entire file as an example, not a code snippet.
........

Merged revisions 387823 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387824 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387803 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387802 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387741 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387740 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387738 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Reload support was originally not included for SLA.  It was added later,
but in a fairly non-traditional way.  It basically sets a flag
indicating that a reload is pending, and then waits for a time where it
thinks everything SLA related is idle and unused, and *then* executes
the reload.  It does this because the reload process is destructive.  It
starts by throwing everything away and starting over.

There are a number of problems with this approach.  One of them is that
the check to see if anything in use was incomplete.  This patch makes it
more complete and thus less likely for a crash to occur during reload
processing.  However, this approach still has problems so some much more
significant reworking of this code will need to come in as a next step.

Patch credit and testing by CoreDial, LLC.
........

Merged revisions 387688 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387689 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387690 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This change adds the ability for modules to add themselves as observers
to sorcery object types. Observers can be notified when objects are
created, updated, or deleted as well as when the object type is loaded or
reloaded. Observer notifications are done using a thread pool in a serialized
fashion so the caller of the sorcery API calls is minimally impacted.

This also adds the ability to create JSON changesets of a sorcery object.

Tests are also present to confirm all of the above functionality.

Review: https://reviewboard.asterisk.org/r/2477/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387662 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch:
 * Cleans up some doxygen
 * Prevents leaking the system level Stasis topics and messages
   on exit (users of valgrind will be happier)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387633 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch removes the direct call to AMI from the SHARED function
and instead call Stasis-Core. Stasis-Core delivers the notification
that a shared variable has changed on a channel to all interested
consumers.

(issue ASTERISK-21462)

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387630 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(issue ASTERISK-21103)
Review: https://reviewboard.asterisk.org/r/2490/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387594 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Use the configured formats for Gulp sessions if there are no joint formats between requested formats and configured formats.

(closes issue ASTERISK-21756)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387545 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch moves VarSet events for local variables raised by GoSub
over to Stasis-Core. It also tweaks up the post-processing documentation
scripts to not combine parameters if both parameters are already documented.

(issue ASTERISK-21462)

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387519 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387482 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Alec's patch that added the Asterisk version to 'core show locks' angered the
items in utils, as they exist somewhat outside of the Asterisk build system.
Some day, this Makefile should get nuked from high orbit, but for now, include
version.c in its list of stuff to pile in.
........

Merged revisions 387421 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387422 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387423 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387420 65c4cc65-6c06-0410-ace0-fbb531ad65f3

chan_sip: Session-Expires: Set timer to correctly expire at (~2/3) of the interval when not the refresher

RFC 4028 Section 10
	if the side not performing refreshes does not receive a
	session refresh request before the session expiration, it SHOULD send
	a BYE to terminate the session, slightly before the session
	expiration.  The minimum of 32 seconds and one third of the session
	interval is RECOMMENDED.

Prior to this asterisk would refresh at 1/2 the Session-Expires interval,
or if the remote device was the refresher, asterisk would timeout at interval end.

Now, when not refresher, timeout as per RFC noted above.

(closes issue ASTERISK-21742)

Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)

Review https://reviewboard.asterisk.org/r/2488/
........

Merged revisions 387344 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387345 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387369 65c4cc65-6c06-0410-ace0-fbb531ad65f3

chan_sip: Honor Session-Expires in 200OK response when it's a RE-INVITE when asterisk is the refresher.

RFC 4028 Section 7.2
 "UACs MUST be prepared to receive a Session-Expires header field in a
 response, even if none were present in the request." 

What changed
  After ASTERISK-20787, inbound calls to asterisk with no Session-Expires in the INVITE are now are offered
  a Session-Expires (1800 asterisk default) in the response, with asterisk as the refresher.

Symptom:
  After 900 seconds (asterisk default refresher period 1800), asterisk RE-INVITEs the device, the device
   may respond with a much lower Session-Expires (180 in our case) value that it is now using.

  Asterisk ignores this response, as it's deemed both an INBOUND CALL, and a RE-INVITE.

  After 180 seconds the device times out and sends BYE (hangs up), asterisk is still working with the
  refresher period of 1800 as it ignored the 'Session Expires: 180' in the previous 200OK response.
 
Fix:
	handle_response_invite() when 200OK, remove check for outbound and reinvite.
  
(closes issue ASTERISK-21664)

Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)

Review https://reviewboard.asterisk.org/r/2463/
........

Merged revisions 387312 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387319 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387327 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Lower bound of a 16bit signed int is -32768 not -32767

(closes issue ASTERISK-21744)

Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
........

Merged revisions 387297 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387298 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387299 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Assist with reporting 'core show locks' when submitting bug reports.

Example below:

===========================
== SVN-branch-1.8-...
== Currently Held Locks
===========================


(closes issue ASTERISK-21743)

Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
........

Merged revisions 387294 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387295 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387296 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387261 65c4cc65-6c06-0410-ace0-fbb531ad65f3

* Remove t and ama local variables.  There is no way they could be
anything other than default because p->owner can only be NULL at this
point.

* Rename tmp and tmp2 to owner and chan respectively.

* Remove redundant initialization of channel context, exten, priority.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387260 65c4cc65-6c06-0410-ace0-fbb531ad65f3

In certain situations, when the RTP engine goes to send a DTMF end digit
it may be in a situation where the remote address is no longer available,
or the digit that was supposed to be sent is invalid. In such cases, we
need to clear the RTP counters appropriately. Otherwise, when the RTP
source is set again, we'll continue to think that we're in the middle of
sending a DTMF digit, which can confuse the remote party (signficantly).

(closes issue ASTERISK-21522)
Reported by: Corey Farrell
patches:
  rtp_dtmf_process_end.patch uploaded by Corey Farrell (License 5909)
........

Merged revisions 387213 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387216 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387220 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387212 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Pretending that chan_local locals container can have more than one bucket
is silly.  The container has no key to help search.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387211 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387210 65c4cc65-6c06-0410-ace0-fbb531ad65f3

There is a reason the heap comparison functions like qsort(), and other
comparison functions specify <0, >0, and =0 for the return values.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387209 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387185 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387184 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387183 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387182 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387181 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When you have lots of SIP peers (according to the issue reporter, around 3500),
the 'sip show peers' CLI command or AMI action can crash due to a poorly placed
string duplication that occurs on the stack. This patch refactors the command
to not allocate the string on the stack, and handles the formatting of a single
peer in a separate function call.

(closes issue ASTERISK-21466)
Reported by: Guillaume Knispel
patches:
  fix_sip_show_peers_stack_overflow_asterisk_11.3.0-v2.patch uploaded by gknispel (License 6492)
........

Merged revisions 387134 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387135 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387108 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Way back when in the dark days of Asterisk 1.8.9, blind transferring a call
in a context that included the 'h' extension would inadvertently execute the
hangup code logic on the transferred channel. This was a "bad thing". The fix
was to properly check for the softhangup flags on the channel and only execute
the 'h' extension logic (and, in later versions, hangup handler logic) if the
channel was well and truly dead (Jim).

Unfortunately, CDRs are fickle. Setting the softhangup flag when we detected
that the channel was leaving the bridge (but not to die) caused some crucial
snippet of CDR code, lying in ambush in the middle of the bridging code, to
not get executed. This had the effect of blowing away one of the CDRs that is
typically created during a blind transfer.

While we live and die by the adage "don't touch CDRs in release branches", this
was our bad. The attached patch restores the CDR behavior, and still manages to
not run the 'h' extension during a blind transfer (at least not when it's
supposed to).

Thanks to Steve Davies for diagnosing this and providing a fix.

Review: https://reviewboard.asterisk.org/r/2476

(closes issue ASTERISK-21394)
Reported by: Ishfaq Malik
Tested by: Ishfaq Malik, mjordan
patches:
  fix_missing_blindXfer_cdr2 uploaded by one47 (License 5012)
........

Merged revisions 387036 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 387038 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387039 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(issue ASTERISK-21103)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2481/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387037 65c4cc65-6c06-0410-ace0-fbb531ad65f3