Added in ability to specify display name format ("name" <sip:name@ipaddr:port>)
for a given URI and made sure it was fully propagated to the outgoing message.
Also made it so outoing messages in res_pjsip always send as "sip:".

(closes issue ASTERISK-22924)
Reported by: Anthony Messina
Review: https://reviewboard.asterisk.org/r/3094/
........

Merged revisions 405266 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Added a new 'set_var' option for ast_sip_endpoint(s).  For each variable
specified that variable gets set upon creation of a pjsip channel involving
the endpoint.

(closes issue ASTERISK-22868)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/3095/
........

Merged revisions 404663 from http://svn.asterisk.org/svn/asterisk/branches/12


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

For the explanation, here is a copy-paste of the review board explanation:

Initially, it was discovered that performing an attended transfer of a
multiparty bridge with a PJSIP channel would cause a deadlock. A PBX thread
started a masquerade and reached the point where it was calling the fixup()
callback on the "original" channel. For chan_pjsip, this involves pushing a
synchronous task to the session's serializer. The problem was that a task ahead
of the fixup task was also attempting to perform a channel masquerade. However,
since masquerades are designed in a way to only allow for one to occur at a
time, the task ahead of the fixup could not continue until the masquerade
already in progress had completed. And of course, the masquerade in progress
could not complete until the task ahead of the fixup task had completed.
Deadlock.

The initial fix was to change the fixup task to be asynchronous. While this
prevented the deadlock from occurring, it had the frightful side effect of
potentially allowing for tasks in the session's serializer to operate on a
zombie channel.

Taking a step back from this particular deadlock, it became clear that the
problem was not really this one particular issue but that masquerades
themselves needed to be addressed. A PJSIP attended transfer operation calls
ast_channel_move(), which attempts to both set up and execute a masquerade. The
problem was that after it had set up the masquerade, the PBX thread had swooped
in and tried to actually perform the masquerade. Looking at changes that had
been made to Asterisk 12, it became clear that there never is any time now that
anyone ever wants to set up a masquerade and allow for the channel thread to
actually perform the masquerade. Everyone always is calling ast_channel_move(),
performs the masquerade itself before returning.

In this patch, I have removed all blocks of code from channel.c that will
attempt to perform a masquerade if ast_channel_masq() returns true. Now, there
is no distinction between setting up a masquerade and performing the
masquerade. It is one operation. The only remaining checks for
ast_channel_masq() and ast_channel_masqr() are in ast_hangup() since we do not
want to interrupt a masquerade by hanging up the channel. Instead, now
ast_hangup() will wait for a masquerade to complete before moving forward with
its operation.

The ast_channel_move() function has been modified to basically in-line the
logic that used to be in ast_channel_masquerade(). ast_channel_masquerade() has
been killed off for real. ast_channel_move() now has a lock associated with it
that is used to prevent any simultaneous moves from occurring at once. This
means there is no need to make sure that ast_channel_masq() or
ast_channel_masqr() are already set on a channel when ast_channel_move() is
called. It also means the channel container lock is not pulling double duty by
both keeping the container locked and preventing multiple masquerades from
occurring simultaneously.

The ast_do_masquerade() function has been renamed to do_channel_masquerade()
and is now internal to channel.c. The function now takes explicit arguments of
which channels are involved in the masquerade instead of a single channel.
While it probably is possible to do some further refactoring of this method, I
feel that I would be treading dangerously. Instead, all I did was change some
comments that no longer are true after this changeset.

The other more minor change introduced in this patch is to res_pjsip.c to make
ast_sip_push_task_synchronous() run the task in-place if we are already a SIP
servant thread. This is related to this patch because even when we isolate the
channel masquerade to only running in the SIP servant thread, we would still
deadlock when the fixup() callback is reached since we would essentially be
waiting forever for ourselves to finish before actually running the fixup. This
makes it so the fixup is run without having to push a task into a serializer at
all.

(closes issue ASTERISK-22936)
Reported by Jonathan Rose

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

Merged revisions 404356 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Objects which are involved in SIP request creation and sending
now allow an outbound proxy to be specified. For cases where
an endpoint is used the outbound proxy specified there will
be applied.

(closes issue ASTERISK-22673)
Reported by: Antti Yrjola

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

Merged revisions 403811 from http://svn.asterisk.org/svn/asterisk/branches/12


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

In some cases messages need to be sent to a direct URI (sip:<ip address>). This
patch adds in that support by using a default outbound endpoint.  When sending
messages, if no endpoint can be found then the default one is used.

To facilitate this a new default_outbound_endpoint option was added to the
globals section for pjsip.conf.

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

Merged revisions 403680 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Since Asterisk has a vector API now, places where arrays are manually
resized don't really make sense any more. Since the auth work in PJSIP
was freshly-written, it was easy to reform it to use a vector.

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



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

Passing a non-zero value causes PJLIB to use the given input as the
hash value. Passing zero causes the parameter to become an output parameter
that receives the hash value that was computed based on the given key.

This change essentially makes ast_sip_dict_get() properly retrieve the
desired value.
........

