Page History

Introduction

This document describes how to calculate DSP resource requirements for the New Investment Protection Configurations of the SBC 1000 using Release 3.2 and 4.0 software. For earlier configurations please refer to the "Quick Guide to DSP Resource Requirements for the Sonus SBC 1000 Session Border Controller: Older Configurations."consumption for newly updated hardware that began shipping from Sonus Networks as of November 2016. For DSP consumption associated with older versions of hardware, please refer to the appropriate release documentation on the Sonus Documentation Portal.

Purpose

This guide is intended to help partners and customers understand how to determine DSP resource requirements for their immediate needs and to support future growth.

How to Use This Guide

This guide is intended to be used in conjunction with the Partner Configurator to determine DSP resource requirements for various codec/transcoding scenarios. This guide is not a replacement for the Partner Configurator.

What You Need to Know

regarding the capacity and use of DSP resources in the newly updated hardware that began shipping as of November 2016, with the expectation that partners and customers select the appropriate instance of

How to Use This Guide

This guide is intended to be used by Sonus customers to help select a

What You Need to Know

Default transcoding scenario: The most common IP ↔ IP transcoding scenario for SBC 1000 is from G.711 (RTP) to G.711 (SRTP). This is considered as the default transcoding scenario for SBC 1000 when Default transcoding scenario: The most common IP – IP transcoding scenario for SBC 1000 is from G.711 (RTP) to G.711 (SRTP). This is considered as the default transcoding scenario for SBC 1000 when calculating DSP resource requirements.

DSP resource requirement number: A DSP resources resource is a unit of DSP processing required to transcode from one codec to another. For SBC 1000, 1 DSP resource is equal to the processing associated with 1 (one) transcoding session for the default transcoding scenario (described above).

DSP resource requirement number: The number of DSP resources required to support a specific number of IP ↔ IP sessions. All calculations mentioned in this document build upon the default transcoding scenario mentioned above. For example, DSP resource requirement number for 100 IP -↔ IP sessions for a default transcoding scenario is 100.

Special case for multiple low-bit rate codecs: In the case where If two or more low-bit rate codecs (G.729ab, G.723.1, G.726, or T.38) will be are used (IP -↔ IP and/or TDM/IP), a 20% uplift is applied to the calculated results. For example, if several codecs will be used and this calculates to a DSP resource requirement of 100, then a 20% uplift is applied and the true DSP resource requirement will be 120. Note that this DSP resource requirement number.

Example: Two or more low-bit-rate codecs are used.

Notes:

This uplift requirement only applies for multiple low-bit-rate codecs (G.729ab, G.723.1, G.726, or T.38).

The combination of a single low-bit rate codec with G.711 does not require an uplift.

It is also important to design for the most DSP-intensive usage.

If multiple codecs

are used and the split among these codecs

varies, be sure to calculate using the codec that is most DSP-intensive and then apply the 20% uplift.

Multiplication Factor: Multiplication factor when multiplied with your session requirement count Value derived from Table 1. The multiplication factor, when multiplied by the number of sessions required for your deployment, gives you the total number of DSP resources required for those sessions and selected codecs.

DSP Mode: Implies a session that is to be acted upon by the DSPs; i.e.

Survivable Branch Appliance (SBA) and Cloud Connector Edition (CCE) applications from Microsoft®: Addition of the SBA does not affect DSP requirements.

DSP mode versus RTP Proxy (Media Pass Through): In the case of RTP Proxy media passes through the SBC and does not use the DSP.

DSP Matrix for the IP-IP Operating Mode

The following table provides multiplication factor (to be used with IP-IP session count requirement) to determine DSP resource requirement. To determine the multiplication factor for your transcoding scenario, select from-codec ('codec type' column) and to-codec ('codec type' row) in the following table. The intersecting cell gives you your multiplication factor.

Caption
0 Table 1 IP-IP DSP Resource Consumption - SBC 1000 IP-IP DSP Multiplication Factor
Image Removed Image Removed

, a session requiring media services.

RTP Proxy Mode: A session that is not subject to DSP services but does flow through the

