Age | Commit message (Collapse) | Author |
|
res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds
the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes
on endpoints for unsolicited mwi and on aors for subscriptions required
that the admin know in advance which the client wanted. If you specified
mailboxes on the endpoint, subscriptions were rejected even if you also
specified mailboxes on the aor.
Voicemail extension:
* Added a global default_voicemail_extension which defaults to "".
* Added voicemail_extension to both endpoint and aor.
* Added ast_sip_subscription_get_dialog for support.
* Added ast_sip_subscription_get_sip_uri for support.
When an unsolicited NOTIFY is constructed, the From header is parsed, the
voicemail extension from the endpoint is substituted for the user, and the
result placed in the Message-Account field in the body.
When a subscribed NOTIFY is constructed, the subscription dialog local uri
is parsed, the voicemail_extension from the aor (looked up from the
subscription resource name) is substituted for the user, and the result
placed in the Message-Account field in the body.
If no voicemail extension was defined, the Message-Account field is not added
to the NOTIFY body.
mwi_subscribe_replaces_unsolicited:
* Added mwi_subscribe_replaces_unsolicited to endpoint.
The previous behavior was to reject a subscribe if a previous internal
subscription for unsolicited MWI was found for the mailbox. That remains the
default. However, if there are mailboxes also set on the aor and the client
subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal
subscription is removed and replaced with the external subscription. This
allows an admin to configure mailboxes on both the endpoint and aor and allows
the client to select which to use.
ASTERISK-25865 #close
Reported-by: Ross Beer
Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
|
|
|
|
There were a number of places in the res_pjsip stack that were getting
all endpoints or all aors, and then filtering them locally.
A good example is pjsip_options which, on startup, retrieves all
endpoints, then the aors for those endpoints, then tests the aors to see
if the qualify_frequency is > 0. One issue was that it never did
anything with the endpoints other than retrieve the aors so we probably
could have skipped a step and just retrieved all aors. But nevermind.
This worked reasonably well with local config files but with a realtime
backend and thousands of objects, this was a nightmare. The issue
really boiled down to the fact that while realtime supports predicates
that are passed to the database engine, the non-realtime sorcery
backends didn't.
They do now.
The realtime engines have a scheme for doing simple comparisons. They
take in an ast_variable (or list) for matching, and the name of each
variable can contain an operator. For instance, a name of
"qualify_frequency >" and a value of "0" would create a SQL predicate
that looks like "where qualify_frequency > '0'". If there's no operator
after the name, the engines add an '=' so a simple name of
"qualify_frequency" and a value of "10" would return exact matches.
The non-realtime backends decide whether to include an object in a
result set by calling ast_sorcery_changeset_create on every object in
the internal container. However, ast_sorcery_changeset_create only does
exact string matches though so a name of "qualify_frequency >" and a
value of "0" returns nothing because the literal "qualify_frequency >"
doesn't match any name in the objset set.
So, the real task was to create a generic string matcher that can take a
left value, operator and a right value and perform the match. To that
end, strings.c has a new ast_strings_match(left, operator, right)
function. Left and right are the strings to operate on and the operator
can be a string containing any of the following: = (or NULL or ""), !=,
>, >=, <, <=, like or regex. If the operator is like or regex, the
right string should be a %-pattern or a regex expression. If both left
and right can be converted to float, then a numeric comparison is
performed, otherwise a string comparison is performed.
To use this new function on ast_variables, 2 new functions were added to
config.c. One that compares 2 ast_variables, and one that compares 2
ast_variable lists. The former is useful when you want to compare 2
ast_variables that happen to be in a list but don't want to traverse the
list. The latter will traverse the right list and return true if all
the variables in it match the left list.
Now, the backends' fields_cmp functions call ast_variable_lists_match
instead of ast_sorcery_changeset_create and they can now process the
same syntax as the realtime engines. The realtime backend just passes
the variable list unaltered to the engine. The only gotcha is that
there's no common realtime engine support for regex so that's been noted
in the api docs for ast_sorcery_retrieve_by_fields.
Only one more change to sorcery was done... A new config flag
"allow_unqualified_fetch" was added to reg_sorcery_realtime.
"no": ignore fetches if no predicate fields were supplied.
"error": same as no but emit an error. (good for testing)
"yes": allow (the default);
"warn": allow but emit a warning. (good for testing)
Now on to res_pjsip...
pjsip_options was modified to retrieve aors with qualify_frequency > 0
rather than all endpoints then all aors. Not only was this a big
improvement in realtime retrieval but even for config files there's an
improvement because we're not going through endpoints anymore.
res_pjsip_mwi was modified to retieve only endpoints with something in
the mailboxes field instead of all endpoints then testing mailboxes.
res_pjsip_registrar_expire was completely refactored. It was retrieving
all contacts then setting up scheduler entries to check for expiration.
Now, it's a single thread (like keepalive) that periodically retrieves
only contacts whose expiration time is < now and deletes them. A new
contact_expiration_check_interval was added to global with a default of
30 seconds.
Ross Beer reports that with this patch, his Asterisk startup time dropped
from around an hour to under 30 seconds.
There are still objects that can't be filtered at the database like
identifies, transports, and registrations. These are not going to be
anywhere near as numerous as endpoints, aors, auths, contacts however.
Back to allow_unqualified_fetch. If this is set to yes and you have a
very large number of objects in the database, the pjsip CLI commands
will attempt to retrive ALL of them if not qualified with a LIKE.
Worse, if you type "pjsip show endpoint <tab>" guess what's going to
happen? :) Having a cache helps but all the objects will have to be
retrieved at least once to fill the cache. Setting
allow_unqualified_fetch=no prevents the mass retrieve and should be used
on endpoints, auths, aors, and contacts. It should NOT be used for
identifies, registrations and transports since these MUST be
retrieved in bulk.
Example sorcery.conf:
[res_pjsip]
endpoint=config,pjsip.conf,criteria=type=endpoint
endpoint=realtime,ps_endpoints,allow_unqualified_fetch=error
ASTERISK-25826 #close
Reported-by: Ross Beer
Tested-by: Ross Beer
Change-Id: Id2691e447db90892890036e663aaf907b2dc1c67
|
|
* Remove duplicate res_parking.conf courtesytone config option
documentation.
ASTERISK-24596 #close
Reported by: Philip Correia
ASTERISK-24605
Reported by: Philip Correia
Patches:
call_park_app_doc.patch (license #6672) patch uploaded by Philip Correia
Change-Id: I90a92a891c6494dc08173e675856afcc4764c5b5
|
|
|
|
The 'reload' mechanism actually involves closing the underlying
socket and calling the appropriate udp, tcp or tls start functions
again. Only outbound_registration, pubsub and session needed work
to reset the transport before sending requests to insure that the
pjsip transport didn't get pulled out from under them.
In my testing, no calls were dropped when a transport was changed
for any of the 3 transport types even if ip addresses or ports were
changed. To be on the safe side however, a new transport option was
added (allow_reload) which defaults to 'no'. Unless it's explicitly
set to 'yes' for a transport, changes to that transport will be ignored
on a reload of res_pjsip. This should preserve the current behavior.
Change-Id: I5e759850e25958117d4c02f62ceb7244d7ec9edf
|
|
Warnings and errors in the pjproject libraries are generally handled by
Asterisk. In many cases, Asterisk wouldn't even consider them to be warnings
or errors so the messages emitted by pjproject directly are either superfluous
or misleading. A good exampe of this are the level-0 errors pjproject emits
when it can't open a TCP/TLS socket to a client to send an OPTIONS. We don't
consider a failure to qualify a UDP client an "ERROR", why should a TCP/TLS
client be treated any differently?
A config file for res_pjproject has bene added (pjproject.conf) and a new
log_mappings object allows mapping pjproject levels to Asterisk levels
(or nothing). The defaults if no pjproject.conf file is found are the same
as those that were hard-coded into res_pjproject initially: 0,1 = LOG_ERROR,
2 = LOG_WARNING, 3,4,5 = LOG_DEBUG<level>
Change-Id: Iba7bb349c70397586889b8f45b8c3d6c6c8c3898
|
|
|
|
* changes:
app_confbridge: Add ability to get the muted conference state.
app_confbridge.c: Update CONFBRIDGE and CONFBRIDGE_INFO documentation.
app_confbridge: Make non-admin users join a muted conference muted.
|
|
ps_systems needed disable_tcp_switch
ps_registrations needed line and endpoint
ASTERISK-25737 #close
Change-Id: Iaf9c2d69e62243d9fa53104c28c5339c47d4ac19
|
|
During ICE negotiation the IPs of the local interfaces are sent to the remote
peer as host candidates. In many cases Asterisk is behind a static one-to-one
NAT, so these host addresses will be internal IP addresses.
To help in hiding the topology of the internal network, this patch adds the
ability to override the host candidates by matching them against a
user-defined list of replacements.
Change-Id: I1c9541af97b83a4c690c8150d19bf7202c8bff1f
|
|
This change exposes the configuration of various aspects of the TLS
support and sets the default to the modern standards.
The TLS cipher is now set to the best values according to the
Mozilla OpSec team, different TLS versions can now be disabled, and
the cipher order can be forced to be that of the server instead of
the client.
ASTERISK-24972 #close
Change-Id: I0a10f2883f7559af5e48dee0901251dbf30d45b8
|
|
ASTERISK-20987 #close
Reported by: hristo
Change-Id: Ic61a2b524ab3a4cfadf227fc6b3506527bc03f38
|
|
Since res_pjsip now depends on res_pjproject, this is now mentioned
in UPGRADE.txt and the basic-pbx modules.conf has been updated.
Change-Id: I42826597d5e10f08e518208860c44c96e52f1b2d
|
|
Update the version number in the comments from Asterisk 12 to Asterisk 12+
Change-Id: Ie692ac8cda3c993c3bf10f27f51a1cca3317ec7b
|
|
|
|
On a system with multiple ip addresses in the same subnet, if a
transport is bound to a specific ip address and endpoint/media_address
is set, the SIP/SDP will have the correct address in all fields but
the rtp stream MAY still originate from one of the other ip addresses,
most probably the "primary" ip address. This happens because
res_pjsip_sdp_rtp/create_rtp always calls ast_instance_new with
the "all" ip address (0.0.0.0 or ::).
The new option causes res_pjsip_sdp_rtp/create_rtp to call
ast_rtp_instance_new with the endpoint's media_address (if specified)
instead of the "all" address. This causes the packets to originate from
the specified address.
ASTERISK-25632
ASTERISK-25637
Reported-by: Olivier Krief
Reported-by: Dan Journo
Change-Id: I3dfaa079e54ba7fb7c4fd1f5f7bd9509bbf8bd88
|
|
Added new global option (regcontext) to pjsip. When set, Asterisk will
dynamically create and destroy a NoOp priority 1 extension
for a given endpoint who registers or unregisters with us.
ASTERISK-25670 #close
Reported-by: Daniel Journo
Change-Id: Ib1530c5b45340625805c057f8ff1fb240a43ea62
|
|
Update documentation to reflect that maximum_number_of_words
has functionality inconsistent with the variable name (and inconsistent
with prior documentation.)
Update documentation for silence_threshold, which previously implied
that it was measuring time, rather than noise averages in the sample.
Update the comments in amd.conf.sample.
ASTERISK-25639 #close
Change-Id: I4b1451e5dc9cb3cb06d59b6ab872f5275ba79093
|
|
This option adds the ability to specify a timeout, in seconds, for a
participant in a ConfBridge. When the user's timeout has been reached,
the user is ejected from the conference with the CONFBRIDGE_RESULT
channel variable set to "TIMEOUT".
The rationale for this change is that there have been times where we
have seen channels get "stuck" in ConfBridge because a network issue
results in a SIP BYE not being received by Asterisk. While these
channels can be hung up manually via CLI/AMI/ARI, adding some sort of
automatic cleanup of the channels is a nice feature to have.
ASTERISK-25549 #close
Reported by Mark Michelson
Change-Id: I2996b6c5e16a3dda27595f8352abad0bda9c2d98
|
|
This patch adds a new setting "websockets_enabled" to sip.conf.
Setting this to false allows chan_sip to be used without causing
conflicts with res_pjsip_transport_websocket.
ASTERISK-24106 #close
Reported by: Andrew Nagy
Change-Id: I04fe8c4f2d57b2d7375e0e25826c91a72e93bea7
|
|
During outbound registration it is possible to receive a fatal (any permanent/
non-temporary 4xx, 5xx, 6xx) response from the registrar that is simply due
to a problem with the registrar itself. Upon receiving the failure response
Asterisk terminates outbound registration for the given endpoint.
This patch adds an option, 'fatal_retry_interval', that when set continues
outbound registration at the given interval up to 'max_retries' upon receiving
a fatal response.
ASTERISK-25485 #close
Change-Id: Ibc2c7b47164ac89cc803433c0bbe7063bfa143a2
|
|
This change adds support for the 'rtp_timeout' and 'rtp_timeout_hold'
endpoint options. These allow the channel to be hung up if RTP
is not received from the remote endpoint for a specified number of
seconds.
ASTERISK-25259 #close
Change-Id: I3f39daaa7da2596b5022737b77799d16204175b9
|
|
Change-Id: I5f62d0c5684f8b2335f9f8ac2d79ee04fbdafb19
|
|
* In sip.conf.sample fix sentence where we said that WS or WSS are supported
transports for use in an outbound register definition. They are not
supported in that case.
* In func_cdr.c made it clear that the Disable option for CDR_PROP can be used
to enable CDR on a channel.
ASTERISK-24867 #close
Reported by: Rusty Newton
ASTERISK-24853 #close
Reported by: PSDK
Change-Id: I3d698bc6302b9d00a0a995b5c4ad9a42d69b48ca
|
|
Some phones send g.726 audio packed for AAL2, which differs from what is
recommended by RFC 3351. If Asterisk receives audio formatted as such when
negotiating g.726 then it sounds a bit distorted. Added an option to
res_pjsip_endpoint that allows g.726 negotiated audio to be treated as g.726
AAL2 packed.
ASTERISK-25158 #close
Reported by: Steve Pitts
Change-Id: Ie7e21f75493d7fe53e75e12c971e72f5afa33615
|
|
The main IVR was playing demo-congrats. I've switched it over to the
basic-pbx-ivr-main file that we added in core sounds 1.4.27. This prompt
has Allison prompting the user with the actual IVR menu.
ASTERISK-24892 #close
Change-Id: Ifb749616ff8e156a1031ddaddfcc9244767a095d
|
|
ASTERISK-25034
Reported by: Richard Mudgett
Change-Id: I1ff8f02124d2f4abd632a050da52c64285bb7f30
|
|
This patch adds a new option to cdr.conf, 'newcdrcolumns', that will handle CDR
columns added in Asterisk 1.8. The columns are:
* peeraccount
* linkedid
* sequence
When enabled, the columns in the database entry will be populated with the data
from the CDR.
ASTERISK-24976 #close
Change-Id: I51a57063f4ae5e194a9d933a8df45dc8a4534f0b
|
|
The sample pjsip.conf has a few comment lines that are missing the
semicolons at the start of the comment, causing the config to fail
load.
Change-Id: I776a38c916a7df7ee3e072fd0b21dbf4cc457352
|
|
option." into 13
|
|
Some telco switches occasionally ignore ISDN RESTART requests. The fix
for ASTERISK-19608 added an escape clause for B channels in the restarting
state if the telco ignores a RESTART request. If the telco fails to
acknowledge the RESTART then Asterisk will assume the telco acknowledged
the RESTART on the second call attempt requesting the B channel by the
telco. The escape clause is good for dealing with RESTART requests in
general but it does cause the next call for the restarting B channel to be
rejected if the telco insists the call must go on that B channel.
chan_dahdi doesn't really need to issue a RESTART request in response to
receiving a cause 44 (Requested channel not available) code. Sending the
RESTART in such a situation is not required (nor prohibited) by the
standards. I think chan_dahdi does this for historical reasons to deal
with buggy peers to get channels unstuck in a similar fashion as the
chan_dahdi.conf resetinterval option.
* Add the chan_dahdi.conf force_restart_unavailable_chans compatability
option that when disabled will prevent chan_dahdi from trying to RESTART
the channel in response to a cause 44 code.
ASTERISK-25034 #close
Reported by: Richard Mudgett
Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65
|
|
Virtual line support establishes a relationship between messages
related to an outbound registration and a local endpoint. This is
accomplished by attaching a parameter to the Contact of the outbound
registration and looking for it on any received requests. If the
parameter exists and can be matched to an outbound registration
the configured endpoint is associated with the request.
ASTERISK-24949 #close
Reported by: Joshua Colp
Change-Id: I7df909d2625479110a83fdd354c21ac539e8615d
|
|
Add new column to INSERT new columns added in cdr 1.8 version. The columns are:
* peeraccount
* linkedid
* sequence
This feature is configurable in cdr_odbc.conf using a new configuration
option, 'newcdrcolumns'.
ASTERISK-24976 #close
Change-Id: Ibe0c7540a88305c6012786f438a0813ad8b19127
|
|
This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
The basic issues are that changes in contact status don't cause events to be
emitted for the associated endpoint. Only dynamic contact add/delete actions
update the endpoint. Also, the qualify timeout is fixed by pjsip at 32 seconds
which is a long time.
This patch makes use of the new transaction timeout feature in r4585 and
provides the following capabilities...
1. A new aor/contact variable 'qualify_timeout' has been added that allows the
user to specify the maximum time in milliseconds to wait for a response to an
OPTIONS message. The default is 3000ms. When the timer expires, the contact is
marked unavailable.
2. Contact status changes are now propagated up to the endpoint as follows...
When any contact is 'Available', the endpoint is marked as 'Reachable'. When
all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'. The
existing endpoint events are generated appropriately.
ASTERISK-24863 #close
Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
Tested-by: Dmitriy Serov
Tested-by: George Joseph <george.joseph@fairview5.com>
|
|
Currently when Asterisk starts initial qualifies of contacts are spread out
randomly between 0 and qualify_timeout to prevent network and system overload.
If a contact's qualify_frequency is 5 minutes however, that contact may be
unavailable to accept calls for the entire 5 minutes after startup. So while
staggering the initial qualifies is a good idea, basing the time on
qualify_timeout could leave contacts unavailable for too long.
This patch adds a new global parameter "max_initial_qualify_time" that sets the
maximum time for the initial qualifies. This way you could make sure that all
your contacts are initialy, randomly qualified within say 30 seconds but still
have the contact's ongoing qualifies at a 5 minute interval.
If max_initial_qualify_time is > 0, the formula is initial_interval =
min(max_initial_interval, qualify_timeout * random(). If not set,
qualify_timeout is used.
The default is "0" (disabled).
ASTERISK-24863 #close
Change-Id: Ib80498aa1ea9923277bef51d6a9015c9c79740f4
Tested-by: George Joseph <george.joseph@fairview5.com>
|
|
After the "progressinband" value setting of "never" was updated to never send a
183 this separated its use from the "no" value. Since "never" was the default,
but most users probably expect "no" this patch updates the default for the
"progressinband" setting to "no."
ASTERISK-24835 #close
Reported by: Andrew Nagy
Review: https://reviewboard.asterisk.org/r/4606/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434654 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Review: https://reviewboard.asterisk.org/r/4503/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433658 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Review: https://reviewboard.asterisk.org/r/4504/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433656 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Example configuration files for a "basic PBX" deployment for the fictitious
Super Awesome Company. Details at https://reviewboard.asterisk.org/r/4488/
and https://wiki.asterisk.org/wiki/display/AST/Super+Awesome+Company
Patch 4488 includes all functionality needed for SAC's outside connectivity
and some externally accessed features, as well as outbound dialing.
Reported by: Malcolm Davenport
Tested by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/4488/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433624 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
messages.
Incoming PJSIP call legs that have not been answered yet send unnecessary
"180 Ringing" or "183 Progress" messages every time a connected line
update happens. If the outgoing channel is also PJSIP then the incoming
channel will always send a "180 Ringing" or "183 Progress" message when
the outgoing channel sends the INVITE.
Consequences of these unnecessary messages:
* The caller can start hearing ringback before the far end even gets the
call.
* Many phones tend to grab the first connected line information and refuse
to update the display if it changes. The first information is not likely
to be correct if the call goes to an endpoint not under the control of the
first Asterisk box.
When connected line first went into Asterisk in v1.8, chan_sip received an
undocumented option "rpid_immediate" that defaults to disabled. When
enabled, the option immediately passes connected line update information
to the caller in "180 Ringing" or "183 Progress" messages as described
above.
* Added "rpid_immediate" option to prevent unnecessary "180 Ringing" or
"183 Progress" messages. The default is "no" to disable sending the
unnecessary messages.
ASTERISK-24781 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4473/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch fixes previously reverted code that caused binary incompatibility
problems with some modules. And like the original patch it makes sure that
no matter what order the endpoint identifier modules were loaded, priority is
given based on the ones specified in the new global 'endpoint_identifier_order'
option.
ASTERISK-24840
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4489/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch corrects the documentation for the AMD application. Specifically:
* It documents the maximum_word_length option, which limits the maximum allowed
length of a single utterance.
* It clarifies the AMDCAUSE values MAXWORDS and MAXWORDLENGTH. MAXWORDLENGTH
was documented as MAXWORDS, while MAXWORDS was undocumented.
Thanks to the issue reporter, Frank DiGennaro, for pointing out the issues.
ASTERISK-19470 #close
Reported by: Frank DiGennaro
........
Merged revisions 432918 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432920 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Due to a break in binary compatibility with some other modules these changes
are being reverted until the issue can be resolved.
ASTERISK-24840
Reported by: Mark Michelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
It's possible to have a scenario that will create a conflict between endpoint
identifiers. For instance an incoming call could be identified by two different
endpoint identifiers and the one chosen depended upon which identifier module
loaded first. This of course causes problems when, for example, the incoming
call is expected to be identified by username, but instead is identified by ip.
This patch adds a new 'global' option to res_pjsip called
'endpoint_identifier_order'. It is a comma separated list of endpoint
identifier names that specifies the order by which identifiers are processed
and checked.
ASTERISK-24840 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4455/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Example configuration files for a "basic PBX" deployment for the fictitious
Super Awesome Company. Details at https://reviewboard.asterisk.org/r/4379/
and https://wiki.asterisk.org/wiki/display/AST/Super+Awesome+Company
Reported by: Malcolm Davenport
Tested by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/4379/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432301 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The "contact" object is not meant to be configured from the pjsip.conf
configuration file. It is meant to be created as a result of a registration
and stored elsewhere.
ASTERISK-24085 #close
Reported by: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431860 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Looking at the Super Awesome Company sample reminded me that creating hints is
just plain gruntwork. So you can now have the pjsip conifg wizard auto-create
them for you.
Specifying 'hint_exten' in the wizard will create
'exten => <hint_exten>,hint/PJSIP/<wizard_id>'
in whatever is specified for 'hint_context'.
Specifying 'hint_application' in the wizard will create
'exten => <hint_exten>,1,<hint_application>'
in whatever is specified for 'hint_context'.
The default for 'hint_context' is the endpoint's context.
There's no default for 'hint_application'. If not specified, no app is added.
There's no default for 'hint_exten'. If not specified, neither the hint itself
nor the application will be created.
Some may think this is the slippery slope to users.conf but hints are a basic
necessity for phones unlike voicemail, manager, etc that users.conf creates.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4383/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Added a new config property [servername] to the http.conf file; updated the http server to use the new property when sending responses, for showing http status through the CLI and when reporting status through the 'httpstatus' webpage.
ASTERISK-24316 #close
Reported By: Andrew Nagy
Review: https://reviewboard.asterisk.org/r/4374/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
across a bridge.
Calling ast_channel_bridge_peer() cannot be done while holding any channel
locks. The reported issue hit the deadlock in chan_iax2, but an audit of
the ast_channel_bridge_peer() calls found three more locations where the
same deadlock can occur.
* Made CHANNEL(peer), res_fax, and the SNMP agent not call
ast_channel_bridge_peer() with any channel locked. For CHANNEL(peer) I
had to rework the logic to not hold the channel lock.
* Made chan_iax2 no longer call ast_channel_bridge_peer(). It was done
for legacy reasons that no longer apply.
* Removed the iax.conf forcejitterbuffer option. It is now always enabled
when the jitterbuffer option is enabled. If you put a jitter buffer on a
channel it will be on the channel.
ASTERISK-24600 #close
Reported by: Jeff Collell
Review: https://reviewboard.asterisk.org/r/4342/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|