Merged revisions 403349 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Transport type determination for security events has been simplified to use
the type present on the message itself instead of searching through configured
transports to find the transport used.

The actual WebSocket transport has also been simplified. It now leverages the
existing PJSIP transport manager for finding the active WebSocket transport
for outgoing messages. This removes the need for res_pjsip_transport_websocket
to store a mapping itself.

(closes issue ASTERISK-22897)
Reported by: Max E. Reyes Vera J.

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

Merged revisions 403256 from http://svn.asterisk.org/svn/asterisk/branches/12


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

The action taken when a redirect occurs is now configurable on a
per-endpoint basis. The redirect can either be treated as a redirect
to a local extension, to a URI that is dialed through the Asterisk
core, or to a URI that is dialed within PJSIP itself.

(closes issue ASTERISK-21710)
Reported by: Matt Jordan

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

Merged revisions 403207 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Created the following AMI commands and corresponding events for res_pjsip:

PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few
                     select attributes on each.
  Events:
    EndpointList - for each endpoint a few attributes.
    EndpointlistComplete - after all endpoints have been listed.

PJSIPShowEndpoint - Provides a detail list of attributes for a specified
                    endpoint.
  Events:
    EndpointDetail - attributes on an endpoint.
    AorDetail - raised for each AOR on an endpoint.
    AuthDetail - raised for each associated inbound and outbound auth
    TransportDetail - transport attributes.
    IdentifyDetail - attributes for the identify object associated with
                     the endpoint.
    EndpointDetailComplete - last event raised after all detail events.

PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound
                                registrations.
  Events:
    InboundRegistrationDetail - inbound registration attributes for each
                                registration.
    InboundRegistrationDetailComplete - raised after all detail records have
                                been listed.

PJSIPShowRegistrationsOutbound  - Provides a detail listing of all outbound
                                  registrations.
  Events:
    OutboundRegistrationDetail - outbound registration attributes for each
                                 registration.
    OutboundRegistrationDetailComplete - raised after all detail records
                                 have been listed.

PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions
                                and their attributes.
  Events:
    SubscriptionDetail - on each subscription detailed attributes
    SubscriptionDetailComplete - raised after all detail records have
                                 been listed.

PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound
                                subscriptions and their attributes.
  Events:
    SubscriptionDetail - on each subscription detailed attributes
    SubscriptionDetailComplete - raised after all detail records have
                                 been listed.

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

Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Renamed, where appropriate, the configuration options for chan/res_pjsip to use
snake case (compound words separated by an underscore).  For example, faxdetect
will become fax_detect, recordofffeature will become record_off_feature, etc...

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

Merged revisions 403022 from http://svn.asterisk.org/svn/asterisk/branches/12


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

........

Merged revisions 402582 from http://svn.asterisk.org/svn/asterisk/branches/12


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

This change fixes two issues when setting an outbound proxy:

1. The outbound proxy URI was not parsed and validated during configuration.
2. If an outgoing dialog was created and the outbound proxy could not be set an assertion would
occur because the usage count on the dialog was not decremented.

The documentation has also been updated to specify that a full URI must be specified for
the outbound proxy.

(closes issue ASTERISK-22672)
Reported by: Antti Yrjola
........

Merged revisions 400824 from http://svn.asterisk.org/svn/asterisk/branches/12


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

pjsip_strerror is only aware of PJSIP-specific error
codes. pj_strerror() is aware of all PJProject error
codes and OS-specific error codes.

This specifically fixes an oft-seen error in transport
configuration code where EADDRINUSE would result in
"Unknown PJSIP error 120098" instead of a useful
message.
........

Merged revisions 400749 from http://svn.asterisk.org/svn/asterisk/branches/12


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

........

Merged revisions 400520 from http://svn.asterisk.org/svn/asterisk/branches/12


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

There was a collision of mod_data use on the transaction between using a nat
hook and an session response callback.  During state change it was assumed
what was in the mod_data was nothing or the response callback.  However, it
was possible for it to also contain a nat hook thus resulting in a bad cast
and a crash.

Added the ability to store multiple data elements in mod_data via a hash table.
In this instance, mod_data now stores a hash table of the two values that can
be retrieved using an associated string key.

(closes issue ASTERISK-22394)
Reported by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/2843/
........

Merged revisions 399990 from http://svn.asterisk.org/svn/asterisk/branches/12


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

........

Merged revisions 399798 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Re-using some of Mark Michelson's text from an E-mail discussion for:

* Modifying synopsis for both options
* Adding description to both options
* Changing name of "external_media_address" for Endpoint configuration to "media_address" in anticipation of the option name being changed. (As it is not really specific to external destinations)

(issue ASTERISK-22405)
(closes issue ASTERISK-22405)
Reported by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/2850/
........

Merged revisions 399781 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Fix crash in res_pjsip on load if error occurs, and prevent unloading of res_pjsip and res_pjsip_session.

During load time in res_pjsip if an error occurred the operation would attempt to rollback all
operations done during load. This is not permitted by PJSIP as it will assert if the operation has
not been done. This fix changes the code so it will only rollback what has been initialized already.

