D i a l o g i c S e ssi o n B o r d e r C o n t r o l l e r S RT P U ......Dialogic® BorderNet...

SRTP User GuideDialogic Session Border Controller

Dialogic Inc. Proprietary Page 1/27

SRTP User Guide

Dialogic® BorderNet™ Session Border Controller (SBC)

Release 3.8.1July 2019



Table of Contents1. 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



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 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.

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



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 HistoryVersion # 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



1. Introduction

1.1 Purpose of this DocumentThis document is intended to familiarize the reader with the Dialogic BorderNet SBC SRTP functionality and its use.

1.2 GlossaryFor 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 DefinitionsTerm 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 betweenrecipients 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 easilyunderstood by anyone except authorized parties.

Decryption The process of transforming (decoding) data that has been rendered unreadable through encryption backto its unencrypted form.

Authentication The process of ensuring that both ends of the connection are in fact who they say they are.



Term Definition

Integrity Ensuring the message sent is the actual message received by the recipient, without being modified orcompromised on the way.

1.4 Contact UsFor a list of Dialogic locations and o�ices, please visit: https://www.dialogic.com/contact.aspx.

https://www.dialogic.com/contact.aspx



2. Secure RTP

2.1 OverviewSecure 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 LevelSRTP 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: []

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:" ["|" 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.



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 PacketsThe 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



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 ContextsEach 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 =

2.3.3 SRTP Parameters



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 SRTCPSecure 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:



Figure 3: SRTCP Packet Format



3. Deployment ScenariosThe 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 SRTPBorderNet 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



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.



Figure 6: Multiple m lines, Audio + Video

3.3 SRTP to SRTP without Media InterceptionIn 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).



Figure 7: SRTP to SRTP without Media Interception



4. BorderNet SBC SRTPImplementation

4.1 GeneralBorderNet 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 AttributesBorderNet 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



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 MessagesThe following table specifies how the SIP signaling is handled for SRTP sessions.

Event BorderNet SBC Actions

Generatingan Invite

If the SRTP profile is set, then the BorderNet SBC inserts a crypto attribute in the SDP media level per "m" linewith 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_80inline:NmU0NTlkM2QzNDkzNGFiNzVjYjE2MWI2ZDcyMWZk a=crypto:2 AES_CM_128_HMAC_SHA1_32inline:M2JhMmJmYmM4OGIxNDRlADY5NDQ5NjMANjljM2Qz

Receivingthe answerto theInvite

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.

Sendingan answerto SDPO�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.



Event BorderNet SBC Actions

Receivingan InitialO�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�erExists

SRTP ProfileAssigned

Encryption Mode BorderNet SBC Action

Yes Yes Allow only encryptedcalls

Invoke SRTP handling

Yes Yes Allow unencrypted calls Invoke SRTP handling

Yes No Any Send a 488 Bad Crypto Negotiation responsecode

No Yes Allow only encryptedcalls

Send a 488 Bad Crypto Negotiation responsecode

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�erExists

SRTP ProfileAssigned

Encryption Mode BorderNet SBC Action

Yes Yes Allow only encryptedcalls

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 responsecode

No Yes Allow only encryptedcalls

Send a 488 Bad Crypto Negotiation responsecode

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



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 SessionFor 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' LinesBorderNet 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 MultiDialogBorderNet 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.



4.7 Media PacketsBorderNet SBC handles media packets, as follows:

Media Packets BorderNet SBC Actions

Outgoing SRTPpackets

Encrypts the RTP payload using the session encryption key and salt key.

Creates an SRTP authentication tag, using the authentication key.

Inserts the encrypted payload as the SRTP payload.

Appends the authentication tag as the last portion of the SRTP layer (a�er the encrypted

payload), to construct the full SRTP packet.

Incoming SRTPpackets

Verifies the authentication tag, and upon failure, the packet is discarded. Otherwise the SRTP

payload is decrypted.

Outgoing SRTCPpackets

Creates an SRTCP authentication tag, using the authentication key.

Inserts the encrypted payload as the SRTCP payload.

Appends the authentication tag as the last portion of the SRTCP layer (a�er the SRTCP index), to

construct the full SRTCP packet.

Incoming SRTCPpackets

Verifies the authentication tag, and upon failure, the packet is discarded. Otherwise the SRTCP

payload is decrypted.

Table 5: Media Packets

Session parameters, such as SRTP parameters, can be changed during an existing session, as well as switching from RTP to SRTP

or from SRTP to RTP, using the Update method or Re-Invite.



