Is your feature request related to a problem? Please describe.

Context
The current A2A specification supports transports that are strictly HTTP(S)-compliant (REST, JSON-RPC over HTTP, gRPC over HTTP/2). This design is excellent for interoperability and alignment with existing web standards.

However, real-time AI agent scenarios (voice assistants, multi-modal conversations, streaming audio/video, low-latency tool coordination) require transports that:

• Operate over UDP/QUIC (not just HTTP(S))
• Support bi-directional, low-latency streaming (voice/video packets, live text/audio synthesis)
• Enable peer-to-peer flows via STUN/TURN/ICE (for scaling media infra)

Problem
Right now, it is unclear how to implement these scenarios without breaking A2A compliance.

For example:

• WebRTC DataChannels / Media Streams run over DTLS/SCTP/UDP.
• WebTransport runs over QUIC.
• Both are not directly expressible as "HTTP(S) transports" under the current spec.

This leaves developers either:

1. Writing a bridge adapter (A2A <-> WebRTC gateway) to stay spec-compliant, or
2. Bypassing A2A for RTC flows, which reduces interoperability and visibility.

Describe the solution you'd like

Proposal
Introduce A2A Transport Extensions for WebRTC and WebTransport.

• Define WebRTC and WebTransport as first-class, optional transports under section 3.2.4 (Transport Extensions).

• Ensure functional equivalence with other transports:

  • Requests/responses map to A2A messages.
  • Streaming and event-driven updates map naturally to RTC channels.

• Security is preserved (DTLS for WebRTC, QUIC for WebTransport).

• Fallback defined: if RTC transport is unavailable, agents must fall back to HTTP-based transports.

Request for Discussion

• Should A2A formally extend to non-HTTP transports like WebRTC/WebTransport?
• Should we provide a reference bridge design for interim adoption?
• How should streaming media flows (voice, video) be represented in the A2A schema?

We propose initiating a working group discussion to scope out how these transports could be standardized in future A2A revisions.

Describe alternatives you've considered

Reference Design (Bridge/Gateway)
In the interim, developers could deploy an A2A-compliant RTC Gateway:

• Upstream: speaks normal A2A (HTTP JSON-RPC / gRPC).
• Downstream: multiplexes RTC channels (WebRTC DataChannel, MediaStream, WebTransport).
• This allows spec-compliant agents to interoperate with RTC-capable agents today.

Additional context

🔗 Why this matters
Real-time, multimodal agents (speech-to-speech, AI copilots, collaborative whiteboarding, low-latency media exchange) are quickly becoming a core part of the AI ecosystem. Without RTC/QUIC support, A2A risks leaving this major category of agent-to-agent communication underspecified.

Code of Conduct

• I agree to follow this project's Code of Conduct