Further changes also prevent res_pjsip and res_pjsip_session from being unloaded. This is due to
limitations within PJSIP itself. The library environment can only be changed to a certain extent
and does not provide the ability, currently, to deinitialize certain required functionality.

(closes issue ASTERISK-22474)
Reported by: Corey Farrell
........

Merged revisions 399624 from http://svn.asterisk.org/svn/asterisk/branches/12


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

(closes issue AST-1207)
reported by John Bigelow

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

Merged revisions 399083 from http://svn.asterisk.org/svn/asterisk/branches/12


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

We shouldn't be exporting any symbols that start with pjsip_.
........

Merged revisions 398927 from http://svn.asterisk.org/svn/asterisk/branches/12


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

Some configuration objects currently won't place nice if reloaded.
Specifically, in this case the pjsip transport objects.  Now when
registering an object in sorcery one may specify that the object is
allowed to be reloaded or not.  If the object is set to not reload
then upon reloading of the configuration the objects of that type
will not be reloaded.  The initially loaded objects of that type
however will remain.

While the transport objects will not longer be reloaded it is still
possible for a user to configure an endpoint to an invalid transport.
A couple of log messages were added to help diagnose this problem if
it occurs.

(closes issue ASTERISK-22382)
Reported by: Rusty Newton
(closes issue ASTERISK-22384)
Reported by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/2807/
........

Merged revisions 398139 from http://svn.asterisk.org/svn/asterisk/branches/12


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

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

There are times when a configuration option should not have documentation.

1. Some options are registered with a particular object merely as a warning to
   users. These options aren't even really 'deprecated' - which has its own
   separate API call - they are actually provided by a different configuration
   file. The options are merely registered so that the user gets a warning that
   a different configuration file provides the item.

2. Some object types - most notably some used by modules that use sorcery - are
   completely internal and should never be shown to the user.

3. Sorcery itself has several 'hidden' fields that should never be shown to a
   user.

This patch updates the configuration framework and sorcery with additional API
calls that allow a module to register types as internal and options as not
requiring documentation. This bypasses the XML documentation checking.

This patch also re-enables the strict XML documentation checking in trunk, as
well as updates some documentation that was missing.

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

(closes issue ASTERISK-22359)
Reported by: Matt Jordan

(closes issue ASTERISK-22112)
Reported by: Rusty Newton



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

Added the ability to handle 'raw' DTMF within the body of an INFO message.
Also made it so values 10-16 are mapped to valid DTMF values.

(closes issue ASTERISK-22144)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2776/


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

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

(issue ASTERISK-22344)
(closes issue ASTERISK-22344)


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

This also removes documentation for the options that no longer exist.

(closes issue ASTERISK-22306)
reported by Rusty Newton


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

(closes issue ASTERISK-22094)
reported by Rusty Newton



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

Added or modified text in the xml doc for the 'aor' config object to address a few issues:
* help for the 'mailboxes' option didn't make it clear how the "list" should be formatted.
* AoR object's involvement in inbound registration wasn't mentioned.
* help for the 'contact' option didn't describe how to specify multiple contacts.
* help for the 'max_contacts' option didn't tell whether it limited the amount of contacts defined through static configuration.

(issue ASTERISK-22118)
(closes issue ASTERISK-22118)


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

'domain_alias' config object XML help doesn't make it clear that the name used for the object is the domain alias

(issue ASTERISK-22114)
(closes issue ASTERISK-22114)


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

(issue ASTERISK-22108)
(closes issue ASTERISK-22108)


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

xml doc change for transport config object - remove non-applicable warning and add text regarding Asterisk restart 

(closes issue ASTERISK-22105)


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

Expose initial size, automatic increment, maximum size, and idle
timeout as configurable parameters for the res_pjsip thread pool.

Review: https://reviewboard.asterisk.org/r/2704/
(closes issue ASTERISK-22143)


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

For chan_pjsip, this introduces CLI/AMI remote unregistration commands,
reworks CLI syntax for sending NOTIFYs, adds AMI qualification support,
and adds documentation for PJSIPNotify.

This also fixes two refcounting bugs in the outbound registration code.

Review: https://reviewboard.asterisk.org/r/2695/
(closes issue ASTERISK-21939)


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

The general gist is to have a clear boundary between old SIP stuff
and new SIP stuff by having the word "SIP" for old stuff and "PJSIP"
for new stuff. Here's a brief rundown of the changes:

* The word "Gulp" in dialstrings, functions, and CLI commands is now
  "PJSIP"
* chan_gulp.c is now chan_pjsip.c
* Function names in chan_gulp.c that were "gulp_*" are now "chan_pjsip_*"
* All files that were "res_sip*" are now "res_pjsip*"
* The "res_sip" directory is now "res_pjsip"
* Files in the "res_pjsip" directory that began with "sip_*" are now "pjsip_*"
* The configuration file is now "pjsip.conf" instead of "res_sip.conf"
* The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP"
* CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as
the starting word instead of "sip"



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

(closes issue ASTERISK-22135)
reported by Matt Jordan

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



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

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


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

(closes issue ASTERISK-22023)
Reported by Rusty Newton



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

The monitor thread is already properly torn down on unload and load
failure.


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