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

options are documented in config sample
sample config rename to proper name - ooh323.conf

To change media address ooh323 send empty TCS if there was 
completed TCS exchange or send facility forwardedelements 
with new fast start proposal if not.
Then close transmit logical channels and renew TCS exchange.

If new fast start proposal is received then ooh323 stack call back
channel driver routine to change rtp address in the rtp instance.
If empty TCS is received then close transmit logical channels and
renew TCS exchange

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



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

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

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



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

There is no need to call check_pendings() on a final response to an INVITE
when destroying the scheduler entry as it will be done later during normal
processing.

(issue ASTERISK-19992)
........

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

Merged revisions 369580 from http://svn.asterisk.org/svn/asterisk/branches/10


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

A previous attempt at fixing this issue had negative side effects related
to attended transfers which this patch should resolve. Many thanks to
Steve Davies for all of the good suggestions and testing.

(closes issue ASTERISK-19992)
Reported by: Steve Davies
Tested by: Steve Davies, Terry Wilson
Review: https://reviewboard.asterisk.org/r/2009/
........

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

Merged revisions 369558 from http://svn.asterisk.org/svn/asterisk/branches/10


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

Add a cleaned up drop-in replacement for res_jabber called res_xmpp. This provides the same externally facing functionality but is implemented differently internally.

This is currently not built by default but this will be changed once chan_jingle2 (insert actual name in your head when reading this after it has been merged)
is in the tree.

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


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

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

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

Don't try to send connectivity checks on RTCP if RTCP is no longer present and don't do multiple ICE connectivity checks at once.


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

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


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

........

Merged revisions 369511 from http://svn.asterisk.org/svn/asterisk/branches/10


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

Hangup handlers are an alternative to the h extension.  They can be used
in addition to the h extension.  The idea is to attach a Gosub routine to
a channel that will execute when the call hangs up.  Whereas which h
extension gets executed depends on the location of dialplan execution when
the call hangs up, hangup handlers are attached to the call channel.  You
can attach multiple handlers that will execute in the order of most
recently added first.

(closes issue ASTERISK-19549)
Reported by: Mark Murawski
Tested by: rmudgett

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


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

........

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

Merged revisions 369491 from http://svn.asterisk.org/svn/asterisk/branches/10


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

The opaquing the ast_channel struct no longer requires .cleancount to be
changed when the struct is changed.

* Bump .cleancount value one last time because of struct ast_channel for
old times sake.


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

(closes issue ASTERISK-16618)
Reported by: Leif Madsen

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

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

Merged revisions 369472 from http://svn.asterisk.org/svn/asterisk/branches/10


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

Allows the setting of flags via the config options api.
For example, code like this:

#define OPT1 1 << 0
#define OPT2 1 << 1
#define OPT3 1 << 2

struct thing {
   unsigned int flags;
};

and a config like this:

[blah]
opt1=yes
opt2=no
opt3=yes

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


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

The basic problem is that if a re-INVITE is sent by Asterisk and it receives a
provisional response, but no final response, then the dialog is never torn
down. In addition to leaking memory, this also leaks file descriptors and will
eventually lead to Asterisk no longer being able to process calls.

This patch just keeps track of whether there is an outstanding re-INVITE, and if
there is goes ahead and cleans up everything as though there was no outstanding
reinvite.

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

(closes issue ASTERISK-19992)
Reported by: Steve Davies
Tested by: Steve Davies, Terry Wilson
........

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

Merged revisions 369437 from http://svn.asterisk.org/svn/asterisk/branches/10


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

Adds call ID logging changes to specific channel drivers that weren't handled
handled in phase II of Call ID Logging. Also covers logging for threads for
threads created by systems that may be involved with many different calls.
Extra special thanks to Richard for rigorous review of chan_dahdi and its
various signalling modules.

review: https://reviewboard.asterisk.org/r/1927/
review: https://reviewboard.asterisk.org/r/1950/



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

When res_adsi is unloaded, it removes the ADSI functions that it previously installed
by passing a NULL adsi_funcs pointer to ast_adsi_install_funcs.  This function was not
checking whether or not the adsi_funcs pointer passed in was NULL before dereferencing
it to check whether or not the version of the functions matches what the core was
expecting it.

This patch makes it so that the version is only checked if a potentially valid adsi_funcs
pointer was passed in.  Passing in NULL removes the installed functions, bypassing the
version check.
........

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

Merged revisions 369391 from http://svn.asterisk.org/svn/asterisk/branches/10


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

Thank you rmudgett for pointing out that I was missing this in the initial
check-in for AMI event documentation (r369346)


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

Certain places in core/cdr.c would, if the duration value were 0, calculate the
duration as being the delta between the current time and the time at which the
CDR record was started.  While this does not typically cause a problem in
non-batch mode, this can cause an issue in batch mode where CDR records are
gathered and written long after those calls have ended. In particular, this
affects calls that were never answered, as those are expected to have a duration
of 0.  Often, this would result in CDR logs with a significant number of calls
with lengthy durations, but dispositions of "BUSY".

Note that this does not affect cdr_csv, as that backend does not use
ast_cdr_getvar and instead directly reports the duration value.  The affected
core backends include cdr_apative_odbc and cdr_custom; other extended or
deprecated CDR backends may potentially still directly manipulate the duration
values.

(issue ASTERISK-19860)
Reported by: Thomas Arimont

(issue AST-883)
Reported by: Thomas Arimont
Tested by: Matt Jordan

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

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

