Page History

Panel

Contents

In this section:

Table of Contents

maxLevel	4

Info

icon	false

Overview

Audio Transcoding and Video Relay

Multiexcerpt

MultiExcerptName	Invoke MRF Intro

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.

Info

title	Note

Only distributed SBC (D-SBC) SWe systems on OpenStack supports this feature.

The

Spacevars

0	product

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)

Info

title	Note

The

Spacevars

0	product2

supports this functionality only for MRF-transcoded calls on D-SBC platforms.

T.140 and TTY Interworking Support

Multiexcerpt

MultiExcerptName	T140 Support

Prior to release 7.1.0, the

Spacevars

0	product

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

Spacevars

0	product

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.

Info

title	Note

This feature does not support sessions that only have a T.140 stream.

The

Spacevars

0	product

does not invoke T.140 and TTY interworking when T.140 is present on both legs and has different transmission rates, or a difference in redundancy packet support.

Info

title	Note

Only the

Spacevars

0	product2

on OpenStack (D-SBC) supports this feature.

Caption

0	Figure
1	Audio and T.140 Transcoded
3	Audio and T.140 Transcoded

Image Added

For T.140 and TTY interworking to succeed,

the offer received by the SBC must have a text stream with a valid IP and Port, and the answer received by the SBC must have a text stream with port=0,
the audio must be transcoded,
the audio codec on the TTY leg must be Baudot capable (G711U, G711A, or EVRC).

Info

title	Note

If the flag transcode-only is enabled, like other packet-to-packet control configurations, the transcode-only applies only to the audio stream.
The T.140 stream can be passed-through or transcoded based on the above conditions.

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.

Caption

0	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

Info

title	Note

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).

Caption

0	Figure
1	Audio pass-through

Image Added

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:

D-SBC Cluster - CLI
Cluster - Type (EMA)

To view media stream statistics, refer to Show Status Address Context - Call Status Details

Prerequisites to Invoking MRF

Info

title	Note

The first three activities below cause the D-SBC to invoke MRF.

Configure MRF Profile in S-SBC
Configure Private LIF Groups in M-SBC
Enable transcoding at the Packet Service Profile (refer to
Link_in_new_tab
Text Packet Service Profile - CLI
URL Packet Service Profile - CLI
).
Create a Path Check Profile, ARS profile, and CAC profile during the initial configuration

Include Page

	Path_Check_Profile_vs_ARS_Profile
	Path_Check_Profile_vs_ARS_Profile

Configure an MRF Profile on the S-SBC

This configuration example explains how to configure the MRF cluster profile in the S-SBC.

Noprint

Toggle Cloak
Click to expand..

Feature Overview

The Sonus Distributed SBC (D-SBC) solution distributes the core SBC components signaling, media and transcoding into discrete functional elements that allows SWe instance to instantiate and scale independently in their own respective clusters. This is ideal for greenfield deployments where all the three clusters are deployed; however, in an existing network, Sonus D-SBC uses the services of an external transcoder for audio transcoding.

In Sonus microservices architecture, the virtualized Sonus Signaling SBC (S-SBC) and Sonus Media SBC (M-SBC) instances supports signaling and media relay functionalities. Media Resource Function (MRF) supports any media inter-working requirement that includes transcoding/transrating. Sonus S-SBC invokes the MRF using a 3PCC call model as per RFC-4117.

Media Resource Function – Resource Manager (MRF-RM) runs on SBC and interacts with external third-party transcoder (MRF Server) to provide transcoding services. S-SBC manages the transcoding resources on MRF server remotely using SIP interface based on RFC-4117. Any third-party transcoder that supports SIP interface based on RFC-4117 can be used as MRF server with the SBC to provide Audio transcoding services.

Key features:

Supports all audio features
Supports mid-call modification to insert or remove the transcoder
MRF related information is logged in CDR:
- Signaling IP/Port information
- Local/Remote End Point information for both Ingress and Egress private leg towards MRF
Sonus PSX Packet Service Profile (PSP) control is used to invoke transcoding

Prerequisites to invoke MRF

All existing controls that causes SBC to include DSP applies:

Configure MRF profile in S-SBC

Configure Private LIF Groups in M-SBC

Enable transcoding at PSP, refer Packet Service Profile - CLI.

Additional Configuration

Create path check profile, ARS profile, and CAC profile during the 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.

For more info on path check, refer Service Profiles - Path Check Profile

For more info on creating IP Peer, refer System Provisioning - Ip Peer for GUI or zone ipPeer - CLI for CLI.

Note

