Dialogic SRTP User guide

Brand: Dialogic

Model: SRTP

Type: User guide

SRTP User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 1/27

SRTP User Guide

Dialogic® BorderNet™ Session Border Controller (SBC)

Release 3.8.1

July 2019

SRTP User GuideDialogic Session Border Controller
Dialogic Inc. Proprietary Page 2/27
Table of Contents
 Introduction
1 Purpose of this Document
2 Glossary
3 Definitions
4 Contact Us
 Secure RTP
1 Overview
2 SRTP in Signaling Level
3 Media Level
3.1 SRTP Packets
3.2 SRTP Cryptographic Contexts
3.3 SRTP Parameters
4 SRTCP
 Deployment Scenarios
1 SRTP to RTP/RTP to SRTP
2 SRTP to SRTP as B2BUA
3 SRTP to SRTP without Media Interception
 BorderNet SBC SRTP Implementation
1 General
2 SDP SRTP Attributes
3 Incoming/Outgoing SIP Messages
4 Aborting an Invalid Session
5 Multiple 'm' Lines
6 MultiDialog
7 Media Packets
 SRTP Profile Provisioning
1 SRTP Profile Creation
2 Assign an SRTP Profile
 Management
1 SDR
2 Statistics
3 High Availability
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

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 ailiates or subsidiaries ("Dialogic"). Reasonable eort 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-aecting situations. Please see

http://www.dialogic.com/company/terms-of-use.aspx for more details.

Due to diering 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 dier from country to country and it is

the responsibility of those who develop the concepts or applications to be aware of and comply with dierent 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 ailiates 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 eects such usage might have, including without limitation eects 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 oices, 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 oer/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 oer/answer determines the selected oered crypto attributes by the answerer.

Crypto-Suite. An identifier that describes the encryption and authentication algorithms, negotiated between the two peers in

oer/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 oered 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 oer/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 dierent.

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 aer 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 dierent '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 oer 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 dierent cryptographic parameters separately negotiated

(dierent oer/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 dierent 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

, 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. Dierent 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 Oer/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 oered crypto

suites sent. If the received crypto attribute does not match any of the oered 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

Oer

BorderNet SBC, upon receiving a valid SDP oer from a peer (following an Invite or an Update with an oer):

matches between the crypto-suites received from the SDP oer, 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

Oer

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 Oer

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 Oer

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 dierent 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 ...

Dialogic SRTP User guide

Dialogic SRTP User guide

Related papers

Other documents