RTP


In VoLTE/IMS Node testing, the RTP tab on the Gm, I2, etc > Media tab allows you to define the RTP traffic profile and resource allocation.

The Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video over IP networks. RTP is used extensively in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features.

RTP is used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams. RTP is originated and received on even port numbers and the associated RTCP communication uses the next higher odd port number.

RTP is one of the technical foundations of Voice over IP and used in conjunction with a signaling protocol which assists in setting up connections across the network (RFC 1889, superseded by RFC 3550).

RTT (Real Time Text) per RFC4103. Protocol for multimedia application text conversation per T.140. Session description protocol (SDP) per RFC2327.

  • RTP DMF 1                               Enable SRTP

  • Type

  • Role

  • Rating Group

  • Service ID

  • RTP DMF 2                               Enable SRTP
  • Type

  • Role

  • Rating Group

  • Service ID

  • RTP DMF 3                               Enable SRTP
RTP Traffic
Enable RTCP
  • Check Interval (ms)
  • Number of UEs Performing RTCP
    • Selection Mode
      • Continuous
        • First UE
      • Random
Voice   Tones
  • Transmit
    • Send Level (dBm)
  • DTMF Tones
    • Time on (ms)
    • Interdigit Pause (ms)
    • Frequencies
  Enable Call Progress Tones

  

Enable RFC2833/RFC4733 - Support for Dual Tone Multi-Frequency (DTMF) on VoLTE.

Enable Audio Recording

 


RTP DMF 1, 2 and 3

  • Type

  • Role

  • Rating Group

  • Service ID

Select the type, Role, Rating Group, and Service ID associated with the RTP traffic.

Select to Enable SRTP. A new tab SRTP will be enabled to enter Secure Real-Time Transport Protocol for a media file. Available for DMF 1, 2 and 3.

  • Type — Indicates the type of media sent with DMF 1, DMF 2 and DMF 3. Select the relevant media type: Audio or (Video or RTT) (Real Time Text). Currently can only support Audio and either Video or RTT - Not all three. When an RTT DMF Type is selected the RTT fields are displayed instead of Video.  

NOTE: The RTP streams follow the basic naming conventions and are added to the Basic library:

DMF in Basic Library:

RTP-Voice-Basic

RTP-Video-Basic

RTP- RTT- Basic

Real CODECs naming:

RTP-Voice-<Codec>

RTP-Video-<Codec>

  • Role — Select the role of RTP DMF: Default, Server, Client.

RtpDmf1Role

RtpDmf2Role

RtpDmf3Role

 

NOTE: The DMF resource allocation is based on the number of SIP Subscribers per UE and their functionality.

For example:

  • For number of UEs = 2, 1 SIP Subscriber per UE are configured: Sub1@UE1 and Sub2@UE2;
  • Sub1 is Originate; Sub2 is Terminate
  • 2 DMFs are configured:Originate and Terminate
  • Rating Group — Indicates the group of services that share the same cost/rating type. A Rating Group can include one service or group of services that share the same cost and rating type — HTTP and email services could be defined in one Rating Group, for example, while multimedia services are defined in another.

RtpDmf1RatingGroup

RtpDmf2RatingGroup

RtpDmf3RatingGroup

 

  • Service ID — Indicates the Service ID for which the credit is granted. The server can choose whether to grant credit for individual services within the same Rating Group or grant credit for the entire Rating Group. In the latter case, all services within a group can draw from the same credit pool.

RtpDmf1ServiceId

RtpDmf2ServiceId

RtpDmf3ServiceId

 

RTP Traffic Start Delay (ms)

Available only if there is at least one DMF included. Enter the required delay.

Default: 1000

Tcl Parameter: RtpTrafficStartDelay

Report Confidence Intervals

Available in AMF Nodal, MME Nodal, and IP Application Node when Enable Mobile to Mobile is enabled on the WebRTC client.

Enable to report the confidence intervals on L57- Voice / Video.  

