Mouth-to-Ear Response Latency for Conversational Voice Systems: Metric Definition and Active Measurement Method

1.1. Motivation and decomposition

For a caller connected to a conversational voice system over SIP and RTP, the interval between the end of the caller's utterance and the arrival of response audio comprises, in order of occurrence:¶

A figure covering one or two of these terms does not predict the interval a caller experiences, and the terms are not separable by observation at the caller. MRL is defined here as the aggregate, observed at a single reference point, precisely because the aggregate is what an external observer can measure without instrumenting the system under test.¶

1.2. Existing practice

Two kinds of figure are published today.¶

Component-level figures are reported by the operators of individual components, most commonly the interval from a request reaching a speech synthesis endpoint to the first audio byte returned, and less commonly the interval to a language model's first token. These are observed at an API boundary internal to the system and cover a subset of the terms above.¶

Caller-side figures are produced by placing a call and observing the response. At least one such effort publishes both its results and its tooling openly [TTFAB], reporting the interval between the caller's speech end and the onset of the response as observed in a recording of the call rather than in any timestamp reported by the system.¶

Caller-side efforts differ from one another along axes that render their outputs incomparable, and those axes are the reason this document exists:¶

• the reference point at which the response is observed, which may be an RTP endpoint, a recording made by a carrier or a conferencing bridge, or an endpoint's audio device, each placing a different and frequently uncharacterised quantity of transport and buffering inside the measured interval. Section 4.2 enumerates these so that a party observing anywhere on that list can produce a conforming report which declares the difference, and Section 4.2.1 gives a way to measure it rather than disclose it;¶

• the determination of the caller's speech end, which may be derived from a voice activity detector applied to the transmitted audio, or from prior annotation of known stimulus material;¶

• the treatment of buffering, since an interval taken at packet arrival and an interval taken after a de-jitter buffer differ by the depth of that buffer;¶

• the definition of response onset, which for audio that ramps in gradually is a choice of threshold rather than an observation;¶

• whether the measuring instrument has itself been calibrated against a known delay, and therefore whether a reported figure is a point estimate or an upper bound.¶

An effort that states its choices along these axes produces figures a reader can interpret, whereas two efforts that have chosen differently produce figures which cannot be placed side by side even when each is internally correct. This document specifies one set of choices and requires that they be reported alongside any figure derived under them.¶

1.3. Scope

This document specifies:¶

• the definition of the MRL metric and its two required variants;¶

• the method of measurement, including the reference point, the determination of the interval endpoints, and the required contents of a capture;¶

• the conditions under which a measurement MUST be treated as invalid;¶

• the fields that MUST accompany a reported figure.¶

This document does not specify endpointing strategy, barge-in handling, speech recognition or synthesis behaviour, or any property of the system under test. It does not specify a signalling protocol; the method assumes an established RTP session and is independent of how that session was established.¶

1.4. Relationship to existing work

The metric defined here is an application-layer performance metric in the sense of [RFC6390], and this document follows the template in Section 5.4 of that document. [RFC6076] defines end-to-end performance metrics for telephony sessions at the SIP layer and is the closest existing IETF work in subject matter; the metric defined here concerns the media plane rather than signalling, and is complementary. No existing IETF document defines the quantity described in Section 1.1 or specifies a reference point at which to observe it.¶

The framework of [RFC2330] and the delay metric of [RFC7679] inform the treatment of error and uncertainty. The method described here is an active method in the taxonomy of [RFC7799], since it generates the stimulus whose response it measures.¶

[RFC3611] and its extensions define a reporting mechanism by which endpoints convey media quality metrics in band. Conveying MRL in that manner is out of scope for this document and is noted in Section 14 as possible follow-on work.¶

• [[EDITOR'S NOTE, on venue. The IPPM charter bounds the group's work to "metrics and methodologies which are applicable over transport-layer protocols over IP", while also covering "applications running over transport layer protocols". Whether a metric whose dominant terms are speech recognition, inference and synthesis falls inside that boundary is a fair question and should be settled before effort is spent on -01.¶

  The precedent in favour is draft-ietf-ippm-responsiveness, an adopted IPPM work item targeting Proposed Standard, which measures at the application layer over HTTP/2 and HTTP/3 and justifies itself explicitly on user experience. The argument against is that responsiveness remains a property of the network under load, whereas most of MRL is not attributable to the network at all.¶

  If IPPM declines, the alternatives are to take the question to DISPATCH, which exists for work with no obvious home, or to pursue publication through the Independent Submission stream. The document is written to stand in any of the three.¶

  Separately, decide whether to pursue registration in the Performance Metrics Registry ([RFC8911], initially populated by [RFC8912]); Appendix A holds a draft entry. The registry has to date been populated with IP-layer path metrics, so eligibility should be confirmed before the appendix is presented as a proposal.]]¶

