Description of the Idea:
During Hold/Unhold transitions, RingCentral internally switches the RTP source without SIP renegotiation and while keeping the same SSRC. Although the stream appears continuous (same SSRC, coherent sequence numbers), this design leads to misinterpretation by VoIP monitoring tools such as OCOM or SIP Capture HOMER, which are widely used in enterprise environments.

Suggested Improvement:
Introduce a mechanism to explicitly signal the change of RTP source, such as:

• Changing the SSRC, as recommended in [RFC 3550 §8.1],
• Resetting RTP timestamps or sequence numbers,
• Using the RTP marker bit to indicate a discontinuity.

This would help monitoring systems correctly interpret the transition as intentional, preventing false positives in packet loss detection and skew computation.

Why it Matters:
Currently, the internal switch causes:

• A small delay (20–30 ms) between the last packet from the old source and the first from the new source — exceeding the expected packetization interval (20 ms for G.711a) and triggering false packet loss or jitter spikes.
• A permanent distortion of the skew metric, since it accumulates based on the initial packet timestamp. Once the skew exceeds 20 ms, all subsequent packets may be incorrectly flagged as lost, degrading MOS scores and user-perceived quality — even though the stream is healthy.

Additionally, occasional deviations from the expected G.711a payload size (160 octets) have been observed, suggesting potential irregularities in packet generation.

Standards References:

• RFC 3550 §6.4.1 – Jitter and packet spacing
• RFC 3550 §8.1 – New SSRC when stream source changes
• RFC 3551 §4.5.4 – G.711a packetization interval (20 ms, 160 octets)
• ITU-T G.1020 & G.114 – QoS metrics for voice performance

Business Impact:
Without a signaling mechanism, transitions cause monitoring tools to misreport RTP quality, leading to:

• Incorrect MOS and SLA metrics
• False alarms in NOC monitoring
• Difficulty in troubleshooting actual network issues

Conclusion:
Implementing a clear indicator of RTP source transition — through SSRC change, timestamp reset, or marker bit — would significantly improve the observability and reliability of RTP stream metrics, aligning with best practices and protocol standards.

Let me know if further technical evidence is helpful (e.g., PCAP traces or graphs).