Tcl Parameter: RtpConfidenceStatsEn

Fireball

Select to send RTP data at a faster rate. Simultaneous RTP Voice and Video are supported. This is a licensed feature.

Additional details in Fireball Data Message Flows. See this table for supported options.

Available in IP Application Node, MME Nodal, PGW Nodal and SGW Nodal test cases.

Tcl Parameter: VolteFireballEn

RTP Traffic

See Data Message Flow (Data Traffic Tab > Data Message Flows) to create RTP DMFs for VoLTE testing.

See DMF | RTP Voice for using rtpvoice protocol.

NOTE: Basic Library includes the following two RTP DMFs:

RTP-Voice-Basic

RTP-Video-Basic

 

RTCP

Enable RTCP
  • Enable RTCP  — Enables the RTCP (Real-Time Transport Control Protocol - defined in RFC 3550) Pane which allows for capture of statistical and control data and works hand in hand with RTP that delivers the data. Additional OMs can be found in the RTP Voice and RTP Video Measurements. RFC 3661 - RTP Control Protocol Extended Reports (RTCP XR) and RFC 7266 - RTCP XR Blocks for Mean Opinion Score (MOS) Metric Reporting.

RtcpEn

 

  • Check Interval (ms) — Indicate the interval in milliseconds that the RTCP reports are sent  out. Range: 100 - 4294967295. Default: 5000.

NOTE: RTCP affects RTP performance. Thus, Check Interval value should be big enough to minimize its performance impact.

 

  • Number of UEs Performing RTCP - Enter the number of UEs performing RTCP. Because RTCP is time consuming, enter the number of UEs performing RTCP operations either Continuous range or pick a certain number of UEs randomly. If Continuous is selected, enter the First UE . By restricting the range we allow for high capacity RTP configurations in Fireball mode with RTCP.

RtcpNumUes

RtcpSelectMode

RtcpFirstUe

NOTE:

  • Both "UEs Performing RTCP" and "First UE" fields have a dynamic maximum equal to the "Number of Subscribers" value for the test.  The range of UEs performing RTCP is meant to be contiguous.  The group will not wrap back to the first UE, the TS will truncate the group size. The GUI and Tcl validation set a warning if the "First UE" is provisioned with a value that will truncate the number of UEs performing RTCP.
  • Example or the warning message : Voice Traffic - Truncation: RTCP Index of First UE [RtcpFirstUe=92] must be <= 91 for an RTCP group size of 10

 

 

Voice

Call Progress Tones - RFC 3960 - Early Media and Ringing Tone Generation

Tones

Select Tones Transmit Send Level (dbm).

Options: - 4, - 7, - 10, - 13, - 16, - 19, - 22, -25

TonesSendLevel

 

DTMF Tones.

  • Enter Time on in milliseconds. Range: 75 to 3600000. Default : 150

  • Enter Interdigit Pause in milliseconds. Range: 75 to 3600000. Default : 150

  • Select Frequencies table:

TonesTimeOn

TonesInterdigitPause

 

Enable Call Progress Tones

Available if Enable RTP Traffic is selected, Functionality Pattern = All Originate or TOTO or OTOT and DMF = rtpvoice (on Nodal test cases).

Available if Mode = SIP Endpoint, Enable RTP Traffic is selected, Final Response Delay is selected, Functionality Pattern = All Terminate or TOTO or OTOT and DMF = rtpvoice (on IMS Node test case).

To make Ringtone detection possible go to Test Server Configuration and select Reserve Resources for : Digital Signal Processing (mutually exclusive with POLQA/VMAF).

Select to add support for ringback tone detection during SIP based MO call setup. SIP has its own embedded mechanism to notify Caller that the Callee is alerting: “180 – Ringing” message. An alternative way is to send ringback tone over early media. Early media is a data path that may have to be established between Caller side and Session Boarder Controller (SBC) or so after sending INVITE and receiving a final response (200 OK on INVITE or 4xx/5xx/6xx). The diagrams below show both ringing models: SIP 180 Ringing and Ringback Tone over early media.