Direct Media Mode: A session that is not subject, and does not flow through, the

DSP Usage in Microsoft Skype for Business Survivable Branch Appliance (SBA) and Cloud Connector Edition (CCE) Deployments

DSP resource usage is unaffected within an

DSP Matrix for the IP ↔ IP Operating Mode

The following table provides multiplication factor (to be used with IP ↔ IP session count requirement) to determine DSP resource requirement. The IP↔ IP operating mode is a bidirectional media session, anchored by the 

To determine the multiplication factor for your transcoding scenario, select from-codec (Codec Type column) and to-codec (Codec Type row) in the following table. The intersecting cell gives you your multiplication factor.

Caption
0 Table 1 IP ↔ IP DSP Resource Consumption - SBC 1000 IP ↔ IP DSP Multiplication Factor
Image Added

Note: Densities assume VAD on (60% silence during call), RTCP on, RFC2833 on, and 20ms packet size for all codecs (except 30ms for G.723.1), G.722.2 at 12.65 kbit/s, RTP (unless specified with SRTP).

DSP Resource Consumption for the TDM ↔ IP Operating Mode

The TDM ↔ IP operating mode is a bidirectional media session, anchored by the 

Resource requirements for TDM/FXx ↔ IP flows can be derived from Table 1. However, the DSP resource requirement presented from Table 1 will be subject to a 50% reduction in value. Note

Note: Densities assume VAD on (60% silence during call), RTCP on, RFC2833 on, and 20ms packet size for all codecs (except 30ms for G.723.1), G.722.2 at 12.65 kbit/s, RTP (unless specified with SRTP).

DSP Resource Consumption for the TDM-IP Operating Mode

Resource requirements for TDM/FXx <> IP usage are measured to be 50% the usage of comparable IP <> IP flows, identified in Table 1, where the TDM/FXx leg of the call can be approximated as a G.711 non-encrypted SIP leg from a media services perspective. By way of

For example, assume the case of in an  TDM/FXx – ↔ IP flow , where encryption on the IP media flow is required with the selection of the G.729ab .codec:

• Follow the first data row in table 1 from the first cell all the way to the end; the last cell represents the intersection of an IP – ↔ IP call, with G.711 with no encryption being coded to a G.729ab media flow with encryption;
• Next, multiply the value in the cell (1.31 DSP resources) by 50% to achieve a the DSP resource consumption requirement value of 0.66.

Note the preceding calculation scheme assumes VAD on (60% silence during call), RTCP on, RFC2833 on, and 20ms packet size for all codecs (except 30ms for G.723.1), G.722.2 at 12.65 kbit/s, RTP(unless specified with SRTP ), and standard Line Echo Canceller.

SBC 1000 Configurations and the DSP Resource-to-DSP SKU Mapping

The SBC 1000 Release 6.1 customer-orderable SKUs are pre-populated with DSP physical resources to support calls that require media services. Depending upon the configuration, the SBC 1000 features one, two, or three DSPs (Digital Signal Processors). The mapping of available DSP resources to available DSPs is presented in the following table:

For the list of available customer-orderable SKUs and available DSPsand the number of DSPs within a given SKU, please contact your Sonus sales representative, or refer to the Partner Configurator.

Calculating DSP Resource Requirement

Follow these steps to determine the appropriate configuration and the number of DSPs you will need.

1. Determine the number of IP -↔ IP sessions you need. Be sure to consider future growth.
2. Determine the IP -↔ IP DSP multiplication factor from the appropriate table above.
3. Multiply the IP -↔ IP session count with the multiplication factor to get your DSP resource requirement number.
4. Repeat steps 1-3 for different IP -↔ IP session scenarios to be used in this unit at a given time.
5. Determine the number of TDM -↔ IP ↔ sessions you need.
6. For simultaneous TDM and IP usage, add all DSP resources from steps 3 and 5, otherwise pick the larger DSP resource requirement of the two.
7. If using multiple low-bit rate codecs, apply 20% uplift to the DSP resource requirement number calculated in step 9.
8. Refer to the Number of DSPs to DSP Resource Mapping mapping table to determine how many DSPs will be needed to support your needs.

