summaryrefslogtreecommitdiff
path: root/channels/sip/sdp_crypto.c
AgeCommit message (Collapse)Author
2013-01-29Corrected crypto tag in SDP ANSWER for SRTP. (again)David M. Lee
The original fix (r380043) for getting Asterisk to respond with the correct tag overlooked some corner cases, and the fact that the same code is in 1.8. This patch moves the building of the crypto line out of sdp_crypto_process(). Instead, it merely copies the accepted tag. The call to sdp_crypto_offer() will build the crypto line in all cases now, using a tag of "1" in the case of sending offers. (closes issue ASTERISK-20849) Reported by: José Luis Millán Review: https://reviewboard.asterisk.org/r/2295/ ........ Merged revisions 380347 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 380350 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-01-24Corrected crypto tag in SDP ANSWER for SRTP.David M. Lee
When Asterisk responds with an SDP ANSWER for SRTP, it had the code to correctly fill in the crypto data, which was overwritten by a call to sdp_crypto_offer. Corrected the situation by changing sdp_crypto_offer to not replacing crypto data if it already exists. (closes issue ASTERISK-20849) Reported by: José Luis Millán Tested by: Iñaki Baz Castillo Patches: fix_sdp_crypto_tags.diff uploaded by Pedro Kiefer (license 6407) ........ Merged revisions 380043 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-09-09Only re-create an SRTP session when neededMatthew Jordan
In r356604, SRTP handling was fixed to accomodate multiple crypto keys in an SDP offer and the ability to re-create an SRTP session when the crypto keys changed. In certain circumstances - most notably when a phone is put on hold after having been bridged for a significant amount of time - the act of re-creating the SRTP session causes problems for certain models of phones. The patch committed in r356604 always re-created the SRTP session regardless of whether or not the cryptographic keys changed. Since this is technically not necessary, this patch modifies the behavior to only re-create the SRTP session if Asterisk detects that the remote key has changed. This allows models of phones that do not handle the SRTP session changing to continue to work, while also providing the behavior needed for those phones that do re-negotiate cryptographic keys. (issue ASTERISK-20194) Reported by: Nicolo Mazzon Tested by: Nicolo Mazzon Review: https://reviewboard.asterisk.org/r/2099 ........ Merged revisions 372709 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 372710 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 372711 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372712 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-07-16Add support for SIP over WebSocket.Joshua Colp
This allows SIP traffic to be exchanged over a WebSocket connection which is useful for rtcweb. Review: https://reviewboard.asterisk.org/r/2008 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-06-15Multiple revisions 369001-369002Kevin P. Fleming
........ 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
2012-06-11Fix coverity UNUSED_VALUE findings in core support level filesKinsey Moore
Most of these were just saving returned values without using them and in some cases the variable being saved to could be removed as well. (issue ASTERISK-19672) ........ Merged revisions 368738 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 368739 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-02-24Allow SRTP policies to be reloadedMatthew Jordan
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
2011-09-20Merged revisions 336936 via svnmerge from Gregory Nietsky
https://origsvn.digium.com/svn/asterisk/branches/10 ........ r336936 | irroot | 2011-09-20 18:51:59 +0200 (Tue, 20 Sep 2011) | 14 lines Allow Setting Auth Tag Bit length Based on invite or config option Update the SIP SRTP API to allow use of 32 or 80 bit taglen. Curently only 80 bit is supported. The outgoing invite will use the taglen of the incoming invite preventing one-way audio. (Closes issue ASTERISK-17895) Review: https://reviewboard.asterisk.org/r/1173/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@336937 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-05Merged revisions 317474 via svnmerge from Russell Bryant
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r317474 | russell | 2011-05-05 17:36:33 -0500 (Thu, 05 May 2011) | 2 lines Fix more "set but unused" warnings. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317475 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-08Add SRTP support for AsteriskTerry Wilson
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