3.1. Metric name

Mouth-to-Ear Response Latency (MRL), reported in two variants named Ingress MRL and Playout MRL.¶

3.2. Metric description

MRL is the interval between the instant at which the calling endpoint transmits the final speech sample of a stimulus utterance and the instant at which the first sample of the SUT's response reaches the calling endpoint.¶

MRL is defined as:¶

MRL = t1 - t0

where t0 and t1 are as defined in Section 3.3 and Section 3.4.¶

MRL is signed. A negative value indicates that response audio reached the calling endpoint before the stimulus had finished being transmitted, which occurs with aggressive endpointing and with backchannel responses. Implementations MUST report negative values as measured and MUST NOT clamp them to zero.¶

3.3. Interval start: t0

t0 is the instant at which the final speech sample of the stimulus is transmitted by the calling endpoint at the reference point.¶

t0 MUST be determined by:¶

1. annotating the stimulus offline to sample precision to locate the speech end;¶

2. mapping that sample onto the RTP packet that carried it, using RTP timestamps as defined in [RFC3550];¶

3. interpolating within that packet at the sample rate to obtain the sample's offset from the packet's transmission instant.¶

t0 is therefore the transmission instant of the carrying packet plus the target sample's offset within that packet. The sign of the offset term is significant; see Section 4.7.¶

t0 MUST NOT be derived from voice activity detection performed at run time. A run-time detector has a decision lag of its own, that lag is a term within the quantity being measured, and using it to define t0 would conceal the term.¶

Annotation of the stimulus MUST NOT extend the speech end by a fixed constant. A fixed extension displaces t0 later by that constant and, since MRL is t1 minus t0, reduces every reported figure by the same constant. See Section 4.7.¶

An implementation MUST NOT be required to use any particular annotation algorithm, and MUST be able to demonstrate that its annotation agrees with a published reference. The reference implementation uses decay-following hysteresis with a short sliding RMS refinement, and publishes a frozen stimulus signal whose speech end is exact by construction, together with the boundary its own annotator locates [HARNESS]. An implementation claiming conformance SHOULD reproduce that boundary and MUST state the deviation where it does not.¶

Specifying the conformance test rather than the algorithm is deliberate. The quantity that matters to a reader is whether two parties locate the same boundary in the same audio, and an algorithm mandated in prose can be implemented differently by two careful people while a boundary in a published waveform cannot be argued about.¶

