SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 2/27
Table of Contents
1. Introduction
1.1 Purpose of this Document
1.2 Glossary
1.3 Definitions
1.4 Contact Us
2. Secure RTP
2.1 Overview
2.2 SRTP in Signaling Level
2.3 Media Level
2.3.1 SRTP Packets
2.3.2 SRTP Cryptographic Contexts
2.3.3 SRTP Parameters
2.4 SRTCP
3. Deployment Scenarios
3.1 SRTP to RTP/RTP to SRTP
3.2 SRTP to SRTP as B2BUA
3.3 SRTP to SRTP without Media Interception
4. BorderNet SBC SRTP Implementation
4.1 General
4.2 SDP SRTP Attributes
4.3 Incoming/Outgoing SIP Messages
4.4 Aborting an Invalid Session
4.5 Multiple 'm' Lines
4.6 MultiDialog
4.7 Media Packets
5. SRTP Profile Provisioning
5.1 SRTP Profile Creation
5.2 Assign an SRTP Profile
6. Management
6.1 SDR
6.2 Statistics
6.3 High Availability
6.4 SRTP Activation
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 3/27
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 4/27
Copyright and Legal Notice
Copyright © 2016-2019 Dialogic Corporation. All Rights Reserved. You may not reproduce this document in whole or in part
without permission in writing from Dialogic Corporation at the address provided below.
All contents of this document are furnished for informational use only and are subject to change without notice and do not
represent a commitment on the part of Dialogic Corporation and its ailiates or subsidiaries ("Dialogic"). Reasonable eort is
made to ensure the accuracy of the information contained in the document. However, Dialogic does not warrant the accuracy of
this information and cannot accept responsibility for errors, inaccuracies or omissions that may be contained in this document.
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED,
BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED
IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS
ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR
WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL
PROPERTY RIGHT OF A THIRD PARTY.
Dialogic products are not intended for use in certain safety-aecting situations. Please see
http://www.dialogic.com/company/terms-of-use.aspx for more details.
Due to diering national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific
countries, and thus may not function properly in other countries. You are responsible for ensuring that your use of such products
occurs only in the countries where such use is suitable. For information on specific products, contact Dialogic Corporation at the
address indicated below or on the web at www.dialogic.com.
It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in
marketing collateral produced by or on web pages maintained by Dialogic may infringe one or more patents or other intellectual
property rights owned by third parties. Dialogic does not provide any intellectual property licenses with the sale of Dialogic
products other than a license to use such product in accordance with intellectual property owned or validly licensed by Dialogic
and no such licenses are provided except pursuant to a signed agreement with Dialogic. More detailed information about such
intellectual property is available from Dialogic's legal department at 3300 Boulevard de la Côte-Vertu, Suite 112, Montreal, Quebec,
Canada H4R 1P8. Dialogic encourages all users of its products to procure all necessary intellectual property licenses required to
implement any concepts or applications and does not condone or encourage any intellectual property infringement and
disclaims any responsibility related thereto. These intellectual property licenses may dier from country to country and it is
the responsibility of those who develop the concepts or applications to be aware of and comply with dierent national license
requirements.
Dialogic, Dialogic Pro, Veraz, Brooktrout, Diva, BorderNet, PowerMedia, PowerVille, PowerNova, MSaaS, ControlSwitch, I-Gate,
Cantata, TruFax, SwitchKit, Eiconcard, NMS Communications, SIPcontrol, Exnet, EXS, Vision, inCloud9, and NaturalAccess, among
others as well as related logos, are either registered trademarks or trademarks of Dialogic Corporation and its ailiates or
subsidiaries. Dialogic's trademarks may be used publicly only with permission from Dialogic. Such permission may only be granted
by Dialogic's legal department at 3300 Boulevard de la Côte-Vertu, Suite 112, Montreal, Quebec, Canada H4R 1P8. Any authorized
use of Dialogic's trademarks will be subject to full respect of the trademark guidelines published by Dialogic from time to time and
any use of Dialogic's trademarks requires proper acknowledgement.
The names of actual companies and products mentioned herein are the trademarks of their respective owners.
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 5/27
This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision
to use open source in connection with Dialogic products (including without limitation those referred to herein), nor is Dialogic
responsible for any present or future eects such usage might have, including without limitation eects on your products, your
business, or your intellectual property rights.
Document History
Version # Version Date Update Description
1.0 August 2016 Release 3.5.0 - Initial version
1.1 September 2016 Release 3.7.0
1.2 May 2019 Release 3.8.1
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 6/27
1. Introduction
1.1 Purpose of this Document
This document is intended to familiarize the reader with the Dialogic BorderNet SBC SRTP functionality and its use.
1.2 Glossary
For the purposes of this document the following abbreviations apply:
Abbreviation Meaning
RTP Real-Time Transport Protocol
SRTP Secure RTP
RTCP Real-Time Transport Control Protocol
SRTCP Secure RTCP
AVP Audio Video Profile
SAVP Secure AVP
SDP Session Description Protocol
MAC Message Authentication Code
1.3 Definitions
Term Definition
RTP payload The data transported by RTP in a packet, for example audio samples.
RTP packet A packet consisting of the RTP header, a list of contributing sources, and the payload data.
RTCP packet A data packet which conveys a number of statistics and other information about an RTP flow between
recipients and senders.
Crypto-Suite An identifier that describes the encryption and authentication algorithms.
Master Key Key material used by the SRTP key derivation process to create SRTP session keys.
Encryption The conversion (encoding) of electronic data into another form, called ciphertext, which cannot be easily
understood by anyone except authorized parties.
Decryption The process of transforming (decoding) data that has been rendered unreadable through encryption back
to its unencrypted form.
Authentication The process of ensuring that both ends of the connection are in fact who they say they are.
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 7/27
Term Definition
Integrity Ensuring the message sent is the actual message received by the recipient, without being modified or
compromised on the way.
1.4 Contact Us
For a list of Dialogic locations and oices, please visit: https://www.dialogic.com/contact.aspx.
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 8/27
2. Secure RTP
2.1 Overview
Secure RTP (SRTP) is a protocol used to encrypt RTP media between two entities, enabling media confidentiality and message
authentication.
SRTP resides between the RTP application and the transport layer, and encrypts only the payload.
SRTP profile is an extension profile to the RTP/AVP profile (RTP/SAVP), accepting all the RTP AVP profile's payload types.
SRTP relies on various existing mechanisms for secure key exchange. BorderNet SBC uses SIP signaling to exchange the SRTP
capabilities via the SDP.
2.2 SRTP in Signaling Level
SRTP encryption keys and encryption algorithms are signaled in the SDP (via the SIP protocol) exchanged between peers
This information is described in the SDP media level, using the SDP attribute: a=crypto.
The crypto attribute is used to signal and negotiate cryptographic parameters for media streams in general, and for SRTP in
particular, using the oer/answer model.
The syntax of the crypto attribute and its parameters are as follows:
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
Example:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:xecNW9BAUUfsgvZgE2OApkYJ20OM3guIqql5gayD
Tag. A decimal number used as a crypto attribute identifier. A media line can have several crypto attributes, each identified by
a unique tag. A tag in oer/answer determines the selected oered crypto attributes by the answerer.
Crypto-Suite. An identifier that describes the encryption and authentication algorithms, negotiated between the two peers in
oer/answer. Example: AES_CM_128_HMAC_SHA1_80.
Key Parameters. One or more sets of keying material for the crypto-suite, used for the encryption method indicated in the
crypto-suite. Currently the only method supported is
inline
, which indicates that the actual keying material is provided in the
key-info field itself (inside the crypto line): "inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]
Example: inline:xecNW9BAUUfsgvZgE2OApkYJ20OM3guIqql5gayD
The inline parameter conveys a master key used by an endpoint to encrypt the media streams transmitted by that endpoint. The
same master key is used by the recipient to decrypt those streams.
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 9/27
There may be one or more key parameters in a crypto attribute. In this way, multiple keys are oered to support key rotation using
a Master Key Identifier (MKI).
Example:
a=crypto:1 F8_128_HMAC_SHA1_80
inline:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm|2^20|1:4;
inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4
2^20 indicates the key lifetime, measured in the number of packets which can be used with this key before it should be
replaced with a new key.
1:4/2:4 indicates the key identification and its length (2:4 signals that key number two should be used).
Session Parameters. The session parameters provide session specific information to establish the SRTP cryptographic context,
and are optionally used to override the default values for the SRTP and SRTCP streams.
The crypto keys exchanged in the SDP during the oer/answer process are unidirectional. Each side sends the encryption key used
to encrypt its transmitted packets.
Note:
The crypto-suite, meaning the type of algorithm used for encryption and authentication, must be the same for both sides. Only
the key used for the crypto-suite is dierent.
2.3 Media Level
2.3.1 SRTP Packets
The Secure Real Time Protocol (SRTP) is a profile for the Real Time Protocol (RTP, IETF RFC 3550) to provide confidentiality,
integrity, and authentication to media streams and is defined in IETF RFC 3711. The SRTP standard also specifies protection for
RTCP messages.
In addition to providing data encryption, the SRTP standard supports message authentication and integrity of the RTP packet.
A Message Authentication Code (MAC) is produced by computing a hash of the entire RTP message, including the RTP headers
and encrypted payload, and placing the resulting value in the Authentication tag header, as depicted in figures 1 and 2 below:
Figure 1: RTP Encryption/Authentication Portions
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 10/27
The SRTP message resembles the format of an RTP message with the exception of two additional headers:
the Master Key Identifier (MKI)
the Authentication tag
Keeping the same RTP header, as well as not encrypting it, allows the SRTP packets to be routed and compressed (RTP header
compression) in the same way as regular RTP packets.
Figure 2: RTP Packet Format
The MKI is optional and indicates the Master Key ID which is used to generate SRTP session keys. It is useful in cases which support
re-keying (changing the key during the lifetime of the session).
The MKI points to the ID of the Master Key to be used, while the actual key is delivered elsewhere by using a key management
mechanism.
The use of the Authentication tag header is important and provides protection against message-replay attacks.
2.3.2 SRTP Cryptographic Contexts
Each SRTP stream requires the sender and receiver to maintain cryptographic state information. This information is called the
"cryptographic context".
Mapping SRTP packets to Cryptographic Contexts is done using the context-id, which is identified by the triplet context identifier:
context id = <SSRC, destination network address, destination transport port number>
2.3.3 SRTP Parameters
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 11/27
SRTP defines several important implicit parameters (they are not conveyed in the packets and are not present in the headers).
Two of the implicit parameters are listed below:
ROC. A 32-bit unsigned rollover counter (ROC), which records how many times the 16-bit RTP sequence number has been
reset to zero aer passing through 65,535.
Index of the SRTP packet. A 48-bit value, constructed from the index and sequence number in the following way: i = 2^16 *
ROC + SEQ.
The index and ROC are crucial to the proper operation of SRTP, as the index 'i' is used in replay protection, encryption, message
authentication and for the key derivation.
In case the index 'i' is not synchronized between the two ends of the connection (each side has a dierent 'i' value), then the
decryption of packets on both sides will fail.
2.4 SRTCP
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
The sensitive information that needs to be protected in an RTCP message includes the originating party of the report and the
contents of the report. Therefore, these headers are encrypted.
The SRTCP index is a 31-bit counter for the SRTCP packet. The index is explicitly included in each packet, in contrast to the
'implicit' index approach used for SRTP.
As a result, the receiver does not need to 'estimate' the index, as it is explicitly signaled in the packet.
The encryption transform and related parameters used for SRTCP are by default the same as those selected for the protection of
the associated SRTP stream (the same cryptographic suite and keys are shared between SRTP and SRTCP).
The below figure depicts the SRTCP packet format:
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 12/27
Figure 3: SRTCP Packet Format
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 13/27
3. Deployment Scenarios
The BorderNet SBC is a B2BUA, and as such it treats each call leg as a separate SIP and SRTP session. As a result, the following
SRTP scenarios are deployed.
3.1 SRTP to RTP/RTP to SRTP
BorderNet SBC supports SRTP to RTP/RTP to SRTP sessions.
The following example shows an SRTP to RTP session, in which the SRTP peer sends an oer with multiple crypto-attributes in the
SDP.
The BorderNet SBC chooses the first crypto with tag=1 and creates an SRTP session on one side and a regular RTP session on the
other side. Each peer utilizing the SRTP generates its own encryption key.
Figure 4: SRTP to RTP, Multiple Crypto Attributes
3.2 SRTP to SRTP as B2BUA
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 14/27
This option allows SRTP on both incoming and outgoing sessions, with dierent cryptographic parameters separately negotiated
(dierent oer/answer instance).
BorderNet SBC authenticates and decrypts the SRTP packets from one side, encrypts them, and sends them to the other side,
applied when both legs require SRTP, and media interception is set to
yes,
as depicted in the below examples.
In the first example each leg has its own SRTP parameters such as crypto-suite and master key, which are dierent from the other
leg. BorderNet SBC provides encryption and decryption per side.
Figure 5: SRTP to SRTP as B2BUA
The second example shows a scenario with two 'm' lines which creates two SRTP streams, one for audio and the second for video.
Each 'm' line has its own crypto attribute which is negotiated independently.
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 15/27
Figure 6: Multiple m lines, Audio + Video
3.3 SRTP to SRTP without Media Interception
In this option the media interception is set to
no
, and the RTP packets are exchanged directly between the two peers without any
intervention of the BorderNet SBC.
BorderNet SBC verifies the crypto attribute syntax and validity before transparently transferring it to the other leg, as depicted in
the example below.
In this example the BorderNet SBC does not negotiate the SDP and SRTP crypto parameters, transfers them transparently from one
leg to the other, and does not handle the media (the SRTP packets are delivered directly between the two peers).
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 16/27
Figure 7: SRTP to SRTP without Media Interception
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 17/27
4. BorderNet SBC SRTP
Implementation
4.1 General
BorderNet SBC currently covers the same encryption and authentication applied to both SRTP and SRTCP. Dierent combinations
are rejected if signaled by the peer entities.
Re-Keying is the process of changing the encryption key while the SRTP session is still on going. Re-Keying is not required in the
current scope.
BorderNet SBC in this release does not deploy fax security, and therefore any fax transmission, even if started with SRTP sessions,
is not encrypted.
4.2 SDP SRTP Attributes
BorderNet SBC negotiates the crypto-attributes in the SDP, in accordance with the SIP Oer/Answer model, supporting the
following parameters:
Tag
Crypto-suite
Key-Params (key-method=inline)
Session-Params - SRTP security descriptions define a set of "session" parameters, which optionally may be used to override
SRTP session defaults for the SRTP and SRTCP streams. In this release the session parameters are not supported.
Cryptographic Transforms - the following two cryptographic transforms are supported, based on the below characteristics: -
the following two cryptographic transforms are supported, based on the below characteristics:
Name AES_CM_128_ HMAC_SHA1_80 AES_CM_128_ HMAC_SHA1_32
Master key length 128 bits 128 bits
Master salt length 112 bits 112 bits
SRTP lifetime 2^48 packets 2^48 packets
SRTCP lifetime 2^31 packets 2^31 packets
Cipher AES Counter Mode AES Counter Mode
Encryption key 128 bits 128 bits
MAC HMAC-SHA1 HMAC-SHA1
SRTP auth. Tag 80 bits 32 bits
SRTCP auth. Tag 80 bits 80 bits
SRTP auth. key len 160 bits 160 bits
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 18/27
Name AES_CM_128_ HMAC_SHA1_80 AES_CM_128_ HMAC_SHA1_32
SRTCP auth. key len 160 bits 160 bits
Table 1: Supported Cryptographic Algorithms
4.3 Incoming/Outgoing SIP Messages
The following table specifies how the SIP signaling is handled for SRTP sessions.
Event BorderNet SBC Actions
Generating
an Invite
If the SRTP profile is set, then the BorderNet SBC inserts a
crypto
attribute in the SDP media level per "m" line
with an RTP/SAVP profile. BorderNet SBC:
adds a unique tag parameter, starting with "1" and incremented by one per
crypto
attribute in the same
"m" line.
sets the ordering of the multiple "a=crypto" lines, according to the order selected in the SRTP profile's
crypto-suites
, as configured in the system (the preferred crypto line is listed first).
generates a key and adds it to the crypto attribute, including a master and a salt key, used for the SRTP
Key Derivation process.
Example: m=audio 11792 RTP/SAVP 0 8 18 9 101 a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:NmU0NTlkM2QzNDkzNGFiNzVjYjE2MWI2ZDcyMWZk a=crypto:2 AES_CM_128_HMAC_SHA1_32
inline:M2JhMmJmYmM4OGIxNDRlADY5NDQ5NjMANjljM2Qz
Receiving
the answer
to the
Invite
The answer can be a reliable 18x or 200 OK. BorderNet SBC:
verifies that the "m" line contains the RTP/SAVP profile and crypto attributes. If one of these arguments
is missing then it aborts the session with a 488 Bad Crypto Negotiation response.
verifies that the received crypto attribute (tag and crypto-suite) is one of the initially oered crypto
suites sent. If the received crypto attribute does not match any of the oered crypto-suites, BorderNet
SBC aborts the session with a 488 Bad Crypto Negotiation response.
retrieves the base64 encoded key from the crypto attribute key-param, and extracts from it the master
and salt keys. The extraction is based on the key length indicated for the type of cipher suite. The
master and the salt keys are used for the SRTP Key Derivation process, in order to create a session
decrypting key, a session authentication key and a salt key.
Sending
an answer
to SDP
Oer
BorderNet SBC, upon receiving a valid SDP oer from a peer (following an Invite or an Update with an oer):
matches between the crypto-suites received from the SDP oer, and the crypto-suites configured in the
SRTP profile. If there is no common crypto-suite, the session is rejected with a 488 Unsupported
Crypto-Suite response.
otherwise a reliable 18x/200 OK message with the common crypto-suites is sent. The keys added are not
copied from the master key received in the crypto attribute of the remote side.
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 19/27
Event BorderNet SBC Actions
Receiving
an Initial
Oer
BorderNet SBC:
checks the transport protocol parameter of the
m line
, and the existence of a crypto attribute, and
aborts if the crypto attribute does not exist with a 488 Bad Crypto Negotiation response.
verifies the SRTP profile, and the state of the
Encryption mode
. If media interception is on, the
BorderNet SBC behaves according to Table 3. Otherwise according to Table 4 (when media interception
is o, the RTP/SRTP packets are not sent via the BorderNet SBC but directly between the peers).
selects the first valid supported crypto attribute in the list, and adds it as the crypto attribute of the
answer.
retrieves the base64 encoded key from the Crypto attribute key-param, and extracts from it the master
key and salt key (it decodes the base64 and then un-concatenates the keys).
Table 2: Incoming/Outgoing SIP Messages
Valid SRTP Oer
Exists
SRTP Profile
Assigned Encryption Mode BorderNet SBC Action
Yes Yes Allow only encrypted
calls Invoke SRTP handling
Yes Yes Allow unencrypted calls Invoke SRTP handling
Yes No Any Send a 488 Bad Crypto Negotiation response
code
No Yes Allow only encrypted
calls
Send a 488 Bad Crypto Negotiation response
code
No Yes Allow unencrypted calls Invoke regular RTP handling
No No Any Invoke regular RTP handling
Table 3: SRTP Profiles & Encryption-Mode Options, with Interception
Valid SRTP Oer
Exists
SRTP Profile
Assigned Encryption Mode BorderNet SBC Action
Yes Yes Allow only encrypted
calls Verify syntax and validity Transfer SDP
Yes Yes Allow unencrypted calls Verify syntax and validity Transfer SDP
Yes No Any Send a 488 Bad Crypto Negotiation response
code
No Yes Allow only encrypted
calls
Send a 488 Bad Crypto Negotiation response
code
No Yes Allow unencrypted calls Regular SDP verification Transfer SDP
No No Any Regular SDP verification Transfer SDP
Table 4: SRTP Profiles & Encryption-Mode Options, No Intercept
SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 20/27
BorderNet SBC generates keys for encrypting SRTP and SRTCP outgoing packets.
The master and the salt keys lengths are corresponded to the type of crypto-suite associated in the interface SRTP profile.
The master and the salt keys received are used for decrypting incoming SRTP and SRTCP packets and not for encrypting outgoing
packets.
The extraction is made based on the key length indicated for the type of cipher suite. The master key and salt key are used for the
SRTP Key Derivation process, in order to create a session decrypting key, a session authentication key and a salt key.
4.4 Aborting an Invalid Session
For a session initiated by the BorderNet SBC, if an invalid crypto attribute is received in:
18x: BorderNet SBC terminates the session and sends a Cancel message.
200 OK: BorderNet SBC sends an ACK message followed by a Bye message.
For a session initiated by a peer, if an invalid crypto attribute is received, then BorderNet SBC rejects the call.
The session rejection and termination above includes the following reason header:
Reason: SIP; cause=488; text=Bad Crypto negotiation.
4.5 Multiple 'm' Lines
BorderNet SBC supports two 'm' lines in cases where one stream is audio and the second one is video (two audio or two video
streams are not supported). Each 'm' line includes a separate crypto attribute at the media level.
4.6 MultiDialog
BorderNet SBC supports the MultiDialog scenario, as follows:
Upon receiving several 18x SIP responses (early dialogs), BorderNet SBC handles the early media and the SDP of the first 18x
received. All the SDP and crypto attributes of all the early dialogs are saved until one of the dialogs is confirmed (200 OK received).
When a 200 OK message is received, then BorderNet SBC uses the SDP and crypto attribute of this confirmed dialog.
If the 200 OK message does not contain SDP and crypto attributes then the BorderNet SBC uses the crypto which was received in
the 18x of the same dialog.
If the confirmed dialog ID, created as a result of the 200 OK, is dierent from the first early dialog used for the early media, then
the SRTP session is switched to use the confirmed dialog SDP and crypto.
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
-
1
-
2
-
3
-
4
-
5
-
6
-
7
-
8
-
9
-
10
-
11
-
12
-
13
-
14
-
15
-
16
-
17
-
18
-
19
-
20
-
21
-
22
-
23
-
24
-
25
-
26
-
27
Ask a question and I''ll find the answer in the document
Finding information in a document is now easier with AI
Related papers
-
Dialogic Bulk User guide
-
-
-
-
-
-
-
-
-
Other documents
-
Kofax Communication Server 10.3.0 User guide
-
Cisco Unified Communications Manager (CallManager) User guide
-
Polycom 1725-31402-001 User manual
-
-
Poly CX5100 Administrator Guide
-
-
-
-
Grandstream Networks BT–200 User manual
-
Cisco Unified Survivable Remote Site Telephony User guide