What Is A-SIP? The Beginner's Guide to the Agentic Session Initiation Protocol
CodexFuse Team · 2026-11-05T03:17:53.080Z · 11 min read min read
What Is A-SIP? The Beginner's Guide to the Agentic Session Initiation Protocol
What Is A-SIP?
A-SIP is the Agentic Session Initiation Protocol, a brand-new IETF Internet-Draft (draft-rosenberg-agentproto-asip-00, published 2 November 2026) that proposes a standard way to set up and manage long-lived conversations — called "agentic dialogs" — between a person and an AI agent, between two AI agents, or between an AI agent and a tool with agentic-like properties. In the draft's own words, "The Agentic Session Initiation Protocol (A-SIP) is used for the establishment and lifecycle maintenance of agentic dialogs." If you run agents on your own hardware — for example on VPS hosting you control — the A-SIP agentic protocol aims to become the open session layer those dialogs run on, the same way phone calls once needed a standard way to be set up.
The author is Jonathan Rosenberg, the lead author of SIP (RFC 3261) itself, the protocol that set up billions of voice calls over the internet. A-SIP is not yet a finished protocol: the draft states it "is not yet a fully fleshed out protocol, and is meant to solicit feedback on this general direction of work." It is an individual draft, not an adopted IETF working-group document, and only the first revision (-00) exists as of this writing.
How Do A-SIP Dialogs Work?
An A-SIP dialog works like a named, queryable resource on the web, and the whole lifecycle runs as ordinary web operations. The draft describes the happy path in five steps:
- Name the agent. Every AI agent gets an HTTPS URI, for example https://example.com/agents/booking. This is the address you talk to.
- Read its capabilities. A GET against the agent URI retrieves a capability document describing what the agent can do.
- Create the dialog. A POST against the agent URI creates a new agentic dialog. The response is the dialog context, which includes an Agentic Dialog Identifier (ADID) — a type-7 UUID, unique in space and time — and all further operations happen against that dialog's own URI.
- Exchange content. Signaling (create, query, modify, delete) and asynchronous content exchange run over HTTP/3. Real-time media and notifications are carried by MOQT, which is optional — simple asynchronous cases never need it.
- Pause and resume. A dialog can be paused with a ":pause" command, which stops the agent's inference run while the conversation waits — potentially for a long time. A later POST to the same dialog URI with ":resume" wakes it up exactly where it left off. Dialog states are ACTIVE, PAUSED, or COMPLETED.
The dialog context also carries an append-only log: a record of every input to and output from the agent, each entry with its own ID. When MOQT is not in use, the client simply posts content to the log and polls it back. That log is what makes the conversation resumable across hours or even days — the draft explicitly notes that agentic dialogs differ from the sessions SIP created because they can last far longer and "span multiple IP hosts".
What Does the A-SIP Protocol Stack Look Like?
A-SIP sits on a deliberately modern, public-cloud-friendly stack. The draft's own description: "A-SIP is built ontop of HTTP/3, web transport and Media Over Quic Transport (MOQT), leveraging a modern, public-cloud friendly protocol stack." Everything — signaling and media alike — is multiplexed over a single QUIC connection.
The A-SIP HTTP3/MOQT split is the clever part. A-SIP signaling (the web API used to create, query, modify and delete agentic dialogs) and asynchronous content exchange run directly over HTTP/3.
The advanced features — real-time media, including real-time text, plus notifications of agent output generated while no connection is active — are optional and are carried by MOQT running over WebTransport, which itself runs over HTTP/3. The draft's design principle: "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."
For identity and authorization, the draft keeps it to one mechanism: "A-SIP relies entirely on OAuth [RFC6749]." If the principal starting the dialog is a human, any OAuth grant flow the agent provider supports will do. If the principal is itself an AI agent — the agent-to-agent or agent-to-tool cases — the draft suggests the newly proposed AAuth grant flow, another Rosenberg draft, which is designed for agents acting on behalf of someone. Receipt-style accountability for what an agent does inside such a session is a separate lane of the same protocol family, covered for example by the AER-1 execution receipts proposal.
What Role Does A-SIP Play in the IETF's AgentProto Work?
A-SIP is one candidate piece of a larger IETF effort. A companion architecture draft defines the Agent Communications Protocol (ACP) — also known as agentproto — abstractly, as "a new protocol to be developed in the IETF" that enables communication between user-agent clients and AI agents, between AI agents, or between AI agents and tools. The architecture breaks ACP into three functional blocks: agentic dialog management, authorization and delegation, and identity management.
The A-SIP ACP role is deliberately narrow. A-SIP positions itself as a concrete protocol that "can play the role of the Agent Communications Protocol (ACP) which is defined abstractly in that document" — specifically the agentic dialog management block.
It is a candidate, not the anointed implementation; discussion happens on the IETF Agent Communication Protocols mailing list, [email protected]. The architecture draft was published 30 October 2026, three days before the A-SIP draft, and both are individual drafts so far.
One source of confusion worth clearing up once: IBM Research's "Agent Communication Protocol" (ACP) is a completely different and unrelated protocol — a REST-based agent messaging spec from IBM's BeeAI project that was merged into the A2A protocol in August 2025 and whose repository is now archived. The IETF's agentproto ACP has nothing to do with it.
Is A-SIP Related to SIP?
Despite the name, A-SIP has no technical relationship with SIP (RFC3261) — that is the draft's own verbatim disclaimer, and it is the most important fact in the comparison. The name is a nod to the author and to the shared job of setting up sessions, not a shared wire format.
That said, the draft calls A-SIP "a spiritual successor of sorts to SIP" — because SIP solved the problem of establishing multimedia sessions (calls, conferences) and A-SIP targets the analogous problem for agentic conversations. This A-SIP vs SIP comparison comes straight from the draft's own wording:
| Aspect | A-SIP (draft, Nov 2026) | SIP (RFC 3261, June 2002) | ACP-abstract (architecture draft, Oct 2026) |
|---|---|---|---|
| What it is | A protocol "used for the establishment and lifecycle maintenance of agentic dialogs" | "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants" | "the Agent Communications Protocol (ACP) - also known as agentproto - a new protocol to be developed in the IETF" that manages agentic dialogs |
| Sessions carry | Conversations between principals and AI agents — long-lived, potentially hours or days, spanning multiple IP hosts | "Internet telephone calls, multimedia distribution, and multimedia conferences" — shorter-lived sessions | Three patterns: user-agent to agent, agent to agent, agent to tool |
| Transport | HTTP/3 + WebTransport + MOQT (optional), multiplexed over a single QUIC connection | Signaling separate from media (RTP on separate connections); "runs on top of several different transport protocols" | "rides ontop of transport protocols" — requirements identified, wire formats out of scope |
| Authorization | "relies entirely on OAuth" (RFC 6749), with AAuth suggested for agent principals | Defined in the RFC; not the focus of this comparison | Functional blocks include "authorization and delegation, and identity management" |
| Status | Individual Internet-Draft, first revision (-00), expires 6 May 2027, "not yet a fully fleshed out protocol" | Internet Standards Track RFC since 2002 | Individual Internet-Draft (-00), 30 October 2026 |
The practical takeaway: if you know SIP, the mental model to borrow is "session setup and teardown" — create, hold, resume, end — not any packet format. A-SIP is web-native from the start: dialogs are HTTP resources you POST, GET, and DELETE.
How Does A-SIP Relate to MCP and A2A?
A-SIP is not competing with the application-layer agent protocols you already know. The architecture draft puts it plainly: "MCP [MCP] and A2A [A2A] are application-layer protocols maintained by the Linux Foundation... MCP addresses agent-to-tool interactions, and A2A addresses agent-to-agent interactions. The agent communication protocol in this architecture is intended to be usable by these protocols through well-defined extension points, not to replace them."
Think of the stack in three layers: A-SIP would establish and maintain the session the conversation happens inside; MCP and A2A handle what gets said and which tools get called within it. Neighboring proposals fill out the rest of the picture rather than rivaling it: the Mitra protocol defines a signed envelope for agent requests, while the TRAIL protocol adds cross-organization auditability and revocation. A-SIP is the session-establishment lane; envelopes, receipts, and audit trails live in their own lanes.
Is A-SIP a Finished Standard?
No — and the draft is upfront about it. "This document does not yet provide a fully fleshed out protocol specification," it says, and it "is meant to solicit feedback on this general direction of work." Only revision -00 exists, published 2 November 2026; the draft expires on 6 May 2027, the standard six-month Internet-Draft lifetime.
As of 2026-11-05 there is no independent coverage, no news articles, no explainers, and no public discussion threads about the draft — just the document itself, its source repository, and the datatracker record. If you want to follow it, watch three places: the datatracker page for draft-rosenberg-agentproto-asip (any future -01 revision or working-group adoption will appear there), the source repository at github.com/jdrosen/draft-rosenberg-agentproto-asip, whose README calls it "the working area for the individual Internet-Draft", and the [email protected] mailing list, where the feedback the draft solicits is actually being given.
Sources
- IETF Datatracker — draft-rosenberg-agentproto-asip-00, "The Agentic Session Initiation Protocol (A-SIP)", full text, November 2026, https://datatracker.ietf.org/doc/html/draft-rosenberg-agentproto-asip-00
- IETF Datatracker — draft-rosenberg-agentproto-asip document information page (status, intended status, expiry), https://datatracker.ietf.org/doc/draft-rosenberg-agentproto-asip/
- IETF Datatracker — draft-rosenberg-agentproto-asip document history, https://datatracker.ietf.org/doc/draft-rosenberg-agentproto-asip/history/
- IETF Datatracker — draft-manyfolks-agentproto-arch-00, "Architecture for AI Agent Communications on the Internet", October 2026, https://datatracker.ietf.org/doc/html/draft-manyfolks-agentproto-arch-00
- GitHub — jdrosen/draft-rosenberg-agentproto-asip, source repository for the draft, https://github.com/jdrosen/draft-rosenberg-agentproto-asip
- RFC Editor — RFC 3261, "SIP: Session Initiation Protocol", June 2002, https://www.rfc-editor.org/rfc/rfc3261
- Wikipedia — Session Initiation Protocol (history: designed 1996 by Mark Handley, Henning Schulzrinne, Eve Schooler and Jonathan Rosenberg), https://en.wikipedia.org/wiki/Session_Initiation_Protocol
- rywalker.com — ACP: Agent Communication Protocol research (IBM ACP merged into A2A, August 2025), https://rywalker.com/research/acp-agent-communication-protocol
- safeguard.sh — Agent Communication Protocol explained: REST-based agent messaging and its merge into A2A, https://safeguard.sh/resources/blog/agent-communication-protocol-explained-rest-based-agent-messaging-and-its-merge-into-a2a
- benchclaw.io — A2A protocol definition, https://benchclaw.io/a2a-protocol/
- arXiv — 2610.30151 (handshake-overhead analysis; IBM ACP frozen/archived status), https://arxiv.org/html/2610.30151
- ietf.org archive — draft-rosenberg-agentproto-asip-00 mirror, https://www.ietf.org/archive/id/draft-rosenberg-agentproto-asip-00.html
Frequently Asked Questions
What does A-SIP stand for?
A-SIP stands for the Agentic Session Initiation Protocol. It is an IETF Internet-Draft (draft-rosenberg-agentproto-asip-00) published 2 November 2026 by Jonathan Rosenberg — the lead author of the original SIP standard — that proposes how long-lived conversations between people, AI agents, and tools get created, maintained, paused, and resumed.
Is A-SIP technically related to SIP?
No. The draft states flatly that there is no technical relationship with SIP (RFC 3261); the sessions A-SIP creates are longer-lived agentic dialogs rather than phone calls, and the wire format is modern web infrastructure (HTTP/3, WebTransport, MOQT) rather than SIP's signaling protocol. The author calls it only "a spiritual successor of sorts" because both solve the problem of establishing sessions.
How are A-SIP dialogs created and identified?
You POST to the agent's HTTPS URI with a dialog-creation request. The response is the dialog context, which contains the Agentic Dialog Identifier (ADID) — a type-7 UUID, unique in space and time — and every later operation (query, content, pause, resume, delete) happens against the dialog's own URI. Dialogs move through ACTIVE, PAUSED, and COMPLETED states.
Does using A-SIP require MOQT?
No. MOQT is optional and only needed when real-time media is exchanged; ordinary asynchronous interactions run entirely over HTTP/3. The draft's principle is that "simple cases remain simple".
When can I use A-SIP in production?
Not yet — and don't treat it as finished. Only the first revision (-00) exists, the draft itself says it "is not yet a fully fleshed out protocol, and is meant to solicit feedback on this general direction of work", and as an individual Internet-Draft it expires on 6 May 2027. Track it on the IETF datatracker page, the GitHub source repository, or the [email protected] mailing list, and expect the protocol to change as feedback lands.