Example 1 - Calculating the DSP resource requirement for a simple low density IP ↔ IP

deployment

1. 1. I need 15 IP
-
2. 1. ↔ IP sessions.
   2. I want to transcode from G.711 (SRTP) to G.729ab. My multiplication factor is 1.31; therefore, my IP
-
3. 1. ↔ IP DSP resource requirement number is 15 * 1.31 = 20 (round up from 19.65). I don't need another low-bit rate codec beyond G.729ab ; as such, no 20% uplift is required.
   2. I also want 4 FXS
–
4. 1. ↔ IP sessions, where the media on the IP legs will be encoded as G.729ab and encrypted. From table 1, the multiplication factor is 1.31*50%, or 0.66; therefore, my IP
-
5. 1. ↔ IP DSP resource requirement number is 2 * 0.66 = 2 (round up from 1.31).
   2. Simultaneous usage – total DSP resource requirement is 20 + 2 = 22.
   3. Based on the mapping table, I can select any SBC 1000 customer-orderable SKU (as all SKUs feature at least one DSP, with a minimum available 64 DSP resources) with 4 FXS ports.

Example 2 - Calculating the DSP resource requirement for a medium density

IP ↔ IP & TDM - IP deployment

1. 1. I need 30 IP
-
2. 1. ↔ IP sessions and 60 TDM
–
3. 1. ↔ IP sessions (TDM flows across 2 E1 ISDN Primary Rate Interface links).
   2. Regarding the IP
–
4. 1. ↔ IP sessions, I want to transcode from G.711 (SRTP) to/from G.722 (SRTP). My multiplication factor is 1.95, and as such my IP
-
5. 1. ↔ IP DSP resource requirement number is 30 * 1.95 = 57 (round up from 56.5). Furthermore, no 20% uplift is required as we do not have multiple low bit rate codecs in the expected IP
–
6. 1. ↔ IP flows.
   2. Regarding the TDM
–
7. 1. ↔ IP flows, I also want 60 TDM to/from IP sessions, where the media on the IP legs will be encoded as G.722 and encrypted. From table 1, the multiplication factor is 1.95*50%, or 0.98; therefore, my IP
-
8. 1. ↔ IP DSP resource requirement number is 60 * 0.98 = 59 (round up from 58.8).
   2. Simultaneous usage: total DSP resource requirement is 59 + 57 = 116.
   3. Based on the mapping table, I can select any SBC 1000 customer orderable SKU that features a minimum of 2 DSPs and 2 PRI links

Example 3 - Calculating the DSP resource usage possible in a high capacity IP ↔ IP

deployment

1. 1. I need to support a maximum
#
2. 1. number of IP
-
3. 1. ↔ IP sessions with the following call flows: G.723.1 RTP (i.e. non-encrypted) on one leg of the call that is transcoded to either G.723.1 SRTP (encrypted) or G.711 SRTP on the 2nd leg of the call. I am attempting to determine the maximum number of calls I can support.
   2. I have purchased an SBC 1000 with 3 DSPs (i.e. 192 DSP resources available across the three DSPs).
   3. The multiplication factor for the selected codec flow is 2.21 (worst case multiplication factor, if all calls are both to & from G.723.1). Furthermore, a 20% uplift is required as we may have multiple low bit rate codecs (G.723.1
–
4. 1. ↔ G. 723.1) in the expected IP
–
5. 1. ↔ IP flows. As such, the true multiplication factor is 2.64
   2. The simultaneous maximum number of calls subject to DSP intervention, worst case (G.723.1
–
6. 1. RTP ↔ G.723.1 SRTP), that may be supported across the system is 192 DSP resources divided by 2.64 = 72 (rounded down from 72.5).
   2. The simultaneous maximum number of calls subject to DSP intervention, best case (all calls G.723.1 RTP to/from G.711 SRTP), that may be supported across the system is 192 DSP resources divided by 1.53 = 126 (rounded down from 126.3). The 1.53 multiplication factor was derived from table 1, and includes no uplift for multiple low bit rate codecs.

