The JSON library Asterisk uses, jansson, is not thread
safe for us in a few ways. To help with this wrappers for JSON
object reference count increasing and decreasing were added
which use a global lock to ensure they don't clobber over
each other. This does not extend to reference count manipulation
within the jansson library itself. This means you can't safely
use the object borrowing specifier (O) in ast_json_pack and
you can't share JSON instances between objects.
This change removes uses of the O specifier and replaces them
with the o specifier and an explicit ast_json_ref. Some cases
of instance sharing have also been removed.
ASTERISK-25601 #close
Change-Id: I06550d8b0cc1bfeb56cab580a4e608ae4f1ec7d1
Both transport and endpoint now check for the existence and readability
of tls certificate and key files before passing them on to pjproject.
This will cause the object to not load rather than waiting for pjproject
to discover that there's a problem when a session is attempted.
NOTE: chan_sip also uses ast_rtp_dtls_cfg_parse but it's located
in build_peer which is gigantic and I didn't want to disturb it.
Error messages will emit but it won't interrupt chan_sip loading.
ASTERISK-25618 #close
Change-Id: Ie43f2c1d653ac1fda6a6f6faecb7c2ebadaf47c9
Reported-by: George Joseph
Tested-by: George Joseph
Previously, format-attribute modules relied on an existing fmtp line in SDP
negotiation. However, fmtp is optional for several formats like the Opus Codec.
Now, the format-attribute module is called with an empty fmtp, which allows the
module to initialise itself to RFC defaults. Furthermore now, Asterisk is able
to differentiate between internally and externally created formats.
ASTERISK-25537 #close
Change-Id: I28f680cef7fdf51c0969ff8da71548edad72ec52
* Make ast_rtp_codecs_payload_code() get the current mapping or create a
rx payload type mapping.
ASTERISK-25166
Reported by: Kevin Harwell
ASTERISK-17410
Reported by: Boris Fox
Change-Id: Ia4b2d45877a8f004f6ce3840e3d8afe533384e56
There are numerous problems with the current implementation of the RTP
payload type mapping in Asterisk. It uses only one mapping structure to
associate payload types to codecs. The single mapping is overkill if all
of the payload type values are well known values. Dynamic payload type
mappings do not work as well with the single mapping because RFC3264
allows each side of the link to negotiate different dynamic mappings for
what they want to receive. Not only could you have the same codec mapped
for sending and receiving on different payload types you could wind up
with the same payload type mapped to different codecs for each direction.
1) An independent payload type mapping is needed for sending and
receiving.
2) The receive mapping needs to keep track of previous mappings because of
the slack to when negotiation happens and current packets in flight using
the old mapping arrive.
3) The transmit mapping only needs to keep track of the current negotiated
values since we are sending the packets and know when the switchover takes
place.
* Needed to create ast_rtp_codecs_payload_code_tx() and make some callers
use the new function because ast_rtp_codecs_payload_code() was used for
mappings in both directions.
* Needed to create ast_rtp_codecs_payloads_xover() for cases where we need
to pass preferred codec mappings to the peer channel for early media
bridging or when we need to prefer the offered mapping that RFC3264 says
we SHOULD use.
* ast_rtp_codecs_payloads_xover() and ast_rtp_codecs_payload_code_tx() are
the only new public functions created. All the others were only used for
the tx or rx mapping direction so the function doxygen now reflects which
direction the function operates.
* chan_mgcp.c: Removed call to ast_rtp_codecs_payloads_clear() as doing
that makes no sense when processing an incoming SDP. We would be wiping
out any mappings that we set for the possible outgoing SDP we sent
earlier.
ASTERISK-25166
Reported by: Kevin Harwell
ASTERISK-17410
Reported by: Boris Fox
Change-Id: Iaf6c227bca68cb7c414cf2fd4108a8ac98bd45ac
ast_rtp_codecs_get_payload() gets called once or twice for every received
RTP frame so it would be nice to not allocate an ao2 object to then have
it destroyed shortly thereafter. The ao2 object gets allocated only if
the payload type is not set by the channel driver as a negotiated value.
The issue affects chan_skinny, chan_unistim, chan_rtp, and chan_ooh323.
* Made static_RTP_PT[] an array of ao2 objects that
ast_rtp_codecs_get_payload() can return instead of an array of structs
that must be copied into a created ao2 object.
ASTERISK-25296 #close
Reported by: Richard Mudgett
Change-Id: Icb6de5cd90bfae07d44403a1352963db9109dac0
* Fix off nominial ref leak of new_type in
ast_rtp_codecs_payloads_set_m_type().
* No need to lock static_RTP_PT_lock in
ast_rtp_codecs_payloads_set_m_type() and
ast_rtp_codecs_payloads_set_rtpmap_type_rate() before the payload type
parameter sanity check.
* No need to create ast_rtp_payload_type ao2 objects with a lock since the
lock is not used.
Change-Id: I64dd1bb4dfabdc7e981e3f61448beac9bb7504d4
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
This adds an "rtp_keepalive" option for PJSIP endpoints. Similar to the
chan_sip option, this specifies an interval, in seconds, at which we
will send RTP comfort noise frames. This can be useful for keeping RTP
sessions alive as well as keeping NAT associations alive during lulls.
ASTERISK-25242 #close
Reported by Mark Michelson
Change-Id: I3b9903d99e35fe5d0b53ecc46df82c750776bc8d
When running valgrind on Asterisk, it complained about:
==32423== Source and destination overlap in memcpy(0x85a920, 0x85a920, 304)
==32423== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/...)
==32423== by 0x55BA91: ast_rtp_engine_unload_format (rtp_engine.c:2292)
==32423== by 0x4EEFB7: ast_format_attr_unreg_interface (format.c:1437)
The code in question is a struct assignment, which may be performed by
memcpy as a compiler optimization. It is changed to only copy the struct
contents if source and destination are different.
ASTERISK-25219 #close
Change-Id: I6d3546c326b03378ca8e9b8cefd41c16e0088b9a
Renamed AST_VECTOR_INSERT to AST_VECTOR_REPLACE because it really
does replace not insert. The few users of AST_VECTOR_INSERT were
refactored. Because these are macros, there should be no ABI
compatibility issues.
Added AST_VECTOR_INSERT_AT that actually inserts an element into the
vector at a specific index pushing existing elements to the right.
Added AST_VECTOR_GET_CMP that can retrieve from the vector based
on a user-provided compare function.
Added AST_VECTOR_CALLBACK function that will execute a function
for each element in the vector. Similar to ao2_callback and
ao2_callback_data functions although the vector callback can take
a variable number of arguments. This should allow easy migration
to a vector where a container might be too heavy.
Added read/write locked vector and lock manipulation macros.
Added unit tests.
ASTERISK-25045 #close
Change-Id: I2e07ecc709d2f5f91bcab8904e5e9340609b00e0
The patch in 0b6410c4f8 did correctly fix a memory leak of the DTLS
structures in the RTP engine. However, when a 'core reload' is issued, a
double free of the memory pointed to by the char *'s in the DTLS
configuration struct can occur, as ast_rtp_dtls_cfg_free does not set
the pointers to NULL when they are freed.
This patch sets those pointers to NULL, preventing a second call to
ast_rtp_dtls_cfg_free from corrupting memory.
ASTERISK-25022
Change-Id: I820471e6070a37e3c26f760118c86770e12f6115
ao2 ref leak in res_rtp_asterisk.c when a DTLS policy is created.
The resources are linked into a table, but the original alloc refs
are never released. ast_strdup leak in rtp_engine.c. If
ast_rtp_dtls_cfg_copy() is called twice on the same destination struct,
a pointer to an alloc'd string is overwritten before the string is free'd.
ASTERISK-25022
Reported by: one47
Change-Id: I62a8ceb8679709f6c3769136dc6aa9a68202ff9b
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
remove passing the version in with the macro. Other facilities
than 'core show file version' make use of the file names, such as
setting a debug level only on a specific file. As such, the act of
registering source files with the Asterisk core still has use. The
macro rename now reflects the new macro purpose.
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Remove the "core show file version" CLI command. Without the file
version, it is no longer useful.
- Remove the ast_file_version_find function. The file version is no
longer tracked.
- Rename ast_register_file_version/ast_unregister_file_version to
ast_register_file/ast_unregister_file, respectively.
* main/manager: Remove value from the Version key of the ModuleCheck
Action. The actual key itself has not been removed, as doing so would
absolutely constitute a backwards incompatible change. However, since
the file version is no longer tracked, there is no need to attempt to
include it in the Version key.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action
- Removal of the "core show file version" CLI command
Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
Since 'core stop now' and 'core restart now' do not stop modules,
it is unsafe for most of the core to run cleanups. Originally all
cleanups used ast_register_atexit, and were only changed when it
was shown to be unsafe. ast_register_atexit is now used only when
absolutely required to prevent corruption and close child processes.
Exceptions that need to use ast_register_atexit:
* CDR: Flush records.
* res_musiconhold: Kill external applications.
* AstDB: Close the DB.
* canary_exit: Kill canary process.
ASTERISK-24142 #close
Reported by: David Brillert
ASTERISK-24683 #close
Reported by: Peter Katzmann
ASTERISK-24805 #close
Reported by: Badalian Vyacheslav
ASTERISK-24881 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4500/
Review: https://reviewboard.asterisk.org/r/4501/
........
Merged revisions 433495 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433497 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses compilation errors on OS X. It's been a while, so
there's quite a few things.
* Fixed __attribute__ decls in route.h to be portable.
* Fixed htonll and ntohll to work when they are defined as macros.
* Replaced sem_t usage with our ast_sem wrapper.
* Added ast_sem_timedwait to our ast_sem wrapper.
* Fixed some GCC 4.9 warnings using sig*set() functions.
* Fixed some format strings for portability.
* Fixed compilation issues with res_timing_kqueue (although tests still fail
on OS X).
* Fixed menuconfig /sbin/launchd detection, which disables res_timing_kqueue
on OS X).
ASTERISK-24539 #close
Reported by: George Joseph
ASTERISK-24544 #close
Reported by: George Joseph
Review: https://reviewboard.asterisk.org/r/4327/
........
Merged revisions 431092 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the RTCP reports are created, the NTP timestamps are stored as strings,
as JSON does not have an integer type long enough to store the value. However,
on 32-bit systems, a signed long may overflow for some portion of the
timestamp.
This patch corrects the overflow by formatting the timestamps as unsigned
longs.
........
Merged revisions 430840 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r428708 additional codecs were added including
a payload type of 128 which is outside of nominal
range of 0-127. This change moves changes 128 to
96 to avoid causing a pjsip assertion when making
a call to an endpoint configured with allow=all.
ASTERISK-24367 #close
Review: https://reviewboard.asterisk.org/r/4286/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When endpoints with direct_media enabled, behind a firewall (Asterisk on a
separate network) and were bridged sometimes Asterisk would send the ip
address of the firewall in the sdp to one of the phones in the reinvite
resulting in one way audio. When sending the reinvite Asterisk will retrieve
the media address from the associated rtp instance, but if frames were being
read this can be overwritten with another address (in this case the
firewall's). This patch ensures that Asterisk uses the original device
address when using direct media.
ASTERISK-24563
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4216/
........
Merged revisions 429195 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429196 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk - in res_rtp_asterisk - only understands a single RTCP report info
block. When the RTCP information was refactored in the RTP Engine to be pushed
over the Stasis message bus, I put in the hooks into the engine to handle
multiple RTCP report info blocks, in the hope that a future RTP implementation
would be able to provide that data. Unfortunately, res_rtp_asterisk has a
tendency to "lie":
(1) It will send RTCP reports with a reception_report_count greater than 1
(which is pulled directly from the RTCP packet itself, so that part is
correct)
(2) It will only provide a single report block
When the rtp_engine goes to convert this to a JSON blob, hilarity ensues as it
looks for a report block that doesn't exist.
This patch updates the rtp_engine to be a bit more skeptical about what it is
presented with. While this could also be fixed in res_rtp_asterisk, this patch
prefers to fix it in the engine for two reasons:
(1) The engine is designed to work with multiple RTP implementation, and hence
having it be more robust is a good thing (tm)
(2) res_rtp_asterisk's handling of RTCP information is "fun". It should report
the correct reception_report_count; ideally it should also be giving us all
of the blocks - but it is *definitely* not designed to do that. Going down
that road is a non-trivial effort.
Review: https://reviewboard.asterisk.org/r/4158/
ASTERISK-24489 #close
Reported by: Gregory Malsack
Tested by: Gregory Malsack
ASTERISK-24498 #close
Reported by: Beppo Mazzucato
Tested by: Beppo Maazucato
........
Merged revisions 427762 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427763 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On some systems, a timeval's tv_sec/tv_usec will be unsigned lont ints, as
opposed to long ints. When the RTP engine formats these as strings, it was
previously formatting them as signed integers, which can result in some
odd negative timestamp values (particularly on 32-bit systems). This patch
formats the values as unsigned long integers.
........
Merged revisions 422766 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422767 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This introduces stasis.conf and a mechanism to prevent certain message
types from being published. Internally, this works by preventing the
chosen message types from being created which ensures that those
message types can never be published. This patch also adjusts message
publishers such that message payloads are not created if the related
message type is not available.
ASTERISK-23943 #close
Review: https://reviewboard.asterisk.org/r/3823/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new module to Asterisk, res_hep_rtcp. The module subscribes
to the RTCP topics in Stasis and receives RTCP information back from the
message bus. It encodes into HEPv3 packets and sends the information to the
res_hep module for transmission.
Using this, someone with a Homer server can get live call quality monitoring
for all RTP-based channels in their Asterisk 12+ systems.
In addition, there were a few bugs in the RTP engine, res_rtp_asterisk, and
chan_pjsip that were uncovered by the tests written for the Asterisk Test
Suite. This patch fixes the following:
1) chan_pjsip failed to set its channel unique ids on its RTP instance on
outbound calls. It now does this in the appropriate location, in the
serialized call callback.
2) The rtp_engine was overflowing some values when packed into JSON.
Specifically, some longs and unsigned ints can't be be packed into integer
values, for obvious reasons. Since libjansson only supports integers,
floats, strings, booleans, and objects, we print these values into strings.
3) res_rtp_asterisk had a few problems:
(a) it would emit a source IP address of 0.0.0.0 if bound to that IP
address. We now use ast_find_ourip to get a better IP address, and
properly marshal the result into an ast_strdupa'd string.
(b) Reports can be generated with no report bodies. In particular, this
occurs when a sender is transmitting information to a receiver (who
will send no RTP back to the sender). As such, the sender has no report
body for what it received. We now properly handle this case, and the
sender will emit SR reports with no body. Likewise, if we receive an
RTCP packet with no report body, we will still generate the appropriate
events.
ASTERISK-24119 #close
........
Merged revisions 419823 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
res_rtp_asterisk: Add SHA-256 support for DTLS and perform DTLS negotiation on RTCP.
This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip and chan_pjsip have also been added to
allow behavior to be tweaked (such as forcing the AVP type media transports in SDP).
ASTERISK-22961 #close
Reported by: Jay Jideliov
Review: https://reviewboard.asterisk.org/r/3679/
Review: https://reviewboard.asterisk.org/r/3686/
........
Merged revisions 417678 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The failing assertion ensures that the final snapshot gets generated so
CDR records can get finalized. The only place where a channel staging
snapshot flag could be left set is in chan_sip.c:handle_request_bye().
The function could return before clearing the flag because the channel
could dissappear while the function had to have the channel unlocked.
* Fixed handle_request_bye() channel snapshot staging coverage area to not
have a return in the middle of it and be unable to clear the staging flag.
* Pushed the channel snapshot staging coverage area into
ast_rtp_instance_set_stats_vars() to ensure that the staging is not
interrutped.
* Made callers of ast_rtp_instance_set_stats_vars() not call it with any
channels or channel driver private locks held to eliminate the deadlock
potential. The callers must hold references to the passed in channel and
rtp objects.
* Eliminated sip_hangup() trying to get the bridge peer. It is futile at
this point because the channel could never be in a bridge.
Review: https://reviewboard.asterisk.org/r/3431/
........
Merged revisions 412385 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412386 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
This change prevents channels used as implementation details from
leaking out to ARI. It does this by preventing creation of JSON blobs
of channel snapshots created from those channels and sanitizing JSON
blobs of bridge snapshots as they are created. This introduces a
framework for excluding information from output targeted at Stasis
applications on a consumer-by-consumer basis using channel sanitization
callbacks which could be extended to bridges or endpoints if necessary.
This prevents unhelpful error messages from being generated by
ast_json_pack.
This also corrects a bug where BridgeCreated events would not be
created.
(closes issue ASTERISK-22744)
Review: https://reviewboard.asterisk.org/r/2987/
Reported by: David M. Lee
........
Merged revisions 403069 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In function ast_rtp_instance_early _bridge_make_compatible the
use of instance 0/1 as arguments doesn't clearly communicate a
direction that the copying of payloads from the source channel
to the destination channel will occur, making it more probable
to have the arguments to ast_rtp_codecs_payloads_copy() put in
the reverse order. This patch renames the arguments with _dst
and _src suffixes and corrects the copy direction.
(closes issue ASTERISK-21464)
Reported by: Kevin Stewart
Review: https://reviewboard.asterisk.org/r/2894/
........
Merged revisions 402000 from http://svn.asterisk.org/svn/asterisk/branches/1.8
Test shows rtpmap:119 being copied per this change, but is not in sip invite
........
Merged revisions 402042 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 402043 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402054 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
........
Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds pass through support for Opus and VP8. That includes:
* Format attribute negotiation for Opus. Note that unlike some other codecs,
the draft RFC specifies having spaces delimiting the attributes in addition
to ';', so you have "attra=X; attrb=Y". This broke the attribute parsing in
chan_sip, so a small tweak was also included in this patch for that.
* A format attribute negotiation module for Opus, res_format_attr_opus
* Fast picture update for VP8. Since VP8 uses a different RTCP packet number
than FIR, this really is specific to VP8 at this time.
Note that the format attribute negotiation in res_pjsip_sdp_rtp was written
by mjordan. The rest of this patch was written completely by Lorenzo Miniero.
Review: https://reviewboard.asterisk.org/r/2723/
(closes issue ASTERISK-21981)
Reported by: Tzafrir Cohen
patches:
asterisk_opus+vp8_passthrough_20130718.patch uploaded by lminiero (License 6518)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is smaller than the initial review placed on review board. This is because
a change to allow for channel drivers to access parking functionality externally was
committed and invalidated quite a few of the changes initially made.
(closes issue ASTERISK-22039)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2717
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents XML documentation duplication by expanding channel and
bridge snapshot tags into channel and bridge snapshot parameter sets
with a given prefix or defaulting to no prefix. This also prevents
documentation from becoming fractured and out of date by keeping all
variations of the documentation in template form such that it only
needs to be updated once and keeps maintenance to a minimum.
Review: https://reviewboard.asterisk.org/r/2708/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It merges Jaco Kroon's patch from ASTERISK-20754, which provides channel
information in the RTCP events. Because Stasis provides a cache, Jaco's
patch was modified to pass the channel uniqueid to the RTP layer as
opposed to a pointer to the channel. This has the following benefits:
(1) It keeps the RTP engine 'clean' of references back to channels
(2) It prevents circular dependencies and other potential ref counting issues
* The RTP engine now allows any RTP implementation to raise RTCP messages.
Potentially, other implementations (such as res_rtp_multicast) could also
raise RTCP information. The engine provides structs to represent RTCP headers
and RTCP SR/RR reports.
* Some general refactoring in res_rtp_asterisk was done to try and tame the
RTCP code. It isn't perfect - that's *way* beyond the scope of this work -
but it does feel marginally better.
* A few random bugs were fixed in the RTCP statistics. (Example: performing an
assignment of a = a is probably not correct)
* We now raise RTCP events for each SR/RR sent/received. Previously we wouldn't
raise an event when we sent a RR report.
Note that this work will be of use to others who want to monitor call quality
or build modules that report call quality statistics. Since the events are now
moving across the Stasis message bus, this is far easier to accomplish. It is
also a first step (though by no means the last step) towards getting Olle's
pinefrog work incorporated.
Again: note that the patch by Jaco Kroon was modified slightly for this work;
however, he did all of the hard work in finding the right places to set the
channel in the RTP engine across the channel drivers. Much thanks goes to Jaco
for his hard work here.
Review: https://reviewboard.asterisk.org/r/2603/
(closes issue ASTERISK-20574)
Reported by: Jaco Kroon
patches:
asterisk-rtcp-channel.patch uploaded by jkroon (License 5671)
(closes issue ASTERISK-21471)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Often, Asterisk may realize that a change in the source of an RTP stream is
about to occur and ask that the RTP engine reset it's lock on the current RTP
source. In certain scenarios, it may take awhile for the new remote system to
send RTP packets, while the old remote system may continue providing RTP during
that time period. This causes Asterisk to re-lock onto the old source, thereby
rejecting the new source when the old source stops sending RTP and the new
source begins.
This patch prevents that by having a constant secondary, 'secret' probation
mode enabled when an RTP source has been chosen. RTP packets from other sources
are always considered, but never chosen unless the current RTP source stops
sending RTP.
Review: https://reviewboard.asterisk.org/r/2364
(closes issue AST-1124)
Reported by: John Bigelow
Tested by: John Bigelow
(closes issue AST-1125)
Reported by: John Bigelow
Tested by: John Bigelow
........
Merged revisions 382573 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r375993 | mmichelson | 2012-11-07 11:01:13 -0600 (Wed, 07 Nov 2012) | 30 lines
Fix misuses of timeouts throughout the code.
Prior to this change, a common method for determining if a timeout
was reached was to call a function such as ast_waitfor_n() and inspect
the out parameter that told how many milliseconds were left, then use
that as the input to ast_waitfor_n() on the next go-around.
The problem with this is that in some cases, submillisecond timeouts
can occur, resulting in the out parameter not decreasing any. When this
happens thousands of times, the result is that the timeout takes much
longer than intended to be reached. As an example, I had a situation where
a 3 second timeout took multiple days to finally end since most wakeups
from ast_waitfor_n() were under a millisecond.
This patch seeks to fix this pattern throughout the code. Now we log the
time when an operation began and find the difference in wall clock time
between now and when the event started. This means that sub-millisecond timeouts
now cannot play havoc when trying to determine if something has timed out.
Part of this fix also includes changing the function ast_waitfor() so that it
is possible for it to return less than zero when a negative timeout is given
to it. This makes it actually possible to detect errors in ast_waitfor() when
there is no timeout.
(closes issue ASTERISK-20414)
reported by David M. Lee
Review: https://reviewboard.asterisk.org/r/2135/
........
r375994 | mmichelson | 2012-11-07 11:08:44 -0600 (Wed, 07 Nov 2012) | 3 lines
Remove some debugging that accidentally made it in the last commit.
........
Merged revisions 375993-375994 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375995 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 376014 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376015 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As mentioned on the review for this, WebRTC has moved towards choosing
DTLS-SRTP as the mechanism for key exchange for SRTP. This commit adds
support for this but makes it available for normal SIP clients as well.
Testing has been done to ensure that this introduces no regressions with
existing behavior and also that it functions as expected.
Review: https://reviewboard.asterisk.org/r/2113/
........
Merged revisions 373229 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373234 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous fix still would look in the static_RTP_PT table, which
is inappropriate since we specifically want to find a codec that has
been negotiated.
(closes issue ASTERISK-20296)
reported by NITESH BANSAL
Patches:
codec_negotiation.patch Uploaded by NITESH BANSAL (License #6418)
........
Merged revisions 372311 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The HANGUPCAUSE hash (trunk only) meant to replace SIP_CAUSE has now
been replaced with the HANGUPCAUSE and HANGUPCAUSE_KEYS dialplan
functions to better facilitate access to the AST_CAUSE translations
for technology-specific cause codes. The HangupCauseClear application
has also been added to remove this data from the channel.
(closes issue SWP-4738)
Review: https://reviewboard.asterisk.org/r/2025/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel drivers that allow native bridging need to handle
AST_CONTROL_PVT_CAUSE_CODE frames and previously did not handle them
properly, usually breaking out of the native bridge. This change
corrects that behavior and exposes the available cause code information
to the dialplan while native bridges are in place. This required
exposing the HANGUPCAUSE hash setter outside of channel.c, so
additional documentation has been added.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369086 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
Add support-level indications to many more source files.
Since we now have tools that scan through the source tree looking for files
with specific support levels, we need to ensure that every file that is
a component of a 'core' or 'extended' module (or the main Asterisk binary)
is explicitly marked with its support level. This patch adds support-level
indications to many more source files in tree, but avoids adding them to
third-party libraries that are included in the tree and to source files
that don't end up involved in Asterisk itself.
........
r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
Add a script to enable finding source files without support-levels defined.
........
Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When remotely bridging calls with directmedia, Asterisk would check
the address of the peers/users holding directmedia ACLs (set via
directmediapermit/directmediadeny) instead of the bridged peer. This
is similar to r366547, but trunk specific and involves changes to
the rtpengine instead of just chan_sip.
(closes issue AST-876)
review: https://reviewboard.asterisk.org/r/1924/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the starting point for the Asterisk 11: Who Hung Up work and provides
a framework which will allow channel drivers to report the types of hangup
cause information available in SIP_CAUSE without incurring the overhead of the
MASTER_CHANNEL dialplan function. The initial implementation only includes
cause generation for chan_sip and does not include cause code translation
utilities.
This change deprecates SIP_CAUSE and replaces its method of reporting cause
codes with the new framework. This change also deprecates the 'storesipcause'
option in sip.conf.
Review: https://reviewboard.asterisk.org/r/1822/
(Closes issue SWP-4221)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move debug message in ast_rtp_instance_early_bridge_make_compatible() to
be output when what it states has actually happened.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362920 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CHANNEL_DEADLOCK_AVOIDANCE() feature of preserving where the channel
lock was originally obtained is overkill where ast_channel_lock_both() was
inlined.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362888 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Everything still compiled after making these changes, so I assume these
whitespace-only changes didn't break anything (and shouldn't have).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit adds GoSub alternatives to connected line, redirecting, and CCSS
macro hooks so that macro can finally be deprecated. This also adds
deprecation warnings for those features when used and in documentation.
Review: https://reviewboard.asterisk.org/r/1760/
(closes issue SWP-4256)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@357013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, when using res_srtp, once the SRTP policy has been added to the
current session the policy is locked into place. Any attempt to replace an
existing policy, which would be needed if the remote endpoint negotiated a new
cryptographic key, is instead rejected in res_srtp. This happens in particular
in transfer scenarios, where the endpoint that Asterisk is communicating with
changes but uses the same RTP session.
This patch modifies res_srtp to allow remote and local policies to be reloaded
in the underlying SRTP library. From the perspective of users of the SRTP API,
the only change is that the adding of remote and local policies are now added
in a single method call, whereas they previously were added separately. This
was changed to account for the differences in handling remote and local
policies in libsrtp.
Review: https://reviewboard.asterisk.org/r/1741/
(closes issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches:
srtp_renew_keys_2012_02_22.diff uploaded by Matt Jordan (license 6283)
(with some small modifications for this check-in)
........
Merged revisions 356604 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 356605 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are many benefits to making the ast_channel an opaque handle, from
increasing maintainability to presenting ways to kill masquerades. This patch
kicks things off by taking things a field at a time, renaming the field to
'__do_not_use_${fieldname}' and then writing setters/getters and converting the
existing code to using them. When all fields are done, we can move ast_channel
to a C file from channel.h and lop off the '__do_not_use_'.
This patch sets up main/channel_interal_api.c to be the only file that actually
accesses the ast_channel's fields directly. The intent would be for any API
functions in channel.c to use the accessor functions. No more monkeying around
with channel internals. We should use our own APIs.
The interesting changes in this patch are the addition of
channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
use accessor functions when ast_channel is really opaque), and some re-working
of the way channel iterators/callbacks are handled so as to avoid creating fake
ast_channels on the stack to pass in matching data by directly accessing fields
(since "name" is a stringfield and the fake channel doesn't init the
stringfields, you can't use the ast_channel_name_set() function). I went with
ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
setter.
The majority of the grunt-work for this change was done by writing a semantic
patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
Review: https://reviewboard.asterisk.org/r/1655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Failing to handle AST_CONTROL_UPDATE_RTP_PEER frames in the local bridge loop
causes the loop to exit prematurely. This causes a variety of negative side
effects, depending on when the loop exits. This patch handles the frame by
essentially swallowing the frame in the local loop, as the current channel
drivers expect the RTP bridge to handle the frame, and, in the case of the
local bridge loop, no additional action is necessary.
(issue ASTERISK-19040)
(issue ASTERISK-19128)
(issue ASTERISK-17725)
(issue ASTERISK-18340)
(closes issue ASTERISK-19095)
Reported by: Stefan Schmidt
Tested by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1640/
........
Merged revisions 349339 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 349340 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349341 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r336307 | jrose | 2011-09-16 16:09:20 -0500 (Fri, 16 Sep 2011) | 20 lines
Merged revisions 336294 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r336294 | jrose | 2011-09-16 14:53:40 -0500 (Fri, 16 Sep 2011) | 13 lines
Fix bad RTP media bridges in directmedia calls on peers separated by multiple Asterisk nodes.
In a situation involving devices on separate Asterisk trunks, the remote RTP bridge would
break when starting a call with directmedia. This patch queues a new type of control frame
so that our RTP bridge loop can properly detect when these situations occur and check to see
if peers need to be updated in order to send their media to the proper location.
(Closes issue ASTERISK-18340)
Reported by: Thomas Arimont
(Closes issue ASTERISK-17725)
Reported by: kwk
Tested by: twilson, jrose
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@336311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.10
................
r328824 | kmoore | 2011-07-19 13:05:21 -0500 (Tue, 19 Jul 2011) | 18 lines
Merged revisions 328823 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r328823 | kmoore | 2011-07-19 12:57:18 -0500 (Tue, 19 Jul 2011) | 11 lines
RTP bridge away with inband DTMF and feature detection
When deciding whether Asterisk was allowed to bridge the call away from the
core, chan_sip did not take into account the usage of features on dialed
channels that require monitoring of DTMF on channels utilizing inband DTMF.
This would cause Asterisk to allow the call to be locally or remotely bridged,
preventing access to the data required to detect activations of such features.
(closes 17237)
Review: https://reviewboard.asterisk.org/r/1302/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@328825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds pass-through support for CELT. CELT
formats are defined in codecs.conf and can be configured
to any sample rate a CELT endpoint supports. This patch also
addresses a crash in channel.c resulting from a frame list being
freed incorrectly. This crash was discovered while testing a CELT
translator which had to split encoded audio into multiple frames.
The codec translator is not a part of this patch, but may be
contributed in the future.
Review: https://reviewboard.asterisk.org/r/1294/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@326855 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r321042 | twilson | 2011-05-26 10:29:54 -0700 (Thu, 26 May 2011) | 6 lines
Initialize stack-allocated ast_sockaddrs before use
It is important to always initialize ast_sockaddrs before use--even if they
are passed to ast_sockaddr_copy as the underlying storage could be bigger
than what ends up being copied--leaving part of the data unitialized.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@321043 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r314017 | dvossel | 2011-04-18 08:41:06 -0500 (Mon, 18 Apr 2011) | 17 lines
sip codec negotiation of dynamic rtp payloads error fix
This patch fixes how chan_sip handles dynamic rtp payload types
it does not understand. At the moment if a dynamic payload's mime
type does not match one we understand, the payload does not get
removed from our payload table. As a result of this, the payload
is set to whatever dynamic codec we use internally for that payload
number on outgoing INVITES. This is incorrect.
This patch fixes this by properly checking the rtpmap set function's
return code to make sure it was found. The function can return both
-1 and -2 depending on the source of the mismatch. We were just
checking -1 explicitly.
Review: https://reviewboard.asterisk.org/r/1169/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r310287 | alecdavis | 2011-03-11 19:47:44 +1300 (Fri, 11 Mar 2011) | 17 lines
remote_bridge_loop: prevent segfault when after transfer of IAX2 of DAHDI call
If the channel condition is one of the following after breaking out of the loop, don't try to update_peer
(where x = 0/1)
1). ZOMBIE
2). cx->tech_pvt != pvtx
3). gluex != ast_rtp_instance_get_glue(cx->tech->type))
(closes issue #18781)
Reported by: alecdavis
Patches:
bug18781.diff3.txt uploaded by alecdavis (license 585)
Tested by: alecdavis, ZX81
Review: https://reviewboard.asterisk.org/r/1128/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate. This allows
for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.
-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c
Review: https://reviewboard.asterisk.org/r/1104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, I had added the ast_sched_thread stuff that was a generic scheduler
thread implementation. However, if you used it, it required using different
functions for modifying scheduler contents. This patch reworks how this is
done and just allows you to optionally start a thread on the original scheduler
context structure that has always been there. This makes it trivial to switch
to the generic scheduler thread implementation without having to touch any of
the other code that adds or removes scheduler entries.
In passing, I made some naming tweaks to add ast_ prefixes where they were not
there before.
Review: https://reviewboard.asterisk.org/r/1007/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293803 | twilson | 2010-11-03 11:05:14 -0700 (Wed, 03 Nov 2010) | 25 lines
Avoid valgrind warnings for ast_rtp_instance_get_xxx_address
The documentation for ast_rtp_instance_get_(local/remote)_address stated that
they returned 0 for success and -1 on failure. Instead, they returned 0 if the
address structure passed in was already equivalent to the address instance
local/remote address or 1 otherwise. 90% of the calls to these functions
completely ignored the return address and passed in an uninitialized struct,
which would make valgrind complain even though the operation was technically
safe.
This patch fixes the documentation and converts the get_xxx_address functions
to void since all they really do is copy the address and cannot fail.
Additionally two new functions
(ast_rtp_instance_get_and_cmp_(local/remote)_address) are created for the 3
times where the return value was actually checked. The
get_and_cmp_local_address function is currently unused, but exists for the sake
of symmetry.
The only functional change as a result of this change is that we will not do an
ast_sockaddr_cmp() on (mostly uninitialized) addresses before doing the
ast_sockaddr_copy() in the get_*_address functions. So, even though it is an
API change, it shouldn't have a noticeable change in behavior.
Review: https://reviewboard.asterisk.org/r/995/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289840 | jpeeler | 2010-10-01 21:43:45 -0500 (Fri, 01 Oct 2010) | 29 lines
Merged revisions 289798 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289798 | jpeeler | 2010-10-01 18:01:31 -0500 (Fri, 01 Oct 2010) | 22 lines
Merged revisions 289797 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289797 | jpeeler | 2010-10-01 17:58:38 -0500 (Fri, 01 Oct 2010) | 15 lines
Change RFC2833 DTMF event duration on end to report actual elapsed time.
The scenario here is with a non P2P early media session. The reported time
length of DTMF presses are coming up short when sending to the remote side.
Currently the event duration is a running total that is incremented when sending
continuation packets. These continuation packets are only triggered upon
incoming media from the remote side, which means that the running total probably
is not going to end up matching the actual length of time Asterisk received
DTMF. This patch changes the end event duration to be lengthened if it is
detected that the end event is going to come up short.
Review: https://reviewboard.asterisk.org/r/957/
ABE-2476
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284477 | twilson | 2010-09-01 13:44:36 -0500 (Wed, 01 Sep 2010) | 17 lines
Fix SRTP for changing SSRC and multiple a=crypto SDP lines
Adding code to Asterisk that changed the SSRC during bridges and masquerades
broke SRTP functionality. Also broken was handling the situation where an
incoming INVITE had more than one crypto offer. This patch caches the SRTP
policies the we use so that we can change the ssrc and inform libsrtp of the
new streams. It also uses the first acceptable a=crypto line from the incoming
INVITE.
(closes issue #17563)
Reported by: Alexcr
Patches:
srtp.diff uploaded by twilson (license 396)
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/878/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@284479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Review: https://reviewboard.asterisk.org/r/743
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
