Navigation Menu
Search code, repositories, users, issues, pull requests..., provide feedback.
We read every piece of feedback, and take your input very seriously.
Saved searches
Use saved searches to filter your results more quickly.
To see all available qualifiers, see our documentation .
- Notifications You must be signed in to change notification settings
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusing round trip time defintion in remote-outbound-rtp #659
k0nserv commented Aug 29, 2022 • edited
- 👍 1 reaction
fippo commented Aug 29, 2022
Sorry, something went wrong.
k0nserv commented Aug 30, 2022 • edited
alvestrand commented Aug 30, 2022
Fippo commented aug 31, 2022 • edited, k0nserv commented sep 1, 2022.
No branches or pull requests
- Skip to content
- Skip to search
- Skip to footer
Cisco Unified Border Element Configuration Guide Through Cisco IOS XE 17.5
Bias-free language.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Read Me First
- New and Changed Information
- Supported Platforms
- Overview of Cisco Unified Border Element
- Virtual CUBE
- Dial-Peer Matching
- Introduction to Codecs
- Call Admission Control
- Basic SIP Configuration
- SIP Binding
- SIP Profiles
- SIP Out-of-Dialog OPTIONS Ping Group
- Configure TCL IVR Applications
- VoIP for IPv6
- Monitoring of Phantom Packets
- Configurable SIP Parameters via DHCP
- Matching Inbound Dial Peers by URI
- URI-Based Dialing Enhancements
- Multiple Pattern Support on a Voice Dial Peer
- Outbound Dial-Peer Group as an Inbound Dial-Peer Destination
- Inbound Leg Headers for Outbound Dial-Peer Matching
- Server Groups in Outbound Dial Peers
- Domain-Based Routing Support on the Cisco UBE
- ENUM Enhancement per Kaplan Draft RFC
- Support for Multi-VRF
- Configuring Multi-Tenants on SIP Trunks
- Codec Support and Restrictions
- Codec Preference Lists
- Transcoding
- Transrating
- Call Progress Analysis Over IP-to-IP Media Session
- Voice Packetization
- Fax Detection for SIP Call and Transfer
- Video Suppression
- Configuring RTCP Report Generation
- Network-Based Recording
- SIPREC (SIP Recording)
- Video Recording - Additional Configurations
- Third-Party GUID Capture for Correlation Between Calls and SIP-based Recording
- Cisco Unified Communications Gateway Services--Extended Media Forking
- CUBE Media Proxy
- Passing Headers Unsupported by CUBE
- Copying SIP Headers
- Manipulate SIP Status-Line Header of SIP Responses
- Dynamic Payload Type Interworking for DTMF and Codec Packets for SIP-to-SIP Calls
- Delayed-Offer to Early-Offer
- H.323-to-SIP Interworking on CUBE
- H.323-to-H.323 Interworking on CUBE
- SIP RFC 2782 Compliance with DNS SRV Queries
- SRTP-SRTP Interworking
- SRTP-RTP Interworking
- SRTP-SRTP Pass-Through
- High Availability on Cisco 4000 Series ISR and Cisco Catalyst 8000 Series Edge Platforms
- High Availability on Cisco ASR 1000 Series Aggregation Services Routers
- High Availability on Cisco CSR 1000V or C8000V Cloud Services Routers
- High Availability on Cisco Integrated Services Routers (ISR-G2)
- DSP High Availability Support
- Stateful Switchover Between Redundancy Paired Intra- or Inter-box Devices
- CVP Survivability TCL support with High Availability
- ICE-Lite Support on CUBE
- Mid-call Signaling Consumption
- Early Dialog UPDATE Block
- Consumption of Forked 18x Responses with SDP During Early Dialog
- Support for Pass-Through of Unsupported Content Types in SIP INFO Messages
- Support for PAID PPID Privacy PCPID and PAURI Headers on the Cisco Unified Border Element
- Dynamic Refer Handling
- Cause Code Mapping
- Hosted and Cloud Services Delivery with CUBE
- CUBE SIP Registration Proxy
- Survivability for Hosted and Cloud Services
- SUBSCRIBE-NOTIFY Passthrough
- Cisco Unified Communications Manager Line-Side Support
- SIP TLS Support on CUBE
- CUBE Call Quality Statistics Enhancement
Voice Quality Monitoring
- CUBE Smart Licensing
- VoIP Trace for CUBE
- Support for Session Identifier
- Common Criteria (CC) and The Federal Information Processing Standards (FIPS) Compliance
- Additional References
Chapter: Voice Quality Monitoring
Feature information for voice quality monitoring, prerequisites for voice quality monitoring, restrictions for voice quality monitoring and voice quality statistics, vqm metrics, enabling media statistics globally, verifying voice quality monitoring, troubleshooting tips, example: configuring media statistics globally, example: cdr enabled mos output.
The Voice Quality Monitoring (VQM) feature gives information on the voice quality metrics related to media (voice) quality, such as conversational mean opinion score (MOS), packet loss rate, and so on. VQM enables you to monitor the quality of calls traversing your VoIP network, and you can diagnose the cause of voice quality issues and troubleshoot them.
The Voice Quality Statistics feature provides information about the quality of the Time-Division Multiplexing Internet Protocol (TDM-IP) voice call.
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
The following commands must be executed to configure the voice quality metrics:
callmonitor
rtcp all-pass-through
- media statistics
media bulk-stats
call-quality
max-dropout number-of-packets —Configures the acceptable out of sequence future packets to drop. The range is 2–2000 packets. The default value is 100.
max-reorder number-of-packets —Configures the acceptable out of sequence late packets. The range is 2–2000 packets. The default value is 100.
Sample Configuration
The following is a sample for the recommended voice quality monitoring configuration:
Only SIP-to-SIP call quality statistics calculation is supported.
The RTCP field is not recalculated, as it is end-to-end statistics.
The round trip delay is only retrieved by RTCP, which means the round trip delay is not calculated if there is no related RTCP.
Only three codec types are supported for one media flow to calculate the jitter; considering the data path performance, these three codecs would be the maximum number in one cache line.
Only one RTP synchronization source (SSRC) is supported concurrently per media flow, which is indicated in the m-line of the session description protocol (SDP).
Round trip delay calculation for transcoding calls is not supported.
VQM MOS values are not calculated for DSP based calls.
MOS value shows 0 if endpoint does not send RTCP packets.
RoundTripDelay
GapFillWithSilence
GapFillWithPrediction
GapFillWithInterpolation
GapFillWithRedundancy
HiWaterPlayoutDelay
LoWaterPlayoutDelay
PlayDelayJitter
Information About Voice Quality Monitoring
The VQM (Voice Quality Monitor) gives information on the voice quality metrics. The VQM on Cisco IOS XE platforms enables statistics gathering based on the received RTCP packets. From these statistics, a voice quality measurement is developed to show the quality of the call. The output is in a simple format, using a system of good, poor, and bad types of ratings.
The following metrics exists in Call Detail Record (CDR) and Management Information Base (MIB) in CUBE, indicating voice quality:
MOSQe (conversational quality MOS)
Round-trip-delay.
Receive-delay (current jitter buffer size).
Packet-Loss-Rate.
The CDR is sent at the end of a call if AAA accounting is configured.
A CDR example is as follows:
<MOS-Con>4.4072</MOS-Con>
<round-trip-delay>1 ms</round-trip-delay>
<receive-delay>64 ms</receive-delay>
<voice-quality-total-packet-loss>0.0000 %</ voice-quality-total-packet-loss>
The following are the metrics exported by VQM:
How to Configure Voice Quality Monitoring
Summary steps.
- configure terminal
- voice service voip
DETAILED STEPS
Perform this task to verify the configuration for voice quality monitoring. The show commands can be entered in any order.
- show call active voice | include LostPackets
- show call active voice | include ReceiveDelay
- show call active voice brief | sec RTT
show call active voice stats | sec MC
Step 5
Displays R-Factor Statistics (G.107 MOS) on the CUBE if the Voice Quality Metrics feature is configured. A sample output is provided below for a voice call using G.711ulaw, VAD on, and at 5 percent packet loss rate.
For more information on the SNMP MIB " cmqVoIPCallActiveRxPred107RMosConv ", see SNMP Object Navigator .
In the sample output, the following can be noted:
ML for codec G.711ulaw is 4.2346.
MC for codec G.711ulaw is 4.2346.
IE for codec G.711 is 0.
The following table defines the abbreviations used in the sample output.
Use the following debug commands to troubleshoot the Voice Quality Monitoring feature:
debug voip rtp packets
debug performance monitor
debug radius accounting
debug aaa accounting
Configuration Examples for Voice Quality Monitoring
At the end of a call, the MOSQe output is displayed in CDR only if the debug radius accounting is enabled.
The show log | sec MOS-Con command displays the MOS-Con value as shown below:
Was this Document Helpful?
Contact Cisco
- (Requires a Cisco Service Contract )
First time here? Check out the FAQ!
RTP packet delay edit
asked 2020-05-06 05:00:34 +0000
updated 2020-11-04 08:45:29 +0000
Hello, i want to ask how to calculate transmission delay for every RTP packet that was captured by Wireshark ?
There Time Delta from previous captured packet frame value in Wireshark, can we represent this value as the delay value of the packet?
Delay on an RTP packet is calculated by looking at the processing time at the sender + transmission time + processing time at the receiver . Can the delta value represent the sender processing time + transmission time , so the packet delay can be calculated by adding up the delta value with receiver's processing time ?
Anybody can help, thanks
answered 2020-11-04 08:19:46 +0000
To see the delays of an RTP packet you need to look at the RTCP packet. Most systems report it in RTCP. There is two actions required. In your captured trace select any RTCP packet, then right click on mouse, Select "Protocol Preferences" then select " Show relative roundtrip calculation" Secondly now apply a Display filter: rtcp.roundtrip-delay You can use the following to see all packets that exceeds the RTP threshold of 300ms RTT. rtcp.roundtrip-delay > 300
The roundtrip-delay field can also be added as a column, right click the field in any packet where it's visible and select Apply as Column .
Your Answer
Please start posting anonymously - your entry will be published after you log in or create a new account.
Question Tools
subscribe to rss feed
Asked: 2020-05-06 05:00:34 +0000
Seen: 2,383 times
Last updated: Nov 04 '20
Related questions
What is wrong with my internets?!
how to get delay...
Delta time with previous frame
Capture incoming packets from remote web server
How to set packet metadata in realtime?
Monitor device
Why would I be getting "LEN 1 (Malformed Packet)"... "(Malformed Packet: RTCP)" on UDP Packets
how to measure network and server latency
Now that the g.729 codec patent has expired, will Wireshark include a decoder for it?
Having issues with RTP not showing up in Voip Calls flow sequence in version 2.4.2.
Wireshark-users: Re: [Wireshark-users] RTCP: Calculate round trip delay (Bishwarup)
I have an RTCP packet (Sender report) with the following specifications. *Frame 3494 (114 bytes on wire, 114 bytes captured) Arrival Time: Jan 9, 2007 11:37:42.890920000 Time delta from previous packet: 0.004804000 seconds Time since reference or first frame: 47.108231000 seconds Last SR timestamp: 556982720 (0x2132e1c0) Delay since last SR timestamp: 308288
*All I know is that 890920000 would give me the number of milliseconds elapsed since the first packet.
Now to calculate the round trip delay, I won't do this.. Wrong -> RTD = 890920000 - 556982720 - 308288 I want to know that what I need to do with the three numbers above to calculate the round trip delay?
Anders Broman (AL/EAB) wrote: > Hi, > When you look at the RTP timestamps do the come up as correct NTP timestamps? > It's not uncommon for clients to fill in the timestamp incorrectly. > Best regards > Anders Gerry Brown wrote: > > Make sure to read the RFC 3550. The values are not always strictly > binary. For instance, NTP is sec/millisecs. The value of DLSR is > represented as 1/65536 of a sec ticks. > > gerry > > > > > > > > - This message has been scanned for viruses, spam and dangerous > content by *www.CleanMailGateway.com* > < http://www.CleanMailGateway.com/ >, and is believed to be clean. > > ------------------------------------------------------------------------ > > _______________________________________________ > Wireshark-users mailing list > Wireshark-users@xxxxxxxxxxxxx > http://www.wireshark.org/mailman/listinfo/wireshark-users
- From: Bishwarup
- From: Gerry Brown
- Prev by Date: [Wireshark-users] Calculating SIP Calls Per Second (CPS) trafic in a wireshark/ethereal trace
- Next by Date: Re: [Wireshark-users] RTCP: Calculate round trip delay
- Previous by thread: Re: [Wireshark-users] RTCP: Calculate round trip delay (Bishwarup)
- Next by thread: Re: [Wireshark-users] RTCP: Calculate round trip delay (Bishwarup)
Join us for SharkFest'24 US, the official Wireshark Developer and User Conference this June
© Wireshark Foundation · Privacy Policy
- Get Wireshark
- Code of Conduct
- Ask a Question
- Documentation
- Mailing Lists
- Online Tools
- Issue Tracker
- Developer's Guide
- Browse the Code
- SharkFest YouTube
IMAGES
VIDEO
COMMENTS
The Mean Network Round-Trip Delay is the mean value of the RTP-to-. RTP interface round-trip delay over the measurement period, expressed in units of 1/65536 seconds. This value is typically. determined using "the NTP timestamp field" in the RTCP sender. report (SR) and "the last SR (LSR) field","delay since last SR.
RFC 3611 RTCP XR November 2003 Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays is as follows; if the round trip delay is denoted, RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then: one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B ...
RTCP XR reports round-trip delay, corresponding to the packet path delay that would be measured using RTCP, and end system delay, which represents the delay that the VoIP endpoint adds (because of ...
The Calculation of the round trip time is defined in section 4.5. of [RFC3611]. If the latest RTCP Extended Report (XR) does not contain the DLRR report block, or if the last RR timestamp in the DLRR report block is zero, or if the delay since last RR value in the DLRR report block is zero, the round trip time is left undefined.
The round trip delay is only retrieved by RTCP, which means the round trip delay is not calculated if there is no related RTCP. Only three codec types are supported for one media flow to calculate the jitter; considering the data path performance, these three codecs would be the maximum number in one cache line. ...
In telecommunications, round-trip delay (RTD) or round-trip time (RTT) is the amount of time it takes for a signal to be sent plus the amount of time it takes for acknowledgement of that signal having been received. This time delay includes propagation times for the paths between the two communication endpoints. In the context of computer networks, the signal is typically a data packet.
The RTP Control Protocol (RTCP) is a binary-encoded out-of-band signaling protocol that functions alongside the Real-time Transport Protocol (RTP). Its basic functionality and packet structure is defined in RFC 3550. RTCP provides statistics and control information for an RTP session. It partners with RTP in the delivery and packaging of multimedia data but does not transport any media data ...
In fact, Eq. 5 reflects computation of round-trip propagation delay in RFC 3550 [8] where recording time A corresponds to (T S 2 − DLSR 2 ) and LSR to T S 1 .
These packets contain information about the quality of service, including data such as packet counts, packet loss, jitter, and round-trip delay. Synchronization: In a multi-participant session ...
Round-trip time is a complex metric that has several components. It includes propagation delay, processing delay, queuing delay, and encoding delay. Propagation delay is usually the dominant component in RTT. It ranges from a few milliseconds to hundreds of milliseconds depending on whether the endpoints are separated by a few kilometers or by ...
RTT (datagram round trip time) is certainly impacted by physical distance. we use the following equation to calculate the minimum RTT over the given distance of a P2P circuit: minimum RTT is two times of the propagation delay on the link: minimum RTT = 2 * Distance / Speed of propagation. Keep in mind that the speed of propagation would be ...
To see the delays of an RTP packet you need to look at the RTCP packet. Most systems report it in RTCP. There is two actions required. In your captured trace select any RTCP packet, then right click on mouse, Select "Protocol Preferences" then select " Show relative roundtrip calculation" Secondly now apply a Display filter: rtcp.roundtrip-delay You can use the following to see all packets ...
rtcp.roundtrip-delay: Roundtrip Delay(ms) Signed integer (32 bits) 1.0.0 to 4.2.5: rtcp.roundtrip-delay.expert: RTCP round-trip delay detected (%d ms) Label: 1.12.0 to 4.2.5: rtcp.roundtrip-delay.negative: Negative RTCP round-trip delay detected (%d ms) Label: 1.12.0 to 4.2.5: rtcp.rtpfb.fmt: RTCP Feedback message type (FMT) Unsigned integer (8 ...
the round-trip-delay for an SSRC. I know that it can be calculated using the formula. Round trip delay = Arrival time- Last Sender Report Timestamp - Delay. since Last Sender Report Timestamp. But I guess the units of Arrival time and the LSR (and DLSR) are. different. I use the arrival time as given by Wireshark.
Hi all! I am working on RTCP protocol. I would like to know how to calculate the round-trip-delay for an SSRC. I know that it can be calculated using the formula Round trip delay = Arrival time- Last Sender Report Timestamp - Delay since Last Sender Report Timestamp But I guess the units of Arrival time and the LSR (and DLSR) are different.I use the arrival time as given by Wireshark.
1. Timing is implicit in TCP (RTP, as its name suggests, relates explicitly to timing). RTT is calculated by Wireshark on packets that have ACKs of past segments, and is calculated as the time delta between the original packet's SEQ and this packet's ACK. Since it is calculated, you will see it under [SEQ/ACK analysis] of the packet and not as ...
Time since reference or first frame: 47.108231000 seconds. Last SR timestamp: 556982720 (0x2132e1c0) Delay since last SR timestamp: 308288. *All I know is that 890920000 would give me the number of milliseconds. elapsed since the first packet. Now to calculate the round trip delay, I won't do this.. Wrong -> RTD = 890920000 - 556982720 - 308288.
RFC 6843 RTCP XR Delay January 2013 If only one measurement of Round Trip Delay is available for the time span of the report (i.e., the measurement period) (whether Interval or Cumulative), this single value SHOULD be reported as the minimum value. If the measurement is unavailable, the value of this field with all bits set to 1 MUST be reported.
To synchronize its clock with a remote server, the NTP client must compute the round-trip delay time and the offset. The round-trip delay is computed as. where. t3 is the client's timestamp of the response packet reception. Therefore. of the request packet and the reception of the response packet and. t2 − t1 is the time the server waited ...
I have an RTCP packet (Sender report) with the following specifications. *Frame 3494 (114 bytes on wire, 114 bytes captured) Arrival Time: Jan 9, 2007 11:37:42.890920000 Time delta from previous packet: 0.004804000 seconds Time since reference or first frame: 47.108231000 seconds Last SR timestamp: 556982720 (0x2132e1c0) Delay since last SR timestamp: 308288