The Agentic Session Initiation Protocol (A-SIP)
draft-rosenberg-agentproto-asip-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Jonathan Rosenberg | ||
| Last updated | 2026-11-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rosenberg-agentproto-asip-00
Agent Communication Protocols J. Rosenberg
Internet-Draft jdrosen.net
Intended status: Standards Track 2 November 2026
Expires: 6 May 2027
The Agentic Session Initiation Protocol (A-SIP)
draft-rosenberg-agentproto-asip-00
Abstract
The Agentic Session Initiation Protocol (A-SIP) is used for the
establishment and lifecycle maintenance of agentic dialogs. It also
enables and content exchange between a principal and an AI Agent over
the Internet. A-SIP can be used between a user agent and AI Agent,
between AI Agents, or between an AI Agent and a tool with agentic-
like properties. A-SIP is built ontop of HTTP/3, web transport and
Media Over Quic Transport (MOQT), leveraging a modern, public-cloud
friendly protocol stack. Its usage of MOQT is optional, needed only
when real-time media is exchanged. This allows asynchronous agent
interactions to be done entirely using HTTP/3, so simple cases remain
simple. Despite the name, A-SIP has no technical relationship with
SIP (RFC3261). This document is not yet a fully fleshed out
protocol, and is meant to solicit feedback on this general direction
of work.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://jdrosen.github.io/draft-rosenberg-agentproto-asip/draft-
rosenberg-agentproto-asip.html. Status information for this document
may be found at https://datatracker.ietf.org/doc/draft-rosenberg-
agentproto-asip/.
Discussion of this document takes place on the Agent Communication
Protocols Working Group mailing list (mailto:agentproto@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/
agentproto. Subscribe at https://www.ietf.org/mailman/listinfo/
agentproto/.
Source for this draft and an issue tracker can be found at
https://github.com/jdrosen/draft-rosenberg-agentproto-asip.
Rosenberg Expires 6 May 2027 [Page 1]
Internet-Draft A-SIP November 2026
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Guiding Principles . . . . . . . . . . . . . . . . . . . . . 4
3.1. Media and Signaling Easily Multiplexed . . . . . . . . . 4
3.2. Built on HTTP and OAuth . . . . . . . . . . . . . . . . . 5
3.3. Signaling via Web API . . . . . . . . . . . . . . . . . . 5
3.4. Distributed Inference is Possible . . . . . . . . . . . . 5
3.5. Simple Things, should be Simple . . . . . . . . . . . . . 6
3.6. Can Also be Used for Human to Human Sessions . . . . . . 6
4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Identifying an Agent . . . . . . . . . . . . . . . . . . 7
5.2. Authenticating and Authorizing the Principal . . . . . . 8
5.3. Retrieving Agent Capabilities . . . . . . . . . . . . . . 8
5.4. Creating an Agentic Dialog . . . . . . . . . . . . . . . 9
Rosenberg Expires 6 May 2027 [Page 2]
Internet-Draft A-SIP November 2026
5.5. Establishing the MOQT Session . . . . . . . . . . . . . . 9
5.6. Establishing Subscriptions . . . . . . . . . . . . . . . 10
5.7. Content Exchange . . . . . . . . . . . . . . . . . . . . 10
5.8. The Log . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.9. Pausing, Resuming and Reconnecting . . . . . . . . . . . 11
6. The Agent Resource . . . . . . . . . . . . . . . . . . . . . 12
6.1. Agent Capabilities Resource . . . . . . . . . . . . . . . 12
6.1.1. Voice Capabilities . . . . . . . . . . . . . . . . . 13
6.1.2. Video Capabilities . . . . . . . . . . . . . . . . . 13
6.1.3. Chat Capabilities . . . . . . . . . . . . . . . . . . 14
6.2. Creating an Agentic Dialog . . . . . . . . . . . . . . . 15
7. Dialog Context Resource . . . . . . . . . . . . . . . . . . . 16
8. AI Authorship Disclosures . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
The widespread usage of AI Agents on the Internet has introduced new
forms of networked communications. User agent clients connect to AI
agents running elswehere, AI agents communicate with other AI agents,
and AI agents communicate with tools. All three of these interaction
patterns - and the many use cases therein - require a session-like
protocol which handles lifecycle management, including creation,
modification, deletion and so on - along with the exchange of input
and output. These session-like associations can be extremely long
lived - running for hours or even days - and span multiple IP hosts
used by the both the principal and by the agent. They can also be
highly intermittent with asynchronous responses. All of these mean a
new type of protocol is needed.
These differ from the type of sessions created by the Session
Initiation Protocol (SIP) [RFC3261], which are shorter lived and work
between a single IP host for each participant.
In [I-D.manyfolks-agentproto-arch], an architecture is presented for
AI Agent networked communications. It introduces the concept of an
agentic dialog, which is defined as an association between two
parties - a principal whose role is to provide input to, and receive
output from, an agent - and the agent, which is running a process
which has properties which are agentic in nature. The agentic
properties that are relevant here are (1) conversational contuity,
and (2) driven by natural language in each direction.
Rosenberg Expires 6 May 2027 [Page 3]
Internet-Draft A-SIP November 2026
This document defines a protocol that can play the role of the Agent
Communications Protocol (ACP) which is defined abstractly in that
document. The protocol defined here - the Agentic Session Initiation
Protocol (A-SIP) - provides for the establishment and lifecycle
maintenance of agentic dialogs. It also enables and content exchange
between a principal and an agent, over any IP network, including the
Internet. A-SIP is built ontop of HTTP/3 [RFC9114] web transport
[I-D.ietf-webtrans-http3] and Media Over Quic Transport (MOQT)
[I-D.ietf-moq-transport].
This document does not yet provide a fully fleshed out protocol
specification. It has sufficient detail to give the general idea of
how it works, along with details for basic happy path. This document
is meant to solicit input and feedback on this general direction of
work.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Guiding Principles
The protocol stack defined in this document is based on a set of
guiding principles which are important to understand.
3.1. Media and Signaling Easily Multiplexed
The core functionality that A-SIP needs to provide combines
traditional signaling (estabishment of an agentic dialog, negotiation
of supported modalities, termination of the agentic dialog, and so
on) and exchange of media (real-time voice, video, images, and text).
This exact problem is solved by SIP [RFC3261]. However, SIP had a
separation between the signaling and media. The media was
transported using the Real-Time Transport Protocol (RTP) [RFC3550],
and ran on a separate UDP connection, using a different IP and port.
This design was sensible at the time SIP was conceived, but over
time, using a separate connection for media and signaling proved to
be incredibly problematic.
The biggest problem is that it made it extremely difficult to run SIP
in public cloud environments. IP addresses are often transient,
unknown to their hosts, and unreachable through public cloud routing
and load balancing. It made it difficult to run SIP servers on
kubernetes. It complicated network and firewall configuration.
Rosenberg Expires 6 May 2027 [Page 4]
Internet-Draft A-SIP November 2026
As a result of these lessons, A-SIP is designed to run on a single
connection (in this case, a QUIC [RFC9000] connection). This
connection multiplexes both the signaling and media over the same
connection. Affordances are made for communication that is needed
outside of the lifetime of the connection itself - needed only for
long-lived agentic dialogs that span hours or days - as an optional
protocol feature.
3.2. Built on HTTP and OAuth
HTTP and OAuth are the foundation of the modern Internet. If you
want to build a new cloud-based application, doing it as an HTTP
application is a given. Much of public cloud infrastructure is
designed around supporting web-based applications, with significant
investments made in scaled load balancers, firewalls, proxies and
similar componentry. Developer tools exist in large volume,
everything from curl to postman to OpenAPI YAML and so on. By
building ontop of HTTP, A-SIP inherits this technology stack,
facilitating its ease of development and deployment on the modern
Internet.
3.3. Signaling via Web API
A natural consequence of the principal of building off of HTTP, is to
make use of web APIs. An agentic dialog is an HTTP-based web
resource which can be queried by a GET, modified with a POST, and
removed with a DELETE. This makes it simple to specify and
implement. A web API works for A-SIP because the agentic protocol is
foundationally assymetric, as discussed in
[I-D.manyfolks-agentproto-arch]. The protocol involves one entity
(the principal) requesting the services of another (the agent). The
agent takes responsibility for state management - specifically the
agentic context defined in that document. This makes a web API a
good fit for those aspects of the protocol.
The web API can also be used for async content exchange, and (in a
pinch) even used for voice and video - but it is insufficient for
real-time.
3.4. Distributed Inference is Possible
To scale, modern AI Agent providers make use of distributed
inference, wherein a particular input from a user may generate
inference on one set of compute resources, and then a different set
serves the next input. This is all transparent to the user. We
would like to make sure that the agent protocol works well in these
cases.
Rosenberg Expires 6 May 2027 [Page 5]
Internet-Draft A-SIP November 2026
The implication on the protocol design is that we want the ability to
route user input to different places without requiring the principal
to do anything different - invisibly to them. It also means that the
output can come from different hosts and be routed to the principal -
also invisibly to the principal and its client.
This is resolved in A-SIP by allowing the agent to make use of a MOQT
relay network, sending the exchanged content through the relay rather
than to the server terminating the original HTTP connection from the
client.
3.5. Simple Things, should be Simple
The use cases for AI Agent communications is large, covering multiple
interaction patterns and multiple media modalities. It needs to
support text chat, image and video exchange, structured data
exchange, voice messaging, and real-time voice and video. It needs
to support AI agent sessions which last seconds, but also sessions
which last hours or days.
In reality, most implementations and AI Agents will only support a
subset of these. Indeed, the most common use case is likely to only
require asynchronous text-chat, with occasional inclusion of other
media types in the async chat, with a duration spanning a few minutes
or hours, all from a single host. This is the predominant use case
for AI Agents today. There is no real-time voice or video in many of
these agents. As a result, our goal is to make the protocol simple
to deploy and use for use cases that don't require advanced features,
and then make use of harder-to-deploy and harder-to-implement
protocol elements for the more advanced features.
Two features in particular are advanced in A-SIP - (1) exchange of
real-time media, and (2) notifications of agent output that are
generated when no connection is active. Both of these make use of
MOQT, which ideally suited for both.
3.6. Can Also be Used for Human to Human Sessions
A key goal of A-SIP is that - even though it is targeting the
communication patterns between a human principal and an AI Agent (or
between AI Agents), the protocol applies equally well to establish
communications between two humans, allowing them to exchange voice,
video or chat. In this regard, this is a spiritual successor of
sorts to SIP [RFC3261].
Rosenberg Expires 6 May 2027 [Page 6]
Internet-Draft A-SIP November 2026
4. Protocol Stack
The A-SIP protocol stack is shown in Figure 1. A-SIP signaling (the
web API used to create, query, modify and delete agentic dialogs) and
asynchronous content exchange run directly over HTTP/3 [RFC9114].
The advanced features - real-time media (including text) and
notifications of agent output generated when no connection is active
- are optional, and are carried by MOQT [I-D.ietf-moq-transport]
running over WebTransport [I-D.ietf-webtrans-http3], which itself
runs over HTTP/3. In all cases, signaling and media are multiplexed
over a single QUIC [RFC9000] connection.
+-------------------------------------------------------+
| A-SIP |
+---------------------------+---------------------------+
| Signaling (Web API) | Real-Time Media and |
| and Async Content | Offline Notifications |
| Exchange | (optional) |
| +---------------------------+
| | MOQT |
| +---------------------------+
| | WebTransport |
+---------------------------+---------------------------+
| HTTP/3 |
+-------------------------------------------------------+
| QUIC |
+-------------------------------------------------------+
| UDP |
+-------------------------------------------------------+
| IP |
+-------------------------------------------------------+
Figure 1: A-SIP Protocol Stack
5. Protocol Overview
This section is non-normative and provides an overview of A-SIP.
5.1. Identifying an Agent
An AI Agent is named with an HTTPS URI (e.g.,
https://example.com/agents/booking). A GET against this resource
retrieves a capability document, discussed below. A POST creates a
new agentic dialog.
Rosenberg Expires 6 May 2027 [Page 7]
Internet-Draft A-SIP November 2026
5.2. Authenticating and Authorizing the Principal
A-SIP relies entirely on OAuth [RFC6749].
If the principal is a human user, it would obtain an access token
through any of the OAuth grant flows that the agent provider wishes
to support. If the principal is an AI Agent, such as in the Agent-
to-Agent to Agent-to-Tool cases, the usage of the newly proposed
AAuth grant flow [I-D.rosenberg-oauth-aauth] is suggested.
5.3. Retrieving Agent Capabilities
A GET against the AI agent URI resource provides a description of the
agent, including its support for A-SIP and its allowed modalities
(voice, video, or chat). We call this the agent capabilities
document. The document also indicates other capabilities that are
optional to support by this specification.
Importantly, for each modality declared in the agent capabilities
document, the agent can indicate whether or not MOQT is supported for
exchange of content for this modality.
The capabilities document for each modality also indicates other
information needed for establishment of a dialog with that modality.
In the case of voice and video, it indicates supported codecs.
Standard ones come from the W3C WebCodec registry [W3CRegistry].
In the case of chat, the capabilities include the list of supported
MIME types which may be exchanged. In this regard, "chat" really
refers to the asynchronous exchange of content, and is not at all
restricted to text. All agents are required to support "text/plain".
Support can be declared for processing of images - for example - by
indicating support for one of the image types (e.g., "image/jpeg"
which is required for any agent that can handle images). The
capability declaration indicates whether or not the agent can support
receiving content of that type, sending content of that type, or
both.
The capabilities document also indicates whether the agent supports
the ability to convey informational elements. These include tool
call requests and responses, sub-agent invocations, and so on.
Similarly, the capabilities document indicates whether the agent
supports the ability to convey progress signaling.
The capabilities of the agent - and its corresponding capabilities
document - are anticipated to be relatively static, and thus
cacheable.
Rosenberg Expires 6 May 2027 [Page 8]
Internet-Draft A-SIP November 2026
5.4. Creating an Agentic Dialog
To create a new agentic dialog, the principal performs a POST against
the agent URI. The body contains a JSON object called an agentic
dialog creation request. It includes the desired modalities, and for
each, the selected capabilities. These must be a subset of the
supported capabilities of the agent. A request to create an agentic
dialog with features or modalities not supported by the agent is
rejected.
The agentic dialog creation request also indicates, for each
modality, whether or not the client wants to use MOQT for content
exchange - assuming it was supported by the server. For chat, the
client can elect to skip MOQT and instead use the web API to send
(and retrieve) content, using the log API endpoints described below.
The agentic dialog creation request also indicates whether the client
wants to receive information output or progress signaling.
The result that comes back is the dialog context meta-data. It
includes the Agentic Dialog Identifier (ADID) in the JSON payload,
and further operations happen against its URI (e.g.
https://example.com/agents/booking/agentic-dialogs/01a198c7-ab2f-
753f-9a6a-67b204b16994).
Importantly, if MOQT is used for the exchange of content for a
particular modality, the agentic dialog resource specifies the full
track names to be used in each direction. In A-SIP, the full track
name is always selected by the server, not the client. In addition,
the server can optionally provide a MOQT URI that the client should
use for the session.
If the client requested receipt of information output and progress
signaling, MOQT track names are provided for those in the agentic
dialog resource.
5.5. Establishing the MOQT Session
For a given modality, A-SIP allows for several supported exchange
techniques:
1. No MOQT: Used only for chat. In this mode of A-SIP, content is
sent from client to server through web API calls noted below.
Content from server back towards the client is received through
polling.
2. Connection shared MOQT: The HTTP connection used for the web API
is reused for content exchange, using webtransport to multiplex.
Rosenberg Expires 6 May 2027 [Page 9]
Internet-Draft A-SIP November 2026
3. Relayed MOQT: A separate MOQT over webtransport connection is
created, targeting the URI defined in the agentic dialog
resource.
The case to be used for each modality is indicated in the agentic
dialog resource. When relayed MOQT is used, it contains a distinct
MOQT URI used for the exchange. Its absence signals using connection
shared MOQT.
Based on the signaling agentic dialog exchange technology, the client
proceeds to set it up.
For connection shared MOQT, the client establishes a webtransport
session over the HTTP connection, and uses the result for MOQT.
Otherwise, it creates a new connection using webTransport towards the
URI provided. Note that A-SIP does not support MOQT directly over
QUIC, it is always over webTransport.
5.6. Establishing Subscriptions
If MOQT (connection shared or relayed) is in use, the client performs
a SUBSCRIBE to the track that the server is using to deliver content,
enabling it to receive real-time updates. SImilarly, the server
SUBSCRIBEs to the track that the client will use to deliver content.
Multiple subscriptions are carried over the same MOQT connection
whenever possible.
In the case where MOQT is not used, no subscriptions are used.
5.7. Content Exchange
Voice and video Content is exchanged using MOQs' Low Overhead Media
Containers (LOC) [I-D.ietf-moq-loc] which encapsulate WebCodec
[WebCodec]. These are published by each side using standard MOQT
procedures.
For chat, if MOQT is used for the exchange, the MIME type is directly
encapsulated into the MOQT payload (OPEN ISSUE - is further
encapsulation needed?).
When MOQT is not used, the client adds the content by posting to the
log, and retrieves it by polling against the log.
5.8. The Log
As noted in [I-D.manyfolks-agentproto-arch] - the dialog context
includes the log. The log is an append-only record of the input to,
and output from, the AI Agent. Each entry in the log has an ID.
Rosenberg Expires 6 May 2027 [Page 10]
Internet-Draft A-SIP November 2026
The client can retrieve log entries by a GET request against the log:
GET example.com/{agentPath}/agentic-dialogs/{adid}/log
This resource supports filtering and pagination features against
time, allowing the client to catch up against items it missed (OPEN
ISSUE - it would be nice if these IDs were the object IDs in MOQT,
which have the property that they increase over time. However they
are only unique within the group, and we want the above API to
retrieve objects across the tracks).
The client can append to this log by POSTing against it, which adds
to the content of the chat modality. (OPEN ISSUE - allow voice or
video too?).
The log contains all input and output, including progress signaling
and information output. Filters exist so that the client can
retrieve only input, only output, or selected types of output (e.g.,
response output only).
Polling to retrieve output is clearly suboptimal. A-SIP specifies
rate limiting negotiation, allowing the server to control pacing. If
clients want responses faster, they need to make use of the MOQT
transport.
5.9. Pausing, Resuming and Reconnecting
A-SIP allows an agentic dialog to be paused. A paused agentic dialog
means that the agent is no longer running inference, and is awaiting
further input which can come at another time, potentially a long time
from now.
To pause a dialog, there is a pause command ":pause" issued as a POST
against the agentic dialog resource:
POST https://example.com/agents/booking/agentic-dialogs/01a198c7-ab2f-753f-9a6a-67b204b16994:pause
This operation allows any inference in-progress to complete, and the
results of it returned over the existing connection. Once done, the
state of the dialog context moves to "PAUSED", and this state change
is conveyed over the MOQT notification topic. At that point, the
client can close the connection entirely, ending the MOQT session and
the HTTP connection in which it resides.
Rosenberg Expires 6 May 2027 [Page 11]
Internet-Draft A-SIP November 2026
If the client abruptly ends the HTTP/3 connection, it has the same
effect as an explicit pause operation. The AI Agent will complete
inference in progress, and add the results to the log. Without an
active connection, the results cannot be communicated to the
principal. However, it can retrieve them via the log when it
resumes.
To resume, the client need only create a new connection by initiating
an HTTP POST operation like this:
POST https://example.com/agents/booking/agentic-dialogs/01a198c7-ab2f-753f-9a6a-67b204b16994:resume
The response contains the current dialog context, which contains the
necessary information (e.g., track names) to create a new MOQ
connection (assuming muxing is used). Typically the same track names
are used across pauses and resumptions - and across reconnections.
This means that, using MOQT subscriptions that reference the last
group that the client received, it can "catch-up" via MOQT. If MOQT
is not used, querying the log with query filters accomplishes the
same goal. This works independent of whether the MOQT session is
multiplexed over the HTTP connection or accessed via a separate
connection.
The server will only allow resumption from the same principal
identified in th
The resume command also works against an active agentic dialog,
making this operation idempotent.
OPEN ISSUE - there is a subtle distinction between "stop running
inference" and "i'm not here anymore to get the results, so stop once
you get to the point where you need my input". Do we need to support
both modes? And which one is implied by a connection termination?
6. The Agent Resource
The agent resource is the root of the resource hierarchy. The URI
can be any valid HTTPS URI. The means by which the principal
discovers this URI is outside of the scope of this specification.
6.1. Agent Capabilities Resource
A GET upon the agent resource returns the agent capabilities
resource. This is a JSON document with the following fields:
* URI: The URI associated with the agent resource (required)
Rosenberg Expires 6 May 2027 [Page 12]
Internet-Draft A-SIP November 2026
* version: The version of the agent, expressed as "X.Y" where X and
Y are major and minor version numbers, which must each be a
positive integer less than 65535. (required)
* voice: if real-time voice is supported, the voice capability
object is included. If it is not supported, it is omitted.
* video: if real-time video is supported, the video capability
object is included. If it is not supported, it is omitted.
* chat: if chat - which includes a range of media types exchanged in
an async, turn-by-turn fashion - is supported, the chat capability
object is included. If it is not supported, it is omitted.
6.1.1. Voice Capabilities
The voice capabilities object in the JSON includes the following
fields:
* codecs: An array of strings. This field is required, and MUST be
non-empty. Each entry MUST be a valid voice codec string from the
W3C WebCodecs registry. All clients and all servers that support
voice, MUST support Opus (codec string: "opus"). Other codecs MAY
be supported.
* moqt: A boolean (optional). If true, it indicates that the agent
supports moqt transport for the voice. If absent, the default is
"true". (OPEN ISSUE: I'm not so sure about this default or even
allowing non-MOQT voice...).
* muxed: A boolean (optional). If true, it indicates that the agent
supports the ability to multiplex the MOQT session over the same
HTTP/3 connection used for the web API. The default is true.
6.1.2. Video Capabilities
The video capabilities object in the JSON includes the following
fields:
* codecs: An array of strings. This field is required, and MUST be
non-empty. Each entry MUST be a valid video codec string from the
W3C WebCodecs registry. All clients and all servers that support
video, MUST support AV1 (codec string: "av01"). Other codecs MAY
be supported.
Rosenberg Expires 6 May 2027 [Page 13]
Internet-Draft A-SIP November 2026
* moqt: A boolean (optional). If true, it indicates that the agent
supports moqt transport for the video. If absent, the default is
"true". (OPEN ISSUE: I'm not so sure about this default or even
allowing non-MOQT video...).
* muxed: A boolean (optional). If true, it indicates that the agent
supports the ability to multiplex the MOQT session over the same
HTTP/3 connection used for the web API. The default is true.
OPEN ISSUE - other video codec capabilities we need to signal?
6.1.3. Chat Capabilities
The chat capabilities object in the JSON includes the following
fields:
* principal-to-agent: An array, each entry containing a string that
is a valid IETF MIME type. This list MUST be non-empty and MUST
include "text/plain". These indicate the types that the AI agent
is able to receive.
* agent-to-principal: An array, each entry containing a string that
is a valid IETF MIME type. This list MUST be non-empty and MUST
include "text/plain". These indicate the types that the AI agent
is able to send.
An agent capable of processing image input would include at least one
image MIME type in the principal-to-agent array. If it supports such
input, then "image/jpeg" MUST be listed, ensuring a baseline image
capability.
Note that "text/plain" is a fairly broad type, and depending on the
flow of the conversation, the AI agent may actually emit any number
of structured outputs, such as code, JSON, or what have you. For
this reason, an AI agent doe not need to explicitly declare support
for structured data types that are encoded with text. For example,
there is no need to declare support for "text/csv".
Along similar lines, the chat capabilities document SHOULD NOT list
any application MIME types, unless the harness (as opposed to the
LLM) has explicit capabilities to recognize and parse them. The
assumption is that any text-based format is likely to be understood
by the LLM, and will passed transparently to the LLM by the harness.
This means that a traditional, text-based LLM that has no multimodal
support, only needs to declare support for "text/plain" in both
directions.
Rosenberg Expires 6 May 2027 [Page 14]
Internet-Draft A-SIP November 2026
6.2. Creating an Agentic Dialog
To create an agentic dialog, the client performs a POST against the
agent resource. The body MUST contain an agentic dialog creation
request.
The agentic dialog creation request has the following fields:
* voice: present if the client is requesting a real-time voice
modality. This MUST NOT be present if the agent capabilities
didn't indicate support for it.
* video: present if the client is requesting a real-time video
modality. This MUST NOT be present if the agent capabilities
didn't indicate support for it.
* chat: present if the client is requesting a real-time video
modality. This MUST NOT be present if the agent capabilities
didn't indicate support for it.
The voice object has the following fields:
* codec: This is a single string, defining the codec in use for the
real-time voice exchange. It MUST be one of the ones listed in
the capabilities.
* moqt: Boolean. True means that moqt transport is to be used.
MUST be true only if the agent indicated support for moqt.
* muxed: Boolean. True means that the moqt transport is to be muxed
with the HTTP connection. MUST be true only if the agent
indicated support for this.
The same fields present in the video object, but refer to video.
For the chat object, the fields mirror those in the capabilities
object:
* principal-to-agent: the MIME types that the principal plans to
send. These MUST be a subset of those indicated in the
capabilities document.
* agent-to-principal: The MIME types that the principal is capable
of receiving. These MUST be a subste of those indicated in the
capabilities document.
Rosenberg Expires 6 May 2027 [Page 15]
Internet-Draft A-SIP November 2026
Upon receipt of this API call, the server MUST authorize the request
using OAUth2.0 [RFC6749], and validate that the requested agentic
dialog is within the capability set supported by the agent.
It is worthwhile to note that the negotiation technique defined here
differs from the offer/answer mechanism specific for SIP in
[RFC3264]. That mechanism proved problematic over time, since it
mixed relatively static capability, with run-time configuration, with
connection information. In A-SIP, these are cleanly separated.
The response from the server contains a dialog context object. This
object is defined in the next section.
7. Dialog Context Resource
The dialog context resource is addressed by an HTTPS URI, and it
represnets the current state of the agentic dialog. Note that this
does not include the log per se, but it does include a timestamp
which represents the most recent log entry.
The dialog context object has the following fields:
* adid: The agentic dialog ID. This MUST be a type 7 UUID, and be
unique in space and time.
* uri: The URI that identifies this agentic dialog
* notifications: This is an object that is used to provide
notifications of state changes that are server initiated. It is
also used to support delivery of notifications through a MOQ relay
network, useful for cases where the client is offline for more
extended periods of time and is waiting for notification of
update. Details are TBD.
* voice: Present if the agentic dialog incldues real-time voice.
* video: Present if the agentic dialog incldues real-time video.
* chat: Present if the agentic dialog incldues chat.
* state: The current state of the agentic dialog. It is one of
ACTIVE, PAUSED, or COMPLETED.
* latest-log: A timestamp representing the most recent entry in the
log.
The voice and video objects have a similar structure:
Rosenberg Expires 6 May 2027 [Page 16]
Internet-Draft A-SIP November 2026
* agent-to-principal: This describes the session between the agent
and principal
* principal-to-agent: This desribes the session between the
principal and agent
Both of these also have the same structure, as they contain:
* codec: The codec in use
* moqt: Boolean, indicating whether moqt is in use
* muxed: Boolean, indicating whether the moqt session is muxed over
the HTTP connection or separate
* track: The full name of the track
* uri: The MOQT URI to use for the connection; only present if the
muxed field is false.
An example of a dialog context object for voice might look like this:
Rosenberg Expires 6 May 2027 [Page 17]
Internet-Draft A-SIP November 2026
{
"adid": "01a198c7-ab2f-753f-9a6a-67b204b16994",
"uri": "https://example.com/agents/booking/agentic-dialogs/01a198c7-ab2f-753f-9a6a-67b204b16994",
"state": "ACTIVE",
"latest-log": "2026-11-02T14:23:07.512Z",
"notifications": {
"uri": "https://relay.example.net/moq",
"track": {
"namespace": [
"example.com",
"booking",
"01a198c7-ab2f-753f-9a6a-67b204b16994"
],
"name": "notifications"
}
},
"voice": {
"principal-to-agent": {
"codec": "opus",
"moqt": true,
"muxed": true,
"track": {
"namespace": [
"example.com",
"booking",
"01a198c7-ab2f-753f-9a6a-67b204b16994"
],
"name": "voice-in"
}
},
"agent-to-principal": {
"codec": "opus",
"moqt": true,
"muxed": true,
"track": {
"namespace": [
"example.com",
"booking",
"01a198c7-ab2f-753f-9a6a-67b204b16994"
],
"name": "voice-out"
}
}
}
}
Rosenberg Expires 6 May 2027 [Page 18]
Internet-Draft A-SIP November 2026
8. AI Authorship Disclosures
This document was written entirely by hand, except for the example
JSON document and the protocol stack diagram, which were generated
with genAI assistance.
9. Security Considerations
TODO Security
10. IANA Considerations
This document has no IANA actions.
11. References
11.1. Normative References
[I-D.ietf-moq-loc]
Zanaty, M., Nandakumar, S., and P. Thatcher, "Low Overhead
Media Container", Work in Progress, Internet-Draft, draft-
ietf-moq-loc-05, 2 November 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-loc-
05>.
[I-D.ietf-moq-transport]
Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
"Media over QUIC Transport", Work in Progress, Internet-
Draft, draft-ietf-moq-transport-23, 2 November 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
transport-23>.
[I-D.ietf-webtrans-http3]
Frindell, A., Kinnear, E., and V. Vasiliev, "WebTransport
over HTTP/3", Work in Progress, Internet-Draft, draft-
ietf-webtrans-http3-17, 2 November 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-
webtrans-http3-17>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
Rosenberg Expires 6 May 2027 [Page 19]
Internet-Draft A-SIP November 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.
[W3CRegistry]
W3C, "WebCodecs Codec Registry", 2026,
<https://www.w3.org/TR/webcodecs-codec-registry/>.
[WebCodec] W3C, "WebCodecs", 2026,
<https://www.w3.org/TR/webcodecs/>.
11.2. Informative References
[I-D.manyfolks-agentproto-arch]
Rosenberg, J., Sarker, Z., Reddy.K, T., Yao, K., Liu, D.,
and S. Krishnan, "Architecture for AI Agent Communications
on the Internet", Work in Progress, Internet-Draft, draft-
manyfolks-agentproto-arch-00, 30 October 2026,
<https://datatracker.ietf.org/doc/html/draft-manyfolks-
agentproto-arch-00>.
[I-D.rosenberg-oauth-aauth]
Rosenberg, J. and P. White, "AAuth - Agentic Authorization
OAuth 2.1 Extension", Work in Progress, Internet-Draft,
draft-rosenberg-oauth-aauth-02, 1 November 2026,
<https://datatracker.ietf.org/doc/html/draft-rosenberg-
oauth-aauth-02>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, July 2002,
<https://www.rfc-editor.org/rfc/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, July 2002,
<https://www.rfc-editor.org/rfc/rfc3264>.
Rosenberg Expires 6 May 2027 [Page 20]
Internet-Draft A-SIP November 2026
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/rfc/rfc3550>.
Acknowledgments
TODO acknowledge.
Author's Address
Jonathan Rosenberg
jdrosen.net
Email: jdrosen@jdrosen.net
Rosenberg Expires 6 May 2027 [Page 21]