Sie sind auf Seite 1von 9

SE9SRFCRED00 RFC2198 Redundancy

Definition

RFC2198 redundancy enables the SE2900 to convert RTP packets between the redundant and
non-redundant formats. With this function, the SE2900 allows UEs using the same media codec but
different encoding formats (redundant and non-redundant) to communicate with each other. The
RFC2198 redundancy function uses a redundant encoding scheme that transmits redundant media
packets to compensate for packet loss and ensure call quality.
This function provides redundancy format conversion for audio packets but not for video packets.
The supported audio codecs are as follows:
 On the fixed-line phone network: G.711 (including G.711 a-law and G.711 μ-law), G.722,
G.723, G.726, G.728, G.729, and G.729E
 On the mobile network: GSM (including EFR, FR, and HR), AMR, AMR-WB, AMR-WB+,
Q8, Q13, EVRC, and 4GV-NB
 On the Internet: Internet low bit rate codec (iLBC)
The following is example SDP description for the RFC2198 redundant format:
m=audio 12345 RTP/AVP 106 18
a=rtpmap:106 red/8000
a=fmtp:106 18/18/18
a=ptime:20

Benefits

For... Benefits

Carriers RFC2198 redundancy enhances carrier service competitiveness and increases


carriers' revenues.

Users This feature enables users to use assured audio services and allows users to have
the same audio quality experience on different networks.

Requirements

NE Function

SBC Converts media packets between the redundant and non-redundant formats.
UE Sends media packets.

Supporting Versions
SE2900 V300R001C00 and later
License Requirements
The RFC2198 Redundancy feature is optional. A license is required for this feature. The license
control item for this feature is "RFC2198 Redundancy (per concurrent session)".
Impact on the System

This feature has no adverse impact on the system.

Application Limitations

 When performing RFC2198 redundant format conversion, RFC2198 redundancy has the
following application limitations:
 Supports RFC2198 redundant format conversion in the SIP-to-SIP interworking
scenario.
 Applies only to the A-SBC scenario, in which the SE2900 negotiates the RFC2198
redundancy capability on the access side with the UE.
 The RFC2198 redundant format conversion service has the following restrictions and
requirements on access-side and core-side media formats:
 Access-side and core-side media codec types and codec ptime must be the same.
 The SE2900 supports a maximum of two levels of redundancy.
 The SE2900 negotiates RFC2198 redundant format conversion for a maximum of
five codecs each time.
 If RFC 2833 packets are involved in a session, both the caller and callee in the
session must support the RFC 2833 capability. The SE2900 does not support
RFC2198 redundant format conversion for RFC 2833 RTP packets.
 If redundant packets with multiple levels of redundancy are involved in a session,
these redundant packets must have the same payload type (PT).
 The SE2900 does not support redundant format conversion between an access-side
and a core-side that have the same codec type but different redundancy levels.
 If the redundant format carried in SDP offer/answer contains different codec types in
RFC2198 redundancy capability negotiation, the SE2900 does not support RFC2198
redundant format conversion. The following is an example SDP description:
 m=audio 12345 RTP/AVP 121 0 5
 a=rtpmap:121 red/8000/1
 a=fmtp:121 0/5

 The SE2900 must renegotiate the RFC2198 redundancy capability with the caller and
callee based on signaling before performing redundant format conversion or changing
RFC2198 redundancy levels.

Interaction with Other Features

Feature Interaction

Media The RFC2198 redundancy feature and the media bypass feature are mutually
Bypass exclusive.
 If the RFC2198 redundancy feature is enabled on the AN to which the caller
and the callee belong and calls use the audio codecs supported by RFC2198,
automatic media bypass and intra-AN automatic media bypass cannot be
implemented for the calls. If calls are non-audio or the codecs used in the calls
are not supported by RFC2198, automatic media bypass and intra-AN
Feature Interaction

automatic media bypass can be implemented for the calls.


 If forced media bypass is enabled, the RFC2198 redundancy feature
automatically ceases to be effective.
Application Scenario

The RFC2198 redundancy function applies to the A-SBC scenario in which soft terminals access
the SE2900 through the Internet. To ensure call quality, configure the RFC2198 redundancy
function.
Figure 1 shows the networking for the RFC2198 redundancy function in an A-SBC scenario.
Figure 1 Networking for the RFC2198 redundancy function

The SE2900 encapsulates the main audio frame to be transmitted and the audio frame in the
previous RTP packet (which is the redundant frame) into an RFC2198 redundant RTP packet and
transmits the audio frame multiple times. A higher redundancy level allows the transmission of more
redundant frames and therefore ensures a better call quality. A higher redundancy level allows the
transmission of more redundant frames and therefore ensures a better call quality. You can run
ADD BCPLC to configure the redundancy level.

Implementation Principle

Service Scenario I: UE-initiated RFC2198 Redundancy Capability Negotiation


Figure 2 shows the flowchart for UE-initiated RFC2198 redundancy capability negotiation.
Figure 2 Flowchart for UE-initiated RFC2198 redundancy capability negotiation

NOTE:
The SDP negotiation procedure for the RFC2198 redundancy capability refers to the offer/answer
model defined in RFC 3261 or RFC 3264. The offer/answer correspond to INVITE and 200 OK
messages respectively, in Figure 2.