5. SRTP Profile ProvisioningTo provision the SRTP profile in the system, create an SRTP profile, and assign it to the appropriate SIP interface.

5.1 SRTP Profile Creation→ To create an SRTP profile:

1. Select Application ➔ SIP Configuration ➔ SRTP Profile.

2. The SRTP Profile window opens.

3. Click on + Add New SRTP Profile.

The Add SRTP Profile window opens.



4. Enter the following parameters:

Name. Enter the name of the SRTP profile.

Crypto-Suite. Select a crypto-suite from the Available field.

Select the Add >> button to move it to the Selected field. Each crypto-suite can be added or removed, as well as shi�ed

up or down in the list. It is mandatory to configure at least one crypto-suite.

Allow Unencrypted Calls. Select:

Yes to allow unencrypted calls.

BorderNet SBC initiates SRTP encryption for the outgoing calls, and accepts the incoming calls with a regular RTP

o�er (without SRTP encryption).

No to allow only encrypted calls.

BorderNet SBC initiates SRTP for the outgoing calls and accepts only SRTP-encrypted calls. Incoming calls without

an SRTP o�er or SDP answers without SRTP's acceptance are rejected with a 488 Bad Crypto Negotiation response.

5.2 Assign an SRTP ProfileSRTP is allowed only when TLS is selected for an SIP interface.

Upon selecting the TLS as the transport protocol in the SIP Interface Configuration window, the SRTP Profile drop-down menu

enables the user to assign an SRTP Profile to the selected SIP Interface.

→ To assign an SRTP Profile to a SIP Interface:

1. Select Application ➔SIP Configuration ➔ Interface.

The SIP Interface window opens.



2. Select an SIP interface, and select the Edit icon (far le�-hand column) to modify the parameters.

The Edit menu opens.

3. Click Edit.

1. The Edit SIP Interface window opens.

2. Set the Status parameter to OFF, and click on Save.

3. Select the SIP interface and click on the Edit button to assign the SRTP Profile.

4. Select TLS as the Transport Protocol using the drop-down menu.



5. Select the pre-configured SRTP Profile using the drop-down menu.

6. Click on the Save button.



6. Management

6.1 SDRThe following Session Detail Record (SDR) parameters reflect the encryption used for the SRTP, on the Ingress and Egress legs:

Number Name Value

85 IngressMediaEncryption

None. No encryption used.

AES_CM_128_HMAC_SHA1_32.

AES_CM_128_HMAC_SHA1_80

156 EgressMediaEncryption

None. No encryption used.

AES_CM_128_HMAC_SHA1_32.

AES_CM_128_HMAC_SHA1_80

Table 6: SRTP SDR Fields

6.2 StatisticsSRTP & SRTCP packets are provided under the SRTP and SRTCP columns in the following windows:

Location Statistics

Diagnostics ➔ System Statistics

Summary

Packet Statistics

Incoming Sessions

Outgoing Sessions

Diagnostics ➔ Interface Statistics

Summary

Packet Statistics

Incoming Sessions

Outgoing Sessions



Location Statistics

Diagnostics ➔ Peer Statistics

Summary

Packet Statistics

Incoming Sessions

Outgoing Sessions

Table 7: SRTP and SRTCP Statistics

6.3 High AvailabilityBorderNet SBC supports SRTP High Availability.

The SRTP sessions information is mirrored between the active and standby systems. Mirrored parameters include the SRTP index,

cryptographic keys and crypto attribute parameters. Upon a failover, all SRTP sessions are maintained.

6.4 SRTP ActivationSRTP is enabled if the SRTP license is loaded to the BorderNet SBC.

The SRTP license for SRTP is per session, limiting the total number of SRTP sessions.

If the ongoing SRTP sessions number reaches the license limit, then calls which require SRTP, will be rejected with a 488 Bad

Crypto Negotiation response code.

A new license updates the maximum number of the SRTP sessions, decreasing or increasing the number of sessions.

If a new license with a decreased number of SRTP sessions is loaded, and the active ongoing number of sessions exceeds the new

license limit, then BorderNet SBC gracefully terminates the calls.

Licensing state is displayed in the System ➔ Administration ➔ License window.

END OF DOCUMENT

D i a l o g i c S e ssi o n B o r d e r C o n t r o l l e r S RT P U ......Dialogic® BorderNet...

Documents

Transcript of D i a l o g i c S e ssi o n B o r d e r C o n t r o l l e r S RT P U ......Dialogic® BorderNet...