In this section:

Overview

The Multimedia Telephony Service for IMS (MTSI), which is also known as Multimedia Telephony is a standardized IMS telephone service in 3GPP. The objective of defining a service is to specify the minimum set of capabilities required in the IP Multimedia sub-system to secure multi-vendor and multi-operator inter-operability for Multimedia Telephony and related Supplementary Services.

The user experience of multimedia telephony is equivalent to or better than corresponding circuit-switched telephony services. Multimedia telephony also exploits the richer capabilities of IMS. In particular, multiple media components can be used and dynamically added or dropped during a session.

The MTSI client functionality is required when the SBC is deployed as:

  • MGCF providing interworking between an MTSI client and a non-MTSI client (that is, a CS UE).
  • Access SBC media gateway.

 

MTSI Workflow

Adaptive Multi-Rate (AMR) Support

SBC Core supports AMR Initial codec mode as per 3GPP26.114 specification. When AMR or AMR-WB is used, to avoid congestion on the link and to improve inter-working with CS GERAN, the SBC limits the initial codec mode for a session to a lower mode until at least one frame-block. On enabling "Initial codec mode" while creating AMR Codec Entry, an AMR call starts with a lowest mode rate or second lowest mode rate until it receives a CMR request from the U.E to adapt the mode rate to a different value. If disabled, the AMR call starts with the highest mode rate within the negotiated mode-set.

The SBC also supports the following functionality:

  • AMR to AMR transcoding for both restricted and unrestricted mode set
  • AMR to non-AMR transcoding
  • AMR attributes such as mode-change-period, mode-change-capability and mode-change-neighbor.

The SBC does not support the following AMR attributes:

  • CRC
  • Robust-Sorting
  • Interleaving

The existing DSPs support CMR interpretation and updating the transmission rate according to peer's CMR requests.

The Synchronization info attribute does not transparently pass during the transcoded and pass-through calls.

For a configuration example, see Configuring AMR/AMR-WB Options.

b=AS Support for AMR/AMR-WB/EVS Codecs

The SBC Core supports to calculate the bandwidth value for AMR and AMR-WB codecs according to the 3GPP TS 26.114 standard.

This feature also enables the SBC to include the b=AS attribute for the core audio stream in the outgoing offer and answer SDP. The value of the b=AS attribute is calculated according to the worst case voice codec that is in the m=audio line. 

The sipTrunkGroup media configuration adds the appSpecificBandwidth flag to control when the SBC sends the b=AS attribute for the core audio stream. If the appSpecificBandwidth is disabled (default value), the SBC does not send the b=AS attribute in the SDP.  If the appSpecificBandwidth flag is enabled on a trunk group, the SBC sends the b=AS attribute in the SDP outgoing offer or answer sent on that trunk group. 

Note

The SBC inserts only the b=AS attribute in the outgoing SDP offer and answer. The SBC does not insert any other bandwidth attribute.

This feature does not support the insertion of the b=AS SDP attribute for non-audio streams or at the session level. The b=AS SDP attribute does not apply to the H.323 signaling interface.

The SIP to SIP call flow is supported.

Note

This feature does not support the insertion of the b=AS attribute for direct media and audio transparency call flows.


The following call flow illustrates the SDP outgoing offer with the b=AS attribute.


b=AS in SDP Outgoing Offer

 


The following call flow illustrates the SDP outgoing answer with the b=AS attribute.

b=AS in SDP Outgoing Answer


Real-Time Transport Control Protocol (RTCP) Bandwidth Interworking Support

The SBC Core supports RTCP bandwidth interworking by negotiating RR and RS bandwidth parameters. However, the SBC does not allow using RTCP in a peer-to-peer voice call. This can be disabled at the MTSI client by setting RS=0 and RR=0 during call setup. But when a call is HELD, MTSI clients can enable RTCP to prevent the triggers of RTP inactivity.

Note

The SBC supports enabling the RTCP for point-to-point calls only when the call is HELD based on the PSX configuration flag.

Note

In sessions with video and audio streams, the SBC now distinguishes between “audio” and “video” so that calls will not be discontinued due to call-hold RTP inactivity. This solution allows enabling/disabling of the RTP inactivity timer on audio and video individually. This means that sessions with an audio stream, but no video stream, the session will stay live.