Two Ringing models: SIP 180 (Left) and Ringback tone (Right)

NOTES:  

  • We assume that ringback tone consists of just two frequencies (f1 and f2),  More complex ringback tone, like music phrase or a voice announcement are not supported at this time.
  • The tones are recognized by DSP functionality (Soft DSP) running optimized version of Goertzel algorithm.
  • As the algorithm is time consuming, the ringback tone recognition may be applied to a subset of the UEs configured in test.
  • The main Audio Codecs used for ringback tone is G.711-muLaw and G.711-ALaw. In addition, G.722, AMR and iLBC codecs are also supported.

 

Tcl Parameter : CptEn

Send Level (dBm)

Select the Send Level in dBm.

Default = -7

Range: -4, -7, -10, -13, -16, -19, -22 , -25

Tcl Parameter : CptSendLevel

Detect Threshold (dBm)

Select the Detect Threshold in dBm.

Default = -23

Range: -11, -17, -23, -29

Tcl Parameter : CptDetectThreshold

Ringback Frequencies (Hz)

We assume that ringback tone is consists of just two frequencies (f1 and f2),  More complex ringback tone, like music phrase or a voice announcement are not supported at this time.

Enter the f1 and f2 Ringback Frequencies (Hz).

Default for f1 = 440

Default for f2 = 480

Range: 50 to 3400

Tcl Parameter : RingbackF1

Tcl Parameter : RingbackF2

Ringback Times (ms)  

Enter the Ringback On and Off times is ms.

Enter the On and Off Ringback Times (ms).

Default for On = 2000

Default for Off = 4000

Range: 1000 to 10000

Tcl Parameter : RingbackOn

Tcl Parameter : RingbackOff

UEs Performing Call Progress

Enter the First UE and the total Number of UEs performing Call Progress.

Default for First UE = 1

Default for Number of UEs = 1

Range: 1000 to 10000

Tcl Parameter : CptFirstUe

Tcl Parameter : CptNumUes

 

DTMF

Enable RFC2833/RFC4733

Enable RFC2833/RFC4733 - Enable to support Dual Tone Multi-Frequency (DTMF).

NOTE: RFC2833/RFC4733 testing is not allowed with SIP script DTMF Tone Send/Wait Actions.  

 

Tcl Parameter : Rfc2833Rfc4733En

Event Type  

Event Type: DTMF -  Enable to VoLTE to emulate Dual Tone Multi-Frequency (DTMF) digit tone as audio encoded signal (G.711) or a Name Telephone Event (NTE) based on RFC2833/RFC4733.

DTMF are signals/tones that are sent when a user presses a telephone's touch keys. They are numbers 0-9, "*", and "#" keys on a standard telephone. DTMF tones or signals are used to access voice mail or navigate IVR.

RFC2833 describes the technique which uses a separate type of RTP payload, called Name Telephony Event (NTE), to carry DTMF digits. NTE are carried as part of the audio stream and must use the same sequence number and timestamps base as the regular audio channel to simplify the generation of audio waveforms at the gateway. Figure 1 show the payload format for NTE.

DTMF tones are delivered either in-band of out-of-band via SIP or RTP signaling messages. Two delivery options:

  • RFC2833 - Sending DTMF information in the RTP stream as a named event (NTE).
  • Inband - Sending DTMF information as an audio encode signal.

 

DTMF digits events are carried as part of the audio stream, and must use the same sequence number and timestamp base as the regular audio channel. The first packet for an event MUST have the M bit set.  The final packet for an event MUST have the E bit set. The update packets MUST have the same RTP timestamp value as the initial packet for the event, but the duration MUST be increased to reflect the total cumulative duration since the beginning of the event.

 