In case of IP address, create different IP Peers for each IP addresses configured in MRF cluster profile as MRF IP address and attach the path check profile.

In case of FQDN, create IP Peer with FQDN and attach the patch check profile.

ARS Profile

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 info, refer Service Profiles - Sip Ars Profile.

Create an ARS profile and attach to the MRF TG as configured in the cluster profile. The ARS feature controls the congestion to handle the 503 response.

CAC Profile

Call Admission Control (CAC) 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 info, refer CAC Provisioning - SIP CAC Profile.

For End point CAC, create CAC profile and attach to the IP Peer.

For TG CAC, create CAC profile and attach to the MRF TG as configured in the cluster profile.

Note

End point CAC does not support FQDN.

Bandwidth CAC is not supported for both TG and Peer level.

Invoking MRF Server

In cluster profile, you can configure routing type as FQDN or list of IP addresses. In case of FQDN, the FQDN resolves into list of IP addresses.

If the MRF profile is configured with a list of MRF server IP addresses and 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, the same IP address is blacklisted. When blacklisted, 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 the same IP when the next call is routed to MRF Server.
S-SBC tries for the next available MRF server IP address configured in the list alternatively.
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, then for the 1st call, S-SBC tries to connect for MRF server IP1. Meanwhile, S-SBC received 2nd, 3rd, 4th calls and connected to the MRF servers IP2, IP3 and IP4 respectively. For the 1st call, the S-SBC has received a Failure/No response from the MRF server IP1. Hence, the S-SBC tries with IP2 and connects successfully.

Signaling and Media Flow

Signaling and Media flow for a transcoded call using S-SBC, M-SBC and MRF:

S-SBC: Provides signaling services and responsible for allocating/activating/managing various resources (including MRF). Configures media flow through M-SBC & MRF.

M-SBC: Provides media services. Public interface is used to communicate with peers & 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.

Caption

0	Figure
1	Signaling and Media Flow

Image Removed

CLI Changes

AnchorConfigure MRF profile in S-SBCConfigure MRF profile in S-SBCConfigure MRF profile in S-SBC

The following CLI commands are required to configure the MRF cluster profile in S-SBC

.

The MRF servers are configured as FQDN or the IP Address address is decided by Routing Type configured in the MRF Profile.

Code Block
% set system dsbc cluster type mrf mrfRoutingType <Routing Type> Possible completions: IpAddress fqdn

To configure the Domain Name of MRF Server

note

Cloak
greentransparent To configure the domain name of the MRF server, select FQDN:
Note When FQDN routing is enabled, configure a DnsGroup on zone in which mrfTgName is present.
Code Block
% set system dsbc cluster type mrf mrfRoutingType fqdn mrffqdn <Domain Name> To configure an IP

-Address

address for the MRF

Servernote

server, select IpAddress.

Note

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

comma (,).

Sonus

Ribbon supports a maximum of four IP address

configuration.

Minimum: 1

Maximum: 4

Code Block
% set system dsbc cluster type mrf mrfRoutingType IpAddress mrfIpAddress <MRF IP-Address>

configurations.

To configure a dedicated

TG

trunk group on MRF servers

, execute below command

:

Code Block
Note
% set system dsbc cluster type mrf mrfTgName <MRF TG Name> To configure transport type for MRF server

, execute below command:

:

Note

Default value is UDP.

Code Block
% set system dsbc cluster type mrf mrfTransportType Possible completions: TCP TLS UDP

To configure request URI sent in the invite towards the MRF server, execute below command:

Code Block
% set system dsbc cluster type mrf mrfRequestUri <MRF Request URI>

To configure Port of the MRF server in MRF Profile, execute below command:

Note
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: Note
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, user you must configure the desired port in DNS server for SRV record.
Code Block
% set system dsbc cluster type mrf mrfPort <MRF Port> To configure the state of the MRF server

, execute below command:

Code Block
% set system dsbc cluster type mrf state <Enabled \| Disabled>

Command Parameters

Caption

0	Table
1	Command Parameters

Parameter Name	Length/Range	Default Value	Parameter Description	Mandatory / Optional
mrfTgName	1-24	undefined	Specifies Trunk Group Name used for MRF signaling.	M
mrfRoutingType	NA	Fqdn	Specifies Routing type used to send invite towards MRF server. Options: FQDN IP Address	O
mrfFqdn	1-63	undefined	Specifies Domain Name of the MRF Server.	M
mrfIpAddress	NA	undefined	Specifies IP Addresses of the MRF Server.	M
mrfRequestUri	1-63	undefined	Specifies Request URI to be sent in Invite towards MRF Server.	M
mrfPort	1-65535	For Fqdn - 0 For IPAddress - 5060	Specifies port of the MRF Server.	O
mrfTransportType	NA	UDP	Specifies transport to be used in communication with MRF Server. Options: TCP TLS UDP	O
state	NA	undefined	The admin state of the mrf cluster. Options: Enabled Disabled	M