For clarity, please note an SBC 1000 (Release 6.1 and later hardware) can always support 192 total calls. Points 4 and 5 merely identify the maximum simultaneous quantity of calls that are subject to DSP intervention; additional calls are supported when running in direct media or RTP proxy mode.

Considerations for DSP Mode versus RTP Proxy

Mode

RTP Proxy was introduced on the Sonus SBC 1000 and Sonus SBC 2000 with Release 3.1. In the case of RTP Proxy media passes through the SBC and (media pass-though), media passes through the 

• DSPs convert between media types (codecs, packet size, SRTP, in-band/out of band, etc.).
• Media pass-through calls are not processed by the DSP. Hence, there is no conversion.
• Signaling groups can be configured to use either use a DSP mode or a media pass-through mode.
• In addition beginning with Release 4.0, one can also set a preference where Preference can be set so that either DSP mode or media pass-through mode is preferred, but not required.
• In the case If media pass-through is configured as preferred by both signaling groups, the call proceeds using media pass-through.
• In the case If DSP Mode is configured as preferred by both signaling groups, the call proceeds in DSP mode.
• In the case If one signaling group is configured as DSP mode preferred, and the other signaling group is configured as media pass-through mode preferred, the selection of mode is based on the preference of the signaling group associated with the party initiating the call. In the case If DSP mode is preferred but there is no available resource for the initiating party, the initiating party will fall back to attempt the call using media pass-through mode.
• After a media path is established between the phone and the SBC 1000 or SBC 2000 the 

  Spacevars
  0 product

  in either DSP mode or media pass-through mode, there is no support for a mid-call dynamic switch to change mode , – this includes the case of call transfer and conference. This is not necessarily a limitation. It simply means that the network deployment/architecture needs to be understood.
• In the case If DSP is preferred but not required: If , and if the other signaling group is configured for media pass-through only, the call then goes through using media pass-through. The advantage this provides is that we can potentially better preserve better preservation of the DSP resource for those calls where the resource is truly needed. However, it is again important to keep in mind that there is no support for a mid-call dynamic switch to change mode, this includes the case of call transfer and conference. This is not necessarily a limitation. It simply means that the network deployment/architecture needs to be understood.

• If DSP mode is either required or preferred and a media pass-through route is not possible, the SBC must have an available DSP resource. Otherwise the call will fail.

Considerations for FAX

• Fax pass-through is defined as G.711 with silence suppression turned off and, depending on the speed of the fax, echo cancellation may also be automatically turned off.
• Call When a call comes in TDM SBC via TDM, the 

  Spacevars
  0 product

  terminates the TDM. Once After the fax tones are detected the SBC ensures the call is negotiated to either fax pass-through or T.38 based on SBC configuration and far-end capabilities. T.38 is more reliable than fax pass-through and also uses less bandwidth. However, in some cases the far end may not support T.38.
• The signaling group can be associated with either T.38 or fax pass-through. T.38 can also be configured to fallback to fax pass-through.
• If the call is IP-to IP configuration calls can be either DSP mode or media pass-through mode. The use case for DSP mode is if there is a incompatibility in the network that requires the SBC

  Spacevars
  0 product

  to perform translation between T.38 and fax pass through..38 and fax pass-through.
• Super Group 3 ↔ Super Group 3 faxes can With Release 4.0 SG3 to SG3 fax reliability has been substantially improved. SG3 to SG3 faxes can now be transmitted using T.38. (The speed of the fax remains that of G3 but the transmission will be T.38.)

Considerations for DTMF

There are several alternatives for DTMF calls:

• Call comes in TDM SBC as TDM. The 

  Spacevars
  0 product

  terminates the TDM and transmits G.711. Other codec types may also be used. However, some such as G.723.1 may be less reliable.
• Call comes in TDM SBC as TDM. The 

  Spacevars
  0 product

  terminates the TDM and transmits the signal out of band RFC 2833/4733 or out of band using the INFO message.

• The signaling group can be associated to transmit in band as voice, RFC 2833/4733, or INFO. There is no fallback function.

• In the case of media pass-through mode the DSP does not process the DTMF.