NOTES:

  • DTMF digit will be transmitting over RTP Voice stream, therefore, at least one of the "RTP DMF" needs to be Audio Type for the DTMF option to enable.
  • DTMF digits can be sent without media or with Basic Voice DMF for testing and verification only, For ACCURATE simulation, RTP Media DMF is needed.
  • DTMF will affect POLQA measurements due to RFC2833 in-band method. As a result, voice quality (MOS) scores will not be accurate.

 

Tcl Parameter : DtmfEventEn

DTMF Pane
  • Enable Send  — Enables the Digits pane which allows for capture of the Digit to be sent and the Duration.

DtmfSendEn

 

  • Payload Number — Indicate the Payload number. Range: 96 - 127. Default: 101.

DtmfPayload

 

  • Alternate Payload Number — Enable to add an Alternate Payload number. Range: 96 - 127. Default: 101. Both the Payload number and the Alternate Payload number will be included in the SIP INVITE SDP. But on the terminator side, the Alternate Payload number will be used for telephone-event only if the Payload number is not included in the SIP INVITE message that it receives.

DtmfAltPayloadEn

DtmfAltPayload

 

  • Volume (dBm0) — Indicate the power level of the tone, expressed in dBm0 after dropping the sign. Range: 0 to -63 dBm0. Default: 8 dBm0.

DtmfVolume

 

Digits/Duration — Digits to be sent over DTMF. "None" will indicate Delay Time. As of release 17.2, this field will be disabled when using SIP Scripts. See SIP Actions (Media_DtmfStart, Media_pause and Media_resume). DTMF digits and timing added as input in Media_DtmfStart (Sip Action). Media_Pause / Media_Resume actions used to handle timing.

Digits to be send over DTMF, “None” will indicate delay time.

Digits Valid value: None, 0 – 9, *, #, A – D

Duration Range: 1 – 65535 milliseconds

Default value: None

 

Example configuration:

Digit

Duration

Comments

None

2000

Delay 2000 ms after Call Established before sending DTMF digits

1

200

Send digit 1 with 200 ms duration

2

300

Send digit 2 with 300 ms duration

None

500

Pause for 500 ms

3

150

Send digit 3 with 150 ms duration

4

200

Send digit 4 with 200 ms duration

None

100

Pause for 100 ms

#

500

Send # for 500 ms duration

 

Measurements: Om counter for each individual event is need to accuracy measure/detect DMTF digits send or received.

Digit 0 through 9 – send and receive Om counter.

Digit * – send and receive Om counter.

Digit # – send and receive Om counter.

Digit A through Z – send and receive Om counter.

Enable Audio Recording

Available for MME Nodal and AMF Nodal. This option is enabled based on any of the selected DMFs being "rtpvoice" protocol.

It allows Landslide to record audio for 1 UE for the duration specified in GUI or Call is disconnected. The 1st call is recorded if there are multiple calls between A and B. Allows for audio recording without enabling POLQA.

The recording will be converted from RTP packets to Wav file and then exported to TAS as tc0_announcement.tar.gz. This announcement folder can be extracted. The audio file recorded will be name as Audio_ts0_tc0_ue0_stream-1_dmf0. The audio file can be played using Audacity tool. 


Enter UE to Record.

Range : 1 to "Number of Subscribers"

Default : 1


Enter Recording Time (s) in seconds.

Range : 1 - 3600

Default : 120

Limitation/Caveat :

  1. As of release, 21.4, the following Codec are not supported for Audio recording. 
    1. G.729 A
    2. G.729 AB
    3. G.722
    4. OPUS
  2.  If recording is enabled for A, the incoming RTP packets are arranged in recorder according to received RTP packet's timestamp. Therefore if A have Multiple dialogues, as in case with 3-way call (A calling B and C), recording data will be overridden if time stamp for incoming RTP packets for B and C are same.       
  3. If there are multiple calls, 1st call is recorded. 
  4. If the codec is changed during the recording, recorder will not work as expected.       

Tcl Parameter : AudioRecordingEn

Tcl Parameter : AudioRecordingFirstUe

Tcl Parameter : AudioRecordingTime

 

^ Back to Top