Overview
Audio Transcoding and Video Relay
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.
The
Unable to show "metadata-from": No such page "_space_variables"
supports the following functionality:
- Relaying both audio and video streams
- Relaying audio, video and T140 streams
- Audio transcode through MRF and video relay
- Audio transcode through MRF and video/T140 relay
- Audio transcode through MRF and T140 relay
- Audio and T.140 transcode through MRF (see T.140 and TTY Interworking Support below)
T.140 and TTY Interworking Support
to release 7.1.0, the
Unable to show "metadata-from": No such page "_space_variables"
invoked MRF only for audio streams to achieve transcoding. Non-audio streams were relayed end-to-end even when the audio was sent to the MRF. Teletype (TTY) as the legacy service offered through encoding text characters as tones that are embedded in a carrier (PCMU, PCMA, or EVRC) media stream. The T.140 streams carry text as a separate payload.Henceforth, the
Unable to show "metadata-from": No such page "_space_variables"
invokes MRF for T.140 and TTY interworking to achieve transcoding. When T.140 and TTY interwork, text characters exchange between the T.140 stream and the tones carried inband with the audio. 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). Keep in mind that T.140 pass-through scenarios are supported without any MRF interaction.
Figure 1: Audio and T.140 Transcoded
For T.140 and TTY interworking to succeed,
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 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 |
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.
Limitations
- Audio-less calls are not supported.
- Only video and T140 streams among the non-audio streams are supported.
For configuration details, refer to:
To view media stream statistics, refer to Show Status Address Context - Call Status Details
Prerequisites to Invoking MRF
- Configure MRF Profile in S-SBC
- Configure Private LIF Groups in M-SBC
- Enable transcoding at the Packet Service Profile (refer to ).
- Create a Path Check Profile, ARS profile, and CAC profile during the initial configuration
This configuration example explains how to configure the MRF cluster profile in the S-SBC.
The MRF servers are configured as FQDN or the IP address is decided by Routing Type configured in the MRF Profile.
set system dsbc cluster type mrf mrfRoutingType <Routing Type>
Possible completions: IpAddress fqdn
To configure the domain name of the MRF server, select FQDN:
set system dsbc cluster type mrf mrfRoutingType fqdn mrffqdn <Domain Name>
To configure an IP address for the MRF server, select IpAddress.
set system dsbc cluster type mrf mrfRoutingType IpAddress mrfIpAddress <MRF IP-Address>
To configure a dedicated trunk group on MRF servers:
set system dsbc cluster type mrf mrfTgName <MRF TG Name>
To configure transport type for MRF server:
set system dsbc cluster type mrf mrfTransportType
Possible completions: TCP TLS UDP
To configure the Request URI sent in the INVITE message toward the MRF server:
set system dsbc cluster type mrf mrfRequestUri <MRF Request URI>
To configure the Port of the MRF server in the MRF profile:
set system dsbc cluster type mrf mrfPort <MRF Port>
To configure the state of the MRF server:
set system dsbc cluster type mrf state <Enabled | Disabled>
This example explains the CLI command required to configure the MRF cluster profile on the M-SBC.
To configure a private IP Interface Group that communicates with the MRF, execute the loadBalancingService
set command:
% set system loadBalancingService privateIpInterfaceGroupName <Private IP Interface Group Name>
To view the configured private IP Interface group name, execute the loadBalancingService
show command:
groupName njmsbclbs.njmrfdsbc.com;
privateIpInterfaceGroupName SLIG2;
Debug Statistics Commands
Use the following command to get the media statistics corresponding to the private NIF resources for an MRF call.
> show status global callRemoteMediaStatus
callRemoteMediaStatus 67108888 0 {
streamId 0;
resId 116;
resType xresUser;
legId 0;
nodeGcidAndIpAddr 67108894(fd00:10:6b50:4d50::3);
localRtpPort 1082;
remoteRtpPort 8999;
remoteRtcpPort 9000;
rtpPacketSent 78;
rtpPacketRecv 656;
rtcpPacketSent 0;
rtcpPacketRecv 0;
rtpPacketDiscard 0;
}
callRemoteMediaStatus 67108888 1 {
streamId 0;
resId 117;
resType xresUser;
legId 0;
nodeGcidAndIpAddr 67108894(fd00:10:6b50:4d50::3);
localRtpPort 1140;
remoteRtpPort 1076;
remoteRtcpPort 1077;
rtpPacketSent 656;
rtpPacketRecv 78;
rtcpPacketSent 0;
rtcpPacketRecv 0;
rtpPacketDiscard 0;
}
callRemoteMediaStatus 67108888 2 {
streamId 0;
resId 118;
resType xresUser;
legId 1;
nodeGcidAndIpAddr 67108894(fd00:10:6b50:4d50::3);
localRtpPort 1082;
remoteRtpPort 8955;
remoteRtcpPort 8956;
rtpPacketSent 417;
rtpPacketRecv 2;
rtcpPacketSent 0;
rtcpPacketRecv 0;
rtpPacketDiscard 0;
}
callRemoteMediaStatus 67108888 3 {
streamId 0;
resId 119;
resType xresUser;
legId 1;
nodeGcidAndIpAddr 67108894(fd00:10:6b50:4d50::3);
localRtpPort 1142;
remoteRtpPort 1076;
remoteRtcpPort 1077;
rtpPacketSent 2;
rtpPacketRecv 417;
rtcpPacketSent 0;
rtcpPacketRecv 0;
rtpPacketDiscard 0;
}
Use the following CLI 'show' command to view the call statistics for an MRF call.
> show status global callDetailStatus
The callDetailStatus command contains the following fields (with example output):
ingressPrivStream1LocalIpSockAddr "fd00:10:6b50:4d51::3/ 1140 (rtcp: 1141)";
ingressPrivStream1RemoteIpSockAddr "fd00:10:6b50:4d30::7f/ 1076 (rtcp: 1077)";
egressPrivStream1LocalIpSockAddr "fd00:10:6b50:4d51::3/ 1142 (rtcp: 1143)";
egressPrivStream1RemoteIpSockAddr "fd00:10:6b50:4d40::7e/ 1076 (rtcp: 1077)";
transcodeResType mrf;
mrfSignalingInfo "fd00:10:6b50:4d30::7f/ 5060";
show status global callDetailStatus
callDetailStatus 67108888 {
mediaStreams audio;
state Stable;
callingNumber "";
calledNumber 7894561232;
addressTransPerformed none;
origCalledNum "";
scenarioType SIP_TO_SIP;
callDuration 6;
mediaType transcode;
associatedGcid1 67108888;
associatedGcid2 67108888;
associatedGcidLegId1 1;
associatedGcidLegId2 0;
ingressSessionBandwidthkbps 32;
egressSessionBandwidthkbps 16;
ingressMediaStream1LocalIpSockAddr "fd00:10:6b50:4d50::3/ 1082 (rtcp: 1083)";
ingressMediaStream1RemoteIpSockAddr "fd00:10:6b50:4500::78/ 8999 (rtcp: 9000)";
egressMediaStream1LocalIpSockAddr "10.54.227.131/ 1082 (rtcp: 1083)";
egressMediaStream1RemoteIpSockAddr "10.54.80.8/ 8955 (rtcp: 8956)";
ingressMediaStream1Security rtp-disabled,rtcp-disabled;
egressMediaStream1Security rtp-disabled,rtcp-disabled;
ingressMediaStream1Bandwidth 32;
egressMediaStream1Bandwidth 16;
ingressMediaStream1IceState NONE;
egressMediaStream1IceState NONE;
ingressDtlsStream1 DISABLED;
egressDtlsStream1 DISABLED;
ingressPrivStream1LocalIpSockAddr "fd00:10:6b50:4d51::3/ 1140 (rtcp: 1141)";
ingressPrivStream1RemoteIpSockAddr "fd00:10:6b50:4d30::7f/ 1076 (rtcp: 1077)";
egressPrivStream1LocalIpSockAddr "fd00:10:6b50:4d51::3/ 1142 (rtcp: 1143)";
egressPrivStream1RemoteIpSockAddr "fd00:10:6b50:4d40::7e/ 1076 (rtcp: 1077)";
iceCallTypes ing-lcl-NONE,ing-rmt-NONE,eg-lcl-NONE,eg-rmt-NONE;
transcodeResType mrf;
mrfSignalingInfo "fd00:10:6b50:4d30::7f/ 5060";
}
Use the following CLI 'show' command to view the call resource statistics for an MRF call.
show status global callResourceDetailStatus
> show table global callResourceDetailStatus
RES RES LEG
GCID INDEX ID RES TYPE CALL ID ID NODE GCID AND IP ADDR
--------------------------------------------------------------------------------------------
67108894 0 116 xresUser 67108894 0 67108888(fd00:10:6b50:4d50::e)
67108894 1 40 bresLe2LeRtcprelay 67108894 0 67108888(fd00:10:6b50:4d50::e)
67108894 2 117 xresUser 67108894 0 67108888(fd00:10:6b50:4d50::e)
67108894 3 119 xresUser 67108894 1 67108888(fd00:10:6b50:4d50::e)
67108894 4 41 bresLe2LeRtcprelay 67108894 1 67108888(fd00:10:6b50:4d50::e)
67108894 5 118 xresUser 67108894 1 67108888(fd00:10:6b50:4d50::e)
Use the following CLI 'show' command to view the call media leg information for an MRF call.
> show status global callMediaStatus
callMediaStatus 67108888 {
mediaStreamsInCall audio;
ingressMacHeader 0-17-A4-BF-81-0;
egressMacHeader 0-17-A4-BF-81-0;
ingressBearerType voice;
egressBearerType voice;
ingressCfgAudioType AMR/BWE;
egressCfgAudioType G723A;
ingressActAudioType amrBwEfficient;
egressActAudioType g723a53;
ingressRemPacketsLost 0;
ingressRFactorInbound 93;
ingressRFactorOutbound 93;
egressRemPacketsLost 0;
egressRFactorInbound 74;
egressRFactorOutbound 74;
mediaStream1Label audio;
mediaStream1Codec AMR/BWE;
ingressMediaStream1PacketsSent 57;
ingressMediaStream1PacketsReceived 488;
ingressMediaStream1OctetsSent 399;
ingressMediaStream1OctetsReceived 13664;
ingressMediaStream1RtcpPacketsSent 0;
ingressMediaStream1RtcpPacketsReceived 0;
ingressMediaStream1PacketsLost 0;
ingressMediaStream1PacketsDiscarded 0;
ingressMediaStream1PacketLatency 0;
ingressMediaStream1InterarrivalJitter 19;
ingressMediaStream1StunDtlsPacketsReceived 0;
ingressMediaStream1StunDtlsPacketsDiscarded 0;
ingressMediaStream1SrtpAuthFailure 0;
ingressMediaStream1SrtpReplayFailure 0;
egressMediaStream1PacketsSent 305;
egressMediaStream1PacketsReceived 2;
egressMediaStream1OctetsSent 1220;
egressMediaStream1OctetsReceived 48;
egressMediaStream1RtcpPacketsSent 0;
egressMediaStream1RtcpPacketsReceived 0;
egressMediaStream1PacketsLost 0;
egressMediaStream1PacketsDiscarded 0;
egressMediaStream1PacketLatency 0;
egressMediaStream1InterarrivalJitter 0;
egressMediaStream1StunDtlsPacketsReceived 0;
egressMediaStream1StunDtlsPacketsDiscarded 0;
egressMediaStream1SrtpAuthFailure 0;
egressMediaStream1SrtpReplayFailure 0;
}
Create a Path Check Profile, ARS profile, and CAC Profile During Initial Configuration
Path Check Profile
The 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 Profile
The 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 Profile
The Call Admission Control (CAC) feaure 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 CAC Provisioning - SIP CAC Profile.
Invoking the MRF Server
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 wit and a call is routed to MRF server(s) as follows:
- If mrfPort is configured as '0', the SBC performs SRV query to fetch the port number based on the priority and weight. Post SRV query, it performs A or AAAA query to fetch the corresponding IP addresses.
- If mrfPort is configured with a valid port number, the SBC performs only A or AAAA query.
- if there is 'No Response' received from MRF server, SBC re-transmits the INVITE for six times.This number of re-transmissions is configurable under trunk group as follows. After the configured number of re-transmissions the SBC tries to re-transmit to the alternative MRF server IP address available in the list by default.
% 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.
Selecting an based on priority and weight
The SRV record look-up response is as follo
# _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. 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 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 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.
- If the target host is “.”, SBC discards the record.
- priority and weight fields in SRV record selection.
- SBC attempts to contact the target host with the lowest-numbered priority it can reach.
- .
- SBC uses “running sum” mechanism that is described in RFC 2782 for load-balancing across SRV RRs of the same priority.
Once a given SRV record is selected, the SBC performs A-Record lookup. If A-record lookup fails, AAAA record look-up is performed.
Selecting an A/AAAA RR based on configuration
. The SBC handles IPV4 and/or IPv6 addresses returned in AAAA record look-up .
An example of A record look-up response is as follows:
bigserver.ribbon.com 86400 IN A 192.168.1.10
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.
% 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:
- A maximum of 4 IPV4/IPV6 can be configured.
- If "No Response or 504" is received from MRF, then SBC will not try for an alternative MRF server and the call gets rejected.
- If "488/500/503" response is received from any MRF server, then SBC tries for an alternative MRF server before rejecting the call.
If the MRF profile is configured with a list of MRF server IP a call is routed to MRF server(s) as follows:
- S-SBC tries to connect to the configured MRF server IP addresses in a round-robin fashion.
- If any failure/no response is received from an MRF server for a specific IP address, . When blacklisted, the S-SBC continuously sends an option message to MRF server to check whether the IP is active/inactive. Once the IP is active, S-SBC removes the IP address from the blacklist state and tries to connect to when the next call is routed to MRF Server.
- The S-SBC tries for the next available MRF server IP address configured in the .
- This process is repeated until S-SBC either receives a SUCCESS response from any of the MRF servers or all the MRF server IP addresses in list is exhausted.
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 . 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:
- S-SBC: Provides signaling services for allocating/activating/managing various resources (including MRF). Configures media flow through M-SBC and MRF.
- M-SBC: Provides media services. Public interface is used to communicate with peers and private interface is used to communicate with MRF.
- MRF: Provides transcoding services. Configured in private network of SBC and uses RFC-4117 interface to communicate with S-SBC.
Figure 3: Signaling and Media Flow