Panel | ||||
---|---|---|---|---|
In this section:
|
Info | ||
---|---|---|
| ||
Related articles: EMA: CLI: |
Multiexcerpt | |||||
---|---|---|---|---|---|
| |||||
SBC SWe systems in an OpenStack cloud environment inter-operate with a third-party transcoding platform called Media Resource Function (MRF) to transcode audio and relay video/T140.
|
Spacevars | ||
---|---|---|
|
Info | ||||
---|---|---|---|---|
| ||||
The
|
Multiexcerpt | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||
Prior to release 7.1.0, the
Henceforth, the
|
Figure 1: Audio and T.140 Transcoded
For T.140 and TTY interworking to succeed,
the audio codec on the TTY leg must be Baudot capable (G711U, G711A, or EVRC).
Info | ||
---|---|---|
| ||
|
The existing t140Call
flag in the PSP achieves T.140 and TTY interworking for MRF transcoding. The following table outlines when the T.140 and TTY can and cannot interwork.
Table 1: PSP PSP Configuration
Offer Leg Route PSP (T.140 Call) | Answer Leg Route PSP (T.140 Call) | Result |
---|---|---|
Disabled | Disabled | T.140 disabled on both legs |
Disabled | Enabled | T.140 disabled on both legs |
Enabled | Disabled | T.140-TTY can interwork |
Enabled | Enabled | T.140-TTY can interwork |
Info | ||
---|---|---|
| ||
A need for interworking is evident when an m=text line for the leg that sends T.140 is below the m=audio line for that leg, and when there is no m=text line for the other leg in the offer sent toward MRF. |
If T.140 and TTY interworking is not required but audio transcoding is required, the audio streams go through MRF and the T.140 streams do not go through MRF.
If the audio is pass-through and T.140 requires transcoding, the SBC does not invoke MRF and instead rejects the text stream on the offer leg (see the following call flow).
Figure 2: Audio pass-through
If T.140 and TTY interworking is required but MRF does not support interworking, the SBC rejects the T.140 stream on the leg that offers T.140.
For configuration details, refer to:
To view media stream statistics, refer to Show Status Address Context - Call Status Details
Info | ||
---|---|---|
| ||
The first three activities below cause the D-SBC to invoke MRF. |
Link_in_new_tab | ||||
---|---|---|---|---|
|
Include Page | ||||
---|---|---|---|---|
|
This configuration example explains how to configure the MRF cluster profile in the S-SBC.
Noprint | |
---|---|
|
Cloak |
---|
To configure the domain name of the MRF server, select FQDN: When FQDN routing is enabled, configure a DnsGroup on zone in which mrfTgName is present. To configure an IP address for the MRF server, select IpAddress. When the Routing Type is selected as IP Address, a minimum of one IP must be configured. In case of multiple IP addresses, each IP address is separated by a comma (,). Ribbon supports a maximum of four IP address configurations. To configure a dedicated trunk group on MRF servers: To configure transport type for MRF server: To configure the Request URI sent in the INVITE message toward the MRF server: To configure the Port of the MRF server in the MRF profile: When the mrfRoutingType is selected as IpAddress, the mrfPort default value is 5060. When the mrfRoutingType is selected as fqdn, the mrfPort default value is 0. When the value for the port is 0, you must configure the desired port in DNS server for SRV record. To configure the state of the MRF server: |
This configuration example explains the CLI command required to configure the MRF cluster profile on the M-SBC.
Noprint | |
---|---|
|
Cloak |
---|
To configure a private IP Interface Group that communicates with the MRF, execute the To view the configured private IP Interface group name, execute the Debug Statistics CommandsUse the following command to get the media statistics corresponding to the private NIF resources for an MRF call. Use the following CLI 'show' command to view the call statistics for an MRF call.
The callDetailStatus command contains the following fields (with example output): Use the following CLI 'show' command to view the call resource statistics for an MRF call.
Value dresMrf indicates MRF is used for transcoding the call. Parameter: resType
Use the following CLI 'show' command to view the call media leg information for an MRF call. |
Div | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
Path Check ProfileThe Path Check Profile specifies the conditions that constitute a connectivity failure, and in the event of such a failure, the conditions that constitute a connectivity recovery.
ARS ProfileThe Address Reachability Service (ARS) determines whether a server is reachable, able to blacklist a server IP address when unreachable, and remove the server from blacklist state. ARS profiles can be created to configure blacklisting and recovery algorithm variants. For more information, refer to Service Profiles - SIP ARS Profile (EMA) or SIP ARS Profile - CLI. Create an ARS profile and attach it to the MRF trunk group as configured in the cluster profile. The ARS feature controls the congestion to handle the 503 response. CAC ProfileThe Call Admission Control (CAC) feaure feature creates and configures a profile that provides each registered SIP or static endpoint to have individual limits on the number of active calls and the call rates. For more information, refer to to CAC Provisioning - SIP CAC Profile.
|
In a cluster profile, you can configure the routing type for an FQDN or a list of IP addresses.
When FQDN is chosen, the FQDN resolves into a list of IP addresses.
If the MRF profile is configured with an FQDN and a call is routed to MRF server(s) as follows:
Code Block |
---|
% set addressContext <address_context> zone <zone name> sipTrunkGroup <TG Name> signalling retryCounters invite <0-6> |
The DNS crankback profile is configured such that, it retries the other records for any error responses received from MRF server. If the error code matches with the entry in the DNS crankbank profile, then SBC retries for alternative MRF server, otherwise the call will be rejected.
The SRV record look-up response is as follows:
# _service._proto.name. | TTL | class | srv | priority | weight | port | target host |
---|---|---|---|---|---|---|---|
_sip._tcp.ribbon.com. | 86400 | IN | SRV | 10 | 60 | 5060 | bigserver.ribbon.com. |
_sip._tcp.ribbon.com. | 86400 | IN | SRV | 10 | 20 | 5060 | smallserver.ribbon.com. |
_sip._tcp.ribbon.com. | 86400 | IN | SRV | 10 | 10 | 5060 | smallserver.ribbon.com. |
_sip._tcp.ribbon.com. | 86400 | IN | SRV | 10 | 10 | 5070 | smallserver.ribbon.com. |
_sip._tcp.ribbon.com. | 86400 | IN | SRV | 20 | 0 | 5060 | backupserver.ribbon.com. |
Priority : Determines the precedence of use of the record's data. The SRV record with the lowest-numbered priority value is used first. if the connection to the host fails, it falls back to other records of equal or higher priority.
Weight: If a service has multiple SRV records with the same priority value, clients use the weight to determine the host to be used. The weight value is relevant only in relation to other weight values for the service, and only among records with the same priority value.
The table above tabulates, the first four records share a priority of 10, so the weight field's value is used to determine which server (host and port combination) to contact. The sum of all four values is 100, so bigserver.ribbon.com is used 60% of the time. The two hosts mediumserver and smallserver is used for 20% of requests each, with half of the requests that are sent to smallserver ( that is 10% of the total requests) going to port 5060 and the remaining half to port 5070. If bigserver is unavailable, these two remaining machines shares the load equally, because they are to be selected 50% of the time. If all four servers with priority 10 are unavailable, the record with the next highest priority value will be chosen, which is backupserver.ribbon.com.
Once a given SRV record is selected, the SBC performs A-Record lookup. If A-record lookup fails, AAAA record look-up is performed.
SBC performes the A-Record lookup and if that fails AAAA record lookup is done. The SBC handles IPV4 and/or IPv6 addresses returned in AAAA record look-up response.
An example of A record look-up response is as follows:
bigserver.ribbon.com 86400 IN A 192.168.1.10
bigserver.ribbon.com 86400 IN A 192.168.1.11
An example of AAAA record look-up response is as follows:
bigserver.ribbon.com 86400 IN AAAA fe80:0:0:0:214:4fff:fe56:848d
bigserver.ribbon.com 86400 IN AAAA fd00:10:6b50:110::28
SBC distributes the A/AAAA records based on the configuration of recordOrder in the DNS group.
Code Block |
---|
% set addressContext <addressContext name> dnsGroup <dnsGroup name> server <DNS server name> recordOrder <centralized-roundrobin | priority | roundrobin> |
Where:
recordOrder
– Indicates the lookup order of local name service records associated with the specified DNS server.centralized-roundrobin
– (recommended) This option uses the round-robin technique with respect to the whole system.priority
(default) – Indicates the lookup order is based on the order of entries returned in DNS response.roundrobin
– This option is used to share and distribute local records among internal SBC processes in a round-robin fashion. Over a large number of calls, a fair amount of distribution occur across all DNS records.In case of multiple SRV RR and multiple A/AAAA RR, SBC selects the next-available SRV address (if all the IP addresses for a given A/AAAA record are tried and not reachable) and retries to reach the MRF sever, using the procedures specified above for selecting an SRV based on priority and weight.
In this profile:
If the MRF profile is configured with a list of MRF server IP addresses then a call is routed to MRF server(s) as follows:
Example: The MRF profile is configured with a list of MRF server IP addresses such as IP1, IP2, IP3 and IP4. For the 1st call, the S-SBC tries to connect to the MRF server IP1. Meanwhile, the S-SBC receives 2nd, 3rd, 4th calls and connects them to the MRF servers IP2, IP3 and IP4 respectively. If for the 1st call the S-SBC receives a Failure/No response from the MRF server IP1, the S-SBC tries with IP2.
Signaling and Media flow for a transcoded call using an S-SBC, M-SBC and MRF:
Figure 3: Signaling and Media Flow