Some Protocol Violation Report

[songxpu]

Hi, thanks for this awesome project!

I've been diving deep into WebRTC protocol specs recently, and while going through the OME codebase, I noticed a few places where the implementation seems to deviate from the standard. I'd like to report them here gradually (based on commit #be6b79e7d49fb54deae91164021a8c1a0b9b7aa6, but I'll double-check against the latest commit #b892b3d64588677aba502d9af917dfb1d2feba4e before submitting each one).

Most of these are likely just functional bugs, but I'm listing them all for completeness. If I come across anything with security implications, I have reported or would report it separately, such as #2086 and #2312.

Since there are quite a few, I thought it'd be better to consolidate them in a single issue rather than flooding the tracker with many separate ones. If you have a preference for how I should organize or submit these, just let me know — I'm happy to follow your lead.

Looking forward to your feedback!

[songxpu]

C3_SRTP_AES128_CM_SHA1_32 Incorrectly Applied to SRTCP

1. Problem Overview

OME negotiates SRTP protection profiles via the DTLS use_srtp extension and writes the negotiated result into the libsrtp policy. This process must ensure that: the DTLS-selected SRTP protection profile is written into the SRTP/SRTCP context with the complete set of RFC-defined profile parameters during the MEDIA phase — not merely passing a profile ID, nor mixing RTP and RTCP parameters.

This audit finds that when the negotiated result is SRTP_AES128_CM_HMAC_SHA1_32, OME applies a 32-bit HMAC-SHA1 authentication tag policy to both RTP and RTCP. For RTP, a 32-bit auth tag is correct; however, for RTCP/SRTCP, RFC 5764 separately specifies an 80-bit RTCP auth tag for this profile. Therefore, OME incorrectly applies RTP's 32-bit authentication policy to SRTCP.

---

2. Specification Reference

The protection profile negotiated via the DTLS-SRTP use_srtp extension is not merely a name, but a set of standard parameters that must be correctly written into the SRTP/SRTCP policy, including cipher, key length, salt length, auth function, auth key length, auth tag length, and lifetime.

RFC 5764 Section 4.1.2 states that parameters in a profile apply to both RTP and RTCP by default, unless RTCP parameters are separately specified:

"All of these parameters apply to both RTP and RTCP, unless the RTCP parameters are separately specified."

For SRTP_AES128_CM_HMAC_SHA1_32, RFC 5764 Section 4.1.2 specifies the following key parameters:

SRTP_AES128_CM_HMAC_SHA1_32
cipher: AES_128_CM
cipher_key_length: 128
cipher_salt_length: 112
maximum_lifetime: 2^31
auth_function: HMAC-SHA1
auth_key_length: 160
auth_tag_length: 32
RTCP auth_tag_length: 80

Source: RFC 5764 §4.1.2

Therefore, when DTLS negotiates SRTP_AES128_CM_HMAC_SHA1_32, the media layer should be configured as:

RTP/SRTP:   auth_tag_length = 32 bit
RTCP/SRTCP: auth_tag_length = 80 bit

In other words, SRTP_AES128_CM_SHA1_32 cannot simply apply a 32-bit policy to both RTP and RTCP. RTCP/SRTCP has a separately specified 80-bit authentication tag requirement.

---

3. Code Analysis

OME first configures available DTLS-SRTP protection profiles via OpenSSL, including SRTP_AES128_CM_SHA1_32:

/* src/projects/modules/dtls_srtp/dtls_transport.cpp:38 */
if (::SSL_CTX_set_tlsext_use_srtp(context, "SRTP_AEAD_AES_128_GCM:SRTP_AES128_CM_SHA1_80:SRTP_AES128_CM_SHA1_32"))

After DTLS handshake completes, OME reads the selected SRTP profile from OpenSSL:

/* src/projects/modules/dtls_srtp/dtls_transport.cpp:161 */
auto crypto_suite = _tls.GetSelectedSrtpProfileId();

GetSelectedSrtpProfileId() traces back to OpenSSL's selected SRTP protection profile:

/* src/projects/base/ovcrypto/openssl/tls.cpp:582 */
SRTP_PROTECTION_PROFILE *srtp_protection_profile = ::SSL_get_selected_srtp_profile(_ssl);

The above path confirms that OME's DTLS layer does negotiate and read the selected SRTP profile. The problem occurs at the stage where the selected profile is written into the libsrtp policy.

In the SRTP_AES128_CM_SHA1_32 branch, OME uses the 32-bit helper for the RTP policy:

/* src/projects/modules/dtls_srtp/srtp_adapter.cpp:50 */
srtp_crypto_policy_set_aes_cm_128_hmac_sha1_32(&policy.rtp);

This line is correct for RTP, as the profile's RTP authentication tag length is 32-bit.

However, the next line uses the same 32-bit helper for the RTCP policy:

/* src/projects/modules/dtls_srtp/srtp_adapter.cpp:51 */
srtp_crypto_policy_set_aes_cm_128_hmac_sha1_32(&policy.rtcp);

This is the violation point. RFC 5764 separately specifies RTCP auth_tag_length: 80 for this profile, so policy.rtcp cannot use the 32-bit helper. The correct mapping should be:

SRTP_AES128_CM_SHA1_32 branch:
    policy.rtp  -> AES_CM_128_HMAC_SHA1_32
    policy.rtcp -> AES_CM_128_HMAC_SHA1_80

Subsequent code saves the incorrect RTCP policy parameters to _rtcp_auth_tag_len:

/* src/projects/modules/dtls_srtp/srtp_adapter.cpp:80 */
_rtcp_auth_tag_len = policy.rtcp.auth_tag_len;

This length directly affects SRTCP packet protection length calculation:

/* src/projects/modules/dtls_srtp/srtp_adapter.cpp:132 */
uint32_t need_len = data->GetLength() + _rtcp_auth_tag_len + 4;

Therefore, the code-level gap is:

OME reuses RTP's 32-bit authentication policy for RTCP/SRTCP policy in the SRTP_AES128_CM_SHA1_32 branch, losing RFC 5764's separately specified 80-bit auth tag requirement for RTCP.

---

4. Impact Analysis

This is a fine-grained DTLS-SRTP profile parameter mapping error, affecting SRTCP interoperability and the integrity protection strength of RTCP control flows.

When OME negotiates SRTP_AES128_CM_SHA1_32 with a peer, OME generates or verifies SRTCP with a 32-bit authentication tag, while RFC 5764-compliant peers use an 80-bit authentication tag for SRTCP. The mismatch in SRTCP authentication tag length between both parties causes bidirectional SRTCP verification failures.

Practical impacts include:

1. OME sends SRTCP with a 32-bit auth tag, which strict peers may reject;
2. Standard 80-bit SRTCP from peers may fail verification by OME;
3. RTCP feedback, SR/RR, NACK, PLI/FIR, and other control messages may be lost;
4. Media quality feedback, congestion control, and key-frame recovery may become abnormal;
5. SRTCP integrity protection is reduced to 32 bits, weaker than the security strength required by RFC for RTCP control flows in this profile.

This issue is not merely a compatibility difference, but a standard parameter mapping error from DTLS negotiation results to the SRTP/SRTCP policy writing stage.

---

5. Dynamic Verification

This issue has been verified using a dynamic test script based on aiortc. The test logic forces both parties to negotiate SRTP_AES128_CM_SHA1_32, and aiortc sends/receives packets using an 80-bit auth tag for SRTCP per RFC 5764, to observe whether OME incorrectly processes SRTCP with a 32-bit tag.

Test command:

PYTHONPATH=/home/xiangpu/Code/webrtcfuzzing/aiortc/src \
python3 /home/xiangpu/Code/webrtcfuzzing/aiortc/examples/ome/whip_c6_srtp_sha1_32.py \
  --whip-url "http://127.0.0.1:13333/app/c6_sha1_32_test?direction=whip" \
  --profile sha1-32 \
  --run-seconds 15 \
  -v

Control test using SRTP_AES128_CM_SHA1_80:

PYTHONPATH=/home/xiangpu/Code/webrtcfuzzing/aiortc/src \
python3 /home/xiangpu/Code/webrtcfuzzing/aiortc/examples/ome/whip_c6_srtp_sha1_32.py \
  --whip-url "http://127.0.0.1:13333/app/c6_sha1_80_test?direction=whip" \
  --profile sha1-80 \
  --run-seconds 10 \
  -v

In the test forcing SRTP_AES128_CM_SHA1_32, OME server logs show SRTCP unprotect failures:

[2026-07-25 08:56:46.350] I [OutboundWorker:54] Publisher | stream.cpp:267  | OVTPublisher Application has started [c6_sha1_32_test(3897227706)] stream (MSID : 0)
[2026-07-25 08:56:46.483] E [SPICE-u11001:39] SRTP | srtp_adapter.cpp:192  | Failed to unprotect SRTCP packet, err=7
[2026-07-25 08:56:47.190] E [SPICE-u11001:39] SRTP | srtp_adapter.cpp:192  | Failed to unprotect SRTCP packet, err=14
[2026-07-25 08:56:47.769] E [SPICE-u11001:39] SRTP | srtp_adapter.cpp:192  | Failed to unprotect SRTCP packet, err=7

This dynamic result is consistent with the static code path: OME uses an incorrect SRTCP authentication tag length under the SRTP_AES128_CM_SHA1_32 profile, causing SRTCP verification failures with RFC 5764-compliant peers that use an 80-bit SRTCP tag.

[songxpu]

c6_New DTLS Association Reuses Recently Used ICE Candidate Set

1. Problem Overview

OME may reuse a local ICE candidate set that has been recently used for another DTLS association when establishing a new DTLS association over UDP/ICE.

During startup, OME generates an ICE candidate list based on configuration and appends it to the observer's _ice_candidate_list. Subsequently, each time an offer or answer is generated, OME does not allocate new local addresses or ports for the new DTLS association. Instead, it selects a set from the fixed candidate pool using the following round-robin logic:

_current_ice_candidate_index++ % _ice_candidate_list.size()

Therefore, if _ice_candidate_list contains only one candidate set, or if the round-robin cycles back to a candidate set recently used for another DTLS association, OME will reuse an old candidate set for the new UDP/DTLS association.

On unordered transports like UDP, late packets from an old DTLS association and packets from a new DTLS association may arrive interleaved. RFC 8842 requires that when establishing a new DTLS association, at least one endpoint must allocate a new 3-tuple; in the ICE context, this further translates to at least one endpoint allocating a set of ICE candidates that has not been recently used for other DTLS associations.

In summary: When generating SDP candidates for a new DTLS association, OME only cycles through a pre-generated fixed candidate pool and does not ensure that the association uses an ICE candidate set that has not been recently used.

---

2. Specification Reference

RFC 8842 states that on unordered transports such as UDP, a new DTLS association requires a new 3-tuple to distinguish DTLS packets of the old association from those of the new association.

RFC 8842 Section 5.1 specifies:

"Because of this, if an unordered transport is used for the DTLS association, a new 3-tuple (transport/source address/source port) MUST be allocated by at least one of the endpoints so that DTLS packets can be demultiplexed."

Source: RFC 8842 §5.1

RFC 8842 Section 6 maps this requirement to the ICE scenario:

"When a new DTLS association is established over an unordered transport, in order to disambiguate any packets associated with the newly established DTLS association, at least one of the endpoints MUST allocate a completely new set of ICE candidates that were not recently used for any other DTLS association."

Source: RFC 8842 §6

Therefore, in ICE-based UDP/DTLS scenarios, merely regenerating ICE ufrag / pwd is insufficient to satisfy this requirement. Implementations must also ensure that at least one endpoint uses a new 3-tuple / ICE candidate set for the new DTLS association. Otherwise, late DTLS packets from the old association may not be reliably distinguishable from DTLS packets of the new association.

---

3. Code Analysis

OME generates ICE candidates during startup and appends them to the observer's _ice_candidate_list:

/* src/projects/modules/ice/ice_port_manager.cpp:56-77 — IcePortManager::CreateIceCandidates */
RtcIceCandidateList ice_candidate_list;

if (GenerateIceCandidates(ice_candidates_config, &ice_candidate_list) == false)
{
    return false;
}

if (_ice_port->CreateIceCandidates(server_name, server_config, ice_candidate_list, ice_worker_count) == false)
{
    Release(observer);
}
else
{
    observer->AppendIceCandidates(ice_candidate_list);
}

The observer simply adds these candidates to an internal list:

/* src/projects/modules/ice/ice_port_observer.h:59-68 — IcePortObserver::AppendIceCandidates */
void AppendIceCandidates(const RtcIceCandidateList &ice_candidate_list)
{
    _ice_candidate_list.insert(_ice_candidate_list.end(), ice_candidate_list.begin(), ice_candidate_list.end());
}

RtcIceCandidateList _ice_candidate_list;

Subsequent Provider offer generation does not reallocate candidates, but selects a set from _ice_candidate_list using modulo:

/* src/projects/providers/webrtc/webrtc_provider.cpp:397-403 — WebRTCProvider::OnRequestOffer */
if (_ice_candidate_list.empty() == false)
{
    auto candidate_index_to_send = _current_ice_candidate_index++ % _ice_candidate_list.size();
    const auto &candidates = _ice_candidate_list[candidate_index_to_send];

    ice_candidates->insert(ice_candidates->end(), candidates.cbegin(), candidates.cend());
}

Publisher offer path uses the same logic:

/* src/projects/publishers/webrtc/webrtc_publisher.cpp:340-346 — WebRtcPublisher::OnRequestOffer */
if (_ice_candidate_list.empty() == false)
{
    auto candidate_index_to_send = _current_ice_candidate_index++ % _ice_candidate_list.size();
    const auto &candidates = _ice_candidate_list[candidate_index_to_send];

    ice_candidates->insert(ice_candidates->end(), candidates.cbegin(), candidates.cend());
}

Answer generation similarly takes a round-robin value from the fixed candidate list:

/* src/projects/providers/webrtc/webrtc_provider.cpp:715-727 — WebRTCProvider::OnSdpOffer */
std::set<IceCandidate> ice_candidates;
if (_ice_candidate_list.empty() == false)
{
    auto candidate_index_to_send = _current_ice_candidate_index++ % _ice_candidate_list.size();
    const auto &candidates = _ice_candidate_list[candidate_index_to_send];

    for (const auto &candidate : candidates)
    {
        ice_candidates.emplace(candidate);
    }
}

auto answer_sdp = application->CreateAnswerSDP(offer_sdp, _ice_port->GenerateUfrag(), ice_candidates);

Finally, these candidates are written into the answer SDP:

/* src/projects/providers/webrtc/webrtc_application.cpp:276-280 — WebRTCApplication::CreateAnswerSDP */
for (const auto &ice_candidate : ice_candidates)
{
    answer_media_desc->AddIceCandidate(std::make_shared<IceCandidate>(ice_candidate));
}

The above paths demonstrate that OME's ICE candidates are not dynamically allocated for each new DTLS association, but are pre-generated during startup and subsequently cyclically reused in offers/answers.

Therefore, OME uses a fixed candidate pool with round-robin selection when generating SDP candidates, but does not track recently used candidate sets, nor does it allocate new local addresses/ports or new ICE candidate sets for new DTLS associations.

---

4. Impact Analysis

This is an issue where the DTLS association demultiplexing condition over UDP/ICE is not guaranteed. It primarily affects reconnection, renegotiation, scenarios with multiple sessions established in quick succession, or cases where late packets from old DTLS associations may be present in the network.

On unordered transports like UDP, late packets from an old DTLS association may still be present in the network. If a new DTLS association reuses the old association's 3-tuple / ICE candidate set, the receiver may not be able to reliably distinguish whether these packets belong to the old association or the new association based solely on the transport 5-tuple. RFC 8842 requires at least one endpoint to allocate a new 3-tuple / candidate set precisely to avoid such demultiplexing ambiguity.

[songxpu]

c12_DTLS Setup Role Does Not Drive Handshake Direction

1. Problem Overview

In OME's publisher path, the DTLS handshake direction is not determined based on the setup value in the remote answer. After saving and logging the remote SDP, RtcSession::Start() unconditionally creates a DTLS server context and ultimately calls SSL_accept(). In other words, regardless of whether the remote answer selects active or passive, OME always acts as a DTLS server and waits for the peer to initiate the handshake. Consequently, when the remote answer selects a=setup:passive, both parties may become passive waiters, preventing the new DTLS association from being established.

However, this issue is conditional: if the remote answer selects a=setup:active, the remote side will actively send a ClientHello, and the role conflict described here does not occur.

2. Specification Reference

RFC 4145 specifies that the offerer declares which role(s) it is willing to perform via the setup attribute, and the answerer, taking the offerer's declared willingness into account, chooses the actual roles that both endpoints will perform during connection establishment.

RFC 4145 Section 4.1 states:

The offerer states which role or roles it is willing to perform; and the answerer, taking the offerer's willingness into consideration, chooses which roles both endpoints will actually perform during connection establishment.

Source: RFC 4145 §4.1

In an actpass offer, the answerer may choose either active or passive. If the answerer selects passive, the offerer is expected to take the active role, i.e., become the DTLS client.

RFC 8842 Section 5.4 further clarifies the offerer's handling requirements upon receiving the answer:

If the offerer becomes DTLS client (based on the value of the SDP "setup" attribute value [RFC4145]), the offerer MUST establish a DTLS association. If the offerer becomes DTLS server, it MUST wait for the answerer to establish the DTLS association.

Source: RFC 8842 §5.4

Therefore, the a=setup attribute in the remote answer cannot be treated as a mere SDP field; it must actively drive the client/server handshake direction of the local DTLS transport.

3. Code Analysis

OME's publisher offer declares actpass in the SDP:

/* src/projects/publishers/webrtc/rtc_stream.cpp:416-426 — RtcStream::CreateSessionDescription */
auto offer_sdp = std::make_shared<SessionDescription>(SessionDescription::SdpType::Offer);
...
offer_sdp->SetIceOption("trickle");
offer_sdp->SetIceUfrag(ov::Random::GenerateString(8));
offer_sdp->SetIcePwd(ov::Random::GenerateString(32));
...
offer_sdp->SetFingerprint("sha-256", _certificate->GetFingerprint("sha-256"));

/* src/projects/publishers/webrtc/rtc_stream.cpp:505-520 — RtcStream::MakeVideoDescription */
video_media_desc->SetSetup(MediaDescription::SetupType::ActPass);
video_media_desc->UseDtls(true);

Upon receiving the remote answer, RtcSession::Start() logs _peer_sdp and then creates a DtlsTransport and starts DTLS:

/* src/projects/publishers/webrtc/rtc_session.cpp:80-102 — RtcSession::Start */
logtd("[WebRTC Publisher] AnswerSDP");
logtd("%s", _peer_sdp->ToString().CStr());
...
_dtls_transport = std::make_shared<DtlsTransport>();

std::shared_ptr<RtcApplication> application =
    std::static_pointer_cast<RtcApplication>(GetApplication());

_dtls_transport->SetLocalCertificate(application->GetCertificate());
_dtls_transport->StartDTLS();

At this point, the code does not read GetSetup() from the remote SDP media description, nor does it select DTLS client or server mode based on the answer's setup value.

Subsequently, DtlsTransport::SetLocalCertificate() unconditionally creates a server context:

/* src/projects/modules/dtls_srtp/dtls_transport.cpp:51-59 — DtlsTransport::SetLocalCertificate */
_tls_context = ov::TlsContext::CreateServerContext(
    ov::TlsMethod::DTls,
    _local_certificate,
    ...
    &tls_context_callback,
    &error);

The server context internally uses DTLS_server_method():

/* src/projects/base/ovcrypto/openssl/tls_context.cpp:26-35 — TlsContext::CreateServerContext */
const SSL_METHOD *ssl_method =
    (method == TlsMethod::Tls) ? ::TLS_server_method() : ::DTLS_server_method();

The handshake subsequently proceeds via Accept():

/* src/projects/modules/dtls_srtp/dtls_transport.cpp:121-125 — DtlsTransport::ContinueSSL */
bool DtlsTransport::ContinueSSL()
{
    logtt("Continue DTLS...");
    int error = _tls.Accept();

Tls::Accept() ultimately calls OpenSSL's SSL_accept():

/* src/projects/base/ovcrypto/openssl/tls.cpp:167-181 — Tls::Accept */
int result = ::SSL_accept(_ssl);
...
return SSL_ERROR_NONE;

Therefore, when the remote answer selects a=setup:passive, the static call path is as follows:

RtcStream::CreateSessionDescription
    -> local offer: a=setup:actpass
    -> remote answer: a=setup:passive
        -> RtcSession::Start
            -> DtlsTransport::SetLocalCertificate
                -> CreateServerContext(DTLS_server_method)
                    -> DtlsTransport::ContinueSSL
                        -> Tls::Accept
                            -> SSL_accept

This path contains no corresponding branch for CreateClientContext(), Tls::Connect(), or SSL_connect(). Hence, OME does not translate the remote answer's setup result into the actual DTLS handshake direction.

4. Impact Analysis

This is an issue where the DTLS setup role fails to drive the handshake direction, primarily affecting interoperability and session availability.

Under the triggering condition, the remote side selects a=setup:passive, indicating that it expects the offerer to initiate the DTLS handshake. OME, as the offerer, should act as the DTLS client and send a ClientHello. However, OME currently unconditionally calls SSL_accept() and also waits for the peer to initiate the handshake. As a result, both parties enter a passive waiting state, and the new DTLS association may fail to be established.

[songxpu]

C13_ICE Capability Declaration — Missing ice2 Option in SDP

1. Problem Overview

Note: if OME explicitly implements only the legacy RFC 5245 ICE specification and does not support RFC 8445 ICE semantics, then the absence of the ice2 option can be considered legacy-compatible behavior and does not constitute a violation. In our analysis, we considered the evolution of RFCs and chose to audit against the latest specification. This report is included here for the sake of analytical completeness.

If OME operates as an RFC 8445-compliant ICE agent, or expects to be treated as one by peers, its SDP MUST declare the ice2 option. However, the current code path does not include this declaration.

OME's current ICE SDP capability declaration is incomplete. The offer path only generates:

a=ice-options:trickle

It does not include the RFC 8445-required:

a=ice-options:ice2

The answer path also does not explicitly set the ice2 option. Therefore, although OME generates ICE credentials and outputs ICE candidates, ice-ufrag, ice-pwd, and other ICE-related fields in the SDP, it does not use ice-options to explicitly inform the peer that it conforms to RFC 8445 ICE semantics.

It is important to note that trickle and ice2 are not equivalent capabilities:

• trickle indicates support for Trickle ICE.
• ice2 indicates that the endpoint complies with RFC 8445 ICE semantics.

Declaring trickle alone does not substitute for ice2.

Core Issue:
OME enables ICE and declares trickle, but—under the premise of RFC 8445 applicability—does not declare ice2, resulting in an incomplete ICE capability declaration.

---

2. Specification Reference

RFC 8445 uses the SDP ice-options attribute to declare the extended capabilities supported by an ICE agent. For an ICE agent compliant with RFC 8445, the specification requires that it MUST use the ice2 option to inform the peer of its compliance.

RFC 8445 Section 10 "ICE Option" states:

"An agent compliant to this specification MUST inform the peer about the compliance using the 'ice2' option."

Source: RFC 8445 §10, ICE Option

Therefore, ice2 serves as the declaration signal for RFC 8445 compliance. If an implementation intends to participate in ICE negotiation under RFC 8445 semantics, it cannot output only trickle while omitting ice2.

In other words:

trickle → supports Trickle ICE
ice2    → declares compliance with RFC 8445 ICE semantics

These two options express different capabilities and are not interchangeable.

---

3. Code Analysis

OME's offer construction path only sets trickle:

/* src/projects/providers/webrtc/webrtc_application.cpp:68-79 — WebRTCApplication::CreateOfferSDP */
offer_sdp->SetExtmapAllowMixed(true);
offer_sdp->SetTiming(0, 0);
offer_sdp->SetIceOption("trickle");
...
offer_sdp->SetFingerprint("sha-256", _certificate->GetFingerprint("sha-256"));

The SDP serialization function outputs only the current _ice_option field's content and does not automatically append ice2:

/* src/projects/modules/sdp/common_attr.cpp:41-54 — CommonAttr::SerializeCommonAttr */
if (!_ice_option.IsEmpty())
{
    sdp.AppendFormat("a=ice-options:%s\r\n", _ice_option.CStr());
}

Therefore, the actual output from the offer path is:

a=ice-options:trickle

rather than:

a=ice-options:trickle ice2

Thus, OME outputs the ice-options field as-is with only the single configured value, but—under the premise of RFC 8445 applicability—fails to include the mandatory ice2 declaration.

---

4. Impact Analysis

This is an incomplete ICE capability declaration issue, primarily affecting protocol compliance and interoperability.

In the offer scenario: if OME actually operates under RFC 8445 ICE semantics but declares only trickle without ice2, a strict peer may be unable to confirm that OME is an RFC 8445-compliant ICE agent and may treat it as a legacy RFC 5245 peer. This can affect both parties' expectations regarding ICE behavior, particularly in areas such as:

• Nomination
• ICE concluding
• Default destination selection
• Extended capability negotiation
• Subsequent SDP update procedures

In the answer scenario: whether this constitutes a violation depends on the remote offer's ICE capability declaration and OME's actual supported ICE semantics. If the remote side has already declared RFC 8445 / ice2 capability, and OME as the answerer also participates in negotiation under RFC 8445 semantics, then the absence of ice2 in the answer results in an incomplete capability declaration. If OME participates solely as an RFC 5245-compatible peer, this behavior can be interpreted as legacy ICE compatibility.

Therefore, under the premise that OME operates as an RFC 8445-compliant ICE agent, its SDP declaring only trickle without ice2 prevents the peer from correctly identifying its RFC 8445 ICE compliance capability through SDP.

[songxpu]

c15_Candidate/EoC Placement Error in BUNDLE and EoC Not Consumed

1. Problem Overview

OME exhibits state fragmentation in both the generation and consumption of ICE candidates and end-of-candidates in BUNDLE scenarios.

On the sending side, when generating an answer containing a BUNDLE group, OME writes the same set of ICE candidates to every media section. Since CommonAttr::SerializeCommonAttr() automatically appends a=end-of-candidates whenever the candidate list is non-empty, each bundled media section ends up with both candidates and an end-of-candidates line. In an answer with two or more bundled media sections, this causes non-tagged m= sections to also carry ICE media-level attributes. Per RFC 9143, ICE media-level attributes in a BUNDLE group MUST only appear in the tagged m= section and apply to the entire BUNDLE group; they should not be duplicated across each bundled section.

On the receiving side, although OME's SDP parser recognizes a=end-of-candidates, the handling logic is simply "Nothing to do." It does not store the presence of this attribute nor pass this end-of-candidates indication to the ICE agent. Consequently, even when the remote SDP explicitly indicates that candidate generation has completed, OME's ICE state cannot consume this information.

---

2. Specification Reference

RFC 9143 has clear requirements regarding the placement of ICE media-level attributes in BUNDLE scenarios. In an answer containing a BUNDLE group, ICE-related media-level attributes MUST only appear in the tagged m= section and apply to the entire BUNDLE group, rather than being repeated across each bundled media section.

RFC 9143 Section 10 states:

"when an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group and when an offerer sends a subsequent offer that contains a BUNDLE group, ICE-related media-level attributes are only included in the tagged "m=" section (suggested offerer-tagged "m=" section or answerer-tagged "m=" section), and the ICE properties are applied to each bundled "m=" section within the BUNDLE group."

Source: RFC 9143 §10, ICE Considerations

RFC 9429 additionally requires that SDP parsers store the presence of a=end-of-candidates when parsing a media section, rather than treating it as a stateless attribute to be ignored.

RFC 9429 Section 5.8.2 states:

"If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in [RFC8840], Section 8.1, and its presence or absence flagged and stored."

Source: RFC 9429 §5.8.2, Media Section Parsing

When applying a remote description, if a=end-of-candidates is present, implementations MUST also pass it as an end-of-candidates indication to ICE processing.

RFC 9429 Section 5.10 states:

"If an "a=end-of-candidates" attribute is present, process the end-of-candidates indication as described in [RFC8838], Section 14."

Source: RFC 9429 §5.10, Applying a Remote Description

For the JSEP API, an empty candidate is not an ordinary invalid candidate but rather an end-of-candidates indication. RFC 9429 Section 4.1.19 states:

"If the IceCandidate's candidate field is non-null, the IceCandidate is treated as a new remote ICE candidate, which will be added to the current and/or pending remote description according to the rules defined for Trickle ICE. Otherwise, the IceCandidate is treated as an end-of-candidates indication, as defined in [RFC8838], Section 14."

Source: RFC 9429 §4.1.19, addIceCandidate

Therefore, the placement of candidates/EoC, the parsing and storage of end-of-candidates, and the end-of-candidates semantics of an empty candidate are not localized formatting issues, but rather cross-cutting constraints spanning SDP generation, SDP parsing, and the ICE agent state machine.

---

3. Code Analysis

OME's SessionDescription writes all media MIDs into a single BUNDLE group:

/* src/projects/modules/sdp/session_description.cpp:48-54 — SessionDescription::UpdateData */
sdp += "a=group:BUNDLE";
for(auto &media_description : _media_list)
{
    sdp.AppendFormat(" %s", media_description->GetMid().value_or("").CStr());
}

In the answer creation path, OME first constructs a common ice_candidates set:

/* src/projects/providers/webrtc/webrtc_provider.cpp:715-727 — WebRTCProvider answer creation */
std::set<IceCandidate> ice_candidates;
...
for (const auto &candidate : candidates)
{
    ice_candidates.emplace(candidate);
}
...
auto answer_sdp = application->CreateAnswerSDP(
    offer_sdp, _ice_port->GenerateUfrag(), ice_candidates);

CreateAnswerSDP() then adds this same set of candidates to every answer media description:

/* src/projects/providers/webrtc/webrtc_application.cpp:276-280 — WebRTCApplication::CreateAnswerSDP */
for (const auto &ice_candidate : ice_candidates)
{
    answer_media_desc->AddIceCandidate(
        std::make_shared<IceCandidate>(ice_candidate));
}

Each media description invokes the common attribute serializer during serialization:

/* src/projects/modules/sdp/media_description.cpp:56-63 — MediaDescription::UpdateData */
ov::String common_attr_text;
if (SerializeCommonAttr(common_attr_text) == false)
{
    return false;
}
sdp.Append(common_attr_text);

The common attribute serializer outputs all candidates in the section and automatically appends a=end-of-candidates when the candidate list is non-empty:

/* src/projects/modules/sdp/common_attr.cpp:57-66 — CommonAttr::SerializeCommonAttr */
for (auto &candidate : _ice_candidates)
{
    sdp.AppendFormat("a=%s\r\n", candidate->ToString().CStr());
}
if (_ice_candidates.empty() == false)
{
    sdp.AppendFormat("a=end-of-candidates\r\n");
}

Therefore, in a multi-media BUNDLE answer, the actual data flow is:

CreateAnswerSDP
    -> each MediaDescription receives the same ice_candidates set
        -> each MediaDescription::UpdateData
            -> CommonAttr::SerializeCommonAttr
                -> each bundled section outputs candidates + end-of-candidates

This causes non-tagged m= sections to also carry ICE media-level attributes, which is inconsistent with RFC 9143's requirements on ICE attribute placement in BUNDLE.

On the receiving side, there is also a semantic loss. After recognizing a=end-of-candidates, the SDP parser stores no state and triggers no end-of-candidates indication to the ICE agent:

/* src/projects/modules/sdp/common_attr.cpp:204-208 — CommonAttr::ParsingCommonAttrLine */
// a=end-of-candidates
else if (content.compare(0, OV_COUNTOF("end-of") - 1, "end-of") == 0)
{
    // Nothing to do
}

This means that a=end-of-candidates appearing in a remote SDP does not enter the MediaDescription state, nor is it translated into an ICE end-of-candidates indication when applying the remote description.

In the signaling candidate update path, empty candidates are directly skipped:

/* src/projects/modules/rtc_signalling/rtc_signalling_server.cpp:975-984 — RtcSignallingServer::DispatchCandidate */
for (const auto &candidate_iterator : candidates_value)
{
    ov::String candidate =
        ov::Converter::ToString(candidate_iterator["candidate"]);

    if (candidate.IsEmpty())
    {
        logtt("[Host -> OME] The host peer sents an empty candidate");
        continue;
    }
    ...
}

If this signaling command carries a JSEP addIceCandidate(null) or the end-of-candidates semantics of an empty candidate, the continue here directly discards the candidate generation completion indication.

In summary, the sending side does not restrict candidate/EoC placement to the BUNDLE tagged section; the receiving side does not store or propagate end-of-candidates state; and empty candidates in signaling do not enter end-of-candidates processing. The code-level gap is: OME treats candidates and EoC as ordinary common attributes for each media section, rather than generating and consuming them as BUNDLE tagged-section-level ICE state.

---

4. Impact Analysis

This is an operational bug, primarily affecting BUNDLE SDP compliance, Trickle ICE termination state, and interoperability. On the sending side, if the answer contains multiple bundled media sections, OME duplicates candidates and end-of-candidates across multiple sections. A strict peer that properly handles BUNDLE attribute placement may consider this answer non-compliant, or may ignore or rewrite ICE attributes in non-tagged sections, leading to inconsistent understanding of ICE attribute ownership between both parties.

On the receiving side, OME discards a=end-of-candidates, preventing the ICE agent from learning that the remote side's candidate generation has completed. This can result in the ICE agent continuing to wait for additional candidates that will never arrive, thereby delaying or preventing the ICE checklist from converging and causing connection establishment to be prolonged or to fail entirely. In some cases, this may lead to timeouts and inconsistent candidate states between the two endpoints, further degrading the reliability of the ICE negotiation process.

[songxpu]

c16_WHIP/WebRTC Provider Does Not Select ICE Role Based on Remote ice-lite

1. Problem Overview

OME's WHIP/WebRTC Provider does not correctly handle the session-level a=ice-lite attribute when receiving a remote SDP offer.

OME itself does not generate a=ice-lite, so under RFC 8839 semantics it should be considered a full ICE agent. If the remote offer carries a=ice-lite, this indicates that the remote side is an ICE-lite agent. In this full/lite combination, the ICE roles are not determined simply by offerer/answerer identity, but rather by RFC 8445: the full agent MUST take the controlling role, and the lite agent MUST take the controlled role.

The issue with the current implementation is that OME does not preserve the a=ice-lite state when parsing the remote SDP, and subsequently in WebRTCProvider::OnSdpOffer() it still unconditionally creates the ICE session with IceSession::Role::CONTROLLED. As a result, in the scenario where the remote side is an ICE-lite offerer and OME is a full ICE answerer, OME incorrectly runs as the controlled agent.

This issue is conditional. In ordinary full/full scenarios, the answerer taking the controlled role is typically correct; the problem only occurs in full/lite combinations where the remote offer explicitly declares a=ice-lite.

2. Specification Reference

RFC 8839 specifies that a=ice-lite is an ICE implementation type declaration. An ICE-lite implementation MUST include this attribute, while a full implementation MUST NOT include it.

RFC 8839 Section 4.2.1.4 states:

"An ICE-lite implementation [RFC8445] MUST include an SDP "ice-lite" attribute. A full implementation MUST NOT include that attribute."

Source: RFC 8839 §4.2.1.4

RFC 8839 Section 5.3 further clarifies:

"ice-lite" is a session-level attribute only, and indicates that an agent is a lite implementation.

Source: RFC 8839 §5.3

ICE roles cannot be determined solely by offerer/answerer identity. RFC 8839 Section 4.2.3 explicitly states that the offerer acts as the initiating agent and the answerer as the responding agent, but the controlling and controlled roles are determined using the procedures in RFC 8445:

"The offerer acts as the initiating agent. The answerer acts as the responding agent. The ICE roles (controlling and controlled) are determined using the procedures in [RFC8445]."

Source: RFC 8839 §4.2.3

For the full/lite combination, RFC 8445 Section 6.1.1 specifies:

"One agent full, one lite: The full agent MUST take the controlling role, and the lite agent MUST take the controlled role. The full agent will form checklists, run the ICE state machines, and generate connectivity checks."

Source: RFC 8445 §6.1.1

Therefore, when the remote offer carries a=ice-lite and OME itself is a full ICE agent, OME—even as the answerer—MUST become the controlling agent, rather than continuing to use the controlled role unconditionally.

3. Code Analysis

The WHIP entry point parses the request body as a remote SDP offer and passes it to the Provider:

/* src/projects/modules/whip/whip_server.cpp:341-359 — WhipServer::CreateInterceptor */
auto data = request->GetRequestBody();
logti("WHIP SDP Offer: %s", data->ToString().CStr());

auto offer_sdp = std::make_shared<SessionDescription>(SessionDescription::SdpType::Offer);
if (offer_sdp->FromString(data->ToString()) == false)
{
	response->SetStatusCode(http::StatusCode::BadRequest);
	return http::svr::NextHandler::DoNotCall;
}

auto answer = _observer->OnSdpOffer(request, offer_sdp);

The SDP parsing enters SessionDescription::FromString(), which dispatches session-level attributes to the session/common attribute parsing logic:

/* src/projects/modules/sdp/session_description.cpp:155-164 — SessionDescription::FromString */
else
{
	if(ParsingSessionLine(type, content) == false)
	{
		return false;
	}
}

Update();

However, CommonAttr::ParsingCommonAttrLine() only handles attributes such as ice-options, ice-ufrag, ice-pwd, and candidate, with no branch for ice-lite:

/* src/projects/modules/sdp/common_attr.cpp:105-162 — CommonAttr::ParsingCommonAttrLine */
else if (content.compare(0, OV_COUNTOF("ice-o") - 1, "ice-o") == 0)
{
	auto match = SDPRegexPattern::GetInstance()->MatchIceOption(content.c_str());
	_ice_option = match.GetGroupAt(1).GetValue();
}
else if (content.compare(0, OV_COUNTOF("ice-u") - 1, "ice-u") == 0)
{
	auto match = SDPRegexPattern::GetInstance()->MatchIceUfrag(content.c_str());
	_ice_ufrag = match.GetGroupAt(1).GetValue();
}
else if (content.compare(0, OV_COUNTOF("ice-p") - 1, "ice-p") == 0)
{
	auto match = SDPRegexPattern::GetInstance()->MatchIcePwd(content.c_str());
	_ice_pwd = match.GetGroupAt(1).GetValue();
}
else if (content.compare(0, OV_COUNTOF("cand") - 1, "cand") == 0)
{
	auto candidate = std::make_shared<IceCandidate>();
	if (candidate->ParseFromString(content.c_str()) == true)
	{
		AddIceCandidate(candidate);
	}
}

Unknown attributes are merely logged and return success. Therefore, the session-level a=ice-lite is accepted but not stored in the SDP object:

/* src/projects/modules/sdp/common_attr.cpp:204-214 — CommonAttr::ParsingCommonAttrLine */
else if (content.compare(0, OV_COUNTOF("end-of") - 1, "end-of") == 0)
{
	// Nothing to do
}
else
{
	logw("SDP", "Unknown attribute type: %c=%s", type, content.c_str());
}

return true;

Subsequently, WebRTCProvider::OnSdpOffer() unconditionally creates the ICE session with IceSession::Role::CONTROLLED:

/* src/projects/providers/webrtc/webrtc_provider.cpp:727-763 — WebRTCProvider::OnSdpOffer */
auto answer_sdp = application->CreateAnswerSDP(offer_sdp, _ice_port->GenerateUfrag(), ice_candidates);
auto ice_session_id = _ice_port->IssueUniqueSessionId();

// Remote Offer, Local Answer
auto stream = WebRTCStream::Create(StreamSourceType::WebRTC, final_stream_name,
                                   PushProvider::GetSharedPtrAs<PushProvider>(),
                                   answer_sdp, offer_sdp, _certificate,
                                   _ice_port, ice_session_id, request_info,
                                   webrtc_app_config);

RegisterStreamToSessionKeyStreamMap(stream);

auto ice_timeout = application->GetConfig().GetProviders().GetWebrtcProvider().GetTimeout();
_ice_port->AddSession(IcePortObserver::GetSharedPtr(), ice_session_id,
                      IceSession::Role::CONTROLLED,
                      answer_sdp, offer_sdp, ice_timeout,
                      session_life_time, stream);

IcePort::AddSession() simply takes the role passed by the caller and creates an IceSession, without re-examining whether the peer SDP contains a=ice-lite:

/* src/projects/modules/ice/ice_port.cpp:337-352 — IcePort::AddSession */
void IcePort::AddSession(const std::shared_ptr<IcePortObserver> &observer,
                         session_id_t session_id, IceSession::Role role,
                         const std::shared_ptr<const SessionDescription> &local_sdp,
                         const std::shared_ptr<const SessionDescription> &peer_sdp,
                         int expired_ms, uint64_t life_time_epoch_ms,
                         std::any user_data)
{
	const ov::String &local_ufrag = local_sdp->GetIceUfrag();
	const ov::String &peer_ufrag = peer_sdp->GetIceUfrag();

	std::shared_ptr<IceSession> new_session =
        std::make_shared<IceSession>(session_id, role, local_sdp, peer_sdp,
                                     expired_ms, life_time_epoch_ms,
                                     user_data, observer);

This role subsequently affects the ICE role attribute carried in STUN Binding Requests. If OME is incorrectly set to CONTROLLED, it will send ICE-CONTROLLED rather than the ICE-CONTROLLING required in the full/lite scenario:

/* src/projects/modules/ice/ice_port.cpp:1017-1052 — IcePort::SendStunBindingRequest */
if (ice_session->GetRole() == IceSession::Role::CONTROLLING)
{
	auto ice_controlling_attr = std::make_shared<StunIceControllingAttribute>();
	message.AddAttribute(ice_controlling_attr);
}
else if (ice_session->GetRole() == IceSession::Role::CONTROLLED)
{
	auto ice_controlled_attr = std::make_shared<StunIceControlledAttribute>();
	message.AddAttribute(ice_controlled_attr);
}

Therefore, the complete path is: a=ice-lite in the remote offer is accepted by the parser as an unknown attribute but not stored; the Provider unconditionally uses the simplified rule of answerer-as-controlled when creating the ICE session; and subsequent STUN connectivity checks also send ICE-CONTROLLED based on this incorrect role. The code does not implement the role selection required by RFC 8445 for the full/lite combination.

4. Impact Analysis

This is an ICE role selection error, primarily affecting interoperability between the WHIP/WebRTC Provider and ICE-lite offerers.

In common browser full/full scenarios, OME using the controlled role as the answerer typically works correctly. However, when the remote side is an ICE-lite offerer, RFC requires OME as the full agent to take the controlling role, responsible for forming checklists, running the ICE state machine, sending connectivity checks, and performing final candidate pair selection and nomination.

The current implementation unconditionally sets OME to controlled, causing both parties to have incorrect role assumptions. The remote ICE-lite agent itself should also be controlled; if OME also runs as controlled, the connectivity check and nomination process may not proceed according to the full/lite mode. In practice, this may manifest as incomplete ICE checks, failure to properly nominate candidate pairs, connection establishment failure, or interoperability failure with ICE-lite WHIP peers.

In summary, OME does not preserve the remote a=ice-lite attribute, nor does it re-select the ICE role based on the full/lite combination; when the remote side is an ICE-lite offerer, OME incorrectly creates the ICE session with the controlled role, violating RFC 8445's requirement that the full agent take the controlling role.

[songxpu]

c21_Answer Rejects rtcp-mux but Still Uses Single ICE Component for RTP/RTCP

1. Problem Overview

OME's WebRTC offerer path requests a=rtcp-mux in the SDP offer, indicating a desire to multiplex RTP and RTCP on the same port. However, upon receiving the remote answer, OME does not check whether the answer also contains a=rtcp-mux, nor does it switch to separate RTP/RTCP port paths when the answer rejects multiplexing.

In the current implementation, ICE candidates default to component 1, and the sending path only uses the currently connected candidate pair. This means that subsequent RTP and RTCP packets are both sent through the same ICE candidate pair. Therefore, if the remote answer does not accept rtcp-mux, OME still sends RTP and RTCP in multiplexed mode, without enabling a second ICE component or using a separate RTCP port.

2. Specification Reference

RFC 5761 requires that upon receiving the answer, the offerer MUST check whether the answer contains a=rtcp-mux. Only when the answer explicitly includes this attribute may the offerer multiplex RTP and RTCP on a single port.

RFC 5761 Section 5.1.1 states:

"If the answer does not contain an "a=rtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute."

Source: RFC 5761 §5.1.1

RFC 5761 Section 5.1.3 further clarifies the interaction with ICE: if the answer accepts rtcp-mux, ICE may proceed as if only a single RTP candidate were offered; if the answer does not accept it, both RTP and RTCP candidate sets should be used, eventually establishing a session with RTP and RTCP on separate ports.

"On receipt of the answer, the offerer looks for the presence of the "a=rtcp-mux" line for each media where multiplexing was offered. If this is present, then connectivity checks proceed as if only a single candidate (for RTP) were offered, and multiplexing is used once the session is established. If the "a=rtcp-mux" line is not present, the session proceeds with connectivity checks using both RTP and RTCP candidates, eventually leading to a session being established with RTP and RTCP on separate ports (as signalled by the "a=rtcp:" attribute)."

Source: RFC 5761 §5.1.3

Therefore, the actual transmission mode for rtcp-mux MUST be determined by the answer. The offerer sending a mux offer does not guarantee that multiplexing will be used; only when the answer also contains a=rtcp-mux may single-port RTP/RTCP multiplexing be employed.

3. Code Analysis

OME's Provider offer generation path enables rtcp-mux:

/* src/projects/providers/webrtc/webrtc_application.cpp:88-96
 * WebRTCApplication::CreateOfferSDP
 */
auto video_media_desc = std::make_shared<MediaDescription>();
video_media_desc->UseRtcpMux(true);
video_media_desc->SetDirection(MediaDescription::Direction::RecvOnly);

Publisher offer generation path similarly enables rtcp-mux:

/* src/projects/publishers/webrtc/rtc_stream.cpp:519-523
 * RtcStream::MakeVideoDescription
 */
video_media_desc->UseRtcpMux(true);

Upon receiving the remote answer, the Provider path directly passes offer_sdp and answer_sdp to IcePort::AddSession(). No conditional branch based on whether a=rtcp-mux exists in answer_sdp is observed in this path:

/* src/projects/providers/webrtc/webrtc_provider.cpp:479-508
 * WebRTCProvider::OnAddRemoteDescription
 */
auto ice_timeout = application->GetConfig().GetProviders().GetWebrtcProvider().GetTimeout();
_ice_port->AddSession(IcePortObserver::GetSharedPtr(), ice_session_id,
                      IceSession::Role::CONTROLLING, offer_sdp, answer_sdp,
                      ice_timeout, session_life_time.value(), stream);

The Publisher path handles it identically:

/* src/projects/publishers/webrtc/webrtc_publisher.cpp:443-457
 * WebRtcPublisher::OnAddRemoteDescription
 */
auto ice_timeout = application->GetConfig().GetPublishers().GetWebrtcPublisher().GetTimeout();
_ice_port->AddSession(IcePortObserver::GetSharedPtr(), ice_session_id,
                      IceSession::Role::CONTROLLING, offer_sdp, answer_sdp,
                      ice_timeout, session_life_time, session);

During SDP serialization, a=rtcp-mux is output solely based on the _use_rtcpmux_flag:

/* src/projects/modules/sdp/media_description.cpp:70-73
 * MediaDescription::UpdateData
 */
if (_use_rtcpmux_flag)
{
    sdp.AppendFormat("a=rtcp-mux\r\n");
}

The parsing side does not establish a separate RTCP port state for a=rtcp::

/* src/projects/modules/sdp/media_description.cpp:582-585
 * MediaDescription::ParsingMediaLine
 */
else if (content.compare(0, OV_COUNTOF("rtcp:") - 1, "rtcp:") == 0)
{
    // No need
}

ICE candidates default to component id 1:

/* src/projects/modules/ice/ice_candidate.cpp:25-32
 * IceCandidate::IceCandidate
 */
IceCandidate::IceCandidate(const ov::String &transport,
                           const ov::SocketAddress &address)
    : _component_id(1),
      _transport(std::move(transport)),
      _priority(50)
{
}

The sending path also only uses the currently connected candidate pair, without distinguishing different components or different ports for RTP/RTCP:

/* src/projects/modules/ice/ice_port.cpp:549-604
 * IcePort::Send
 */
auto connected_candidate_pair = ice_session->GetConnectedCandidatePair();
if (connected_candidate_pair == nullptr)
{
    return false;
}

return remote->SendFromTo(connected_candidate_pair->GetAddressPair(),
                          send_data);

4. Impact Analysis

This is an issue where the RTP/RTCP mux negotiation result is not enforced, primarily affecting interoperability with peers that do not support or reject a=rtcp-mux.

If the remote answer does not contain a=rtcp-mux, per RFC 5761, OME as the offerer MUST NOT continue to multiplex RTP and RTCP on a single port, and should instead use a separate RTCP port or the corresponding ICE component. The current implementation still sends both RTP and RTCP through the same connected candidate pair, which may prevent the remote side from receiving control packets on the expected RTCP port, or cause RTCP session establishment to fail.

Since RTCP carries receiver reports, sender reports, NACK, PLI/FIR, transport feedback, and other control information, a broken RTCP path may also impair media quality feedback, congestion control, key-frame recovery, and session statistics. For strict peers that adhere to offer/answer semantics, OME's behavior may also be perceived as failing to comply with the negotiated answer, potentially leading to session establishment failure or abnormal media negotiation.

[songxpu]

c23_RTP with Bound SSRC Does Not Validate Negotiated PT*

1. Problem Overview

OME's RTP receive path, after parsing the RTP payload type (PT), does not check whether that PT belongs to the negotiated payload type set of the corresponding media section or track.

The current implementation first binds the RTP packet to an established track based on SSRC, MID, or RID; once the track is found, the RTP packet is sent directly to the jitter buffer and ultimately passed to that track's depacketizer for processing. For RTP streams with an existing SSRC mapping, even if subsequent packets use an unknown PT, or a PT that does not belong to that track's negotiated formats, they are not discarded.

2. Specification Reference

The RTP payload type identifies the media format corresponding to the current RTP payload. The receiver cannot rely solely on SSRC to pass arbitrary payloads to a bound track for decoding; it must also confirm that the PT is a format that has been negotiated and understood by this media stream.

RFC 3550 Section 5.1 states:

"A receiver MUST ignore packets with payload types that it does not understand."

Source: RFC 3550 §5.1, RTP Fixed Header Fields

RFC 3264 Section 5.1 explains that the SDP media format list conveys both the set of formats (codecs and parameters) that the offerer can send and/or receive, and—in the case of RTP—the RTP payload type numbers used to identify those formats:

"The list of media formats for each media stream conveys two pieces of information, namely the set of formats (codecs and any parameters associated with the codec, in the case of RTP) that the offerer is capable of sending and/or receiving (depending on the direction attributes), and, in the case of RTP, the RTP payload type numbers used to identify those formats."

Source: RFC 3264 §5.1, Unicast Streams

In BUNDLE scenarios, RFC 9143 has explicit requirements for PT checking after an SSRC mapping already exists:

"If the SSRC of the RTP stream is in the incoming SSRC mapping table, check that the payload type used by the RTP stream matches a payload type included in the matching "m=" section. If so, associate the RTP stream with that "m=" section. Otherwise, the RTP stream is not decoded, and the payload data is discarded."

Source: RFC 9143 §9.2, Associating RTP/RTCP Streams with the Correct SDP Media Description

OME's current WebRTC SDP generates BUNDLE, so this PT validation requirement applies to multi-media WebRTC sessions. The key point here is not that OME must use only one RTP routing algorithm, but rather: after an RTP packet has been associated with a media section via SSRC/MID/RID, it must still be validated that the packet's PT belongs to that media section's negotiated PT set.

3. Code Analysis

The RTP packet parsing stage extracts and stores the payload type:

/* src/projects/modules/rtp_rtcp/rtp_packet.cpp:99-116
 * RtpPacket::Parse
 */
_marker = (buffer[1] & 0x80) != 0;
_payload_type = buffer[1] & 0x7f;
_sequence_number = ByteReader<uint16_t>::ReadBigEndian(&buffer[2]);
_ssrc = ByteReader<uint32_t>::ReadBigEndian(&buffer[8]);

However, the subsequent track lookup logic does not use PT. FindTrackId(packet) selects the track based solely on SSRC, MID, and RID:

/* src/projects/modules/rtp_rtcp/rtp_rtcp.cpp:244-282
 * RtpRtcp::FindTrackId(const std::shared_ptr<const RtpPacket>&)
 */
auto track_id = GetTrackId(rtp_packet->Ssrc());
if(track_id.has_value())
{
    return track_id;
}

for (const auto &rtp_track_id : _rtp_track_identifiers)
{
if (rtp_track_id.ssrc.has_value() &&
    rtp_track_id.ssrc.value() == rtp_packet->Ssrc())
{
    return rtp_track_id.GetTrackId();
}

auto mid = rtp_packet->GetExtension(rtp_track_id.mid_extension_id);
auto rid = rtp_packet->GetExtension(rtp_track_id.rid_extension_id);

if (rtp_track_id.mid.has_value() && mid.has_value() &&
    mid.value().ToString() == rtp_track_id.mid.value())
{
    if (rtp_track_id.rid.has_value() && rid.has_value() &&
        rid.value().ToString() == rtp_track_id.rid.value())
    {
        return rtp_track_id.GetTrackId();
    }
    else if (rtp_track_id.rid.has_value() == false)
    {
        return rtp_track_id.GetTrackId();
    }
}
}

In the receive path, OnRtpReceived() establishes an SSRC-to-track binding once the track is found, then continues processing the packet:

/* src/projects/modules/rtp_rtcp/rtp_rtcp.cpp:440-475
 * RtpRtcp::OnRtpReceived
 */
auto packet = std::make_shared<RtpPacket>(data);
std::optional<uint32_t> track_id_opt = GetTrackId(packet->Ssrc());
if (track_id_opt.has_value() == false)
{
    track_id_opt = FindTrackId(packet);
    if (track_id_opt.has_value() == false)
    {
        logte("Could not find track ID for SSRC %u", packet->Ssrc());
        return false;
    }
    ConnectSsrcToTrack(packet->Ssrc(), track_id_opt.value());
}

The packet then goes directly to the corresponding track's jitter buffer:

/* src/projects/modules/rtp_rtcp/rtp_rtcp.cpp:483-490,588-600
 * RtpRtcp::OnRtpReceived
 */
auto track = track_it->second;
...
auto jitter_buffer = buffer_it->second;
jitter_buffer->InsertPacket(packet);

After frame assembly, WebRTCStream::OnRtpFrameReceived() continues to find the track by SSRC and passes the RTP payload to the corresponding depacketizer:

/* src/projects/providers/webrtc/webrtc_stream.cpp:707-743
 * WebRTCStream::OnRtpFrameReceived
 */
auto ssrc = first_rtp_packet->Ssrc();
auto track_id_opt = _rtp_rtcp->GetTrackId(ssrc);
auto track_id = track_id_opt.value();
auto depacketizer = GetDepacketizer(track_id);

/* src/projects/providers/webrtc/webrtc_stream.cpp:735-743
 * WebRTCStream::OnRtpFrameReceived
 */
for (const auto &packet : rtp_packets)
{
    auto payload = std::make_shared<ov::Data>(
        packet->Payload(), packet->PayloadSize());
    payload_list.push_back(payload);
}

auto bitstream = depacketizer->ParseAndAssembleFrame(payload_list);

During track creation, the negotiated PayloadAttr is indeed used to select the codec and depacketizer:

/* src/projects/providers/webrtc/webrtc_stream.cpp:214-240
 * WebRTCStream::CreateChannel
 */
auto track = CreateTrack(payload_attr);
if (AddDepacketizer(track->GetId()) == false)
{
    logte("Could not add depacketizer : pt(%d)", payload_attr->GetId());
    return false;
}

However, when registering the RTP receiver, RtpTrackIdentifier stores routing identifiers such as SSRC, CNAME, and MID, but does not store the set of PTs allowed for that track:

/* src/projects/providers/webrtc/webrtc_stream.cpp:295-305
 * WebRTCStream::CreateChannel
 */
RtpRtcp::RtpTrackIdentifier rtp_track_id(track->GetId());
rtp_track_id.ssrc = remote_media_desc->GetSsrc();
rtp_track_id.cname = answer_media_desc->GetCname();
rtp_track_id.mid = has_mid_extension
                       ? answer_media_desc->GetMid()
                       : std::nullopt;
_rtp_rtcp->AddRtpReceiver(track, rtp_track_id);

Therefore, the actual processing path is:

RtpPacket::Parse
    -> extract payload_type
    -> OnRtpReceived
        -> GetTrackId(packet->Ssrc()) / FindTrackId(packet)
            -> jitter_buffer->InsertPacket(packet)
                -> WebRTCStream::OnRtpFrameReceived
                    -> depacketizer->ParseAndAssembleFrame(payload)

This path is missing a critical branch:

if packet.PT not in negotiated PT set for matched track:
    discard payload

In summary: OME knows the negotiated PTs during track creation, but does not carry that PT set into the RTP receive path; after finding the track, the RTP receive path does not check whether the current packet's PT belongs to that track's negotiated formats.

4. Impact Analysis

This is a missing RTP payload type filter, primarily affecting protocol compliance, interoperability, and media input robustness.

If the peer sends an unnegotiated PT on the same SSRC, or sends a PT that does not belong to the current media section, OME may still feed that payload into the bound track's jitter buffer and depacketizer. This can result in incorrect codec processing of incorrect payloads, manifesting as decoding failures, invalid frames, media interruptions, statistical anomalies, or persistent depacketization failures.

In BUNDLE scenarios, this issue also weakens the boundary check between RTP and the media section. Even after an SSRC has been mapped to a media section, the specification still requires checking whether the PT belongs to that section. The current implementation lacks this check, so unknown or mismatched PTs are not discarded at the receive entry point.

[songxpu]

c24_BUNDLE Offer Lacks MID RTP Header Extension

1. Problem Overview

When OME generates a BUNDLE offer containing multiple RTP-based m= sections, it writes all media MIDs into a single a=group:BUNDLE line. However, when creating video and audio media descriptions, OME only adds RTP header extensions such as Transport-CC, CompositionTime, and framemarking, but does not add the BUNDLE-required MID RTP header extension:

urn:ietf:params:rtp-hdrext:sdes:mid

Consequently, OME's generated bundled RTP-based m= sections lack the MID extension required by RFC 9143. Since BUNDLE causes multiple media sections to share the same RTP transport, the peer needs to rely on the MID extension to associate RTP streams with the correct m= section. The absence of this extension makes RTP stream routing over the shared transport unreliable.

2. Specification Reference

RFC 9143 requires that the RTP MID header extension MUST be enabled in RTP-based media sections using BUNDLE. This extension is declared via the SDP extmap attribute, with the URI:

urn:ietf:params:rtp-hdrext:sdes:mid

RFC 9143 Section 9.1 states:

"The RTP MID header extension MUST be enabled by including an SDP 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp-hdrext:sdes' URI value defined in this specification in each bundled RTP-based "m=" section in every offer and answer."

Source: RFC 9143 §9.1, Single RTP Session

RFC 9143 Section 9.2 further explains that BUNDLE endpoints must be able to associate RTP/RTCP packets with the correct m= section via the MID mechanism:

"In order for an offerer and answerer to always be able to associate an RTP stream with the correct "m=" section, the offerer and answerer using the BUNDLE extension MUST support the mechanism defined in Section 15, where the offerer and answerer insert the identification-tag associated with an "m=" section (provided by the remote peer) into RTP and RTCP packets associated with a BUNDLE group."

Source: RFC 9143 §9.2, Associating RTP/RTCP Streams with the Correct SDP Media Description

Therefore, as long as OME declares BUNDLE in the SDP and the relevant m= sections are RTP-based media sections, the MID RTP header extension MUST be declared in each bundled section.

3. Code Analysis

OME's session description serialization writes all media MIDs into a single BUNDLE group:

/* src/projects/modules/sdp/session_description.cpp:48-56
 * SessionDescription::UpdateData
 */
sdp += "a=group:BUNDLE";

for(auto &media_description : _media_list)
{
    sdp.AppendFormat(" %s", media_description->GetMid().value_or("").CStr());
}

sdp += "\r\n";

This means OME explicitly declares that these media sections share the same BUNDLE transport.

However, in the Provider offer generation path, the video and audio media descriptions add other RTP header extensions but do not include the MID URI:

/* src/projects/providers/webrtc/webrtc_application.cpp:88-105,136-149
 * WebRTCApplication::CreateOfferSDP
 */
video_media_desc->SetMid(ov::Random::GenerateString(6));
video_media_desc->AddExtmap(
    RTP_HEADER_EXTENSION_TRANSPORT_CC_ID,
    RTP_HEADER_EXTENSION_TRANSPORT_CC_ATTRIBUTE);
video_media_desc->AddExtmap(
    RTP_HEADER_EXTENSION_COMPOSITION_TIME_ID,
    RTP_HEADER_EXTENSION_COMPOSITION_TIME_ATTRIBUTE);

audio_media_desc->SetMid(ov::Random::GenerateString(6));
audio_media_desc->AddExtmap(
    RTP_HEADER_EXTENSION_TRANSPORT_CC_ID,
    RTP_HEADER_EXTENSION_TRANSPORT_CC_ATTRIBUTE);

The Publisher offer generation path similarly lacks the MID extension, adding only framemarking and Transport-CC:

/* src/projects/publishers/webrtc/rtc_stream.cpp:505-550,555-582
 * RtcStream::MakeVideoDescription / MakeAudioDescription
 */
video_media_desc->SetMid(ov::Random::GenerateString(6));
video_media_desc->AddExtmap(
    RTP_HEADER_EXTENSION_FRAMEMARKING_ID,
    RTP_HEADER_EXTENSION_FRAMEMARKING_ATTRIBUTE);
video_media_desc->AddExtmap(
    RTP_HEADER_EXTENSION_TRANSPORT_CC_ID,
    RTP_HEADER_EXTENSION_TRANSPORT_CC_ATTRIBUTE);

audio_media_desc->SetMid(ov::Random::GenerateString(6));
audio_media_desc->AddExtmap(
    RTP_HEADER_EXTENSION_TRANSPORT_CC_ID,
    RTP_HEADER_EXTENSION_TRANSPORT_CC_ATTRIBUTE);

The answer path only copies the MID extension when the remote offer already provides it:

/* src/projects/providers/webrtc/webrtc_application.cpp:250-268
 * WebRTCApplication::CreateAnswerSDP
 */
if (offer_media_desc->FindExtmapItem(
        "urn:ietf:params:rtp-hdrext:sdes:mid",
        extmap_id, extmap_attribute))
{
    answer_media_desc->AddExtmap(extmap_id, extmap_attribute);
}

This shows that OME can recognize and copy the MID extension, but its own offer path does not declare it by default.

On the receiving side, channel creation also treats the MID extension as a conditional capability. If the MID extmap is not present in the answer, the MID association is not saved for the RTP track identifier:

/* src/projects/providers/webrtc/webrtc_stream.cpp:260-264,295-303
 * WebRTCStream::CreateChannel
 */
bool has_mid_extension =
    answer_media_desc->FindExtmapItem(
        "urn:ietf:params:rtp-hdrext:sdes:mid",
        mid_extension_id, mid_extension_uri);

rtp_track_id.mid =
    has_mid_extension ? answer_media_desc->GetMid() : std::nullopt;
rtp_track_id.mid_extension_id = mid_extension_id;

In summary, OME generates a BUNDLE offer declaring multiple media sections sharing a transport, but does not include the RFC 9143-required MID RTP header extension in each bundled RTP-based m= section.

4. Impact Analysis

This is a missing BUNDLE RTP routing capability declaration, primarily affecting protocol compliance and interoperability.

In BUNDLE scenarios, multiple media sections share the same RTP transport. The peer needs a reliable mechanism to determine which m= section an incoming RTP/RTCP packet belongs to. The MID RTP header extension is specifically designed to provide this media section identification.

If OME's BUNDLE offer lacks the MID extension, a strict peer may reject the offer, or may be unable to rely on MID to route RTP streams to the correct media section over the shared transport.

[songxpu]

c27_Simulcast SDP with Missing RID Declarations Is Accepted

1. Problem Overview

RFC 9429 requires that every rid-id referenced in an a=simulcast line must have a corresponding a=rid line. If this semantic check fails, the parsing process MUST stop and return an error.

The current OME implementation does not satisfy this requirement. When MediaDescription::SetSimulcast() fails to find a RID, it only logs a warning, skips that RID, and continues building the simulcast layers, with the function ultimately returning true. Additionally, MediaDescription::FromString() places SetSimulcast() inside a post-processing lambda with no return value, so even if the a=simulcast line references non-existent RIDs, the SDP parsing ultimately succeeds.

In summary, semantically invalid simulcast SDP is accepted as an incomplete simulcast configuration rather than being rejected.

2. Specification Reference

RFC 9429 defines the relationship between a=simulcast and a=rid as a strong reference. That is, every rid-id appearing in an a=simulcast line MUST already be declared by an a=rid line within the same media section.

RFC 9429 Section 5.8.3 states:

"All rid-ids referenced in an "a=simulcast" line MUST exist as "a=rid" lines."

Source: RFC 9429 §5.8.3

The same section also requires that once a semantic check fails, processing MUST stop and an error MUST be returned:

"If any of the preceding checks failed, processing MUST stop and an error MUST be returned."

Source: RFC 9429 §5.8.3

Therefore, a missing RID is not a recoverable situation that can be skipped, but rather an SDP semantic validation failure.

3. Code Analysis

When parsing a=simulcast, OME defers the actual processing until after all a=rid lines have been parsed. This design itself is reasonable, because a=simulcast may reference RIDs that appear later in the same media section.

/* src/projects/modules/sdp/media_description.cpp:415-431 — MediaDescription::ParsingMediaLine */
else if (content.compare(0, OV_COUNTOF("simulcast") - 1, "simulcast") == 0)
{
	auto match = SDPRegexPattern::GetInstance()->MatchSimulcast(content.c_str());
	if (match.GetGroupCount() < 1 + 2)
	{
		parsing_error = true;
		break;
	}

	_post_parsing_tasks.push([=]() {
		// It must be run after parsing all rid lines
		SetSimulcast(match.GetGroupAt(2).GetValue(), match.GetGroupAt(4).GetValue());
	});
}

The problem is that the post-processing lambda has no return value, and the result of SetSimulcast() is not fed back to FromString(). After the post-processing tasks are executed, FromString() simply calls Update() and returns true:

/* src/projects/modules/sdp/media_description.cpp:274-283 — MediaDescription::FromString */
// Run post parsing tasks
while (_post_parsing_tasks.empty() == false)
{
	_post_parsing_tasks.front()();
	_post_parsing_tasks.pop();
}

Update();
return true;

Inside SetSimulcast(), when a missing RID is encountered in the send branch, it only logs a warning and continues processing subsequent RIDs:

/* src/projects/modules/sdp/media_description.cpp:803-810 — MediaDescription::SetSimulcast */
auto rid_attr = GetRid(rid);
if (rid_attr == nullptr)
{
	logtw("Cannot find rid : %s", rid.CStr());
	continue;
}

layer->AddRid(rid_attr);

The recv branch follows the same logic:

/* src/projects/modules/sdp/media_description.cpp:833-847 — MediaDescription::SetSimulcast */
auto rid_attr = GetRid(rid);
if (rid_attr == nullptr)
{
	logtw("Cannot find rid : %s", rid.CStr());
	continue;
}

layer->AddRid(rid_attr);
return true;

For example, when the same media section contains:

a=simulcast:send f

but does not contain:

a=rid:f send

the current implementation logs:

Cannot find rid : f

but still completes parsing and allows FromString() to return success.

4. Impact Analysis

This is an SDP simulcast semantic validation error, primarily affecting interoperability and media configuration consistency.

From an interoperability perspective, invalid SDP from a remote peer is accepted by OME, leading to inconsistent understanding of available simulcast encodings between both parties. From a media behavior perspective, after missing RIDs are silently removed, the internal layer list may be incomplete, potentially leading to unpredictable behavior in subsequent stream selection, encoding layer matching, or bandwidth switching operations.

[songxpu]

c28_SDP Bandwidth Lines Not Parsed or Stored

1. Problem Overview

OME's SDP parser does not handle session-level or media-level b= lines.

When the remote SDP contains bandwidth modifiers such as b=RS, b=RR, or b=AS, the current parser does not parse the bwtype and bandwidth values, nor does it store them in the SDP data structure. These b= lines fall into the unknown attribute logging path; the parsing still returns success, but the corresponding bandwidth semantics are silently discarded.

Consequently, OME cannot correctly receive and preserve RTCP bandwidth parameters via SDP, nor can it use these values in subsequent RTP/RTCP configuration.

2. Specification Reference

RFC 9429 requires that SDP parsers MUST parse and store the bwtype and bandwidth values from b= lines. This requirement applies to both session-level and media-level.

RFC 9429 Section 5.8.1 specifies the requirement for session-level parsing:

"The "b=" line, if present, MUST be parsed as specified in [RFC4566], Section 5.8, and the bwtype and bandwidth values stored."

Source: RFC 9429 §5.8.1

RFC 9429 Section 5.8.2 has the same requirement for media section parsing:

"The "b=" line, if present, MUST be parsed as specified in [RFC4566], Section 5.8, and the bwtype and bandwidth values stored."

Source: RFC 9429 §5.8.2

For WebRTC scenarios, RFC 8834 also requires endpoints to support exchanging RTCP bandwidth values. If using SDP, these values SHALL be expressed as described in RFC 3556:

"RTCP bandwidth: Support for exchanging RTCP bandwidth values with the endpoints will be necessary. This SHALL be done as described in 'Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth' [RFC3556] if using SDP, or something semantically equivalent."

Source: RFC 8834 §10

Therefore, bandwidth modifiers such as b=RS and b=RR are not unknown fields that can be unconditionally ignored. The receiving side should at least parse and store their types and values for subsequent RTCP bandwidth calculation or policy processing.

3. Code Analysis

OME's session-level SDP parsing function has no case 'b' or equivalent branch. Unrecognized fields fall into the default branch, which only logs an unknown attribute message and then returns success:

/* src/projects/modules/sdp/session_description.cpp:390-399 — ParsingSessionLine */
default:
	logt("SDP", "Unknown Attributes : %c=%s", type, content.c_str());
}

return true;

The media-level SDP parsing function similarly lacks a branch for handling b= lines and also falls into the default branch returning success:

/* src/projects/modules/sdp/media_description.cpp:620-630 — ParsingMediaLine */
default:
	logt("SDP", "Unknown Attributes : %c=%s", type, content.c_str());
	break;
}

return true;

Therefore, input containing valid SDP bandwidth lines such as:

b=RS:1000
b=RR:3000

is accepted by the parser, but RS, RR, and their corresponding values are not stored.

There is also no data model currently visible in the code for storing bandwidth modifiers such as b=RS, b=RR, or b=AS, nor any corresponding serialization or subsequent RTP/RTCP configuration path that consumes these values.

In summary, OME's SDP parser does not implement parsing and storage of b= lines, causing legitimate bandwidth modifiers to be skipped as unknown fields.

4. Impact Analysis

This is a missing SDP bandwidth parsing issue, primarily affecting protocol compliance and interoperability.

If the remote peer sends RTCP bandwidth values such as b=RS or b=RR via SDP, OME accepts the SDP but does not preserve these parameters. This may prevent both parties from establishing a consistent view of RTCP bandwidth, potentially leading to RTCP transmission intervals, bandwidth allocation, feedback frequencies, or timeout calculations that diverge from the remote peer's expectations.

[songxpu]

c29_SDP_MEDIA_rtcp_feedback_config — FIR Sent Without Negotiated ccm fir

1. Problem Overview

OME's WebRTC Provider path may send FIR without having negotiated ccm fir.

FIR is a codec control feedback message defined in RFC 5104. Under the offer/answer semantics of RTCP feedback, both parties may only use feedback mechanisms that are explicitly allowed by the negotiated result. If the negotiation result for a given video payload does not include ccm fir, the local endpoint MUST NOT send FIR.

In the current implementation, the FIR sending condition in WebRTCStream::OnFrame() only checks three factors: whether _fir_interval is non-zero, whether the timer has expired, and whether the track is video. Once these conditions are met, the code directly calls RtpRtcp::SendFIR(). This path does not check whether ccm fir has been negotiated for the current payload, nor does it consult the final intersection of a=rtcp-fb in the SDP.

Therefore, even when the remote SDP or the final negotiation result does not include ccm fir, OME may still send PSFB/FIR as long as the timer triggers.

2. Specification Reference

RFC 4585 requires that the answer result for RTCP feedback is binding for the media session. Both parties may only use feedback mechanisms negotiated in this way.

RFC 4585 Section 4.2 states:

"The answer is binding for the media session, and both offerer and answerer MUST only use feedback mechanisms negotiated in this way."

Source: RFC 4585 §4.2

For CCM feedback, RFC 5104 further requires that both parties may only use the joint subset of CCM parameters that are explicitly supported in both the offer and the answer, and MUST NOT send unnegotiated feedback messages.

RFC 5104 Section 7.2 states:

"The answer is binding for the media session and both offerer and answerer MUST NOT use any feedback messages other than what both sides have explicitly indicated as being supported. In other words, only the joint subset of CCM parameters from the offer and answer may be used."

Source: RFC 5104 §7.2

Therefore, ccm fir is not a local policy that an implementation can unilaterally enable. OME may only send FIR when the negotiation result includes ccm fir.

3. Code Analysis

OME's WebRTCStream configures a FIR timer by default, with a default interval of 3000 ms:

/* src/projects/providers/webrtc/webrtc_stream.h:102-103 — WebRTCStream */
ov::StopWatch _fir_timer;
int _fir_interval = 3000; // ms

In WebRTCStream::OnFrame(), the FIR sending condition only checks _fir_interval, the timer, and the media type. As long as the track is video and the timer has expired, it directly calls SendFIR():

/* src/projects/providers/webrtc/webrtc_stream.cpp:909-918 — WebRTCStream::OnFrame */
SendFrame(packet_to_send);

// Send FIR to reduce keyframe interval
// _fir_interval can be 0 to disable FIR sending. The default value is 3000 ms.
if (_fir_interval != 0 && _fir_timer.IsElapsed(_fir_interval) && track->GetMediaType() == cmn::MediaType::Video)
{
	_fir_timer.Update();
	//_rtp_rtcp->SendPLI(first_rtp_packet->Ssrc());
	_rtp_rtcp->SendFIR(track->GetId());
}

There is no check here for the RTCP feedback negotiation result of the current payload, such as:

PayloadAttr::IsRtcpFbEnabled(PayloadAttr::RtcpFbType::CcmFir)

or any equivalent ccm fir gate.

RtpRtcp::SendFIR() then directly constructs the FIR and sends the RTCP packet:

/* src/projects/modules/rtp_rtcp/rtp_rtcp.cpp:188-211 — RtpRtcp::SendFIR */
bool RtpRtcp::SendFIR(uint32_t track_id)
{
	auto stat_it = _receive_statistics.find(track_id);
	if(stat_it == _receive_statistics.end())
	{
		return false;
	}

	auto stat = stat_it->second;
	auto fir = std::make_shared<FIR>();

	fir->SetSrcSsrc(stat->GetReceiverSSRC());
	fir->SetMediaSsrc(stat->GetMediaSSRC());
	fir->AddFirMessage(stat->GetMediaSSRC(), static_cast<uint8_t>(stat->GetNumberOfFirRequests()%256));

	auto rtcp_packet = std::make_shared<RtcpPacket>();
	rtcp_packet->Build(fir);

	stat->OnFirRequested();
	_last_sent_rtcp_packet = rtcp_packet;

	return SendDataToNextNode(NodeType::Rtcp, rtcp_packet->GetData());
}

The FIR RTCP packet type is PSFB, with FMT set to FIR:

/* src/projects/modules/rtp_rtcp/rtcp_info/fir.h:45-54 — FIR */
RtcpPacketType GetPacketType() const override
{
	return RtcpPacketType::PSFB;
}

uint8_t GetCountOrFmt() const override
{
	return static_cast<uint8_t>(PSFBFMT::FIR);
}

Therefore, the static sending path is:

WebRTCStream::OnFrame
    -> _fir_interval != 0
    -> _fir_timer.IsElapsed(...)
    -> track is Video
        -> RtpRtcp::SendFIR(track_id)
            -> build PSFB/FIR
            -> SendDataToNextNode(NodeType::Rtcp, ...)

This path does not access the SDP payload nor check whether ccm fir has been negotiated in a=rtcp-fb. Consequently, when the applicable conditions are met, FIR can be sent bypassing the RTCP feedback negotiation gate.

4. Impact Analysis

This is an issue where the RTCP feedback negotiation result is not enforced, primarily affecting interoperability and media control behavior.

If the peer has not negotiated ccm fir, a strict implementation may ignore, log, or reject this unnegotiated FIR. In this case, OME's strategy of relying on FIR to shorten the keyframe interval may fail, making keyframe recovery unreliable.

If the peer executes the FIR despite not having negotiated it, this may trigger an unscheduled keyframe, causing a sudden bitrate spike or bandwidth fluctuation. Since _fir_interval defaults to 3000 ms, this path is not purely theoretical; as long as the configuration is not disabled and the video track continues to operate, the timer may trigger.

[songxpu]

c30_SDP_MEDIA_rtcp_mux — Answer Forces a=rtcp-mux Even When Offer Does Not Request Mux

1. Problem Overview

When generating an SDP answer, OME does not respect the RTP/RTCP mux negotiation premise established by the offer.

When a remote offer's RTP media section does not contain a=rtcp-mux, WebRTCApplication::CreateAnswerSDP() merely logs a warning:

Offer SDP has no rtcp-mux

But then unconditionally executes:

answer_media_desc->UseRtcpMux(true);

During subsequent SDP serialization, MediaDescription::UpdateData() outputs the following based on this flag:

a=rtcp-mux

This means: even when the offer does not request RTP/RTCP mux, OME as the answerer still actively adds a=rtcp-mux to the answer.

Per RFC 8035, if the offer does not contain a=rtcp-mux, the answerer MUST NOT include this attribute in the answer, and MUST NOT multiplex RTP and RTCP packets on a single port. Therefore, this issue is a deterministic violation.

2. Specification Reference

RTP/RTCP mux is an offer/answer negotiation outcome that applies on a per-media-section basis. The answerer may only choose to accept this multiplexing mode and include a=rtcp-mux in the answer when the corresponding offer already contains a=rtcp-mux.

RFC 8035 Section 3.1 explicitly states:

"If the offer does not contain the "a=rtcp-mux" attribute, the answerer MUST NOT include an "a=rtcp-mux" attribute in the answer, and the answerer MUST NOT multiplex RTP and RTCP packets on a single port."

Source: RFC 8035 §3.1

The same section also specifies that if the answer contains a=rtcp-mux, both parties MUST actually multiplex RTP and RTCP packets on a single port:

"If the answer contains an "a=rtcp-mux" attribute, the offerer and answerer MUST multiplex RTP and RTCP packets on a single port."

Source: RFC 8035 §3.1

Therefore, a=rtcp-mux cannot be unilaterally added by the answerer. When the offer does not propose mux, the answerer must either maintain non-mux semantics or reject the media section / session, but MUST NOT forcibly enable mux in the answer.

3. Code Analysis

OME's answer generation path does check whether the offer contains a=rtcp-mux. However, when this check fails, the code does not return an error nor preserve the non-mux state; instead, it continues and unconditionally enables mux:

/* src/projects/providers/webrtc/webrtc_application.cpp:203-212 — WebRTCApplication::CreateAnswerSDP */
auto answer_media_desc = std::make_shared<MediaDescription>();
answer_media_desc->SetMediaType(offer_media_desc->GetMediaType());
answer_media_desc->SetConnection(4, "0.0.0.0");

// rtcp-mux
if (offer_media_desc->IsRtcpMux() == false)
{
	logtw("Offer SDP has no rtcp-mux");
}
answer_media_desc->UseRtcpMux(true);

The key issue here is that offer_media_desc->IsRtcpMux() == false only triggers a log and does not affect the final answer generation.

Subsequently, the SDP serialization function outputs a=rtcp-mux as long as _use_rtcpmux_flag is true:

/* src/projects/modules/sdp/media_description.cpp:70-73 — MediaDescription::UpdateData */
if (_use_rtcpmux_flag)
{
	sdp.AppendFormat("a=rtcp-mux\r\n");
}

In summary, OME treats the absence of a=rtcp-mux in the offer as a warning rather than as a transmission mode gate for answer generation; it ultimately still forces a mux answer.

4. Impact Analysis

This is an RTP/RTCP mux offer/answer semantic error, primarily affecting interoperability and transport state consistency.

For a strict RFC 8035-compliant offerer that did not include a=rtcp-mux in its offer, receiving a mux answer from OME may be considered illegal, potentially causing the offerer to reject the session or terminate negotiation.

From a transport consistency perspective, the offerer may have originally expected RTP and RTCP to use separate ports, while OME's answer indicates that both parties should use single-port multiplexing. This creates a mismatch in both parties' understanding of the RTP/RTCP transmission mode, which may subsequently lead to RTCP routing errors, abnormal ICE component handling, media initialization failures, or session establishment failures.

[songxpu]

c31_SDP_MEDIA_rtcp_rsize — Reduced-Size RTCP Negotiation Result Not Propagated to Answer

1. Problem Overview

OME is capable of parsing a=rtcp-rsize from a remote offer, and its Publisher offer generation path also actively writes this attribute, indicating that the code already has SDP expression capability for Reduced-Size RTCP. However, in the WHIP/WebRTC Provider answer generation path, WebRTCApplication::CreateAnswerSDP() creates a new answer media description but does not copy the already-parsed rtcp-rsize flag from the remote offer to the answer. The final generated answer will lack a=rtcp-rsize. Therefore, when the remote offer already carries a=rtcp-rsize and the media section is accepted by OME, OME's answer does not preserve this negotiated attribute, causing the Reduced-Size RTCP capability declaration from the offer to be dropped during the offer-to-answer state transfer.

2. Specification Reference

a=rtcp-rsize is the SDP attribute used to negotiate Reduced-Size RTCP. Upon receiving an offer containing this attribute, if the answerer supports Reduced-Size RTCP and wishes to use it, it SHALL include this attribute in the answer.

RFC 5506 Section 5 "Signaling" states:

"If "a=rtcp-rsize" is present in the offer SDP, the answerer that supports Reduced-Size RTCP and wishes to use it SHALL include the "a=rtcp-rsize" attribute in the answer."

Source: RFC 5506 §5

For JSEP initial answers, RFC 9429 also requires retaining the a=rtcp-rsize line present in the offer.

RFC 9429 Section 5.3.1 "Initial Answers" states:

"If present in the offer, an "a=rtcp-rsize" line, as specified in [RFC5506], Section 5."

Source: RFC 9429 §5.3.1

Additionally, when applying an answer, if the media section has Reduced-Size RTCP enabled, the RTCP transmission configuration MUST also use Reduced-Size RTCP.

RFC 9429 Section 5.11 "Applying an Answer" states:

"If the "m=" section has Reduced-Size RTCP enabled, configure the RTCP transmission for this "m=" section to use Reduced-Size RTCP, as specified in [RFC5506]."

Source: RFC 9429 §5.11

Therefore, a=rtcp-rsize is not an ordinary attribute that can be unconditionally discarded during answer generation. It needs to be propagated from the remote offer's media state to the local answer's media state, and further affect RTCP transmission configuration.

3. Code Analysis

OME's Publisher offer generation path actively enables rtcp-rsize:

/* src/projects/publishers/webrtc/rtc_stream.cpp:520-523 — RtcStream::MakeVideoDescription */
video_media_desc->UseDtls(true);
video_media_desc->UseRtcpMux(true);
video_media_desc->UseRtcpRsize(true);
video_media_desc->SetDirection(MediaDescription::Direction::SendOnly);

The SDP parser can also recognize a=rtcp-rsize from a remote SDP and set the media description's _use_rtcprsize_flag:

/* src/projects/modules/sdp/media_description.cpp:443-450 — MediaDescription::ParsingMediaLine */
else if (content.compare(0, OV_COUNTOF("rtcp-r") - 1, "rtcp-r") == 0)
{
	// a=rtcp-rsize
	auto match = SDPRegexPattern::GetInstance()->MatchRtcpRsize(content.c_str());
	if (match.GetError() == nullptr)
	{
		UseRtcpRsize(true);
	}
}

The serialization logic itself also supports outputting a=rtcp-rsize. As long as _use_rtcprsize_flag is true, the attribute is written:

/* src/projects/modules/sdp/media_description.cpp:70-78 — MediaDescription::UpdateData */
if (_use_rtcpmux_flag)
{
	sdp.AppendFormat("a=rtcp-mux\r\n");
}

if (_use_rtcprsize_flag)
{
	sdp.AppendFormat("a=rtcp-rsize\r\n");
}

The problem occurs during answer generation. WebRTCApplication::CreateAnswerSDP() creates a new answer_media_desc and copies media type, ICE, fingerprint, MID, SSRC, payload, and some feedback information, but does not check offer_media_desc->IsUseRtcpRsize(), nor does it call answer_media_desc->UseRtcpRsize(true):

/* src/projects/providers/webrtc/webrtc_application.cpp:203-226 — WebRTCApplication::CreateAnswerSDP */
auto answer_media_desc = std::make_shared<MediaDescription>();
answer_media_desc->SetMediaType(offer_media_desc->GetMediaType());
answer_media_desc->SetConnection(4, "0.0.0.0");

answer_media_desc->UseRtcpMux(true);
answer_media_desc->SetDirection(MediaDescription::Direction::RecvOnly);
answer_media_desc->SetIceUfrag(ice_local_ufrag);
answer_media_desc->SetIcePwd(ice_local_pwd);
answer_media_desc->SetFingerprint("sha-256", _certificate->GetFingerprint("sha-256"));

// MID, SSRC, payload, and rtcp-fb are copied later, but rtcp-rsize is not copied

4. Impact Analysis

This is a Reduced-Size RTCP negotiation state loss issue, primarily affecting interoperability and RTCP transmission configuration consistency.

If the remote offer contains a=rtcp-rsize but OME's answer does not preserve this attribute, a strict JSEP peer may interpret this as OME not accepting Reduced-Size RTCP, and fall back to compound RTCP, or consider the answer as having inconsistent capability negotiation. Both parties may have differing understandings of RTCP packet format and transmission strategy, potentially impacting RTCP feedback, bandwidth usage, and media recovery behavior.

[songxpu]

C34_RTP Profile Handling — SDP m= Profile Not Preserved in Answer

1. Problem Overview

OME accepts multiple RTP profiles when parsing SDP m= lines, but internally does not preserve the original profile token. Instead, it uses only a UseDtls boolean state to indicate whether DTLS is used. This causes the precise differences between AVP, AVPF, SAVP, and SAVPF to be collapsed and lost during the parsing stage.

Specifically, UDP/TLS/RTP/SAVP and UDP/TLS/RTP/SAVPF are both collapsed to UseDtls(true), while RTP/AVP and RTP/AVPF are both collapsed to UseDtls(false). After this collapse, OME can no longer distinguish whether the offer used AVP or AVPF, nor can it preserve the difference between SAVP and SAVPF.

More critically, CreateAnswerSDP() does not copy the original RTP profile from the offer when creating the answer media description. Since the MediaDescription constructor defaults to calling UseDtls(true), the answer typically ends up outputting UDP/TLS/RTP/SAVPF. Therefore, when the remote offer uses RTP/AVP or RTP/AVPF, OME may generate an answer with the secure profile UDP/TLS/RTP/SAVPF, resulting in a mismatch between the answer's m= profile and the offer.

Core Issue: OME accepts the RTP profile from the offer but does not preserve and exactly replicate it in the answer; instead, it collapses the profile to a DTLS boolean state and defaults to outputting UDP/TLS/RTP/SAVPF in the answer.

2. Specification Reference

JSEP allows implementations to receive several legacy RTP profile strings, but when generating an answer, the profile MUST exactly match the profile provided in the offer.

RFC 9429 Section 5.1.2 "Profile Names and Interoperability" states:

"The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer."

Source: RFC 9429 §5.1.2

Additionally, WebRTC media itself requires the use of the full RTP/SAVPF profile to protect RTP and RTCP packets. RFC 8834 Section 4.2 states:

"WebRTC endpoints MUST NOT send packets using the basic RTP/AVP profile or the RTP/AVPF profile; they MUST employ the full RTP/SAVPF profile to protect all RTP and RTCP packets that are generated."

Source: RFC 8834 §4.2

Furthermore, RTCP feedback only applies to AVPF-class profiles. RFC 4585 Section 4.2 states:

"The "rtcp-fb" attribute MUST only be used in media sessions for which the "AVPF" is specified."

Source: RFC 4585 §4.2

Therefore, the RTP profile cannot be reduced to a single boolean of "whether DTLS is used." The tokens AVP, AVPF, SAVP, and SAVPF directly affect security attributes, RTCP feedback semantics, and the legality of the answer. The answer MUST exactly match the offer's profile; if OME does not support a particular profile, it should reject that media section rather than silently rewriting it to a different profile.

3. Code Analysis

When parsing the m= line, OME's SDP parser reads the protocol field. However, it subsequently only calls UseDtls(true/false) and does not preserve the original profile token:

/* src/projects/modules/sdp/media_description.cpp:337-350 — MediaDescription::ParsingMediaLine */
ov::String protocol = match.GetGroupAt(3).GetValue();
if (protocol.UpperCaseString() == "UDP/TLS/RTP/SAVPF" ||
	protocol.UpperCaseString() == "UDP/TLS/RTP/SAVP")
{
	UseDtls(true);
}
else if (protocol.UpperCaseString() == "RTP/AVPF" ||
		 protocol.UpperCaseString() == "RTP/AVP")
{
	UseDtls(false);
}

UseDtls() itself directly rewrites _protocol. If DTLS is enabled, it is fixed to UDP/TLS/RTP/SAVPF; if DTLS is not enabled, it is fixed to RTP/AVPF:

/* src/projects/modules/sdp/media_description.cpp:674-685 — MediaDescription::UseDtls */
void MediaDescription::UseDtls(bool flag)
{
	_use_dtls_flag = flag;

	if (_use_dtls_flag)
	{
		_protocol = "UDP/TLS/RTP/SAVPF";
	}
	else
	{
		_protocol = "RTP/AVPF";
	}
}

This results in two immediate consequences: UDP/TLS/RTP/SAVP becomes UDP/TLS/RTP/SAVPF after parsing; RTP/AVP becomes RTP/AVPF. In other words, the original profile token is already irrecoverable at the parser stage.

The answer generation path further amplifies this issue. The MediaDescription constructor enables DTLS by default:

/* src/projects/modules/sdp/media_description.cpp:19-23 — MediaDescription::MediaDescription */
MediaDescription::MediaDescription()
{
	UseDtls(true);
	UseRtcpMux(false);
}

CreateAnswerSDP() creates a new answer media description, but only sets media type, connection, rtcp-mux, direction, ICE, and fingerprint fields, without copying the original profile from the offer or rejecting the media section when the profile is unsupported:

/* src/projects/providers/webrtc/webrtc_application.cpp:203-215 — WebRTCApplication::CreateAnswerSDP */
auto answer_media_desc = std::make_shared<MediaDescription>();
answer_media_desc->SetMediaType(offer_media_desc->GetMediaType());
answer_media_desc->SetConnection(4, "0.0.0.0");
answer_media_desc->UseRtcpMux(true);
answer_media_desc->SetDirection(MediaDescription::Direction::RecvOnly);

Therefore, the typical path can be summarized as:

offer m=... RTP/AVP ...
    -> MediaDescription::ParsingMediaLine()
        -> UseDtls(false)
        -> original RTP/AVP token lost
            -> WebRTCApplication::CreateAnswerSDP()
                -> new MediaDescription()
                    -> UseDtls(true)
                    -> _protocol = UDP/TLS/RTP/SAVPF
                        -> answer m=... UDP/TLS/RTP/SAVPF ...

For RTP/AVPF, UDP/TLS/RTP/SAVP, or UDP/TLS/RTP/SAVPF, the same profile exactness issue exists: the code does not treat the offer's profile token as binding state for the answer, but regenerates the profile based on either the default constructor or the fixed mapping in UseDtls().

Additionally, the copying of rtcp-fb is not gated by the exact profile. If the offer profile is AVP or SAVP, RTCP feedback attributes should be constrained by the AVPF profile requirement; however, since the profile state has already been collapsed, subsequent answer generation cannot reliably determine which feedback attributes may be legally retained.

In summary, OME does not preserve and propagate the profile token from the SDP m= line as an independent negotiation state, but rewrites the profile using the UseDtls boolean, preventing the answer from satisfying RFC 9429's exact-match requirement.

4. Impact Analysis

This is an RTP profile negotiation state binding error, primarily affecting SDP compliance, RTP/SRTP session establishment, and interoperability.

A strict peer may directly reject OME's generated answer because the answer's m= profile does not match the offer. For example, a peer sending an RTP/AVP offer but receiving a UDP/TLS/RTP/SAVPF answer may consider the offer/answer negotiation illegal.

More importantly, the RTP profile is not just a string difference. It determines whether RTP/RTCP is security-protected, and whether AVPF feedback semantics are enabled. By silently rewriting a non-secure profile to a secure one, or rewriting AVP/SAVP to AVPF/SAVPF, OME causes both parties to have differing understandings of critical state: RTP/RTCP packet format, whether DTLS-SRTP should be established, whether RTCP feedback is available, and whether the media section should be accepted.