Major standards bodies including 3GPP, ITU-T, and ETSI have all adopted SIP as the core signalling protocol for services such as LTE , VoIP, conferencing, Video on Demand (VoD), IPTV (Internet Television), presence, and Instant Messaging (IM) etc. With the continous evolution of SIP as the defacto VoIP protocol , we need to underatdn the risk mitigartion practices around it .
I have written about VoIP and security in these blogs before
For Security around web browser based calling via webrtc i have written
Webrtc Security , which describes browser threat modal , access to local resource , Same Orogin Policy (SOP) and Cross Resource Sharing ( CORS) as well as Location sharing , ICE , TUEN and threats to privacy with screen sharing , microgone camera long term access and probable mid call attacks .
Genric secrutity of web Application build around hosting platform of webrtc. Includs concepts like Identity management , browser security – cross site security amd clickjacking , Authetication of devices and applications , Media Encryption and regex checking.
In this article we will cover types of attacks on SIP systems
Types of attacks on SIP based systems
Registration Hijacking
malicious registrations on registrar by a third party who modifies From header field of a SIP request.
exmaple implementation : attacker de-registers all existing contacts for a URI attacker can also register their own device as the appropriate contact address, thereby directing all requests for the affected user to him
solution – Autheticaion of user
Impersonating a Server
attacker impersonates the remote server user’s request can now be intercepted by some other party user’s request may be forwarded to insecure locations
Solution –
confidentiality, integrity, and authentication of proxy servers
Proxy/redirect sever, and registrars SHOULD possess a site certificate issued by CA which could be validated by UA
Temparing Message bodies
If users are relying on SIP message bodies to communicate either of
session encryption keys for a media session
MIME bodies
SDP
encapsulated telephony signals Then the atackers on proxy server can modify the session key or can act as a man-in-the-middle and do eaves droppng
exmaple implementation : attacker can point RTP media streams to a wiretapping device can changes Subject header field to appear to users as spam
solution – end to end ecryption over TLS + Digest Authorization
mid-session threats like tearing down session
Request forging attacker learns the params of the session like To , From tags etc then he can alter ongoing session parameters and even bring it down
example implementation : attacker inserts a BYE in a ongoing session thereby tearing it down can insert re INVITE and redierct the stream to wiretaping device
solution – authetication on every request signing and encrypting of MIME bodies, and transference of credentials with S/MIME
Denial of Service and Amplification
DOS attacks – rendering a particular network element unavailable, usually by directing an excessive amount of network traffic at its interfaces. dDOS – multiple network hosts to flood a target host with a large amount of network traffic.
Can be created by sending falsified sip requests to other parties such that numerous transactions originating in the backwards direction comes to the target server created congestion.
exmaple implementation : attackers creates a falsified source IP address and a corresponding Via header field that identify a targeted host as the originator of the request. Then send this to large number of SIP network element . This geneerates DOS aimed at target.
attackers uses falsified Route header field values in a request that identify the target host and then send such messages to forking proxies that will amplify messaging sent to the target.
Flooding with register attacks can deplete available memory and disk resources of a registrar by registering huge numbers of bindings. Flooding a stateful proxy server causes it to consume computational expense associated with processing a SIP transaction
Solution – detect flooding and pike in traffic and use ipban to block challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus behaving statelessly towards unauthenticated requests.
Security mchanisms
Full encryption vs hop by hop encrption
SIP mssages cannot be encrypted end-to-end in their entirety since message fields such as the Request-URI, Route, and Via need to be visible to proxies in most network architectures so that SIP requests are routed correctly. proxy servers need to also update the message with via headers
Thus SIP uses low level security along with hop by hop encrption and auth headers to verify the identity of proxy servers
Transport and Network Layer Security
IPsec – used where set of hosts or administrative domains have an existing trust relationship with one another.
TLS – used where hop-by-hop security is required between hosts with no pre-existing trust association.
SIPS URI Scheme
Used as an address-of-record for a particular user, signifies that each hop over which the request is forwarded, must be secured with TLS
HTTP Authentication
Reuse of the HTTP Digest authentication via 401 and 407 response codes that implement challenge for autehtication provides replay protection and one-way authentication.
S/MIME
allows SIP UAs to encrypt MIME bodies within SIP, securing these bodies end-to-end without affecting message headers. provides end-to-end confidentiality and integrity for message bodies
nonce-count
provides replay protection
SIP over TLS
SIP messages can be secured using TLS. There is also TLS for Datagrams called DTLS.
Security of SIP signalling is different from security of protocols used in concert with SIP like RTP , RTCP. and that will be covered in later topics of this article.
TLS operation consists of two phases: handshake phase and bulk data encryption phase
Handshake phase
Prepare algorithm to be used during TLS session
Server Authentication
server sends its certificate to the client, which then verifies the certificate using a certificate authority’s (CA’s) public key.
Client Authentication
Server sends an additional CertificateRequest message to request the client’s certificate. The client responds with
Certificate message containing the client certificate with the client public key and
CertificateVerify message containing a digest signature of the handshake messages signed by clients private key
Server authenticates client by client’s public key , since only client holding correct private key can sign the message.
prepare the shared secret for bulk data encryption
client generate a pre_master_secret, and encrypt it using the server’s public key obtained from the server’s certificate. The server decrypts the pre_master_secret using its own private key. Both the server and client then compute a master_secret they share based on the same pre_master_secret. The master_secret is further used to generate the shared symmetric keys for bulk data encryption and message authentication
Public key cryptographic operations such as RSA are much more expensive than shared key cryptography. This is why TLS uses public key cryptography to establish the shared secret key in the handshake phase, and then uses symmetric key cryptography with the negotiated shared secret as the data encryption key.
Stateless proxy servers do not maintain state information about the SIP session and therefore tend to be more scalable. However, many standard application functionalities, such as authentication, authorization, accounting, and call forking require the proxy server to operate in a stateful mode by keeping different levels of session state information.
Steps :
The SIP proxy server enforces proxy authentication with 407 Proxy Authentication Required challenge.
UAC provides credentials that verify its claimed identity (e.g., based on MD5 [34] digest algorithm) and retransmits in authorization header
Security of RTP
confidentiality protection of the RTP session and integrity protection of the RTP/RTCP packets requires source authentication of all the packets to ensure no man-in-the-middle (MITM) attack is taking place.
end to end media encryption – SRTP ( Secure RTP )
encodes the voice into encrypted IP packages and transport those via the internet from the transmitter to receive
References
The Impact of TLS on SIP Server Performance – Charles Shen† Erich Nahum‡ Henning Schulzrinne† Charles Wright , Department of Computer Science, Columbia University,IBM T.J. Watson Research Center
This article describes various Certificates and compliances, Bill and Acts on data privacy, Security and prevention of Robocalls as adopted by countries around the world pertaining to Interconnected VoIP providers, telecommunications services, wireless telephone companies etc
Compliance certificates by Industry types
HIPAA (Health Insurance Portability and Accountability Act)
Deals with privacy and security of personal medical records and electronic health care transaction
Applicability : If voip company handles medical information
Includes :
Not allowed Voice mail transcription
Should have End-to-End Encryption
Restrict using unsecured WiFi networks to prevent Snooping
User security , strong password rules and mandatory monthly change
Secure Firmware on VoIP phones
Maintaining Call and Access Logs
SOX( Sarbanes Oxley Act of 2002)
Also known as SOX, SarbOX or Public Company Accounting Reform and Investor Protection Act
Applicability : if managing the communications operations of a regulated, publicly traded company
Includes :
Retain records which include financial and other sensitive data
ways employees are provided or denied access to records or data based on their roles and responsibilities
do information audit by a trusted third party.
Retention and deletion of files such as audio files like voicemails, text messages, video clips, declared paper records, storage, and logs of communications activities
Physical and digital security controls around cloud-based VoIP applications and the networks
Privacy Related Compliance certificates
COPPA (Children’s Online Privacy Protection Act ) of 1998
prohibits deceptive marketing to children under the age of 13, or collecting personal information without disclosure to their parents.
any information is to be passed on to a third party, must be easy for the child’s guardian to review and/or protect
2011 amendment requires that the data collected was erased after a period of time,
2014 FTC issued guidelines that apps and app stores require “verifiable parental consent.”
CPNI (Customer Proprietary Network Information) in united states is the information that communication providers acquire about their subscribers. This Individually identifiable information that is created by a customer’s relationship with a provider, such as data about the frequency, duration, and timing of calls, the information on a customer’s bill, and call identifying information. This processing information is governed strictly by FCC and certification should be renewed on an annual basis
Provider can pass along that information to marketers to sell other services, as long as the customer is notified
In 2007, the FCC explicitly extended the application of the Commission’s CPNI rules of the Telecommunications Act of 1996 to providers of interconnected VoIP service.
CALEA
Communications Assistance for Law Enforcement Act (CALEA) conduct electronic surveillance by imposing specific obligations on “telecommunications carriers” for assisting law enforcement, including delivering call interception and call identification functionality to the government with a minimum of interference to customer service and privacy.
Establishes requirements of organizations that process data, defines the rights of individuals to manage their data, and outlines penalties for those who violate these rights.
No personal data may be processed unless this processing is done under one of six lawful bases specified by the regulation (consent, contract, public task, vital interest, legitimate interest or legal requirement). When the processing is based on consent the data subject has the right to revoke it at any time.
Controllers must notify Supervising Authorities (SA)s of a personal data breach within 72 hours of learning of the breach.
California Consumer Privacy Act (CCPA) 2019
consumer rights relating to the access to, deletion of, and sharing of personal information that is collected by businesses.
Allows consumers to know whether their personal data is sold or disclosed , to whom .
Allows opt-out right for sales of personal information
Right to deletion – to request a business to delete any personal information about a consumer collected from that consumer
Personal Data Protection Bill (PDP) – India 2018
This bill introduces various private and sensitive protection frameworks like restriction on retention of personal data, Right to correction and erasure (such as right to be forgotten) , Prohibition and transparency of processing of personal data. It also classifies data fiduciaries including certain social media intermediaries.
The Bill amends the Information Technology Act, 2000 to delete the provisions related to compensation payable by companies for failure to protect personal data.
Other data privacy acts similar to GDPR
South Korea’s Personal Information Protection Act 2011
Brazil’s Lei Geral de Proteçao de Dados (LGPD) 2020
Privacy Amendment (Notifiable Data Breaches) to Australia’s Privacy Act 2018
Japan’s Act on Protection of Personal Information 2017
Thailand Personal Data Protection Act (PDPA) 2020
Features offered by VOIP companies for Data privacy
Access Control & Logging
Auto Data Redaction / Account Deletion policy
SIEM (Security information and event management) alerts
Information security , Encrypted Storage For Recordings & Transcripts
Disclosing all third party services that are involved in data processing too
Role Based Access Control and 2 Factor Authentication
Data Security Audits and appointing data protection officer to oversee GDPR compliance
Against Robocalls and SPIT ( SPAM over Internet Telephony)
2009 Truth in Caller ID Act
Telephone Consumer Protection Act of 1991
Implementation of Do not call registry against use of robocalls, automatic dialers, and other methods of communication
Do-Not-Call Implementation Act of 2003
if a business has an established relationship with a customer, it can continue to call them for up to 18 months. If a consumer calls the company, say, to ask for information about the product or service, the company has three months to get back to him.
if the customer asks to not receive calls, the company must stop calling, or be subject to fines.
Exemptions – Calls from a not-for-profit B organisation , informational messages as flight cancellations , Calls from sales and debt collectors etc
Personal Data Privacy and Security Act 2009
Implemented to curb identity theft and computer hacking. Sensitive personal identifiable information includes : victim’s name, social security number, home address, fingerprint/biometrics data, date of birth, and bank account numbers.
Any company that is breached must notify the affected individuals by mail, telephone, or email, and the message must include information on the company and how to get in touch with credit reporting agencies
If the breach involves government or national security , company must also contact the Secret Service within fourteen days
TRACED Act (Telephone Robocall Abuse Criminal Enforcement and Deterrence) 2019
Canadian Radio-television and Telecommunications Commission (CRTC) 2018 -32
Unlike traditional telephone connections, which are tied to a physical location, VOIP’s packet switched technology allows a particular number to be anywhere making it more difficult for it to reach localised services like emergency numbers of Public Safety Answering Points (PSAPs) . Thus FCC regulations as well as the New and Emerging Technologies 911 Improvement Act of 2008 (NET 911 Act), interconnected VoIP providers are required to provide 911 and E911 service.
To understand the need for implementing an identification verification technique in Internet protocol based network to network communication system , we need to evaluate the existing problem plaguing the VoIP setup .
What is Call ID spoofing ?
Vulnerability of existing interconnection phone system which is used by robo-callers to mask their identity or to make it appear the call is from a legitimate source, usually originates from voice-over-IP (VOIP) systems.
In this context understand the Caller Line identification CLI/ NCLI techniques used by VoIP and OTT( over the top) providers today.
CLI (Caller Line Identification)
If call goes out on a CLI route ( White Route ) the received party will likely see your callerID information
Lawful – Termination is legal on the remote end ie abiding country’s telco infrastructure and stable
Expensive – usually with direct or via leased line (TDM) interconnections with the tier-1 carriers.
Non-CLI (Non-Caller Line Identification)
The Caller ID is not visible at the call If call goes out on a Non-CLI route (Grey Route) goes out on a non-CLI routes they will see either a blocked call or some generic number.
Unlawful – questionable legality or maybe violating some providers AUP(Acceptable Use Policy ) on the remote end.
Cheaper – low quality , usually via VoIP-GSM gateways
Example include robocalls , tele-marketting / spam etc which are unwilling to share their Caller Id for call receiver, to not be blocked or cancelled.
To overcome the problem of non-verifiable spam , robocalls a suite of protocols and procedures are proposed that can combat caller ID spoofing on VOIP and connected public telephone networks.
STIR/SHAKEN
Secure Telephony Identity Revisited / Signature-based Handling of Asserted information using toKENs
Used by robocallers to mask their identity or to make it appear the call is from a legitimate source usually orignates from voice-over-IP (VOIP) systems
STIR
Standards developed by the Internet Engineering Task Force (IETF)
For telecommunication service providers implement certificate management system to create and manage the public and private keys, digital certificates used to sign and verify Caller ID details.
Adds information to the SIP headers that allow the endpoints along the system to positively identify the origin of the data , such as JSON web tokens encrypted with the provider’s private key, encoded using Base64,
There are three levels of verification, or “attestation”
A : Full Attestation indicates that the provider recognizes the entire phone number as being registered with the originating subscriber.
B : Partial Attestation call originated with a known customer but the entire number cannot be verified,
C : Gateway Attestation call can only be verified as coming from a known gateway
How can the Public Key Infrastructure be used ?
In an interconnection network , each telephone service provider will obtain its digital certificate from a certificate authority (CA) that is trusted by other telephone service providers. Calling party signs the SIP Header caller ID as legitimate . The called party verifies that the calling number is authentic
STIR
Originating service provider’s encrypted SIP Identity Header includes the following data:
Attestation level
Date and Time
Calling and Called Numbers
Orig ID for analytics and/or traceback purposes among others
Location of certificate repository
Signature
Encryption algorithm
FCC has also assigned the role of a Secure Telephone Identity Policy Administrator (STI-PA) which oversees that CAs do not provide certificate to spoofing robocallers and enforce the framework for STIR /SHAKEN .
STIR is based on the SIP protocol and is designed to work with calls being routed through a VOIP network. Since traditional endpoints like POTS and SS7 networks also should be covered under this call authenticity framework , SHAKEN was developed to manage call via IP-to-telephone gateways .
Developed by the Alliance of Telecommunications Industry Solutions (ATIS)
Working Steps :
When a call is initiated, a SIP INVITE is received by the originating service provider.
Originating service provider verifies the call source and number to determine how to confirm validity.
Full Attestation (A) — The service provider authenticates the calling party AND confirms they are authorized to use this number. An example would be a registered subscriber.
Partial Attestation (B) — The service provider verifies the call origination but cannot confirm that the call source is authorized to use the calling number. An example would be a calling number from behind an enterprise PBX.
Gateway Attestation (C) — The service provider authenticates the call’s origin but cannot verify the source. An example would be a call received from an international gateway.
Create a SIP Identity header that contains information on the calling number, called number, attestation level, and call origination, along with the certificate thus caller ID “signed” as legitimate
SIP INVITE with the SIP Identity header with the certificate is sent to the destination service provider.
Destination service provider verifies the identity of the header and certificate.
Diagrammatic depiction of flow of how Telecom carriers to digitally validates authenticity before receiving or handoff through their network
SHAKEN
References
RFC 8224 – Authenticated Identity Management in the Session Initiation Protocol (SIP)
RFC 8226 – Secure Telephone Identity Credentials: CertificatesRFC 8588 – Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)
With advent of Voice over IP , the real time streaming of data/audio/video also became critically important to be protected from eavesdropping or modification over the open internet.
While Secure Real-time Transport Protocol (SRTP) is a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).
ZRTP is a protocol that negotiates the keys and other information required to setup a SRTP audio and video session
SRTP provides a framework for encryption and message authentication of RTP and RTCP streams by negotiating keys.
It is not a transport but a profile of the Real-time Transport Protocol (RTP) for securing RTP streams in addition to providing confidentiality, integrity protection, source authentication, and replay protection.
The SRTP specification also defines how to setup and maintain a cryptographic context. This context holds all necessary data to perform the security operations, for example the SRTP encryption keys, the packet sequence counters, authentication keys, and so on. Each SRTP session, which is the same as a RTP session, has its own context. Thus a bidirectional SRTP communication requires two different SRTP cryptographic contexts.
Features of SRTP
framework for encryption and message authentication of RTP and RTCP streams confidentiality and integrity of the entire RTP and RTCP packets, together with protection against replayed packets. secure for unicast and multicast RTP applications low computational cost and small footprint high throughput and low packet expansion to support bandwidth economy. permits upgrading with new cryptographic transforms, protection for heterogeneous environments (mix of wired and wireless networks)
Independant from the underlying transport, network, and physical layers used by RTP, in particular high tolerance to packet loss and re-ordering.
Normal RTP PacketSecureRTP Packet
SRTCP ( Secure RTCP)
Secure RTCP (SRTCP) is similar to the SRTP format of the SRTCP packet which has the authentication tag and MKI headers, including two additional headers:
SRTCP index
Encrypt-flag
Key management protocols for SRTP
Since SRTP does not contain an integrated key management solution, one can employ any of the following key management protocols
It is a way to negotiate the key/cryptographic parameters for SRTP. Keys are transported in the SDP attachment of a SIP message using TLS transport layer (SSLv3/TLSv1) or other methods like S/MIME.
media attribute defined by SDES is “crypto” a=crypto: inline: [session-parms]
SDES packet
3 commonly used crypto suites are :
AES_CM_128_HMAC_SHA1_80
AES_CM_128_HMAC_SHA1_32
F8_128_HMAC_SHA1_32
DTLS – SRTP Key management
DTLS keying happens on the media path, independent of any out-of-band signalling channel present.
For Secure Communication kamailio supports – Digest SIP User authentication , Authorization via ACL or group membership , IP and Network authentication , TLS support for SIP signaling , transparent handling of SRTP for secure audio , TLS domain name extension support ,authentication and authorization against database (MySQL, PostgreSQL, UnixODBC, BerkeleyDB, Oracle, text files), RADIUS and DIAMETER.
Code to set flag rtp_secure_media to true if both TLS and SRTP are active
Invite from Jitsi client alternatively offering 3 different types of audio SDP’s – RTP/SAVPF , RTP/SAVP and RTP/AVP. Which ever will be accepted by the other endpoint will be communicated back using SDP in 200 OK.
When SRTP it’s critical to not offer or accept variable bit rate codecs, doing so would leak information and possibly compromising SRTP stream. (FS-6404)
Supported SRTP Crypto Suites:
AEAD_AES_256_GCM_8
This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116]), except that the tag length, t, is 8, and an
authentication tag with a length of 8 octets (64 bits) is used. An AEAD_AES_256_GCM_8 ciphertext is exactly 8 octets longer than its
corresponding plaintext.
AEAD_AES_128_GCM_8
This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 8, and an
authentication tag with a length of 8 octets (64 bits) is used. An AEAD_AES_128_GCM_8 ciphertext is exactly 8 octets longer than its
corresponding plaintext.
AES_CM_128_HMAC_SHA1_80 is the SRTP default AES Counter Mode cipher and HMAC-SHA1 message authentication with an 80-bit authentication
tag. The master-key length is 128 bits and has a default lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes
first.
This crypto-suite is identical to AES_CM_128_HMAC_SHA1_80 except that the authentication tag is 32 bits. The length of the base64-decoded key and salt value for this crypto-suite MUST be 30 octets i.e., 240 bits; otherwise, the crypto attribute is considered invalid.
AES_CM_128_NULL_AUTH
The SRTP default cipher (AES-128 Counter Mode), but to use no authentication method. This policy is NOT RECOMMENDED unless it is unavoidable; see Section 7.5 of [RFC3711].
SRTP variables that modify behaviors based on direction/leg:
rtp_secure_media
possible values:
mandatory – Accept/Offer SAVP negotiation ONLY
optional – Accept/Offer SAVP/AVP with SAVP preferred
forbidden – More useful for inbound to deny SAVP negotiation
false – implies forbidden
true – implies mandatory
default if not set is accept SAVP inbound if offered.
This is the same as rtp_secure_media, but would apply to either inbound
or outbound offers specifically.
How to specify crypto suites:
By default without specifying any crypto suites FreeSWITCH will offer crypto suites from strongest to weakest accepting the strongest each
endpoint has in common. If you wish to force specific crypto suites you can do so by appending the suites in a comma separated list in the order that you wish to offer them in.
Optionaly you can use rtp_secure_media_suites to dictate the suite list and only use rtp_secure_media=[optional|mandatory|false|true] without having to dictate the suite list with the rtp_secure_media* variables.
In vars.xml
SIP and TLS settings. http://wiki.freeswitch.org/wiki/Tls valid options: sslv2,sslv3,sslv23,tlsv1,tlsv1.1,tlsv1.2 default: tlsv1,tlsv1.1,tlsv1.2
TLS cipher suite: default ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH The actual ciphers supported will change per platform. openssl ciphers -v ‘ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH’ Will show you what is available in your verion of openssl.
SRTP to RTP over multiple Crypto suits
Logs :
A client at 7777777777@ is trying to call 9999999999@ , which freeswtch has to proxy and convert from RTP to SRTP.
The following debug logs form sofia external show this process.
recv 1215 bytes from udp/[]:4642 at 07:08:27.374857:
[DEBUG] sofia.c:7693 (sofia/external/7777777777@:5080) State Change CS_NEW -> CS_INIT
State NEW
Running State Change CS_INIT (Cur 1 Tot 33)
Standard INIT
State Change CS_INIT -> CS_ROUTING
State INIT going to sleep
Running State Change CS_ROUTING (Cur 1 Tot 33)
Callstate Change DOWN -> RINGING
State ROUTING
send 389 bytes to udp/[]:4642 at 07:08:27.376085:
After the invote is recived and processed with 100 trying reply , the routing and rtp secure trabformation begins by adding crypto keys and forarding to
Standard EXECUTE
ed5e07ee EXECUTE sofia/external/7777777777@:5080 set(rtp_secure_media=optional)
[rtp_secure_media]=[optional]
ed5e07ee EXECUTE sofia/external/7777777777@:5080 log(INFO Forwarding calls 9999999999@ )
Forwarding calls 9999999999@
…
Set Local audio crypto Key [1 AEAD_AES_256_GCM_8 inline:aHJ1yquBtm4Lzfi2oMpe6cV7IBEy3YgKxrJ3qjvLuRXSuZfHcV4VtVNwHDw]
Set Local video crypto Key [1 AEAD_AES_256_GCM_8 inline:qeJbqlSbnKBNew575hSZ3LX78o6GBsjgOrSMxzGH/zb1E7mkls1Mda93U9w]
Set Local text crypto Key [1 AEAD_AES_256_GCM_8 inline:VghMVsjWQwnOAAjBJ1NTB3jZgfpNV/Yu4poxkAPMqkC7C+fhPKApCJrWg3U]
Set Local audio crypto Key [2 AEAD_AES_128_GCM_8 inline:7XNrjjwC/eOVnWlBSp74DfiIGAEYn/BN+latfA]
Set Local video crypto Key [2 AEAD_AES_128_GCM_8 inline:UQrFpy9Q7L5DI/ww4e5IAmwy7BxSw5yd/T0v0Q]
Set Local text crypto Key [2 AEAD_AES_128_GCM_8 inline:ZqkEPrUFHkaQ+7CROp52H/JO0MbrYWk/Eyl9lQ]
Set Local audio crypto Key [3 AES_CM_256_HMAC_SHA1_80 inline:PTGAm2KlbfuKtIUVGtXknKKzALAzfILZJuPOjfO9S07eWRE6FR0aMUvjuehJgw]
Set Local video crypto Key [3 AES_CM_256_HMAC_SHA1_80 inline:ahHIB0o/dp3SliYWK9BkxM7TfzILwG0bjDn7JuvYi+puRkTM4mYvvsSmywLaYA]
Set Local text crypto Key [3 AES_CM_256_HMAC_SHA1_80 inline:crAs8dPcWJkEEGj5nqTvFGl/TWpxxb86k+dX5gBXhh+q6DO2pEqWNkQmm55aLA]
Set Local audio crypto Key [4 AES_CM_192_HMAC_SHA1_80 inline:SLBJWjgMdfiYX7TUwWQ9CmqUsILLJrpBIVjbfuQmpBIFLvvA/XU]
Set Local video crypto Key [4 AES_CM_192_HMAC_SHA1_80 fNazWgWwNRPjUKNHVqkz44]
Set Local text crypto Key [4 AES_CM_192_HMAC_SHA1_80 inline:hbe9qqETBSK5hRQ8DI9mXL4QAjjGSR8tGDiTHCJF3yxCrRk1ajk]
Set Local audio crypto Key [5 AES_CM_128_HMAC_SHA1_80 inline:8q8mer9N2V4qVxnaazuJeT0KXgW2scONy36J3KaS]
Set Local video crypto Key [5 AES_CM_128_HMAC_SHA1_80 inline:TP5NQ1yB8ZSCCwZMgXur9VHZ5SlpNfnXePj7eZrk]
Set Local text crypto Key [5 AES_CM_128_HMAC_SHA1_80 inline:HT3F3iYG8H/majhBZbOs2Z8ye/WEVGT5Oytx2oQS]
Set Local audio crypto Key [6 AES_CM_256_HMAC_SHA1_32 inline:fEohh92lX2xLmeFYlt8YouM2jN4z5pU05d90BYfoAKU6m4CWv8g8AnifDUKk9A]
Set Local video crypto Key [6 AES_CM_256_HMAC_SHA1_32 inline:+uBNmLcvj41hXoMxNlMNBpq68gU4PmLwYcdopEB/X/jfPElkUgHfguPIgIFJUg]
Set Local text crypto Key [6 AES_CM_256_HMAC_SHA1_32 inline:cqk7D3+KMQ+31R4FFDRRzn/aluyIgjxBL59vfxcsdf5OW9izEJtU+06GewJyIA]
Set Local audio crypto Key [7 AES_CM_192_HMAC_SHA1_32 inline:Tv25TfP9fQZ+ljs/tFlHohkckiK4F6cemzEjHSvo2+q6No4ai+o]
Set Local video crypto Key [7 AES_CM_192_HMAC_SHA1_32 inline:CY/Dizd1QrlobZtgnigr0hWE+oDSx4S1F51Zpo4aZamN+8ZMdp8]
Set Local text crypto Key [7 AES_CM_192_HMAC_SHA1_32 inline:aEox/7IMps5c+uOWbosZ618+opkJV/GnrKc2EnAhVnDNeo91+No]
Set Local audio crypto Key [8 AES_CM_128_HMAC_SHA1_32 inline:0LwKGyljIed0zhukiMMyD5ive0ZsyybwBrnevcAv]
Set Local video crypto Key [8 AES_CM_128_HMAC_SHA1_32 inline:eZN8rAG8UPPntdYxsg1kkWL4qMsVgTiGGiS4UeUM]
Set Local text crypto Key [8 AES_CM_128_HMAC_SHA1_32 inline:bAYzbfr+El8usaTkPBR6iFuTda4uLNGjyx9lQWkX]
Set Local audio crypto Key [9 AES_CM_128_NULL_AUTH inline:5m3142gGG1HZ5VnoXsAOyopSwDCYbrIsGpdbEO3D]
Set Local video crypto Key [9 AES_CM_128_NULL_AUTH inline:zXk67wjwRhSilq0kiz5TWxXqrxuTaWTA3qqbVo/G]
Set Local text crypto Key [9 AES_CM_128_NULL_AUTH inline:FRP9CJbBO+PRj6I9RSBAiMxRZ/qFtyrEXPfxocG0]
sending invite version: 1.9.0 -742-8f1b7e0 64bit
Local SDP:
v=0
o=FreeSWITCH 1552960557 1552960558 IN IP4
s=FreeSWITCH
c=IN IP4
t=0 0
m=audio 18750 RTP/SAVP 102 9 0 8 103 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40; stereo=1
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 telephone-event/48000
a=fmtp:103 0-16
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=crypto:1 AEAD_AES_256_GCM_8 inline:aHJ1yquBtm4Lzfi2oMpe6cV7IBEy3YgKxrJ3qjvLuRXSuZfHcV4VtVNwHDw
a=crypto:2 AEAD_AES_128_GCM_8 inline:7XNrjjwC/eOVnWlBSp74DfiIGAEYn/BN+latfA
a=crypto:3 AES_CM_256_HMAC_SHA1_80 inline:PTGAm2KlbfuKtIUVGtXknKKzALAzfILZJuPOjfO9S07eWRE6FR0aMUvjuehJgw
a=crypto:4 AES_CM_192_HMAC_SHA1_80 inline:SLBJWjgMdfiYX7TUwWQ9CmqUsILLJrpBIVjbfuQmpBIFLvvA/XU
a=crypto:5 AES_CM_128_HMAC_SHA1_80 inline:8q8mer9N2V4qVxnaazuJeT0KXgW2scONy36J3KaS
a=crypto:6 AES_CM_256_HMAC_SHA1_32 inline:fEohh92lX2xLmeFYlt8YouM2jN4z5pU05d90BYfoAKU6m4CWv8g8AnifDUKk9A
a=crypto:7 AES_CM_192_HMAC_SHA1_32 inline:Tv25TfP9fQZ+ljs/tFlHohkckiK4F6cemzEjHSvo2+q6No4ai+o
a=crypto:8 AES_CM_128_HMAC_SHA1_32 inline:0LwKGyljIed0zhukiMMyD5ive0ZsyybwBrnevcAv
a=crypto:9 AES_CM_128_NULL_AUTH inline:5m3142gGG1HZ5VnoXsAOyopSwDCYbrIsGpdbEO3D
a=ptime:20
a=sendrecv
Once the SDP is ready with crypto keys it is the forwarded to the next_up
send 2104 bytes to udp/[]:5060 at 07:08:27.378167:
Multimedia Internet Keying (MIKEY) – Key management of SRTP
can establish multiple security contexts or cryptographic sessions with a single message. Can be used in p2p or bradcast scenarios where one entity generates the key and needs to distribute the key to a number of participants
