This document describes how to identify the required vCPU and RAM resources for an SBC SWe Lite to process planned SIP-based traffic models.
Purpose
This document is intended to help partners and customers accomplish one of the following goals:
• Identify the number of media sessions requiring manipulation supported by a given vCPU and RAM configuration of an SBC SWe Lite;
• Identify the number of vCPU and RAM resources to be provisioned to an SBC SWe Lite to address a given number of media sessions requiring manipulation.
Both goals support a partner/customer's effort to ensure traffic processing expectations are met in a given SBC deployment.
How To Use This Document
This document is intended to be used offline by Sonus customers to help select an SBC SWE Lite configuration instance that includes an appropriate quantity of vCPU and RAM resources to support a given density of call sessions subject to media intervention. The available SBC SWe Lite configurations (i.e. "Partner Configurator"), which includes a description of embedded features and options, is available behind the partner portal.
Terminology
| Term | Definition |
|---|---|
| Default Media Manipulation Scenario | A basic IP ↔ IP media manipulation for the SBC SWe Lite is G.711 (RTP) ↔ G.729ab (SRTP). This is considered as the default media manipulation scenario for SBC SWe Lite when calculating vCPU and RAM resource requirements. |
| Media Manipulation | The action taken by virtual DSP (Digital Signal Processor) logic within the SBC SWe Lite on a bi-directional media session to accomplish some form of intended media manipulation such as translation of media from one codec to another, encrypting/decrypting media, and in-band tone detection. |
| Media Session | A bi-directional flow of audio, video, or other real-time information (such as FAX) between two endpoints that may or may not directly subtend the SBC. |
| RAM | Random Access Memory. Refer to https://en.wikipedia.org/wiki/Random-access_memory. For SBC SWe Lite planning, RAM requirements are always presented in integer GB multiples (Gigabyte, or 1,000,000,000 bytes). |
| vCPU | Refer to https://www.quora.com/What-is-the-difference-between-a-core-a-virtual-CPU-and-a-thread. For SBC SWe Lite planning, vCPU requirements are always presented in integer GB multiples (Gigabyte, or 1,000,000,000 bytes). |
Concepts
| Concept | Definition |
|---|---|
| Direct Media Mode Sessions | A media session that does not flow through the SBC SWe Lite. These flows are common with endpoints that reside within the same physical premises (such as a single branch office) where there is no need for any manipulation of any aspect of the media flow (such as codecs, headers, and encrypting/decrypting) The implications of such sessions on the SBC SWe Lite are: 1. The SBC SWe Lite does not consume any RAM or vCPU resources processing the direct media mode sessions. 2. Partners/customers do not need to consider direct media mode sessions when determining an appropriate vCPU and RAM assignment to a given SBC SWe Lite. |
| Licensing | The SBC SWe Lite supports a single media session on a 1:1 basis with an associated SIP signaling session. Note the following: • The SBC SWe Lite requires a license to enable a given quantity of SIP signaling sessions. • A direct media mode session will be supported without any additional licensing licensing beyond the corresponding SIP session license. Refer to Obtaining and Installing a SWe Lite License for a description of available SBC SWe Lite session and feature licenses. |
| RTP Proxy Media Mode Sessions | A media session that flows through the SBC SWe Lite but does not require media manipulation. These flows may be common with endpoints that may not reside within the same physical premises, but do reside within the same enterprise. If these sessions require access to a public SIP trunk (call flows out of the corporate WAN), there may be a need for encryption/decryption and IP address manipulation services, as many public carriers do not support the forwarding of encrypted media or private IP addresses. However, complex media manipulation such as transcoding will not be required due to enterprise-wide policies surrounding codec usage being in force. The implications of such sessions on the SBC SWe Lite are: 1. The SBC SWe Lite consumes RAM and vCPU resources processing the RTP proxy media mode sessions |
| RTP Proxy Media Mode Sessions – Licensing | As mentioned previously, the SBC SWe Lite supports a single RTP proxy media mode session on a 1:1 basis with an associated SIP signaling session. Note the following regarding RTP proxy media mode session: • An RTP proxy media mode session will be supported without any additional licensing beyond the corresponding SIP session license if encryption/decryption services are not required. Services the SBC is capable of applying to such media streams include: • The modification of IP address and other data within the S/RTP, UDP, IP and other header data as provisioned by the user
• An RTP proxy media mode session that requires the SBC support RTP ↔ SRTP conversions Other considerations: |
| Media Manipulation Mode Sessions | A media session that requires media manipulation is considered a media manipulation mode session. These flows are common with endpoints that could communicate across enterprise and public boundaries. The common call types that require media manipulation services include the following (this not an exhaustive list):
a) In-band DTMF tone detection interworking with out of band SIP INFO messages 5. Jitter compensation to maximize user experience with voice quality • G.711 announcements /* what is this ... same as MoH? */
1. The SBC SWe Lite consumes RAM and vCPU resources processing media manipulation mode sessions |
| Media Manipulation Mode Sessions – Licensing | The SBC SWe Lite supports a single media manipulation mode session on a 1:1 basis with an associated SIP signaling session. Note the following regarding licensing implications: • A media manipulation mode session requires additional licensing beyond the corresponding SIP session license. Refer to the section above for an example of services available with a media manipulation mode-related license. • A media manipulation mode session supports encryption/decryption services. Encryption/decryption services means: • An RTP proxy media mode session that requires that the SBC support RTP ↔ SRTP conversions. Other considerations: • Multiple media manipulation mode session streams (such as audio) may be associated with a given SIP session, and will not require additional licensing unless identified elsewhere. |
Session Density Map
The following table presents a guide to partners and customers regarding the maximum capacity of:
- Media manipulation mode sessions
- RTP proxy session mode sessions requiring encryption/decryption services
- RTP proxy session mode sessions not requiring encryption/decryption services
- Direct media mode sessions supported with a given vCPU and RAM resource assignment
...on an example SBC SWe Lite.
The table will be used extensively to identify and plan the required resource configuration for a given deployment of an SBC SWe Lite to address a partner/customers expected SIP traffic flow.
Session Density Map
Number of vCPUs | Amount of RAM | Number of Registrations | Total Number of Allowed Calls | Number of proxy calls only
| Number of DSP calls:Proxy (G.711 a/u law RTP/SRTP<=> G.729 A/B/AB RTP/SRTP) |
|---|---|---|---|---|---|
| 1 | 1 GB | 1000 | 100 | 100 | 50:50 |
| 2 | 2 GB | 5,000 | 1,000 | 1,000 | 100:900 |
| 4 | 4 GB | 5,000 | 1,000 | 1,000 | 300:700 |
Determining vCPU and RAM Requirements
Follow these steps to determine the number of vCPUs and RAM required for your SBC SWe Lite deployment.
- Determine the number of media manipulation mode sessions needed (taking into account future growth): From Table 3, identify the required *minimum* quantity of vCPUs and RAM to address your required capacity, and then record the values.
- Determine the additional RTP proxy session mode sessions requiring encryption/decryption services for your SBC SWe Lite deployment (taking into account future growth):
Step Action a From Table 3, identify the available RTP proxy session mode session capacity (with encryption/decryption services) available with the quantity of of vCPUs and RAM recorded from Step 1. b Determine if the available RTP proxy session capacity from (a) above is larger than your required capacity of additional RTP proxy session mode sessions requiring encryption/decryption services:
If... Then Capacity from (a) is larger Proceed to step 3, using the quantity of vCPUs and RAM determined from point 1 above. Capacity from (a) is smaller Review Table 3 and increase the quantity of vCPUs and RAM until you arrive at a quantity of both that supports an RTP proxy session capacity (with encryption/decryption services) equal to/greater than your required numer of sessions. Record these values. Determine the additional RTP proxy session mode sessions not requiring encryption/decryption services for your SBC SWe Lite deployment (taking into account future growth):
Step Action a From Table 3, identify the total number of media sessions available with the quantity of of vCPUs and RAM recorded from point 2(a) or 2(b) above. b Add the number of required media manipulation mode sessions and RTP proxy session mode sessions requiring encryption/decryption services and record the value. c Subtract the value recorded in 3(b) from the value recorded in 3(a).
d Determine if the value in (c) above is greater than/equal to the required additional RTP proxy session mode sessions not requiring encryption/decryption services for your SBC SWe Lite deployment. If... Then The value in (c) above is greater than/equal to Proceed to step 4, using the quantity of vCPUs and RAM determined from point 3(a) above. The value in (c) above is less than Review Table 3 and increase the quantity of vCPUs and RAM and repeat Steps 3(a) through 3(c) until you arrive at a quantity of both that supports an overall session capacity greater than your total required number of sessions across all modes. Record these vCPU and RAM values. - Prepare to configure your SBC SWe Lite with the required number of vCPUs and RAM by referring to the /* ADD LINK TO PROVISIONING THE SWE LITE WITH A GIVEN CPU AND RAM */
Examples
Calculating the DSP Resource Requirements for a Low-Density SBC SWe Lite Deployment
1. I need 15 media manipulation mode sessions (sessions will be equivalent to the Default Media Manipulation Scenario defined above). From Table 3 I see a single vCPU and 1 GB of RAM will support this capacity. I record these values as the potential number of vCPU and RAM resources to assign to my SBC SWe Lite.
2. I need 35 additional RTP proxy session mode sessions requiring encryption/decryption services. From Table 3 I see a single vCPU and 1 GB of RAM will support up to 50 RTP proxy session mode sessions requiring encryption/decryption services alongside a maximum of 50 media manipulation mode sessions. I continue to use the number of vCPU and RAM resources from point 1 to assign to my SBC SWe Lite.
3. I need 50 additional RTP proxy session mode sessions not requiring encryption/decryption services.
(a) From Table 3, I see a single vCPU and 1 GB of RAM will support up to 100 total sessions.
(b) The sum from adding the required media manipulation mode sessions plus RTP proxy session mode sessions requiring encryption/decryption services is 50.
(c) The difference from subtracting 3(b) from 3( a) results in 50 sessions.
(d) As 3(c) is equal to the 50 RTP proxy session mode sessions not requiring encryption/decryption services, I continue to use the number of vCPU and RAM resources determined from point 2 above to assign to my SBC SWe Lite.
Calculating the DSP Resource Requirements for a High-Density SBC SWe Lite Deployment
1. I need 100 media manipulation mode sessions (sessions will be equivalent to the Default Media Manipulation Scenario defined above). From Table 3, I see two vCPU and 2 GB of RAM will support this capacity. I record these values as the potential number of vCPU and RAM resources to assign to my SBC SWe Lite.
2. I need 400 additional RTP proxy session mode sessions requiring encryption/decryption services. From Table 3, I see a two vCPU and 2 GB of RAM will support up to 700 RTP proxy session mode sessions requiring encryption/decryption services alongside a maximum of 100 media manipulation mode sessions. I continue to use the number of vCPU and RAM resources from point 1 to assign to my SBC SWe Lite.
3. I need 500 additional RTP proxy session mode sessions not requiring encryption/decryption services.
(a) From Table 3, I see a two vCPU and 2 GB of RAM will support up to 1000 total sessions.
(b) The sum of adding the required media manipulation mode sessions and RTP proxy session mode sessions requiring encryption/decryption services is 500.
(c) The difference from subtracting 3( b) from 3(a) is 500 sessions.
(d) As 3(c) is equal to the 500 RTP proxy session mode sessions not requiring encryption/decryption services, I continue to use the number of vCPU and RAM resources determined from point 2 above to assign to my SBC SWe Lite.
Considerations for Media Manipulation Session Mode versus RTP Proxy Session Mode
SIP Signaling Group Considerations
SIP Signaling groups (provisioning constructs that represent a connection between the SBC SWe Lite and another SIP based peer) can be configured to use either media manipulation session mode or a RTP proxy session mode. Note the following:
• Preference can be set so that either media manipulation session mode or RTP proxy session mode is preferred, but not required.
• If RTP proxy session mode is configured as preferred by both signaling groups, the call proceeds using RTP proxy session mode.
• If media manipulation session mode is configured as preferred by both signaling groups, the call proceeds in media manipulation session mode.
• If one signaling group is configured as media manipulation session mode preferred, and the other signaling group is configured as RTP proxy session mode preferred, the selection of mode is based on the preference of the signaling group associated with the party initiating the call. If media manipulation session mode is preferred but there is no available resource for the initiating party, the initiating party will fall back to attempt the call using RTP proxy session mode.
• After a media path is established between the SIP client and the SBC SWe Lite in either media manipulation session mode or RTP proxy session 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. It simply means that the network deployment/architecture needs to be understood.
• If media manipulation session mode is preferred but not required, and if the other signaling group is configured for RTP proxy session mode only, the call goes through using RTP proxy session mode. This improves preservation of the media manipulation session mode resource for calls which require the resources most. However, keep in mind that there is no support for a mid-call dynamic switch to change mode, including the case of call transfer and conference. This is not necessarily a limitation. This also emphasizes the importance of understanding the network deployment/architecture.
• If media manipulation session mode is either required or preferred and a RTP proxy session mode route is not possible, the SBC must have an available media manipulation session mode resource; otherwise, the call will fail.
Considerations for FAX
• Fax pass-through is defined as G.711 with silence suppression turned off. Echo cancellation may also be automatically turned off depending on the speed of the fax transmission.
• When a fax call is received, the SBC SWe Lite terminates the call. 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. /* Neel is this right ? */
• The signaling group can be associated with either T.38 or fax pass-through. T.38 can also be configured to fall back to fax pass-through.
• SBC SWe Lite media sessions operate in either media manipulation session mode, RTP proxy session mode, or direct media session mode. Media manipulation session mode is used when there is a incompatibility in the network that requires the SBC SWe Lite to perform translation between T.38 and fax pass-through. /* Neel is this right ? */
• Super Group 3 ↔ Super Group 3 faxes can be transmitted using T.38 (G3 fax speed with T.38.) /* Neel is this right ? */
Considerations for DTMF
There are several alternatives for DTMF calls:
• When a DTMF call is received, the SBC SWe Lite terminates the call and transmits G.711. Other codec types may also be used. However, types such as G.723.1 may be less reliable.
• When a DTMF call is received, the SBC SWe Lite terminates the call and transmits the signals as out-of-band RFC 2833/4733 compliant messages or out-of-band SIP INFO messages.
• A signaling group can be provisioned to transmit in-band signals as voice, RFC 2833/4733, or SIP INFO messages. There is no fall back function.
• In the case of RTP proxy session mode, the SBC SWe Lite does not process the DTMF.
Overview
Content Tools