Several fixes for the WebSockets implementation in res/res_http_websocket.c
* Flush the websocket session FILE* as fwrite() may not actually guarantee sending
the data to the network. If we do not flush, it seems that buffering on the SSL
socket for outbound messages causes issues
* Refactored ast_websocket_read to take into account that SSL file descriptors
may be ready to read via fread() but poll() will not actually say so because
the data was already read from the network buffers and is now in the libc buffers
(closes issue ASTERISK-23099)
(closes issue ASTERISK-21930)
Review: https://reviewboard.asterisk.org/r/3248/
........
Merged revisions 409681 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 409697 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
Correct RTP handling in chan_unistim and fix transfer process broken in previous fix:
- Fixed too early RTP setup with phone, that cause no ringback tone on caller side
- Handle call transfer cancel only in STATE_CALL case (related to ASTERISK-23073)
(Reported by: Németh Tamás, niurkin sil)
........
Merged revisions 409761 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Remove some unnecessary RAII_VAR() usage.
* Made the struct stasis_subscription ao2 object use the ao2 lock instead
of a redundant join_lock in the struct for ast_cond_wait().
* Removed locks on some ao2 objects that don't need the lock.
* Made the topic pool entries container use the ao2 template functions.
* Add some missing allocation failure checks.
* Add missing cleanup in off nominal path of dispatch_message().
........
Merged revisions 409270 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409271 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r409129 | jrose | 2014-02-27 13:19:02 -0600 (Thu, 27 Feb 2014) | 15 lines
res_rtp_asterisk: Fix checklist creating problems in ICE sessions
Prior to this patch, local candidate lists including SRFLX would fail to start
properly when building ICE candidate check lists. This patch fixes that problem
by making sure that each SRFLX candidate is associated with the proper
base address so that the check list can create matches properly.
This patch was written by jcolp. The issue will be left open to await testing
by the issue participants.
(issue ASTERISK-23213)
Reported by: Andrea Suisani
Review: https://reviewboard.asterisk.org/r/3256/
........
r409130 | jrose | 2014-02-27 13:38:10 -0600 (Thu, 27 Feb 2014) | 8 lines
res_rtp_asterisk: correct build error from r409129
Accidentally placed a declaration below functional code
(issue ASTERISK-23213)
Reported by: Andrea Suisani
Review: https://reviewboard.asterisk.org/r/3256/
........
Merged revisions 409129-409130 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 409131 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The setting 'use_ptime' is supposed to tell Asterisk to honour the ptime
attribute in an offer, preferring it to whatever packetization
preferences have been set internally. Currently, however, something
rather quirky will happen:
(1) The SDP answer will be constructed in create_outgoing_sdp_stream.
This will use the preferences from the endpoint, such that the 200 OK
response will add the packetization preferences from the endpoint, and
not what was offered.
(2) When the 200 response is issued, apply_negotiated_sdp_stream is called.
This will call apply_packetization, which will use the ptime attribute
from the offer internally.
We end up telling the offerer to use the internal ptime attribute, but we end
up using the offered ptime attribute. Hilarity ensues.
This patch modifies the behaviour by calling apply_packetization from
negotiate_incoming_sdp_stream, which is called prior to
create_outgoing_sdp_stream. This causes the format preferences on the
session's media object to be set to the inbound ptime value (if 'use_ptime'
is enabled), such that the construction of the answer gets the right value
immediately.
Review: https://reviewboard.asterisk.org/r/3244/
........
Merged revisions 408999 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409000 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Make the consumer ao2 object use the ao2 lock instead of a redundant
lock in the struct for ast_cond_wait().
* Fixed some curly brace placements.
* Fixed use of malloc(0). malloc(0) has variant behavior. It is up to
the implementation to determine if it returns NULL or a valid pointer that
can be later passed to free().
........
Merged revisions 408983 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When accidentally compiling against a wrong version of
pjsip headers with a different pjsip_inv_session size,
the invite_tsx structure could be null in the answer()
function. This led to a crash because it attempted to
send the session response with an uninitialized packet
pointer. This patch presets packet to null and adds a
diagnostic log message to explain why the call fails.
Review: https://reviewboard.asterisk.org/r/3267/
........
Merged revisions 408970 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408971 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is currently possible for an ast_sip_session to exist without an
associated channel as is the case when a new invite is coming in or
just after a hangup is issued on a chan_pjsip channel. Part of the
attended transfer code assumed the channel would be non-NULL and used
it as such causing a crash. This bug was exposed thanks to the attended
transfer ARI test in the test suite.
(closes issue ASTERISK-23287)
Reported by: Matt Jordan
........
Merged revisions 408941 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the ability for transferring directly to voicemail on digium phones.
Added a new module that checks for the presence of a custom header and/or
diversion header within a sip REFER. If either is found and they specify
a sending to voicemail action then variables are added to the channel
allowing the user access to them in the dialplan. Dialplan can then be
written that branches based upon these values allowing, for instace, for
a single number to be used for dialing and/or accessing voicemail directly.
Also fixed a problem where the PJSIP_HEADER function was allowing non pjsip
channels through (checked to make sure it has the correct channel type before
proceeding).
Review: https://reviewboard.asterisk.org/r/3245/
........
Merged revisions 408880 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is possible to pre-load pbx_config. As a result, pbx_config - which will
load and parse the dialplan - will attempt to use various dialplan components,
such as device state providers and presence state providers, prior to them
being initialized by the core. This would lead to a crash, as the components
had not created their Stasis cache entries.
This patch moves a number of core component initializations before the module
pre-load. This guarantees that if someone does pre-load pbx_config - or other
pbx modules - that the Stasis caches for the various core components are
created.
(closes issue ASTERISK-23320)
Reported by: xrobau
(closes issue ASTERISK-23265)
Reported by: Andrew Nagy
Tested by: Andrew Nagy, Rusty Newton
........
Merged revisions 408855 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408859 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk didn't support the dynamic payload change in rtp mapping in the 200
OK response.
Scenario:
Asterisk sends the INVITE proposing alaw and telephone-event, it proposes
rtpmap:101 for telephone-event. Peer responds with 2xx, it answers with
alaw and telephone-event also, but it proposes a different rtpmap number
(rtpmap:103) for telephone-event.
Expected Behaviour:
Asterisk should honour the rtpmapping in the response and send DTMF packets
using 103 as payload type for DTMF.
Actual Behaviour: Asterisk sends DTMF packets using payload type 101.
With this patch asterisk now supports changes that can occur in the rtp mapping
in the response.
(closes issue ASTERISK-23279)
Reported by: NITESH BANSAL
Review: https://reviewboard.asterisk.org/r/3225/
Patches:
dynamic_payload_change.patch uploaded by nbansal (license 6418)
........
Merged revisions 408729 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 408730 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed off-nominal json ref counting issue with using the following API
calls: ast_json_object_set() and ast_json_array_append().
* Fixed off-nominal error reporting in ast_ari_endpoints_list().
* Fixed some miscellaneous off-nominal json ref counting issues in
report_receive_fax_status() and dial_to_json().
........
Merged revisions 408713 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408714 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Updated the code to check to see if MOH is playing on the transferor and if
so then start it on the channel that replaces it during a masquerade.
Example scenario of the problem:
Alice calls Bob and then Bob begins the attended transfer process into a queue.
Upon going on hold Alice hears music and so does Bob once he is in the queue.
Bob then transfers Alice into the queue and then music for Alice stops even
though she should be hearing it since has now replaced Bob in the queue.
The problem that was occurring is that once the channel was masqueraded the app
(queues, confbridge, etc...) had no way of knowing that the channel had just
been swapped out thus it did not start music for the present channel.
Credit to Olle Johansson for pointing me in the right direction on this issue.
(closes issue ASTERISK-19499)
Reported by: Timo Teräs
Review: https://reviewboard.asterisk.org/r/3226/
........
Merged revisions 408642 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 408643 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 408644 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408645 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the "x" option (specify a DTMF digit to exit the application), it is
not obvious in the documentation that this only works when spying on a channel.
If a channel being used to spy on other channels is waiting to connect to a
channel or is no longer attached to a channel, the DTMF is ignored.
As noted on the issue tracker, since there are workarounds available and this is
a rarely used option we are opting for a documentation change here.
(closes issue ASTERISK-22661)
Reported by: Chris Hillman
Patches:
asterisk-22661-doc-clarify-chan_spy.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2990/
........
Merged revisions 408536 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 408537 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 408538 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to retrieve an arbitrary sorcery instance from a dialplan function
(or any place else) there needs to be a registry of sorcery instances.
ast_sorcery_init now creates a hashtab as a registry.
ast_sorcery_open now checks the hashtab for an existing sorcery instance
matching the caller's module name. If it finds one, it bumps the
refcount and returns it. If not, it creates a new sorcery instance,
adds it to the hashtab, then returns it.
ast_sorcery_retrieve_by_module_name is a new function that does a hashtab
lookup by module name. It can be called by the future dialplan function.
res_pjsip/config_system needed a small change to share the main res_pjsip
sorcery instance.
tests/test_sorcery was updated to include a test for the registry.
(closes issue ASTERISK-22537)
Review: http://reviewboard.asterisk.org/r/3184/
........
Merged revisions 408518 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When 'use_avpf' is set to True, inbound offers must use the AVPF/SAVPF RTP
profile. However, when 'use_avpf' is set to False, Asterisk will accept
both AVP/SAVP or AVPF/SAVPF RTP profiles in inbound offers. The documentation
previously implied that Asterisk would reject AVPF/SAVPF if 'use_avpf' was
set to False and a UA offered said profile in an INVITE request.
........
Merged revisions 408502 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408503 65c4cc65-6c06-0410-ace0-fbb531ad65f3