Merged revisions 369369 from http://svn.asterisk.org/svn/asterisk/branches/10


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

Match our local tag to whatever to-tag was sent in the initial INVITE.
Because the size of the to-tag may not fit in the buffer in the sip_pvt,
it has been changed to a string field.

(closes issue ASTERISK-19892)
reported by Walter Doekes

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

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

Merged revisions 369353 from http://svn.asterisk.org/svn/asterisk/branches/10


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

This patch adds the core changes necessary to support AMI event documentation
in the source files of Asterisk, and adds documentation to those AMI events
defined in the core application modules.  Event documentation is built from
the source by two new python scripts, located in build_tools:
get_documentation.py and post_process_documentation.py.

The get_documentation.py script mirrors the actions of the existing AWK
get_documentation scripts, except that it will scan the entirety of a source
file for Asterisk documentation.  Upon encountering it, if the documentation
happens to be an AMI event, it will attempt to extract information about the
event directly from the manager event macro calls that raise the event.  The
post_process_documentation.py script combines manager event instances that
are the same event but documented in multiple source files.  It generates
the final core-[lang].xml file.

As this process can take longer to complete than a typical 'make all', it
is only performed if a new make target, 'full', is chosen.

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

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

* Fix do_bridge_masquerade() getting the resume location from the zombie
channel.  The code must not touch a clone channel after it has masqueraded
it.  The clone channel has become a zombie and is starting to hangup.

(closes issue ASTERISK-19985)
Reported by: jamicque
Patches:
      jira_asterisk_19985_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: jamicque
........

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

Merged revisions 369328 from http://svn.asterisk.org/svn/asterisk/branches/10


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

........
  r369323 | mmichelson | 2012-06-25 10:35:43 -0500 (Mon, 25 Jun 2012) | 9 lines
  
  Eliminate embedding of res_adsi.so module.
  
  The way this is done is to stop using the optional API.
  Instead, res_adsi.so, when loaded fills in a table of
  function pointers.
  
  Review: https://reviewboard.asterisk.org/r/1991
........
  r369324 | mmichelson | 2012-06-25 10:50:17 -0500 (Mon, 25 Jun 2012) | 2 lines
  
  Forgot to svn add this file in my last commit.
........

Merged revisions 369323-369324 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 369325 from http://svn.asterisk.org/svn/asterisk/branches/10


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

When Asterisk receives an INVITE from an external domain when allowexternaldomains=no
send a 403 instead of a 404. This is consistent with Asterisk's behavior when receiving
a REGISTER in this situation.

(Closes issue ASTERISK-19601)
Reported by Matthew Jordan
Patches:
	ASTERISK-19601-no401.patch uploaded by Mark Michelson (License #5049)
........

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

Merged revisions 369303 from http://svn.asterisk.org/svn/asterisk/branches/10


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

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

* Fix AMI Bridge action disconnecting the AMI link on error.

* Fix AMI Bridge action and Bridge application not checking if their
masquerades were successful.

* Fix Bridge application running the h-exten when it should not.

* Made do_bridge_masquerade() return if the masquerade was successful so
the Bridge application and AMI Bridge action could deal with it correctly.

* Made bridge_call_thread_launch() hangup the passed in channels if the
bridge_call_thread fails to start.  Those channels would have been
orphaned.

* Made builtin_atxfer() check the success of the transfer masquerade
setup.
........

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

Merged revisions 369283 from http://svn.asterisk.org/svn/asterisk/branches/10


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

........

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

Merged revisions 369263 from http://svn.asterisk.org/svn/asterisk/branches/10


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

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

........

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

Merged revisions 369259 from http://svn.asterisk.org/svn/asterisk/branches/10


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

........

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

Merged revisions 369239 from http://svn.asterisk.org/svn/asterisk/branches/10


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

........

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

Merged revisions 369236 from http://svn.asterisk.org/svn/asterisk/branches/10


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

A sip_pvt may not have relatedpeer set if a call doesn't match up
with a peer. If there is no relatedpeer, there is no direct media
ACL to apply, so just return that it is allowed.

(closes issue ASTERISK-20040)
Reported by: Terry Wilson
........

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

Merged revisions 369215 from http://svn.asterisk.org/svn/asterisk/branches/10


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

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

The sendonly/recvonly/sendrecv/inactive media stream attributes were
parsed for video, but nothing was ever done with them.  With this code
removed, an UNSUPPORTED message is produced when these attributes are
used in conjunction with a video stream which is the better behavior
since they were never really supported in the first place.
........

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

Merged revisions 369206 from http://svn.asterisk.org/svn/asterisk/branches/10


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

This adds a minimal implementation of the "Who Hung Up?" Asterisk 11
work to chan_dahdi.c for the MFC/R2 DAHDI subtech.  Given the way that
OpenR2 interfaces with chan_dahdi, it is much harder to expose the
type of protocol information that is available in PRI, SS7, or other
channel technologies.


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

This is part of the DAHDI support for the Asterisk 11 "Who Hung Up?"
project and covers the implementation for the technologies implemented
in sig_analog.c and sig_pri.c. Tested on a local machine to verify
protocol and cause information is available.

Review: https://reviewboard.asterisk.org/r/1953/
(issue SWP-4222)


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

Testing was done on a local machine to verify that protocol and
cause information was being sent properly.

Review: https://reviewboard.asterisk.org/r/1955/
(issue SWP-4222)


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