Command Syntax

Code Block

language	none

% set system dsbc cluster type mrf
	mrfRoutingType <IpAddress | fqdn>
    mrfPort <5060 | 0> 
    mrfTgName <trunking group name>
    mrfTransportType <TCP| TLS| UDP>
    mrfRequestUri <Request URI>
    state <disabled | enabled>

Configuration Example

Code Block

language	none

% set system dsbc cluster type mrf mrfRequestUri <transcoding@sonusnet.com>
% set system dsbc cluster type mrf mrfRoutingType <fqdn mrffqdn sonusnet.com>
% set system dsbc cluster type mrf mrfRoutingType IpAddress mrfIpAddress <10.54.80.7 fdda:5cc1:23:4::1f fdda:5cc1:23:4::1e 10.54.80.8>
% set system dsbc cluster type mrf mrfTgName <MRF_TG>
% set system dsbc cluster type mrf mrfTransportType <UDP>
% set system dsbc cluster type mrf mrfPort <5060>
% set system dsbc cluster type mrf state <enabled>

AnchorConfigure Private LIF Groups in M-SBCConfigure Private LIF Groups in M-SBCConfigure Private LIF Groups in M-SBC

To configure Private IP Interface Group that communicates towards MRF, execute below command:

set system loadBalancingService

Code Block
% set system loadBalancingService privateIpInterfaceGroupName <Private IP Interface Group Name>

To view the configured Private IP Interface Group Name, execute below command in M-SBC:

show system loadBalancingService

Code Block
groupName njmsbclbs.njmrfdsbc.com; privateIpInterfaceGroupName SLIG2;

Image Removed

Debug Stat Commands

The following CLI can be used to get the media stats corresponding to private NIF resources for an MRF call.

show status global callRemoteMediaStatus

Code Block

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;
}

To View the Call Remote Media Status on EMA

1. Log on to EMA as admin user.

2. Click ALL.

3. On the navigation pane, click Global > CAC > Call Remote Media Status.

Image Removed

The following CLI can be used to get the call stats for an MRF call.

show status global callDetailStatus

Note

The callDetailStatus command contains the following new fields:

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";

Code Block

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";
}

To View the Call Detail Status on EMA

1. Log on to EMA as admin user.

2. Click ALL.

3. On the navigation pane, click Global > CAC > Call Detail Status.

Image Removed

The following CLI can be used to get the call resource stats for an MRF call.

show status global callResourceDetailStatus

Note

Value dresMrf indicates MRF is used for transcoding the call.

Parameter: resType
Value: dresMrf

Code Block

show status global callResourceDetailStatus 
    callResourceDetailStatus 67108888 0 {
    resId             116;
    resType           xresUser;
    callId            67108888;
    legId             0;
    nodeGcidAndIpAddr 67108894(fd00:10:6b50:4d50::3);
}
callResourceDetailStatus 67108888 1 {
    resId             117;
    resType           xresUser;
    callId            67108888;
    legId             0;
    nodeGcidAndIpAddr 67108894(fd00:10:6b50:4d50::3);
}
callResourceDetailStatus 67108888 2 {
    resId             24;
    resType           dresMrf;
    callId            67108888;
    legId             1;
    nodeGcidAndIpAddr 67108888(fd00:10:6b50:4d30::7f);
}
callResourceDetailStatus 67108888 3 {
    resId             119;
    resType           xresUser;
    callId            67108888;
    legId             1;
    nodeGcidAndIpAddr 67108894(fd00:10:6b50:4d50::3);
}
callResourceDetailStatus 67108888 4 {
    resId             118;
    resType           xresUser;
    callId            67108888;
    legId             1;
    nodeGcidAndIpAddr 67108894(fd00:10:6b50:4d50::3);
}

show table global callResourceDetailStatus

Code Block

                           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)

The following CLI can be used to get the call media leg information for an MRF call.

show status global callMediaStatus

Code Block

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;
}

To View the Call Media Status on EMA

1. Log on to EMA as admin user.

2. Click ALL.

3. On the navigation pane, click Global > CAC > Call Media Status.

Image Removed

EMA Changes