The SBC supports:

  • Relaying RTCP packets irrespective of zero or non-zero RS and RR values. 
  • Passing the received RS and RR values without changing them.
  • Sending the RR and RS values in the outgoing SDP (to peers or Media Resource Function (MRF)) only when the SBC receives these values.
  • The RTCP must be enabled on both the legs (route PSPs).
  • The flags enableRTCPForHeldCalls and terminationForPassthrough must be disabled on both the route PSPs.
  • The RR and RS values must be configured to the maximum values of 4000 bps and 3000 bps respectively.

Including RR/RS in the SDP

The SBC includes RR and RS values in the outgoing SDP if the IPSP flag sendRTCPBandwidthInfo is enabled and RR and RS attributes are received from the peer.

  • If SDP offer received from the User-Agent Client (UAC) contains RR/RS attributes, the SBC includes RR/RS values in the outgoing SDP towards User-Agent Server (UAS) or in the first part of the SDP towards MRF.
  • If SDP answer received from the UAS contains RR/RS attributes, the SBC includes RR/RS values in the outgoing SDP towards UAC or in the second part of the SDP towards MRF.

Calculating RR/RS

The SBC computes RR/RS values as described below:

  • During an offer, the SBC relays RR/RS values to UAS after normalization with route PSPs.
  • During an answer, following are the behavior:
    • For pass-through calls, the SBC sends the answer with the received RR/RS values from UAS (after normalization with route PSPs) to the UAC.
    • For MRF transcoded calls,
      • The SBC sends the RR/RS values it received from the UAC/UAS in m1/m2 respectively (after normalization with route PSPs) to MRF.
      • The SBC sends answer to UAC with the RR/RS values it received from the MRF in the first part corresponding to the ingress peer (after normalization with route PSPs).
      • The SBC does not include the RR/RS attributes in the answer to the UAC, if MRF does not include RR/RS attributes in the response.
    • For I/T-SBC transcoded calls, the SBC sends answer to UAC with the RR/RS values it received from the UAC (after normalization with route PSPs).

Relaying or Terminating RTCP

The SBC relays the RTCP for pass-through and MRF transcoded calls. However, the SBC continues to terminate the RTCP for the SBC transcoded calls.

Call Flow Scenarios

The following call flow scenarios provide RTCP behavior for the SBC pass-through calls, SBC transcoded calls, and MRF transcoded calls:

Note

In these scenarios:

  • The MRF must respond with the same RR/RS values as sent by the SBC. If the SBC does not include RR/RS, MRF does not respond with them.
  • The RTCP is enabled on both the legs and RR and RS values are configured to the maximum values of 4000 bps and 3000 bps respectively.
  • x means RR/RS not included in the SDP.

Pass-through Calls

ScenariosCall FlowsPass-through Calls
1

-------RR/RS=500-----> SBC----- RR/RS=500------>

<-----RR/RS=400 ------ SBC <----  RR/RS=400 ------

RCTP ports on the SBC: ON
2

-------RR/RS=500-----> SBC----- RR/RS=500------>

<-----RR/RS=0 -------   SBC <----  RR/RS=0 ------

RTCP ports on the SBC: OFF
3

-------RR/RS=500-----> SBC----- RR/RS=500------>

<-----RR/RS=x -------   SBC <----  RR/RS=x ------

RTCP ports on the SBC: ON
4

-------RR/RS=0-----> SBC------- RR/RS=0------>

<-----RR/RS=0 -------SBC <----  RR/RS=0 ------

RTCP ports on the SBC: OFF
5

-------RR/RS=0 -------> SBC------- RR/RS=0------>

<-----RR/RS=400 -------SBC <----  RR/RS=400 ----

RTCP ports on the SBC: OFF
6

-------RR/RS=0----->    SBC ----- RR/RS=0------>

<-----RR/RS=x -------   SBC <----  RR/RS=x ------

RTCP ports on the SBC: OFF
7

-------RR/RS=x -------> SBC ----- RR/RS=x------>

<-----RR/RS=x -------   SBC <----  RR/RS=x ------

