Introduce a new property to rtp-engine to make it aware of
the desire for assymetric codecs or not. If asymmetric codecs
is not allowed, the bridge will compare read/write formats
and shut down the p2p bridge if needed
ASTERISK-26745 #close
Change-Id: I0d9c83e5356df81661e58d40a8db565833501a6f
There have been reports of deadlocks caused by an attempt to send a frame
to a channel's rtp instance after the channel has left the native bridge
and been destroyed. This patch effectively causes the bridge channel to
keep a reference to the glue and both the audio and video rtp instances
so what gets started will get stopped.
ASTERISK-26978 #close
Reported-by: Ross Beer
Change-Id: I9e1ac49fa4af68d64826ccccd152593cf8cdb21a
This commit adds support for RFC 5761: Multiplexing RTP Data and Control
Packets on a Single Port. Specifically, it enables the feature when
using chan_pjsip.
A new option, "rtcp_mux" has been added to endpoint configuration in
pjsip.conf. If set, then Asterisk will attempt to use rtcp-mux with
whatever it communicates with. Asterisk follows the rules set forth in
RFC 5761 with regards to falling back to standard RTCP behavior if the
far end does not indicate support for rtcp-mux.
The lion's share of the changes in this commit are in
res_rtp_asterisk.c. This is because it was pretty much hard wired to
have an RTP and an RTCP transport. The strategy used here is that when
rtcp-mux is enabled, the current RTCP transport and its trappings (such
as DTLS SSL session) are freed, and the RTCP session instead just
mooches off the RTP session. This leads to a lot of specialized if
statements throughout.
ASTERISK-26732 #close
Reported by Dan Jenkins
Change-Id: If46a93ba1282418d2803e3fd7869374da8b77ab5
Function CHANNEL(rtcp,all_rtt) CHANNEL(rtcp,all_loss) CHANNEL(rtcp,all_jitter)
always return 0.0 due to wrong define of macro "AST_RTP_SATA_SET" and
"AST_RTP_STAT_STRCPY".
It should compare "combined" with "stat" not "current_stat".
ASTERISK-26710 #close
Reported-by: Aaron An
Tested-by: AaronAn
Change-Id: Id4140fafbf92e2db689dac5b17d9caa009028a15
The dynamic range (96-127) allows 32 RTP Payload Types. RFC 3551 section 3
allows to reassign other ranges. Consequently, when the dynamic range is
exhausted, you can go for "rtp_pt_dynamic = 35" (or 0) in asterisk.conf. This
enables the range 35-63 (or 0-63) giving room for another 29 (or 64) payload
types.
ASTERISK-26311 #close
Change-Id: I7bc96ab764bc30098a178b841cbf7146f9d64964
(cherry picked from commit 9ac53877f6)
Asterisk uses separate UDP ports for RTP and RTCP traffic and RFC 5764
explicitly states:
There MUST be a separate DTLS-SRTP session for each distinct pair of
source and destination ports used by a media session
This means RTP keying material cannot be used for DTLS RTCP, which was
the reason why RTCP encryption would fail.
ASTERISK-25642
Change-Id: I7e8779d8b63e371088081bb113131361b2847e3a
rxcount, txcount, rxoctetcount and txoctetcount weren't being calculated
for bridged streams because the calulations were being done after the
bridged short-circuit. Actually, rxoctetcount wasn't ever being calculated.
Moved the calculations so they occur for all valid received packets and
all transmitted packets. Also added rxoctetcount and txoctetcount to
ast_rtp_instance_stat.
Change-Id: I08fb06011a82d38c3b4068867a615068fbe59cbb
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: I06660ba672c0a343814af4cec838e6025cafd54b
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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. The number of file descriptors an ioqueue instance can handle is fixed, so we
now spawn the required number to handle the load.
2. Our transport identifiers were exceeding the range supported by pjnath.
3. The TURN client did not set up client binding causing needless bandwidth usage.
4. The code no longer updates address information on each packet.
5. STUN traffic was getting looped back to Asterisk instead of going through the
TURN server.
6. Synchronization now ensures things are completely setup or destroyed.
7. Logging now reflects the target the TURN server is sending to/receiving from
on our behalf.
ASTERISK-23577 #close
Reported by: Jay Jideliov
ASTERISK-23634 #close
Reported by: Roman Skvirsky
Review: https://reviewboard.asterisk.org/r/3982/
........
Merged revisions 423150 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423151 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423152 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
* Fix memory leak in ast_unreal_new_channels(). Made it generate the ;2
uniqueid on a stack variable instead of mallocing it.
* Made send error response to ARI and AMI requests instead of just logging
excessive uniqueid length and allowing truncation. action_originate() and
ari_channels_handle_originate_with_id().
* Fixed minor truncating uniqueid hole when generating the ;2 uniqueid
string length. Created public and internal lengths of uniqueid. The
internal length can handle a max public uniqueid plus an appended ;2.
* free() and ast_free() are NULL tolerant so they don't need a NULL test
before calling.
* Made use better struct initialization format instead of the position
dependent initialization format. Also anything not explicitly initialized
in the struct is initialized to zero by the compiler.
* Made ast_channel_internal_set_fake_ids() use the safer
ast_copy_string() instead of strncpy().
Review: https://reviewboard.asterisk.org/r/3371/
........
Merged revisions 410949 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410950 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
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
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
This patch fixes numerous doxygen warnings across Asterisk. It also updates
the makefile to regenerate the doxygen configuration on the local system
before running doxygen to help prevent warnings/errors on the local system.
Much thanks to Andrew for tackling one of the Asterisk janitor projects!
(issue ASTERISK-20259)
Reported by: Andrew Latham
Patches:
doxygen_partial.diff uploaded by Andrew Latham (license 5985)
make_progdocs.diff uploaded by Andrew Latham (license 5985)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fix involves moving the allocation of some temporary codec structures to the heap and also reduces the number of maximum payloads to something more sane for both regular and low memory builds.
(closes issue ASTERISK-20140)
Reported by: jonnt
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370171 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
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
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
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
-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
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
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The mis-placement of the latest entry meant that when it was set, it was writing
one index past the end of the properties array in the ast_rtp_instance (which
happened to be the local_address field).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250871 65c4cc65-6c06-0410-ace0-fbb531ad65f3
