The endpoint option does not apply to communication with external entities. Rather,
the option is applied to all communications with the endpoint. The external_media_address
transport configuration option may override the endpoint option if it turns out that
we are going to be communicating with an external entity.
Two things of note:
1) I have not updated the XML documentation. This is being taken care of by Rusty as part
of his work on issue ASTERISK-22405
2) This commit is likely to cause testsuite failures since there are tests that use the
external_media_address endpoint option, and they will need to be changed over. Well, I'm
planning to get that updated ASAP after this commit.
(closes issue ASTERISK-22528)
reported by Rusty Newton
........
Merged revisions 399283 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The rtpengine configuration parameter was documented in the XML documentation,
but it was not actually registered with the sorcery object. This adds the
parameter with a default of "asterisk", such that res_rtp_asterisk is chosen as
the default RTP implementation.
(closes issue ASTERISK-22380)
Reported by: Rusty Newton
Tested by: Rusty Newton
........
Merged revisions 397621 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397622 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
This is more-or-less a reversion of previous ACL behavior so that
it is more self-contained. ACL sections are now only parsed if res_pjsip_acl.so
is loaded. Moreover, the configuration section is now "type=acl" instead of
"type=security".
The original reason for having ACLs configured in a "type=security" section
was to lump ACLs and other security-related items into the same section. The
problem is that ACLs really should be in their own sections and there are
no other security-related options implemented anyways.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397193 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