RTCP ports on the SBC: ON
8

-------RR/RS=x -----> SBC----- RR/RS=x------>

<-----RR/RS=0 -------SBC <----  RR/RS=0 ------

RTCP ports on the SBC: OFF

MRF Transcoded Calls

ScenariosCall FlowsMRF Transcoded Calls
1

-------RR/RS=500-----> SBC ----- RR/RS=500------>
<-----RR/RS=500 ------ SBC <----  RR/RS=400 ------

RR/RS sent by the SBC to the MRF:

m1=500
m2=400

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: ON

2

-------RR/RS=500-----> SBC----- RR/RS=500------>

<-----RR/RS=500 -----   SBC <----  RR/RS=0 ------

RR/RS sent by the SBC to the MRF:

m1=500
m2=0

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: OFF

3

-------RR/RS=500-----> SBC----- RR/RS=500------>
<-----RR/RS=500 ------  SBC <----  RR/RS=x ------

RR/RS sent by the SBC to the MRF:

m1=500
m2=x

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: ON

4

-------RR/RS=0-----> SBC------- RR/RS=0------>
<-----RR/RS=0 -------SBC <----  RR/RS=0 ------

RR/RS sent by the SBC to the MRF:

m1=0
m2=0

Ingress RCTP port on the SBC: OFF

Egress RCTP port on the SBC: OFF

5

-------RR/RS=0 -------> SBC------- RR/RS=0------>
<-----RR/RS=0 -------SBC <----  RR/RS=400 ----

RR/RS sent by the SBC to the MRF:

m1=0
m2=400

Ingress RCTP port on the SBC: OFF

Egress RCTP port on the SBC: ON

6

-------RR/RS=0----->    SBC ----- RR/RS=0------>
<-----RR/RS=0 -------   SBC <----  RR/RS=x ------

RR/RS sent by the SBC to the MRF:

m1=0
m2=x

Ingress RCTP port on the SBC: OFF

Egress RCTP port on the SBC: ON

7

-------RR/RS=x -------> SBC ----- RR/RS=x------>
<-----RR/RS=x -------   SBC <----  RR/RS=x ------

RR/RS sent by the SBC to the MRF:

m1=x
m2=x

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: ON

8

-------RR/RS=x -----> SBC----- RR/RS=x------>
<-----RR/RS=x -------SBC <----  RR/RS=0 ------

RR/RS sent by the SBC to the MRF:

m1=x
m2=0

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: OFF

SBC Transcoded Calls

ScenariosCall FlowSBC Transcoded Call
1

-------RR/RS=500-----> SBC ----- RR/RS=500------>

<-----RR/RS=500 ------ SBC <----  RR/RS=400 ------

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: ON

2

-------RR/RS=500-----> SBC----- RR/RS=500------>

<-----RR/RS=500 -----   SBC <----  RR/RS=0 ------

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: OFF

3

-------RR/RS=500-----> SBC----- RR/RS=500------>

<-----RR/RS=500 ------  SBC <----  RR/RS=x ------

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: ON

4

-------RR/RS=0-----> SBC------- RR/RS=0------>

<-----RR/RS=0 -------SBC <----  RR/RS=0 ------

Ingress RCTP port on the SBC: OFF

Egress RCTP port on the SBC: OFF

5

-------RR/RS=0 -------> SBC------- RR/RS=0------>

<-----RR/RS=0 -------SBC <----  RR/RS=400 ----

Ingress RCTP port on the SBC: OFF

Egress RCTP port on the SBC: OFF

6

-------RR/RS=0----->    SBC ----- RR/RS=0------>

<-----RR/RS=0 -------   SBC <----  RR/RS=x ------

Ingress RCTP port on the SBC: OFF

Egress RCTP port on the SBC: OFF

7

-------RR/RS=x -------> SBC ----- RR/RS=x------>

<-----RR/RS=x -------   SBC <----  RR/RS=x ------

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: ON

8

-------RR/RS=x -----> SBC----- RR/RS=x------>

<-----RR/RS=x -------SBC <----  RR/RS=0 ------

Ingress RCTP port on the SBC: ON

Egress RCTP port on the SBC: OFF