Creating MRF Cluster Type

To establish connection between SBC and MRF, create an MRF Cluster Type.

Log on to the EMA Configurator as admin.

Click All tab.

On the navigation pane, click System > DSBC > Cluster > Type.

Caption

0	Figure
1	Cluster Type

Image Removed
Click +New Type. By default, Create New Type window for Policer is displayed. To create MRF Type, select the Name as MRF.

Caption

0	Figure
1	Create New Type - Policer

Image Removed

To create MRF with Routing Type as FQDN:

In Name drop-down menu, choose MRF.

Select the State.

Select the MRF Routing Type as FQDN.

Caption

0	Figure
1	Create New Type - MRF with Routing Type as FQDN

Image Removed

In MRF TG Name drop-down menu, choose MRF_TG.

Type MRF Request URI.

Type MRF Port.

In MRF Transport Type drop-down menu, choose the appropriate transport type.

Type MRFFQDN.
To create MRF with Routing Type as IP Address V4 or V6:

In Name drop-down menu, choose MRF.

Type MRF IP Address.

Select the State.

Select the MRF Routing Type as IP Address V4 or V6.

Caption

0	Figure
1	Create New Type - MRF with Routing Type as IP Address V4 or V6

Image Removed

In MRF TG Name drop-down menu, choose MRF_TG.

Type MRF Request URI.

Type MRF Port.

In MRF Transport Type drop-down menu, choose the appropriate transport type.

Click Save.

:

Configure Private LIF Groups on the M-SBC

This configuration example explains the CLI command required to configure the MRF cluster profile on the M-SBC.

Noprint

Toggle Cloak
Click to expand...

Cloak

greentransparent

To configure a private IP Interface Group that communicates with the MRF, execute the loadBalancingService set command:

To view the configured private IP Interface group name, execute the loadBalancingService show command:

Debug Statistics Commands

Use 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.

> show status global callDetailStatus

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.

show status global callResourceDetailStatus

Note

Value dresMrf indicates MRF is used for transcoding the call.

Parameter: resType
Value: dresMrf

Use the following CLI 'show' command to view the call media leg information for an MRF call.

Create a Path Check Profile, ARS profile, and CAC Profile During Initial Configuration

Div

style	padding-left:1%;
id	indent

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.

For more information on path check, refer Service Profiles - Path Check Profile

For more information on creating IP Peer, refer to System Provisioning - IP Peer for GUI or Zone - IP Peer - CLI.

Info

title	Note

If using an IP address, create different IP peers for each IP address configured in the MRF cluster profile as an MRF IP address and attach the Path Check profile.

If using an FQDN, create the IP peer with an FQDN and attach the Path Check profile.

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.

For End point CAC, create CAC profile and attach to the IP Peer.
For trunk group CAC, create a CAC profile and attach it to the MRF trunk group as configured in the cluster profile.
Info
title Note
Endpoint CAC does not support FQDN.
Info
title Note
Bandwidth CAC is not supported for both trunk group and peer level.

Invoking the MRF Server

In a cluster profile, you can configure the routing type for an FQDN or a list of IP addresses.

MRF Server Configured as FQDN

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:

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 that lasts 32 seconds. 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.

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.

Selecting an SRV RR based on priority and weight

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.

If the target host is “.”, SBC discards the record.
SBC use priority and weight fields in SRV record selection.
- SBC attempts to contact the target host with the lowest-numbered priority it can reach.
- If multiple records has the same priority, the SBC usesthe weight field to select the target host with records with larger weight given a proportionately higher probability of being selected.
  - 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

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.

MRF Server configured as IP

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 addresses then 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, the same IP address is blacklisted. 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 the same IP when the next call is routed to MRF Server.
The S-SBC tries for the next available MRF server IP address configured in the list alternatively.
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 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

Signaling and Media flow for a transcoded call using an S-SBC, M-SBC and MRF:

S-SBC: Provides signaling services and responsible 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.

Caption

0	Figure
1	Signaling and Media Flow

Image Added

Pagebreak

Modify MRF Cluster Type

Log on to the EMA Configurator as admin.

Click All tab.

On the navigation pane, click System > DSBC > Cluster > Type.

Caption

0	Figure
1	Type List

Image Removed
Select the radio button adjacent to the MRF name. The Edit Selected Type window is displayed.

Caption

0	Figure
1	Edit Selected Type - IP Address

Image Removed

Caption

0	Figure
1	Edit Selected Type - FQDN

Image Removed

To modify the Type, you must first select the State as Disabled, and click Save.

