In this section:
This document describes how to determine vCPU and RAM resources required for an
This document is intended to help partners and customers who employ a VM (Virtual Machine) hosting an instance of the SBC SWe Lite:
• Identify the number of media sessions requiring manipulation supported by a given vCPU and RAM configuration of an
Both goals support a partner/customer's effort to ensure traffic processing expectations are met in an
The available
Term | Definition |
---|---|
Default RTP Media Manipulation Mode Scenario | A bi-directional IP-based RTP ↔ RTP media manipulation mode session scenario for the Unable to show "metadata-from": No such page "_space_variables" is G.711 (RTP) ↔ G.729ab (SRTP). This is considered as the default media manipulation scenario when calculating vCPU and RAM resource requirements. |
RTP Media Manipulation | The action taken by virtual DSP (Digital Signal Processor) logic within the Unable to show "metadata-from": No such page "_space_variables" 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, in-band tone detection, enhanced interoperability, improved user experience, and other media-related services that require direct access to the media flow and information. |
RTP 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 Random Access Memory. For Unable to show "metadata-from": No such page "_space_variables" planning, RAM requirements are always presented in integer GiB multiples (https://en.wikipedia.org/wiki/Gibibyte ). |
vCPU | Refer to https://www.quora.com/What-is-the-difference-between-a-core-a-virtual-CPU-and-a-thread. For Unable to show "metadata-from": No such page "_space_variables" planning, vCPU requirements are always presented in integer vCPU multiples. |
A media session that does not flow through the
The
• The
• A direct media mode session will be supported without any additional licensing licensing beyond the corresponding SIP session license.
• Multiple direct media mode session streams (audio, video, and so on) may be associated with a given SIP session, and will not require additional licensing unless identified elsewhere.
• Only one mode of media is supported against a given SIP session. For example, you cannot have one stream of media in direct media mode, one stream of media in RTP proxy media mode, and both associated with the same SIP signaling session.
Refer to Obtaining and Installing a SWe Lite License and Working with Licenses or a description of available
A media session that flows through the
1. The
The
• 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
• The pass-through of encrypted media traffic (SRTP ↔ SRTP) where no change is required to the previously applied encryption
• An RTP proxy media mode session requiring encryption/decryption services will require additional licensing beyond the corresponding SIP session license. Encryption/decryption services means:
• An RTP proxy media mode session that requires the SBC support RTP ↔ SRTP conversions
• An RTP proxy media mode session that requires SRTP ↔ SRTP changes, such as a cipher change, and authentication algorithm change as the media flow transits the SBC
Other considerations:
• Multiple RTP proxy media mode session streams (audio, video, and so on) may be associated with a given SIP session, and will not require additional licensing unless identified elsewhere
• Only ONE mode of media is supported against a given SIP session; for example, you cannot have one stream of media in direct media mode, one stream of media in RTP proxy media mode, both associated with the same SIP signaling session
Refer to Obtaining and Installing a SWe Lite License and Working with Licenses for a description of available
A media session requires media manipulation is considered a media manipulation mode session. Such flows may be common with endpoints that may communicate across enterprise and public boundaries. The common call types that require media manipulation services include the following (not an exhaustive list):
The implications of media manipulation mode sessions on the
The
• 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 manipulation mode session that requires that the SBC support RTP ↔ SRTP conversions.
• An RTP proxy media manipulation mode session that requires SRTP ↔ SRTP changes, such as a cipher change, authentication algorithm change, and so on as the media flow transits the SBC.
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.
• Only one mode of media is supported against a given SIP session. For example, you cannot have one stream of media in media manipulation mode session mode, one stream of media in RTP proxy media mode, both associated with the same SIP signaling session.
Refer to Obtaining and Installing a SWe Lite License and Working with Licenses for a description of available
The table below is a guide to the maximum capacity of an
The table will be used extensively to identify and plan the required resource configuration for a given deployment of an
Session Density Map
SWe Lite Virtual Machine Resources, applicable to all supported hypervisors (KVM, VMware®) | Maximum SIP with corresponding RTP Sessions | SIP Signaling Sessions | RTP Media Sessions | ||||||||||
RTP Media Manipulation Mode (transcode, in-band services, encryption, and other services) | RTP Proxy Media Mode | Video Streams² | |||||||||||
vCPU # | GiB RAM | Maximum TCP/TLS-based SIP Signaling Sessions | Maximum SIP Registrations (60 minute refresh rate) | No transcode, with in-band services scenario | Default transcode scenario: G.711/G.729ab RTP ↔ G.729ab/G.711 SRTP, with in-band services | Complex transcode scenario: G.7xx RTP ↔ G.7xx SRTP, with in-band services¹ | Encryption services: G.711 RTP ↔ G.711 SRTP, with or without RTP/UDP/IP header changes | No encryption services: RTP proxy media mode, including RTP↔RTP, SRTP↔SRTP, with or without RTP/UDP/IP header changes | |||||
1 | 1 GiB | 100 | 100 | 1,000 | 50 | 50 | 50 | 100 | 100 | 25 | |||
2 | 1.5 GiB | 1,000 | 1,000 | 5,000 | 100 | 100 | 100 | 1,000 | 1,000 | 50 | |||
4 | 2.5 GiB | 1,000 | 1,000 | 5,000 | 300 | 300 | 300 | 1,000 | 1,000 | 100 |
¹G.722 (AMR) reduces values by 30%.
²SWe Lite supports 25 video streams per vCPU to a maximum of 100 streams. Exceeding 4 vCPUs will not allow more than 100 video streams.
Follow these steps to determine the number of vCPUs and RAM required for your
Determine the number of RTP 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
Step | Action | ||||||
---|---|---|---|---|---|---|---|
a | From Table 3, identify the maximum 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 maximum 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:
|
Determine the additional RTP proxy session mode sessions not requiring encryption/decryption services for your
Step | Action | ||||||
---|---|---|---|---|---|---|---|
a | From Table 3, identify the total number of RTP media sessions available with the quantity of vCPUs and RAM recorded from point 2(a) or 2(b) above. This value can be found in the Maximum SIP with corresponding RTP Sessions column. | ||||||
b | Add the number of required RTP 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 Unable to show "metadata-from": No such page "_space_variables" deployment.
|
1. I need 15 RTP 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 GiB of RAM will support this capacity. I record these values as the potential number of vCPU and RAM resources to assign to my
(a) From Table 3, I see a single vCPU and 1 GiB of RAM will support a maximum of 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
1. I need 100 RTP media manipulation mode sessions (sessions will be equivalent to the RTP Default Media Manipulation Scenario defined above). From Table 3, I see 2 vCPU and 1.5 GiB of RAM will support this capacity. I record these values as the potential number of vCPU and RAM resources to assign to my
2. I need 400 additional RTP proxy session mode sessions requiring encryption/decryption services. From Table 3, I see 2 vCPU and 1.5 GiB of RAM will support up to 1,000 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
3. I need 500 additional RTP proxy session mode sessions not requiring encryption/decryption services.
(a) From Table 3, I see 2 vCPU and 1.5 GiB of RAM will support up to 1,000 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 (2 vCPUs, 1.5 GiB RAM) determined from point 2 above to assign to my
The required vCPU and RAM for a high capacity SIP Registration deployment are relatively simple: if the number of SIP registrations exceeds 1,000 endpoints, please configure the VM with a minimum of 4 vCPUs and 2.5 GiB RAM. If less/equal to 1,000, the RAM is defined by the required session capacity.
SIP Signaling groups (provisioning constructs that represent a connection between the
• 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
• 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
There are several alternatives for DTMF calls:
• When a DTMF call is received, the
• When a DTMF call is received, the
• 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
SWe Lite supports 25 video streams per vCPU to a maximum of 100 streams. Exceeding 4 vCPUs will not allow more than 100 video streams.