Introduction
For DSP consumption associated with older versions of hardware, refer to the appropriate release documentation on the Ribbon Documentation Portal.
Purpose
This guide is intended to help partners and customers 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 SBC Edge to satisfy call deployment requirements.
How to Use This Guide
This guide is intended to be used by Ribbon customers to help select a SBC Edge configuration instance that includes an appropriate quantity of DSP resources to support a given density of call sessions subject to DSP-related media intervention.
Definitions and Terminology
Transcoding: The action taken by a DSP (Digital Signal Processor) within a physical SBC Edge on a bi-directional media session to accomplish some form of intended media manipulation (e.g. translation of media from one codec to another, encrypting/decrypting media, etc.)
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: A DSP resource is a unit of DSP processing required to transcode from one codec to another. For the SBC 1000, one DSP resource is equivalent to the processing ability associated with 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: If two or more low-bit rate codecs (G.729ab, G.723.1, G.726, or T.38) are used (IP ↔ IP and/or TDM/IP), a 20% uplift is applied to the DSP resource requirement number.
Example: Two or more low-bit-rate codecs are used.
DSP Resource Requirement | 100 |
Plus 20% Uplift | 20 |
True DSP Resource Requirements | 120 |
- 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: Value derived from Table 1.
DSP Mode: Implies a session that is to be acted upon by the DSPs; i.e., a session requiring media services.
RTP Proxy Mode: A session that is not subject to DSP services but flows through the SBC Edge for non-media intervention purposes (e.g., IP headers being modified for revised network addressing, etc.) is considered a session
Direct Media Mode: A session and does not flow through, the SBC Edge is considered a session running in Direct Media mode. mode do not use any SBC Edge media processing resources including DSP resources.
DSP Resource Consumption for the IP ↔ IP Operating Mode
The following table provides the multiplication factor in conjunction with the IP ↔ IP session count requirement) to help users determine the required quantity of DSP resources. The IP↔ IP operating mode is a media session, anchored by the SBC Edge, between two SIP/RTP endpoints.
An SBC Edge can support both IP ↔ IP and TDM ↔ IP modes simultaneously.
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.
SBC 1000 IP ↔ IP DSP Multiplication Factor (click to enlarge)
Note
Densities assume VAD on (60% silence during call), RTCP on, RFC2833 on, and 20 ms packet size for all codecs (except 30 ms 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 media session, anchored by the SBC Edge, between a non-SIP/RTP endpoint (e.g., an FXS client, an FXO trunk, a PRI/BRI channel, etc.) and a SIP/RTP endpoint.
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 the TDM/FXx leg of the call can be approximated as a G.711 non-encrypted SIP leg from a media services perspective.
For example, in an TDM/FXx ↔ IP flow where encryption on the IP media flow is required with the selection of the G.722.2 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 transcoded to a G.722.2 media flow with encryption;
- Next, multiply the value in the cell (2.78 DSP resources) by 50% to achieve the DSP resource requirement value of 1.39
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.
An SBC Edge can support both IP ↔ IP and TDM↔ IP modes simultaneously.
SBC 1000 Configurations and the DSP Resource-to-DSP SKU Mapping
ustomer-orderable SKUs are pre-populated with DSP physical resources to support calls that require media services. Depending upon the configuration, the SBC 1000 DSPs The mapping of available DSP resources to available DSPs is presented in the following table:
DSPs to DSP Resource Mapping
Number of DSPs | Available DSP Resources |
---|
1 | 64 |
2 | 128 |
3 | 192 |
For the list of available customer-orderable SKUs and the number of DSPs within a given SKU, please contact your Ribbon 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 .
- Determine the IP ↔ IP DSP multiplication factor from Table 1.
- Multiply the IP ↔ IP session count with the multiplication factor to obtain the DSP resource requirement number.
- Repeat steps 1-3 for different IP ↔ IP session scenarios in this unit at a given time.
- Determine the number of TDM ↔ IP sessions
- For simultaneous TDM and IP usage, add all DSP resources from steps 3 and 5; otherwise, pick the usage with the larger DSP resource requirement.
- If using multiple low-bit rate codecs, apply 20% uplift to the DSP resource requirement number calculated in step 6.
- Refer to the DSPs to DSP Resource Mapping table to determine the number of to support requirements.
- Calculating the DSP resource requirements for a simple, low-density IP ↔ IP deployment
- I need 15 IP ↔ IP sessions.
- I want to transcode from G.711 (SRTP) to G.729ab. My multiplication factor is 1.31; therefore, my IP ↔ 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.
- I also want 4 FXS ↔ 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 ↔ IP DSP resource requirement number is 2 * 0.66 = 2 (round up from 1.31).
- Simultaneous usage – total DSP resource requirement is 20 + 2 = 22.
- 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 requirements for a medium-density, IP ↔ IP and TDM ↔ IP deployment
- I need 30 IP ↔ IP sessions and 60 TDM ↔ IP sessions (TDM flows across 2 E1 ISDN Primary Rate Interface links).
- Regarding the IP ↔ 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 ↔ 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 ↔ IP flows.
- Regarding the TDM ↔ 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 ↔ IP DSP resource requirement number is 60 * 0.98 = 59 (round up from 58.8).
- Simultaneous usage: total DSP resource requirement is 59 + 57 = 116.
- 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
- I need to support a maximum number of IP ↔ IP sessions with the following call flows: G.723.1 RTP (i.e. non-encrypted) on one leg of the call to/from either G.729ab 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.
- I have purchased an SBC 1000 with 3 DSPs (i.e. 192 DSP resources available across the three DSPs).
- The multiplication factor for the selected codec flow is 2.00 (worst case multiplication factor, if all calls are G.723.1 RTP ↔ G.729ab SRTP). Furthermore, a 20% uplift is required as we may have multiple low bit rate codecs (G.723.1, G.729ab) in the expected IP ↔ IP flows. As such, the true multiplication factor is 2.40.
- The simultaneous maximum number of calls subject to DSP intervention, worst case (G.723.1 RTP ↔ G.729ab SRTP), that may be supported across the system is 192 DSP resources divided by 2.40 = 80.
Considerations for DSP Mode versus RTP Proxy Mode
In the case of RTP Proxy Mode (media pass-though), media passes through the SBC Edge but does not use DSP resources, as opposed to the DSP Mode.
- DSPs convert between media types (codecs, packet size, SRTP, in-band/out-of-band, etc.).
- Signaling groups can be configured to use either a DSP mode or a media pass-through mode.
- Preference can be set so that either DSP mode or media pass-through mode is preferred, but not required.
- If media pass-through is configured as preferred by both signaling groups, the call proceeds using media pass-through.
- If DSP Mode is configured as preferred by both signaling groups, the call proceeds in DSP mode.
- 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. 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 Edge 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 emphasizes the importance of understanding the network deployment/architecture.
- If DSP is preferred but not required, and if the other signaling group is configured for media pass-through only, the call goes through using media pass-through.
- 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
- When a call comes in via TDM, the SBC Edge terminates the TDM. 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.
- IP ↔ IP calls are either DSP mode or media pass-through mode. is a incompatibility in the network that requires the SBC Edge to perform translation between T.38 and fax pass-through.
- Super Group 3 ↔ Super Group 3 faxes can be transmitted using T.38
Considerations for DTMF
There are several alternatives for DTMF calls:
- Call comes in as TDM. The SBC Edge 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 as TDM. The SBC Edge 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 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.
DSP resource usage is unaffected within an SBC Edge product with an onboard Microsoft Skype for Business SBA or CCE. Sessions that originate from, or terminate to, the onboard SBA or CCE are treated by the SBC Edge as exactly equivalent to an off-board SBA or CCE application (analogous to a SIP server residing within its own physically separate processing environment). As such, these calls impose no requirements over and above a call to/from an off-board SIP entity.