Select the radio button adjacent to the MRF name.

Make the relevant modifications, and select State as Enabled.

Click Save.

Deleting MRF Cluster Type

Log on to the EMA Configurator as admin.

Click All tab.

On the navigation pane, click System > DSBC > Cluster > Type.

To delete the Type, you must first select the MRF cluster profile State as Disabled, and click Save.

Once the Type is listed, click Delete this element button adjacent to MRFFQDN column.

Caption

0	Figure
1	Type List

Image Removed

Creating Policer Cluster Type

To establish connection between SBC and MRF, create an Policer Cluster Type.

Log on to the EMA Configurator as admin.

Click All tab.

On the navigation pane, click System > DSBC > Cluster > Type.

Caption

0	Figure
1	Type List

Image Removed
Click +New Type. By default, Create New Type window for Policer is displayed.

Caption

0	Figure
1	Create New Type - Policer

Image Removed

In Name drop-down menu, choose Policer.
Select the State.
Type FQDN.
In DNS Group drop-down menu, choose the DNS Group.
Click Save.

Modifying Policer Cluster Type

Log on to the EMA Configurator as admin.

Click All tab.

On the navigation pane, click System > DSBC > Cluster > Type.

Caption

0	Figure
1	Type List

Image Removed
Select the radio button adjacent to the Policer name. The Edit Selected Type window is displayed.

Caption

0	Figure
1	Edit Selected Type

Image Removed

To modify the Type, you must first select the State as Disabled, and click Save.

Select the radio button adjacent to the Policer name.

Make the relevant modifications, and select State as Enabled.

Click Save.

Deleting Policer Cluster Type

Log on to the EMA Configurator as admin.

Click All tab.

On the navigation pane, click System > DSBC > Cluster > Type.

Once the Type is listed, click Delete this element button adjacent to MRFFQDN column.

Caption

0	Figure
1	Type List

Image Removed

CAM Changes

Four new fields indicating the Ingress and the Egress Leg media connection details towards MRF is added as sub-fields to existing CDR field, Media Stream Data (field#230)

Caption

0	Table
1	CDR Fields and Descriptions

CDR Fields	Length/Range	Descriptions	Sample Value
Ingress Private Leg Local EP1	57	Contains the Ingress Leg local media IP and port offered by DSBC in the INVITE message to MRF.	10.54.4.101:1116
Ingress Private Leg Remote EP1	57	Contains the Ingress Leg remote media IP and port present in the answer SDP received from MRF.	10.54.4.171:1094
Egress Private Leg Local EP1	57	Contains the Egress Leg local media IP and port offered by DSBC in the INVITE message to MRF.	10.54.4.101:1118
Egress Private Leg Remote EP1	57	Contains the Egress Leg remote media IP and port present in the answer SDP received from MRF.	10.54.6.171:1090
Transcode Resource Type	4	Indicates the type of transcoder used for the call.	TSBC/MRF
MRF INFORMATION	39	Stores MRF related information. Options: Signaling IP Signaling PORT	IP: 10.54.6.178 Port: 1099

New Standards

Sonus S-SBC invokes the MRF using a 3PCC call model as per RFC-4117.

SBC Platforms Supporting this Feature

Caption

0	Table
1	Supported Platform

Virtualization/Cloud Platforms

For Cloud:

SWe on OpenStack (D-SBC)

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 1

New Version Current

Key

Overview

Audio Transcoding and Video Relay

T.140 and TTY Interworking Support

Limitations

Prerequisites to Invoking MRF

Configure an MRF Profile on the S-SBC

Feature Overview

Prerequisites to invoke MRF

Additional Configuration

Path Check Profile

ARS Profile

CAC Profile

Invoking MRF Server

Signaling and Media Flow

CLI Changes

Command Parameters

Command Syntax

Configuration Example

Debug Stat Commands

EMA Changes

Creating MRF Cluster Type

Configure Private LIF Groups on the M-SBC

Debug Statistics Commands

Create a Path Check Profile, ARS profile, and CAC Profile During Initial Configuration

Path Check Profile

ARS Profile

CAC Profile

Invoking the MRF Server

MRF Server Configured as FQDN

Selecting an SRV RR based on priority and weight

Selecting an A/AAAA RR based on configuration

MRF Server configured as IP

Signaling and Media Flow

Modify MRF Cluster Type

Deleting MRF Cluster Type

Creating Policer Cluster Type

Modifying Policer Cluster Type

Deleting Policer Cluster Type

CAM Changes

New Standards

SBC Platforms Supporting this Feature