Page History

Overview

Audio

Transcoding and Video Relay

Multiexcerpt
MultiExcerptName Invoke MRF Intro
SBC SWe systems in an OpenStack cloud environment inter-operate with

The SBC uses

a third-party transcoding platform called Media Resource Function (MRF) to transcode audio and relay video/T140.

The SBC inter-operates only with Media Resource Function (MRF) a third-party application/tool.

Note
Only SBC SWe on OpenStack (D-SBC) supports this enhancement.

The SBC supports the following:

Note
The SBC supports this functionality only for MRF transcoded calls on D-SBC platform.

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.
  

Note
If the Packet Service Profile is configured as "Transcode-only", the SBC transcodes the audio and relays video/ T140.

Limitations

The limitations are:

• The SBC does not support audio less call.
• The SBC does not support video licenses. Only one video stream is supported.
• The SBC supports only video and T140 streams among the non-audio streams.

For more information on CLI changes and CDR changes, refer to:

• CAM Changes
• D-SBC with Third-Party MRF as Transcoder in CLI

Prerequisites to invoke MRF

The following existing controls that cause the SBC to include DSP applies when invoking MRF.

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.

• Audio and T.140 transcode through MRF (see T.140 and TTY Interworking Support below)

T.140 and TTY Interworking Support

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

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.

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

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

1. Configure MRF Profile in S

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 to the MRF TG 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 MRF Server

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

1. -SBC
2. Configure Private LIF Groups in M-SBC

The following CLI command is required to configure the MRF cluster profile in M-SBC.

To configure Private IP Interface Group that communicates towards 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

The following CLI can be used to get the media statistics corresponding to 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 new 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.

1. Enable transcoding at the Packet Service Profile (refer to 

   Link_in_new_tab
   Text Packet Service Profile - CLI URL Packet Service Profile - CLI

   ).
2. Create a Path Check Profile, ARS profile, and CAC profile during the initial configuration

Configure an MRF Profile on the S-SBC

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

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.

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

Invoking the MRF Server

 % set addressContext <address_context> zone <zone name> sipTrunkGroup <TG Name> signalling retryCounters invite <0-6>

# _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.

% set addressContext <addressContext name> dnsGroup <dnsGroup name> server <DNS server name> recordOrder <centralized-roundrobin | priority | roundrobin>

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.