• [[EDITOR'S NOTE: the reference signal is frozen bytes rather than a generator seed, because a signal rebuilt by its generator changes when the generator does. Whether the signal itself should be carried in an IANA registry, an appendix, or by reference to the archived implementation is a question for the working group; reference is assumed here.]]¶

3.4. Interval end: t1

t1 is the instant at which the first sample of the SUT's response reaches the calling endpoint, taken at the reference point.¶

t1 MUST be determined by reassembling the received stream in RTP timestamp order, locating the response onset as specified in Section 3.5, and mapping the onset sample back through the packet that carried it.¶

Two variants of t1 are defined, and both MUST be reported.¶

3.5. Response onset

The instant at which audio begins has no unique definition, because synthesised speech commonly ramps in over tens of milliseconds rather than beginning at full level. Onset is therefore computed under three named variants, and the dispersion across them is a component of the reported uncertainty.¶

Levels are expressed in dBov, referenced to full-scale RMS.¶

The headline variant is the reported figure. The spread of MRL across all three variants is the onset-definition uncertainty of the measurement and MUST be published alongside any headline figure. On an abrupt onset the spread is small; on a gradual ramp it grows with the ramp duration and becomes the dominant uncertainty term.¶

Sub-frame refinement of the onset instant MUST use a short sliding RMS. Instantaneous sample magnitude crosses any fixed threshold on isolated noise peaks at a rate high enough to displace the boundary materially; see Section 4.7.¶

3.6. Unprompted audio

A conversational voice system commonly speaks before the caller does, opening with a greeting that arrives within a few hundred milliseconds of the session being established. That audio responds to nothing, because the caller has not yet spoken.¶

Response-onset detection MUST NOT begin before the end of any such unprompted audio. The point at which it ended MUST be recorded in the capture, and the noise-floor estimate required by Section 3.5 MUST be taken from audio following that point.¶

Detection across the whole received stream locates the greeting instead of the response. Since the greeting precedes t0, the resulting MRL is large and negative, and because this document licenses negative values as genuine behaviour there is no bound against which such an error announces itself. In the reference implementation, a capture carrying an 800 ms greeting with a true MRL of 900 ms yielded -2085 ms and satisfied every condition in Section 8.¶

A greeting falling inside the noise-floor window is speech rather than channel noise, so it raises the estimate and displaces every onset threshold derived from it. On the same capture the floor moved by 1.35 dB.¶

A calling endpoint SHOULD NOT begin transmitting its stimulus while unprompted audio is still in progress. A system that implements barge-in detection will stop speaking when it hears the caller, which truncates the greeting and alters the interaction under measurement.¶

The interval from session establishment to the onset of unprompted audio is a distinct and useful quantity, since a caller who hears nothing for several seconds after the line opens is poorly served whatever the system's MRL turns out to be. It shares no terms with MRL and is not defined here; see Section 14.¶

3.7. Filler audio and response continuity

t1 as defined in Section 3.4 is the onset of the system's first response audio, whatever that audio happens to contain. A system that emits an earcon, a breath or a filled pause while its response is still being generated therefore records a low MRL while conveying nothing during that interval, and would rank above a system that stayed quiet and then answered.¶

This document does not resolve that by identifying which audio carries meaning. A metric incorporating a judgement about meaning cannot be re-derived from a published capture by an independent reviewer, and that reproducibility is the property which makes the rest of this specification worth having. The discriminator is structural instead: filler is followed by silence before the substantive response begins, and continuous speech is not.¶

An implementation MUST, within a window of 2000 ms following t1, measure the longest interval whose level lies below the onset threshold of the headline variant. Intervals carried by no packet MUST be excluded from that measurement, because a lost or late-discarded frame leaves a gap indistinguishable from a deliberate pause and would otherwise allow a degraded path to manufacture filler.¶

Where that interval exceeds 150 ms:¶

• the response MUST be reported as discontiguous;¶

• a second onset MUST be reported, at the start of the final contiguous segment, together with the MRL derived from it.¶

MRL itself is unchanged by this section, so no figure measured under an earlier revision becomes invalid. A reader receives both onsets and can see whether they differ and by how much.¶

The 2000 ms window and the 150 ms threshold are fixed by this document rather than left to the implementation, for the reason given in Section 3.5: figures derived under different parameters cannot be compared even when each is internally correct. Both MUST be reported alongside any figure derived under them.¶

4.1. Reference point

All timestamps MUST be taken at the RTP egress and ingress reference point of the calling endpoint, that is, immediately before a packet is passed to the operating system for transmission and immediately after a packet is received from it.¶

The reference point is chosen so that the measurement includes every term a caller experiences downstream of the calling endpoint's own send path, and excludes the calling endpoint's own playout hardware, which is a property of the observer rather than of the SUT.¶

4.2. Observing elsewhere

Not every party measuring this quantity controls an RTP endpoint. A figure derived from a carrier's call recording is a real measurement of something a caller experienced, and declaring it as such is more useful than being unable to describe it at all.¶

An implementation MAY therefore observe at a point other than the one in Section 4.1, provided it declares which, and provided it discloses what that choice places inside the measured interval. Such a report conforms to this document. What it does not do is produce a figure comparable with one taken at the RTP reference point, because the two intervals contain different terms.¶

Where a value other than rtp-endpoint is declared, the additional terms MUST be disclosed and the figure MUST be reported as an upper bound rather than a point estimate, unless those terms have been characterised as below. Figures taken at different reference points MUST NOT be pooled into one distribution.¶

4.3. Stimulus requirements

Stimulus material MUST be prerecorded and MUST be transmitted at the nominal frame rate of the codec in use. The stimulus MUST be hashed and the hash MUST be recorded with the capture, so that a changed stimulus invalidates a comparison loudly rather than silently.¶

The method is independent of the codec, and the codec in use MUST be reported with any figure derived under it. Where a payload format from [RFC3551] is used, the sample rate and frame period follow that profile, and the companding of [G711] applies to the PCMU and PCMA formats.¶

4.4. Transmission pacing

The calling endpoint MUST measure the deviation of its own transmission instants from the nominal frame grid and MUST record the worst deviation observed during the call. An endpoint that cannot pace its own transmission has an unreliable t0 and therefore an unreliable MRL. See Section 8.¶

4.5. Capture contents

A capture MUST contain raw payloads and raw timestamps only. A capture MUST NOT contain any derived quantity, including any latency figure.¶

This requirement exists so that a revised onset definition, or a definition proposed by a reviewer, can be applied to existing data without repeating a collection. The uncertainty analysis in Section 3.5 is not possible otherwise.¶

4.6. Clock requirements

Both t0 and t1 MUST be taken from a single monotonic clock on the calling endpoint.¶

Because the interval is the difference of two timestamps drawn from one clock on one host, the metric requires no synchronisation between the calling endpoint and the SUT, and is insensitive to offset between them. This is a deliberate property of the definition and distinguishes the method from one-way delay measurement, where clock synchronisation between the two hosts dominates the error budget as described in Section 3.7.1 of [RFC7679].¶

A wall-clock timestamp MAY be recorded in parallel for the sole purpose of correlating captures with traces obtained from the SUT. Any offset or skew in that clock affects such correlation only and MUST NOT affect the reported MRL.¶

4.7. Sources of error and calibration

An implementation MUST state its calibrated accuracy, and MUST state the conditions under which that calibration was obtained.¶

Calibration is performed by replacing the SUT with a reference responder that replies at a programmed delay, so that ground truth is known exactly. Under each channel condition the offset from ground truth that the physics of the channel requires is predictable in advance: for Ingress MRL it is the base transit delay plus the mean jitter excess, and for Playout MRL it is the base transit delay plus the buffer target depth. The calibration criterion is therefore the residual after subtracting that predicted offset, rather than the raw difference from ground truth.¶

Calibration MUST NOT be performed exclusively at programmed delays that are integer multiples of the frame period. A responder that evaluates its emission deadline once per received frame quantises its own output to the frame period, and that error is invisible at frame-commensurate delays because the deadline then falls on a frame boundary.¶

The following error mechanisms are known to produce plausible-looking but incorrect figures, and an implementation is advised to test for each:¶

Fixed annotation extension:

Extending the stimulus speech end by a constant biases every figure low by that constant.¶

Instantaneous-magnitude thresholding, at either boundary:

Sub-frame refinement on sample magnitude rather than a short sliding RMS lets isolated noise peaks cross the threshold. At the stimulus end boundary this displaces t0 late; at the response onset it displaces t1 early, biasing MRL low by up to one analysis window. The second was masked in the reference implementation for as long as its calibration responder placed responses on the analysis grid, and surfaced only once a media-clock responder placed them where they began: it accounted for the whole of a -0.40 ms headline bias and a 0.99 ms spread between onset variants on a hard onset. A fix applied at one boundary has to be checked against its mirror.¶

Frame-quantised reference responder:

Adds a uniform error between zero and one frame period, invisible at frame-commensurate calibration delays.¶

Frame-offset sign error:

Using the wrong sign for the within-frame offset term of t0 produces a residual of twice the offset with the opposite sign. A large bias accompanied by a tight spread is the signature of a definitional or arithmetic error rather than of host timing noise, and implementations are advised to report that discrimination automatically.¶

Symmetric jitter modelling:

A simulated channel that models network jitter as zero-mean Gaussian permits a minimum-tracking de-jitter anchor to sit earlier than the minimum transit delay allows, which appears as a negative bias in Playout MRL. Network jitter is one-sided and has a hard floor at the minimum transit delay. Sender pacing deviation is a different mechanism and is symmetric, because a timer-driven sender can fire either early or late.¶

Calibration source that is not an honest RTP sender:

A reference responder whose RTP timestamps count frames rather than follow a media clock, or whose idle-stream pacing depends on whether it is receiving anything, produces playout figures with errors that ingress cannot see, since ingress is derived from arrival and playout through the timestamp. Observed as a 44.7 ms transit slip that flagged late discard on jitter-free calls, and 9.54 ms of playout spread that no buffer target reduced. Both surfaced only from kept captures over a real path.¶

• [[EDITOR'S NOTE: the reference implementation's calibrated figures are published in [HARNESS] and are deliberately not reproduced here. A metric specification that carries one implementation's results becomes stale and invites the reader to treat those figures as a conformance target. Confirm this is the right call in review.]]¶

7.1. Turns within a session

Several exchanges within one session are permitted and are the realistic case, since a caller does not hang up after one question. They are not interchangeable, though, and a report that pools them without saying so is not comparable with one that does not.¶

A system's first response in a session carries terms that later responses do not: session establishment, whatever a model does on a cold start, caches not yet populated, and connections not yet open. Later responses may in turn benefit from conversational state the system has accumulated. Both effects are real properties of the system rather than measurement artefacts, and both are invisible in an aggregate that does not record which turn each measurement came from.¶

Therefore:¶

• each measurement MUST record its turn index within the session, counting from one;¶

• a reported distribution MUST state which turn indices it covers;¶

• first-turn measurements MUST NOT be pooled with later ones unless the report states that they are pooled and gives the counts of each.¶

This specifies what must be reported rather than how many turns to measure. A study of cold-start behaviour measuring only first turns, and a study of steady-state behaviour discarding them, are both valid and are answering different questions; what makes them comparable to each other is that both said which they did.¶

A calling endpoint conducting a multi-turn session MUST NOT transmit its next stimulus while the system is still speaking, for the reason given in Section 3.6: a system implementing barge-in detection will stop, which alters the interaction under measurement. Locating the end of the system's turn is the same problem as locating the end of a greeting and admits the same solution.¶

8.1. Blocking conditions

A measurement exhibiting any of the following MUST be discarded and MUST NOT be reported as a figure:¶

• no speech end could be located in the stimulus;¶

• no packets were received from the SUT;¶

• no response onset was found;¶

• the response onset fell within the first received frame, so that the true onset may precede the observation window;¶

• the worst transmission pacing deviation exceeded a stated threshold.¶

The pacing threshold in the reference implementation is 5 ms. A calling endpoint that cannot pace its own transmission within that bound has an unreliable t0.¶

Discarding a measurement under these conditions is correct behaviour. An implementation MUST NOT relax a blocking condition in order to retain a measurement.¶

8.2. Advisory conditions

The following conditions do not invalidate a measurement but MUST be reported with it:¶

• packet loss above a stated threshold;¶

• late discard above a stated threshold.¶

A call over a lossy path remains a valid measurement of a lossy path. Where the frame carrying the response onset is itself lost, onset detection is deferred by whole frames and the resulting figure is an upper bound rather than a point estimate, which is why the flag has to travel with the number.¶

8.3. Reporting of discards

Every reported distribution MUST be accompanied by the count of measurements discarded. A run that discards a large fraction of its measurements is not comparable with one that discards none, irrespective of the percentiles of the survivors.¶

9.1. Required fields

A reported MRL figure MUST be accompanied by:¶

• Ingress MRL and Playout MRL, both signed;¶

• the playout target depth;¶

• the onset variant used for the headline figure, and the spread across all three variants;¶

• the codec and frame period;¶

• the number of measurements attempted and the number discarded;¶

• any advisory flags raised;¶

• the calibrated accuracy of the measuring implementation and the conditions of that calibration;¶

• an identifier for the SUT configuration sufficient to establish that two figures refer to the same configuration, without necessarily disclosing that configuration.¶

9.2. Reporting format

A reported result MUST be expressible as a JSON object [RFC8259] carrying the members defined below. The format exists so that a reader can establish, without contacting the party who produced a figure, whether two figures were derived under the same choices.¶

The schema member MUST be present and MUST be the string mrl-report/1 for reports conforming to this document.¶

{
  "schema": "mrl-report/1",
  "instrument": {
    "name": "voice-ai-latency-harness",
    "version": "0.1.1",
    "calibration": {
      "conditions": "clean channel, 20 ms grid, PCMU",
      "ingress": { "bias_ms": -0.40, "p95_abs_error_ms": 2.38 },
      "playout": { "bias_ms": -0.40, "p95_abs_error_ms": 2.38 },
      "reference": "https://doi.org/10.5281/zenodo.22124823"
    }
  },
  "measurement": {
    "reference_point": "rtp-endpoint",
    "reference_point_notes": null,
    "reference_point_bound_ms": null,
    "codec": "PCMU",
    "frame_period_ms": 20.0,
    "sample_rate_hz": 8000,
    "playout_target_ms": 40.0,
    "onset_variants": [
      { "name": "sensitive", "margin_db": 6.0,
        "absolute_dbov": -55.0, "sustain_ms": 10.0 },
      { "name": "headline", "margin_db": 10.0,
        "absolute_dbov": -50.0, "sustain_ms": 20.0 },
      { "name": "strict", "margin_db": 12.0,
        "absolute_dbov": -45.0, "sustain_ms": 30.0 }
    ],
    "headline_variant": "headline",
    "continuity_window_ms": 2000.0,
    "continuity_gap_threshold_ms": 150.0
  },
  "subject": {
    "sut_identifier": "system-A",
    "sut_config_sha256": "9f2b...c41e",
    "stimulus_id": "eval-set-1/utt-017",
    "stimulus_sha256": "3ad1...77b0"
  },
  "results": {
    "n_attempted": 20,
    "n_reported": 18,
    "n_discarded": 2,
    "turn_indices": { "1": 8, "2": 5, "3": 5 },
    "discard_reasons": {
      "onset_not_found": 1, "tx_pacing_deviation": 1
    },
    "ingress": {
      "mean_ms": 812.4, "p50_ms": 796.0,
      "p95_ms": 1043.2, "max_ms": 1101.7
    },
    "playout": {
      "mean_ms": 852.4, "p50_ms": 836.0,
      "p95_ms": 1083.2, "max_ms": 1141.7
    },
    "onset_definition_uncertainty_ms": { "p50": 4.7, "max": 9.8 },
    "continuity": {
      "gap_p50_ms": 48.0,
      "gap_max_ms": 512.0,
      "n_discontiguous": 4,
      "contiguous": {
        "mean_ms": 941.7, "p50_ms": 802.0,
        "p95_ms": 1418.6, "max_ms": 1461.0
      }
    },
    "advisory_flags": {
      "high_loss": 1,
      "high_late_discard": 0,
      "discontiguous_response": 4
    }
  }
}

15.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3550]

Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/rfc/rfc3550>.

[RFC3551]

Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <https://www.rfc-editor.org/rfc/rfc3551>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

15.2. Informative References

[G114]

ITU-T, "One-way transmission time", ITU-T Recommendation G.114, 2003.

[G711]

ITU-T, "Pulse code modulation (PCM) of voice frequencies", ITU-T Recommendation G.711, 1988.

[HARNESS]

Nygate, D., "voice-ai-latency-harness: an instrument for measuring mouth-to-ear response latency", DOI 10.5281/zenodo.22124823, 2026, <https://doi.org/10.5281/zenodo.22124823>.

[RFC2330]

Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/rfc/rfc2330>.

[RFC3611]

Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <https://www.rfc-editor.org/rfc/rfc3611>.

[RFC6076]

Malas, D. and A. Morton, "Basic Telephony SIP End-to-End Performance Metrics", RFC 6076, DOI 10.17487/RFC6076, January 2011, <https://www.rfc-editor.org/rfc/rfc6076>.

[RFC6390]

Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <https://www.rfc-editor.org/rfc/rfc6390>.

[RFC7679]

Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/rfc/rfc7679>.

[RFC7799]

Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/rfc/rfc7799>.

[RFC8911]

Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, "Registry for Performance Metrics", RFC 8911, DOI 10.17487/RFC8911, November 2021, <https://www.rfc-editor.org/rfc/rfc8911>.

[RFC8912]

Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, "Initial Performance Metrics Registry Entries", RFC 8912, DOI 10.17487/RFC8912, November 2021, <https://www.rfc-editor.org/rfc/rfc8912>.

[TTFAB]

OpenBenchmarks Labs, "Voice agent latency benchmark: time to first audio byte measured from real phone calls", 2026, <https://openbenchmarks.com/voice-agent-latency>.