P1:
Upon receiving an offer (an INVITE message) from the access network, the SBC forwards the offer
to the core network without modifying the SDP description in the offer. This is because the SBC
does not initiate RFC2198 redundancy capability negotiation on the core side.
The following is an example SDP offer:
m=audio xxx RTP/AVP 107 18 126
a=rtpmap:107 iLBC/8000
a=fmtp:107 mode=20
a=rtpmap:18 G729/8000
a=rtpmap:126 red/8000
a=fmtp:126 18/18/18
a=ptime:20
P2:
Upon receiving the offer from the core network, the SBC initiates RFC2198 redundancy capability
negotiation on the access side when forwarding the offer to the access network.
 If the received offer contains a G.729 redundancy capability, the SBC does not add G.729
redundancy capabilities of other levels.
 If the received offer contains the iLBC codec but the iLBC codec does not carry the iLBC
redundancy capability, the SBC adds the iLBC redundancy capability to the offer.
Then the SBC forwards the offer to the access network.
The following is an example SDP offer:
m=audio xxx RTP/AVP 107 18 126 127
a=rtpmap:107 iLBC/8000
a=fmtp:107 mode=20
a=rtpmap:18 G729/8000
a=rtpmap:126 red/8000
a=fmtp:126 18/18/18
a=rtpmap:127 red/8000
a=fmtp:127 107/107/107
a=ptime:20
P3:
Upon receiving an answer (a 200 OK message that contains the media capability selected by the
callee) from the access network, the SBC compares the SDP description in this answer with the
SDP description in the offer originating from the core network. This answer contains only the iLBC
codec that carries the iLBC redundancy capability, but the offer does not require the iLBC
redundancy capability. The requirements for redundancy capabilities on the access side and core
side are different. The SBC needs to apply for resources to implement conversion between
redundant formats of access-side redundant RTP packets and core-side non-redundant RTP
packets.
The following is an example SDP answer:
m=audio xxx RTP/AVP 107
a=rtpmap:107 iLBC/8000
a=fmtp:107 mode=20
a=ptime:20

NOTE:
The SBC, based on the offer/answer model, negotiates the RFC2198 redundancy capability for the
codec, which is used by both the access side and core side. Therefore, there is a probability that
the access side supports the non-redundant format but the core side supports the redundant format
to avoid large end-to-end delay caused by redundant format conversion on multiple nodes in a
session.

P4:
Upon receiving an answer (a 200 OK message that contains the media capability selected by the
callee) from the core network, the SBC compares the SDP description in this answer with the SDP
description in the offer originating from the access network. This answer contains the iLBC codec
and the media capability is a subset of the media capability in the offer. Therefore, media format
conversion is not required.
The SBC returns an answer containing the iLBC codec to the access network.
P5:
The SBC receives an RTP packet containing the iLBC codec from the core network and performs
redundant format conversion.
 The SBC parses the received RTP packet to obtain the codec frame.
 The SBC combines frames into a redundant RTP packet, which contains a main frame and
two redundancy frames. The two redundancy frames are the main frames of the previous
redundant RTP packet. The SBC sends the redundant RTP packet to the access network.
P6:
Upon receiving a redundant RTP packet containing the iLBC codec from the access network, the
SBC performs redundant format conversion.
 The SBC disassembles the received redundant RTP packet to find the main frame. If no
main frame is found, the SBC will find the main frame from the next redundant RTP
packet.
 The SBC reassembles the main frame into an RTP packet containing the iLBC codec and
sends the RTP packet to the core network.
Service Scenario II: UE-initiated RTP Packet RFC2198 Redundancy Level Renegotiation
Figure 3 shows the flowchart for UE-initiated RTP packet RFC2198 redundancy level renegotiation.
Figure 3 Flowchart for UE-initiated RTP packet RFC2198 redundancy level renegotiation

P1:
Upon receiving an offer from the access network, the SBC forwards the offer to the core network
without modifying the SDP description in the offer.
P2:
Upon receiving the offer from the core network, the SBC initiates RFC2198 redundancy capability
negotiation on the access side when forwarding the offer to the access network. The received offer
contains only the iLBC codec that carries the RFC2198 redundancy capability. The SBC does not
add the redundancy capability or modify the SDP description.
P3:
Upon receiving an answer (a 200 OK message that contains the media capability selected by the
callee) from the access network, the SBC compares the SDP description in this answer with the
SDP description in the offer originating from the core network. This answer contains the iLBC codec
and the media capability is a subset of the media capability in the offer. Therefore, media format
conversion is not required.
The SBC returns an answer containing the iLBC codec to the core network.
P4:
Upon receiving an answer (a 200 OK message that contains the media capability selected by the
callee) from the core network, the SBC compares the SDP description in this answer with the SDP
description in the offer originating from the access network. This answer contains the iLBC codec
and the media capability is a subset of the media capability in the offer. Therefore, media format
conversion is not required.
The SBC returns an answer containing the iLBC codec to the access network.

Charging and CDR

None

Feature Specifications

Item Specifications

Maximum number of concurrent 14000


calls supported by each pair of
single-CPU ISUs to implement
RFC2198 redundancy format
conversion
Maximum number of concurrent 21000
calls supported by each pair of
single-CPU ESUs to implement
RFC2198 redundancy format
conversion
Maximum number of concurrent 28000
calls supported by each pair of
dual-CPU ISUs to implement
RFC2198 redundancy format
conversion
Maximum number of concurrent 42000
calls supported by each pair of
dual-CPU ESUs to implement
RFC2198 redundancy format
conversion
Standards Compliance
Category Name Purpose Remarks

IETF RFC 2198: RTP Defines RTP redundant Complete compliance


Payload for Redundant packet formats and
Audio Data RTP redundancy
capabilities in SDP.

Das könnte Ihnen auch gefallen