This document shows how to determine the VM (Virtual Machine), vCPU, and RAM resources (or a VM instance for cloud-related deployments) required for an SBC SWe Edge deployment to support an enterprise's planned maximum SIP session density.
Concepts
RTP Direct Media Mode Sessions
Description
RTP direct media mode sessions do not flow through the SBC SWe Edge. 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 Edge are:
- The SBC SWe Edge does not consume a VM's RAM or vCPU resources processing the RTP direct media mode sessions; vCPU and RAM resources are consumed for SIP signaling and call processing only.
- Partners/customers do not need to consider RTP direct media mode sessions when determining a VM's vCPU and RAM resources for a given SBC SWe Edge deployment.
- Multiple direct media mode session streams (audio, video, and so on) may be associated with a given SIP session, and do not require additional licensing unless identified elsewhere.
- Only one mode of media is supported against a given SIP session. For example, one stream of media in direct media mode and one stream of media in RTP proxy media mode, cannot both be associated with the same SIP signaling session.
Licensing
The SBC SWe Edge supports a single RTP media session on a 1:1 basis with an associated SIP signaling session. Note the following:
- The SBC SWe Edge requires a SIP session license to enable a given SIP signaling session. Refer to: SIP Session Licensing.
- Any SIP session license also enables RTP direct media mode session support on a 1:1 basis with an associated SIP signaling session (i.e., no additional licensing beyond the SIP session license is required for RTP direct media mode session support).
Refer to Node-Locked Licensing - SBC 1000/2000 and SBC SWe Edge for a description of available SBC SWe Edge SIP session licenses that include support for RTP direct media mode session, as follows:
- For KVM, VMware, Microsoft Hyper-V on-premises SBC SWe Edge deployments, all SIP session licenses that end with the following characters: -SG, -SGX, -SP
- For Microsoft Azure cloud-based SBC SWe Edge deployments, all SIP session licenses that end with the following characters: -SG-CLOUD, -SGX-CLOUD, -SP-CLOUD
RTP Proxy Media Mode Sessions
Description
These flows are common with endpoints that do 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. Many public carriers do not support the forwarding of encrypted media or private IP addresses. However, complex media manipulation such as transcoding is not required due to enterprise-wide policies surrounding codec usage being in force. The implications for these sessions include:
- The SBC SWe Edge consumes a VM's RAM and vCPU resources processing the RTP proxy media mode sessions.
- Consumption of RAM and vCPU resources is less than the consumption of RAM and vCPU resources associated with RTP media manipulation mode sessions.
- RTP proxy media mode sessions must be accessed when determining a VM's vCPU and RAM resources for a given SBC SWe Edgedeployment.
- Multiple RTP proxy media mode session streams (audio, video, and so on) may be associated with a given SIP session, and do not require additional licensing unless identified elsewhere.
- Only ONE mode of media is supported against a given SIP session. For example, with one stream of media in direct media mode and one stream of media in RTP proxy media mode, both cannot be associated with the same SIP signaling session.
Licensing
The SBC SWe Edge 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 sessions:
- The SBC SWe Edge requires a SIP session license to enable a given SIP signaling session. For more information, refer to: SIP Session Licensing.
- Any SIP session license also enables RTP proxy media mode session support without encryption/decryption services on a 1:1 basis with an associated SIP signaling session (i.e. no additional licensing beyond the SIP session license is required for RTP proxy media mode session support without encryption/decryption services). The SBC applies the following:
- The modification of the 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.
- Select (not all) SIP session licenses also enable RTP proxy media mode session support with encryption/decryption services on a 1:1 basis with an associated SIP signaling session. Encryption/decryption services means:
- An RTP proxy media mode session that requires the SBC to 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.
Refer to Node-Locked Licensing - SBC 1000/2000 and SBC SWe Edge for more information about SIP session licenses that support RTP proxy media mode sessions:
- For SIP sessions requiring no support for encryption/decryption services within the context of RTP proxy media mode sessions:
- KVM, VMware, Microsoft Hyper-V on-premises SBC SWe Edge deployments, all licenses that end with the following characters: -SG, -SGX, -SP
- Microsoft Azure cloud-based SBC SWe Edge deployments, all licenses that end with the following characters: -SG-CLOUD, -SGX-CLOUD, -SP-CLOUD
- For SIP sessions requiring support for encryption/decryption services within the context of RTP proxy media mode sessions:
- KVM, VMware, Microsoft Hyper-V on-premises SBC SWe Edge deployments, all licenses that end with the following characters: -SGX, -SP
- Microsoft Azure cloud-based SBC SWe Edge deployments, all licenses that end with the following characters: -SGX-CLOUD, -SP-CLOUD
RTP Media Manipulation Mode Sessions
Description
A media session requiring media manipulation is labeled an RTP media manipulation mode session. Such flows are common with endpoints that communicate across enterprise and public boundaries. The SBC SWe Edge delivers RTP media manipulation services through the application of virtual DSP (Digital Signal Processing) feature to the media session. The media manipulation services delivered by the SBC SWe Edge include:
-
- Transcoding. This includes G.711 (common codec in enterprises) ↔ G.729ab (common codec in public networks) translation, and G.711 A-law ↔ G.711 µ-law. Refer to Protocols and Protocols and Functions Supported for the list of codecs.
- Transrating. Transrating includes call legs that carry a different time sample size of media, where the SBC SWe Edge performs the translation. Transrating is used often when enterprises or the service provider is looking to save bandwidth by reducing packet count at the expense of voice quality (should a packet be dropped).
- Silence suppression. The SBC SWe Edge looks to remove/insert RTP packets carrying no meaningful media to save packet traffic.
- Fax calls.
- Fax tone detection and interworking to T.38
- G.711 fax media pass-through, as DSP intervention reduces the likelihood of in-band fax signaling/media issues
- In-band ↔ out-of-band interworking. Required for the following:
- In-band DTMF tone detection interworking with out-of-band RFC 4733 (supersedes RFC 2833)
- In-band DTMF tone detection interworking with SIP INFO messages
- Interworking RTP dynamic payload types, required when the subtended SBC peers use differing payload type identifiers from the dynamic RTP payload range (for example 96 - 127) to identify a common payload format (in other words, codec)
- Media that originates from the SBC in support of call developments. For example:
- Announcement playback
- Local ringback tone
- Music on Hold
- Comfort noise
- Jitter compensation. Used to maximize user experience with voice quality.
- Certified Skype for Business/Teams Phones and Devices interworking with non-certified endpoints. With virtual DSP intervention, SBC SWe Edges can address media incompatibility issues between certified Skype for Business Server endpoints (Refer to https://technet.microsoft.com/en-us/office/dn947482) and other SIP-based client endpoints, such as RTCP reporting interval mismatch, and unrecognized in-band supplementary service requests.
The implications of RTP media manipulation mode sessions are the following:
- The SBC SWe Edge consumes VM RAM and vCPU resources to deliver RTP media manipulation services via the virtual DSP feature.
- Consumption of a VM's RAM and vCPU resources is higher when delivering RTP media manipulation services than the consumption of RAM and vCPU resources associated with RTP proxy media mode services.
- Consider RTP media manipulation mode session density to determine a VM's vCPU and RAM resources for a specific SBC SWe Edge.
RTP Media Manipulation Mode - Notes
- The virtual DSP (within the context of an RTP media manipulation mode session) supports complete encryption/decryption services, such as RTP ↔ SRTP conversions, cipher change, & authentication algorithm change.
- Multiple RTP media manipulation mode session streams (audio, video, and so on) may be associated with a given SIP session, and do 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 RTP media manipulation mode, one stream of media in RTP proxy media mode, both associated with the same SIP signaling session.
Licensing
The SBC SWe Edge supports a single RTP media manipulation mode session on a 1:1 basis with an associated SIP signaling session. See below.
- The SBC SWe Edge requires a SIP session license to enable a given SIP signaling session. Refer to SIP Session Licensing.
- Select (not all) SIP session licenses also enable RTP media manipulation mode session support on a 1:1 basis with an associated SIP signaling session.
Refer to Node-Locked Licensing - SBC 1000/2000 and SBC SWe Edge for a description of available SBC SWe Edge SIP session licenses that include support for RTP media manipulation mode sessions. See below.
- For SIP sessions requiring no support for transcoding and/or transrating but support for all other RTP media manipulation services:
- KVM, VMware, Microsoft Hyper-V on-premises SBC SWe Edge deployments, all licenses that end with the following characters: -SGX, -SP, -ME
- Microsoft Azure cloud-based SBC SWe Edge deployments, all licenses that end with the following characters: -SGX-CLOUD, -SP-CLOUD, -ME-CLOUD
- Amazon Web Services (AWS) cloud-based SBC SWe Edge deployments, all licenses that end with the following characters: -SGX-CLOUD, -SP-CLOUD, -ME-CLOUD
- For SIP sessions requiring support for transcoding and/or transrating over and above other RTP media manipulation services:
- KVM, VMware, Microsoft Hyper-V on-premises SBC SWe Edge deployments, all licenses that end with the following characters: -SP, -ME
- Microsoft Azure cloud-based SBC SWe Edge deployments, all licenses that end with the following characters: -SP-CLOUD, -ME-CLOUD
- Amazon Web Services (AWS) cloud-based SBC SWe Edge deployments, all licenses that end with the following characters: -SP-CLOUD, -ME-CLOUD
Session Density Map
The table below is a guide to the maximum capacity of an SBC SWe Edge configured into a VM (Virtual Machine) with a given set of vCPU and RAM resources. The maximum number of the following items vary depending upon a given VM resource profile:
- RTP 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 (not presented in the table, but equivalent to RTP proxy session mode sessions not requiring encryption/decryption services)
- SIP registrations.
Use the tables below to identify and plan the required resource configuration for a given deployment of an SBC SWe Edge to address SIP traffic flow.
Call Performance - KVM, VMware, Microsoft Hyper-V On-Premises Deployments
|
SBC SWe Edge Virtual Machine Resources, applicable to all supported hypervisors (KVM, VMware® Microsoft Hyper-V) |
Maximum SIP |
SIP Signaling Session Limits |
RTP Media Session Limits |
Maximum Call Rate Setup (CPS) |
||||||
|
Media Manipulation Mode2 (Requires Virtual DSP Intervention) |
Proxy Media Mode (No Virtual DSP Intervention) |
Audio/Video Streams3 |
||||||||
|
vCPU # |
GB RAM |
Maximum TCP/TLS-based SIP↔SIP Signaling Sessions7 |
Maximum SIP Registrations (60 minute refresh rate) |
No transcode, with in-band services scenario8 |
Default scenario: G.711/G.729ab RTP ↔ G.729ab/G.711SRTP, with in-band services9 |
Encryption services: G.711 RTP ↔ G.711 SRTP8 |
No encryption services: RTP ↔ RTP/SRTP ↔ SRTP10 |
|||
|
1 |
1.5 GiB |
100 |
300 |
1000 |
100 |
100 |
3006 |
3006 |
25 |
10 |
|
2 |
2 GiB |
1000 |
1000 |
1000 |
200 |
200 |
10006 |
10006 |
50 |
10 |
|
4 |
3 GiB |
1000 |
10004/6005 |
5000 |
4504/6005 |
4504/6005 |
10006 |
10006 |
100 |
10 |
|
10 |
4 GiB |
1000 |
1200 |
5000 |
1200 |
1200 |
1200 |
1200 |
100 |
10 |
1Maximum number of concurrent sessions. The number assumes that calls are made using RTP/SRTP Proxy mode, or a mix of RTP/SRTP Proxy, media manipulation and video calls.
2Maximum number of concurrent sessions with virtual DSP intervention. See Transcoding Capacity below for details.
3Maximum number of concurrent audio/video sessions. The total system capacity is affected if A/V calls are introduced into the call mix. Maximum number of calls is reduced by the number of video streams used. For example, 1 vCPU instance processing 25 A/V calls has a total capacity of: 300 (max number of calls) - 25 (calls processed with 1 vCPU instance) = 275 calls.
4Maximum number of concurrent sessions (when virtual DSP intervention is applied to 450 sessions) is 1000.
5Maximum number of concurrent sessions (when virtual DSP intervention is applied to 600 sessions) is 600.
6Maximum number of proxy media mode concurrent sessions is reduced by a count equivalent to the active number of concurrent RTP media manipulation sessions. Refer to note 1.
7Supported by *-SG/*-SGX/*-SP licenses.
8Supported by *-SGX/*-SP licenses.
9Supported only by *-SP licenses.
10Supported by -SGX/-SG/-SP. See "SIP Signaling & RTP Direct Media/RTP Proxy Sessions without Encryption Services" in Node-Locked Licensing - SBC 1000/2000 and SBC SWe Edge.
Azure Deployment
Call Performance - Microsoft Azure Cloud
|
Azure Virtual Machine (VM) Resources |
Maximum SIP |
SIP Signaling Session Limits |
RTP Media Session Limits |
Maximum Call Rate Setup (CPS) |
|||||
|
Media Manipulation Mode2 (Requires Virtual DSP Intervention) |
Proxy Media Mode (No Virtual DSP Intervention) |
||||||||
|
VM Instance |
vCPU |
Maximum TCP/TLS-based SIP↔SIP Signaling Sessions4 |
Maximum SIP Registrations (60 minute refresh rate) |
No transcode, with in-band services scenario5 |
Default scenario: G.711/G.729ab RTP ↔ G.729ab/G.711SRTP, with in-band services6 |
Encryption services: G.711 RTP ↔ G.711 SRTP5 |
No encryption services: RTP ↔ RTP/SRTP ↔ SRTP4 |
||
|
B1ms |
1 |
10 |
10 |
100 |
10 |
10 |
103 |
103 |
10 |
|
B2s |
2 |
100 |
100 |
500 |
60 |
60 |
1003 |
1003 |
10 |
|
DS1_v2 |
1 |
300 |
300 |
1000 |
120 |
120 |
3003 |
3003 |
10 |
|
DS3_v2 |
4 |
1000 |
1000 |
5000 |
480 |
480 |
5003 |
5003 |
10 |
1Maximum number of concurrent sessions. The number assumes that calls are made using RTP/SRTP Proxy mode, or a mix of RTP/SRTP Proxy, media manipulation and video calls.
2Maximum number of concurrent sessions with virtual DSP intervention. See Transcoding Capacity below for details.
3Maximum number of proxy media mode concurrent sessions is reduced by a count equivalent to the active number of concurrent RTP media manipulation sessions. Refer to note 1.
4Supported by -SG-CLOUD/-SGX-CLOUD/-SP-CLOUD licenses.
5Supported by -SGX-CLOUD/-SP-CLOUD licenses.
6Supported by -SP-CLOUD license.
AWS Deployment
Call Performance - AWS Cloud
|
AWS (VM) Resources |
Maximum SIP |
SIP Signaling Session Limits |
RTP Media Session Limits |
Maximum Call Rate Setup (CPS) |
|||||
|
Media Manipulation Mode2 (Requires Virtual DSP Intervention) |
Proxy Media Mode (No Virtual DSP Intervention) |
||||||||
|
VM Instance |
vCPU |
Maximum TCP/TLS-based SIP↔SIP Signaling Sessions4 |
Maximum SIP Registrations (60 minute refresh rate) |
No transcode, with in-band services scenario5 |
Default scenario: G.711/G.729ab RTP ↔ G.729ab/G.711SRTP, with in-band services6 |
Encryption services: G.711 RTP ↔ G.711 SRTP5 |
No encryption services: RTP ↔ RTP/SRTP ↔ SRTP4 |
||
|
t3.small |
2 |
100 |
100 |
100 |
30 |
30 |
1003 |
1003 |
10 |
|
c5.large |
2 |
300 |
300 |
1000 |
120 |
120 |
3003 |
3003 |
10 |
|
c5.xlarge |
4 |
1000 |
1000 |
5000 |
480 |
480 |
5003 |
5003 |
10 |
1Maximum number of concurrent sessions. The number assumes that calls are made using RTP/SRTP Proxy mode, or a mix of RTP/SRTP Proxy, media manipulation and video calls.
2Maximum number of concurrent sessions with virtual DSP intervention. See Transcoding Capacity below for details.
3Maximum number of proxy media mode concurrent sessions is reduced by a count equivalent to the active number of concurrent RTP media manipulation sessions. Refer to note 1.
4Supported by -SG-CLOUD/-SGX-CLOUD/-SP-CLOUD licenses.
5Supported by -SGX-CLOUD/-SP-CLOUD licenses.
6Supported by -SP-CLOUD license.
Number of RTP Port Pairs must be increased above maximum call capacity
The number of RTP Port Pairs must be configured slightly larger than the actual number of ports required to support the projected number of calls. We recommend you over-allocate the number of port pairs by approximately 25 - 30% above the number of calls you want to support. For details, see Configuring the Media System.
Call Capacity Limitations
- Call capacity is limited to 4 calls per second when Info level logging is enabled. Additional logging verbosity reduces the call capacity.
- Although the call setup rate is 10 calls per second, if Call Admission Control (CAC) is enabled, calls over the rate limit will be rejected with the message 480 Temporary Not Available.
SIPREC Capacity - KVM, VMware, Microsoft Hyper-V On-premises Deployments (1vCPU, 2vCPU, 4vCPU)
SIPREC Capacity - KVM, VMware, Microsoft Hyper-V On-premises Deployments (1, 2, 4 vCPU)
|
SIPREC Scenario |
Virtual Machine vCPU Count |
||
|
1 vCPU |
2 vCPU |
4 vCPU |
|
|
G711U SRTP -> G729 |
50 |
100 |
300 |
|
G711 SRTP -> SILK NB |
50 |
100 |
300 |
|
G711U Proxy |
150 |
500 |
500 |
|
G711U Proxy SRTP |
150 |
500 |
500 |
SIPREC Capacity - Microsoft Azure Cloud Deployments
SIPREC Capacity - Microsoft Azure Cloud Deployments
|
SIPREC Scenario |
Microsoft Azure VM Instance |
|||
|
B1ms |
B2S |
DS3_v2 |
DS1_v2 |
|
|
G711U ->G729 |
10 |
30 |
200 |
60 |
|
G711U Proxy |
10 |
50 |
500 |
150 |
SIPREC Capacity - Amazon Web Services (AWS)
SIPREC Capacity - Amazon Web Services (AWS)
|
SIPREC Scenario |
Amazon Web Services VM Instance |
||
|
t3.small |
c5.large |
c5.xlarge |
|
|
G711U -> G729 |
15 |
60 |
200 |
|
G711U Proxy |
50 |
150 |
500 |
Transcoding Capacity - KVM, VMware, Microsoft Hyper-V On-premises Deployments (1vCPU, 2vCPU, 4vCPU)
Transcoding Capacity - KVM, VMware, Microsoft Hyper-V On-premises Deployments (1, 2, 4 vCPU)
|
Transcoding Scenario |
Virtual Machine vCPU Count |
|||
|
CODEC 1 |
CODEC 2 |
1 vCPU |
2 vCPU |
4 vCPU |
|
G.711A-law or G.711u-law |
G.711A-law or G.711u-law |
100 |
200 |
600 |
|
G.711A-law or G.711u-law |
G.723 |
80 |
160 |
480 |
|
G.711A-law or G.711u-law |
G.726 or G.729 |
100 |
200 |
600 |
|
G.711A-law or G.711u-law |
AMR WB |
38 |
76 |
225 |
|
G.711A-law or G.711u-law |
Opus |
24 |
54 |
165 |
|
G.711A-law or G.711u-law |
T.38 |
50 |
100 |
300 |
Transcoding Capacity - KVM, VMware, Microsoft Hyper-V On-premises Deployments (10 vCPU)
Transcoding Capacity - KVM, VMware, Microsoft Hyper-V On-premises Deployments (10 vCPU)
|
CODEC 1 |
CODEC 2 |
10 vCPU |
|
G.711A-law or G.711u-law |
G.711A-law or G.711u-law |
1200 |
|
G.711A-law or G.711u-law |
G.729 |
1200 |
|
Opus |
G.711A-law/mu-law |
360 |
Transcoding Capacity - Microsoft Azure Cloud Deployments
Transcoding Capacity - Microsoft Azure Cloud Deployments
|
Transcoding Scenario |
Microsoft Azure VM Instance |
||||
|
CODEC 1 |
CODEC 2 |
B1MS VM |
B2S VM |
DS1_v2 |
DS3_v2 |
|
G.711A-law or G.711u-law |
G.711A-law or G.711u-law |
10 |
60 |
120 |
480 |
|
G.711A-law or G.711u-law |
G.726 or G.729 |
10 |
60 |
120 |
480 |
Transcoding Capacity - Amazon Web Services (AWS)
Transcoding Capacity - Amazon Web Services (AWS)
|
Transcoding Scenario |
Amazon Web Services VM Instance |
|||
|
CODEC 1 |
CODEC 2 |
t3.small |
c5.large |
c5.xlarge |
|
G.711A-law or G.711u-law |
G.711A-law or G.711u-law |
30 |
120 |
480 |
|
G.711A-law or G.711u-law |
G.726 or G.729 |
30 |
120 |
480 |
SILK Performance for Amazon Web Services (AWS)
SILK Performance for AWS
|
Transcoding Scenario |
Amazon Web Services (AWS) VM Size |
||
|
t3.small |
c5.large |
c5.xlarge |
|
|
SILKNB SRTP -> G711U RTP |
30 |
200 |
440 |
|
SILKNB SRTP -> G729A RTP |
16 |
110 |
250 |
|
SILKNB SRTP -> SILKWB RTP |
20 |
80 |
210 |
SILK Performance for Microsoft Azure Cloud Deployments
The following table outlines the SILK performance numbers for Microsoft Azure Cloud deployments.
SILK Performance for Microsoft Azure Cloud Deployments
|
Transcoding Scenario |
Microsoft Azure VM Size |
|||
|
B1ms |
B2s |
DS1_v2 |
DS3_v2 |
|
|
SILKNB SRTP -> G711U RTP |
10 |
60 |
95 |
480 |
|
SILKNB SRTP -> G729A RTP |
10 |
60 |
50 |
300 |
|
SILKNB SRTP -> SILKWB RTP |
10 |
60 |
35 |
200 |
SILK Performance for On-premises Deployments
The following table outlines the SILK performance numbers for On-premises deployments.
SILK Performance for On-premises Deployments
|
Codec |
Virtual Machine vCPU Count |
||
|
1 vCPU |
2 vCPU |
4 vCPU |
|
|
SILK-WB-G711U |
55 |
135 |
340 |
|
SILK-WB-G729 |
35 |
95 |
230 |
|
SILK-WB-SILK-NB |
35 |
88 |
215 |
|
SILK-NB-G711U |
95 |
200 |
595 |
|
SILK-NB-G729 |
50 |
130 |
325 |
|
G711U-SILK-NB |
95 |
200 |
595 |
|
G729-SILK-NB |
50 |
130 |
308 |
|
SILK-NB-WB |
35 |
88 |
215 |
Process to Determine VM Resources
- Identify and record the minimum quantity of VM resources to support your maximum default RTP media manipulation mode sessions:
- For an on-premises SBC SWe Edge deployment, refer to Table 1 and record the required minimum quantity of vCPUs and RAM found in the vCPU # and GB RAM column that supports a number of default RTP media manipulation mode sessions greater or equal to your deployment need; note the number of supported default RTP media manipulation mode sessions is found in the Default scenario: G.711/G.729ab RTP ↔ G.729ab/G.711SRTP, with in-band services column.
- For an Microsoft Azure-based SBC SWe Edge deployment, refer to Table 2 and record the required minimum Azure VM instance type found in the VM instance column that supports a number of default RTP media manipulation mode sessions greater or equal to your deployment need; note the number of supported default RTP media manipulation mode sessions is found in the Default scenario: G.711/G.729ab RTP ↔ G.729ab/G.711SRTP, with in-band services column.
Use of Table 3 for non-default RTP media manipulation mode sessions
If on-premises SBC SWe Edge deployment is required to support a transcoding scenario other than G.711 ↔ G.729ab (the default RTP media manipulation mode session scenario), use Table 3 to identify the required minimum quantity of vCPUs to assign to the VM. For example, support for 50 G.711 ↔ OPUS sessions requires 2 vCPUs. The 2 vCPU figure should be used when undertaking step 2(a).
- Identify and record the minimum quantity of VM resources to support the additional RTP proxy session mode sessions (beyond the maximum default RTP media manipulation mode sessions) for your SBC SWe Edge deployment.
Calculating the maximum available RTP proxy mode sessions for your VM resource
The maximum available RTP proxy session mode session capacity is not equal to a value found in the Maximum SIP with corresponding RTP Media Sessions column in Tables 1 or 2; rather, it is determined by subtracting the maximum default RTP media manipulation mode sessions identified in Step 1 from the Maximum SIP with corresponding RTP Media Sessions column value associated with the quantity of vCPUs and RAM recorded from Step 1.
|
Step |
Action |
||||||
|
a |
For an on-premises SBC SWe Edge deployment, refer to Table 1 and calculate the maximum available RTP proxy session mode session capacity with the quantity of vCPUs and RAM recorded from Step 1 (or Step 2 (b)). For an Microsoft Azure-based SBC SWe Edge deployment, refer to Table 2 and calculate the maximum available RTP proxy session mode session capacity with the Azure VM instance type recorded from Step 1 (or Step 2(b)). For an Amazon Web Services (AWS)-based SBC SWe Edge deployment, refer to Table 2 and calculate the maximum available RTP proxy session mode session capacity with the Azure VM instance type recorded from Step 1 (or Step 2(b)). |
||||||
|
b |
Identify if the calculated maximum available RTP proxy session capacity from (a) above is larger than your required additional RTP proxy session mode sessions:
|
- Prepare to configure your SBC SWe Edge with the resources arrived at the end of step 2.
- For an on-premises SBC SWe Edgedeployment, refer Installing SBC SWe Edge.
- For an Microsoft Azure-based SBC SWe Edgedeployment, refer to Running an SBC SWe Edge via Microsoft Azure Marketplace.
- For an Amazon Web Services (AWS) basedSBC SWe Edge deployment, refer to Deploying an SBC SWe Edge via Amazon Web Services - AWS.
Examples
For details on the numbers used for calculations, see the Transcoding and Call Performance tables above.
Calculating a VM's vCPU and RAM Resource Requirements for an On-premises Low-Density KVM-based SBC SWe Edge Deployment
- Fifty (50) RTP media manipulation mode sessions are required (a session is equivalent to the Default RTP Media Manipulation Scenario defined above).
- A single vCPU and 1 GiB of RAM is the minimal vCPU and RAM count that supports this number of RTP media manipulation sessions.
- Record these values as the potential number of vCPU and RAM resources to assign to the VM hosting the SBC SWe Edge.
- One hundred (100) additional RTP proxy session mode sessions services are required.
- A single vCPU and 1 GiB of RAM supports a maximum of 300 total SIP with corresponding RTP sessions. Subtract the 50 RTP media manipulation mode sessions from the 300 and there are 250 remaining sessions.
- 250 sessions is greater than the 100 additional RTP proxy session mode sessions; run concurrent to the 50 RTP media manipulation mode sessions, and use the 1 vCPU and 1 GiB RAM resources identified from point 1.
- Refer to the Installing SBC SWe Edge on KVM Hypervisor to configure a VM with 1 vCPU and 1 GiB RAM to host the SBC SWe Edge.
Identifying the Microsoft Azure VM Instance for a Cloud-based SBC SWe Edge Deployment
- 200 RTP media manipulation mode sessions that support G.711 ↔ G.729ab transcoding are required.
- The DS3 v2 VM supports this capacity of the default RTP media manipulation sessions.
- Record the DS3 v2 value as the potential Azure VM that will host the SBC SWe Edge.
- 800 additional RTP proxy session mode sessions are required.
- The DS3 v2 VM supports 1000 SIP with corresponding RTP media sessions.
- Subtract the 200 RTP media manipulation mode sessions from the 1000, and 800 sessions remain.
- Record the DS3 v2 VM instance as the 800 sessions determined previously is equal to the 800 additional RTP proxy session mode sessions required to run concurrent to the 200 RTP media manipulation mode sessions.
- Refer to Running an SBC SWe Edge via Microsoft Azure Marketplace to start a DS3 v2 VM hosting the SBC SWe Edge.
Identifying the Amazon Web Services (AWS) VM Instance for a Cloud-based SBC SWe Edge Deployment
- 200 RTP media manipulation mode sessions that support G.711 ↔ G.729ab transcoding are required and supported with C5.large.
- 400 additional RTP media manipulation mode sessions are supported with C5.xlarge.
- Refer to Deploying an SBC SWe Edge via Amazon Web Services - AWS for details on hosting the SBC SWe Edge on AWS.
Calculating the vCPU and RAM Resource Requirements for an On-premises High-Density Hyper-V based SBC SWe Edge Deployment
- 200 RTP media manipulation mode sessions are required to support G.711 ↔ AMR WB transcoding.
- 4 vCPU supports this capacity.
- Record the 4 vCPU value as the potential number of vCPU resources to assign to the VM that will host (under Hyper-V) the SBC SWe Edge. Note the required RAM will be determined in the next step.
- 800 additional RTP proxy session mode sessions with encryption/decryption services.
- From Table 1, I see 4 vCPU and 2.5 GiB of RAM supports 1000 SIP with corresponding RTP media sessions are required.
- Subtract the 200 RTP media manipulation mode sessions from the 1000, and 800 sessions remain.
- Record the 4 vCPU and 2.5 GiB RAM figures; the 800 session figure determined previously is equal to the 800 additional RTP proxy session mode sessions required to run concurrent to the 200 RTP media manipulation mode sessions.
- Refer to Hyper-V installation guide to begin the process of instantiating a VM with 1 vCPU and 1 GiB RAM to host the SBC SWe Edge.
Calculating the vCPU and RAM Resource Requirements for a High-Density SIP Registration SBC SWe Edge Deployment
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, 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.
Considerations for RTP 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 Edge and another SIP based peer) can be configured to use either RTP media manipulation session mode or a RTP proxy session mode. See below:
- 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 falls back to attempt the call using RTP proxy session mode.
- After a media path is established between the SIP client and the SBC SWe Edge 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 emphasizes the importance of understanding the network deployment/architecture.
- 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. A mid-call dynamic switch to change mode, including the case of call transfer and conference is not supported. 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 SWe Edge must have an available media manipulation session mode resource. Otherwise, the call will fail.
Considerations for DTMF
There are several alternatives for DTMF calls:
- When a DTMF call is received, the SBC SWe Edge 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 Edge 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 Edge does not process the DTMF.
Considerations for Video Interworking
The SBC SWe Edge supports 25 video streams per vCPU to a maximum of 100 streams. Exceeding 4 vCPUs does not allow more than 100 video streams.