]> Vconic

thomas@vconic.com

ART Agent Communication Protocols agentic dialog contact center voice SIP vCon Contact centers bring people, AI agents, and business systems into the same voice session. Consumer-controlled agents are also beginning to call agents operated by businesses. This document describes five contact center use cases for the agentic dialog management protocol: a consumer agent calling a business agent, escalation from an AI agent to a human representative, a call that resumes on another channel, a voice dialog passing through speech recognition and synthesis, and a dialog crossing an existing SIP or PSTN network. It derives numbered requirements that can be incorporated into the working group's use cases and requirements document. It also explains how a dialog identifier relates to the conversation records that contact centers already keep. About This Document Status information for this document may be found at . Discussion of this document takes place on the agentproto Working Group mailing list (), which is archived at . Subscribe at .

Introduction The agentproto charter names voice as one modality, calls out interactive voice as needing very low latency, and requires dialog context to stay coherent across intermediaries and trust boundaries. Contact centers put all three into one call. A single customer conversation can pass through a carrier, a session border controller, a speech recognizer, an AI agent, a queue, and a human representative in a different company, and can drop and resume on a different device the next day. The use cases in describe interaction patterns but do not include a contact center voice scenario. describes contact center transfer topologies (blind, supervised, sidebar, conference and passthrough) and notes that the user to agent leg often runs over a phone call. This document addresses both, and does not repeat the common requirements of (CMN-1 to CMN-12), which should apply here unchanged. Each requirement carries a CC prefix and one or more protocol-area tags defined in : Dialog, Transport, Security, and Authentication. The table identifies each requirement being extended. This document follows the charter's line between dialog context and task context. Dialog context includes the identifiers and lifecycle state needed to correlate and maintain a dialog. Transcripts, recordings, customer records and agent memory are task context and are not carried by the protocol. Several requirements in this document let a participant use the dialog identifier to find its own task context or records, described in Section 2.1 of .

Terminology This document uses the terms Dialog, Dialog Context, Task Context, Participant, Modality and Delegation as defined in . In addition:

Brand:

The business that operates a contact center and the agents and representatives that answer for it.

Consumer:

A person who contacts a brand, or on whose behalf a consumer agent contacts a brand.

Doorman:

A brand agent that identifies and routes inbound communications. The name echoes the admission-control and address-translation role of an H.323 gatekeeper .

Consumer Agent:

An AI agent acting for a consumer, outside the brand's administrative domain.

Brand Agent:

An AI agent operated by or for the brand that handles contacts.

Human Representative:

A person who handles contacts for a brand. Contact centers traditionally call these people "agents". This document avoids that usage to keep "agent" for AI agents.

Contact Center Platform:

The system that routes, queues, records and reports on contacts for a brand, and that presents contacts to human representatives.

Recorder:

A participant that receives media and dialog context in order to keep a record of the dialog and does not take part in it, such as a SIPREC Session Recording Server .

Transformer:

An intermediary that converts content from one modality to another, such as speech recognition (audio to text), speech synthesis (text to audio) or live translation.

As an unfortunate consequence of a limited operational vocabulary, three uses of "dialog" overlap in a contact center:

• An agentic dialog, in the sense of the agentproto charter, is the correlated sequence of interactions over the course of a task.
• A SIP dialog is a peer-to-peer signaling relationship between two user agents. A transfer, a callback or a reconnection each creates a new SIP dialog. A single agentic dialog can span several SIP dialogs, and in a conference several SIP dialogs exist at the same time.
• The dialog array in a vCon holds the media segments of a recorded conversation (recordings, text messages, transfers). A record of one agentic dialog can hold many vCon dialog objects.

In this document "dialog" alone means an agentic dialog.

Use Cases

Consumer Agent Calls a Brand

Description A consumer asks their own agent to cancel a car rental, dispute a charge or rebook a flight. The consumer agent connects to the brand's published contact point by placing a call over the PSTN or opening a real-time Internet channel such as chat or WebSocket. The brand answers with its own brand agent. Neither agent has a prior relationship with the other. The consumer agent knows only a contact address, such as a phone number or URL. The brand agent knows only what arrives with the contact. The agents may begin in synthesized speech because the brand publishes a phone number built for people. After they identify each other as agents, they may move to structured messages while keeping audio open for a human participant. The consumer may also join the call and speak for themselves. If the consumer later disputes the outcome, the brand's record shows what its agent did and the consumer agent's record shows its instructions. Comparing those records depends on both sides recording the same dialog identifier.

Interaction Flow | Agent | +--------+ . . +----+-----+ . voice, then . +---------+ . . | . structured . . . +----+-----+ . messages . . . | Consumer | . . . . +----------+ . . . ..................... ............................. ]]>

Protocol Requirements Consumer agent calls a brand

REQ-ID	Description	Tag
CC1-1	The protocol is required to support establishing a dialog between participants in different administrative domains that share no prior relationship, where the initiator holds only a contact address such as a telephone number or URL.	Dialog, Authentication
CC1-2	Each participant is required to be able to present an agent identity distinct from the telephone number it calls from and from the identity of the user on whose behalf it acts.	Authentication
CC1-3	The protocol is required to allow each participant to learn whether the peer participant is an AI agent or a human.	Dialog, Authentication
CC1-4	The protocol is required to support changing the active modalities of an established dialog, including moving from audio to structured messages while audio stays available, without establishing a new dialog. Extends A1-5 and CMN-11.	Dialog, Transport
CC1-5	The protocol is required to support signaling that a human user has joined a dialog or taken over from the agent acting for them, without terminating the dialog.	Dialog
CC1-6	Each authorized participant in a dialog is required to receive the same dialog identifier, so that records kept independently in each domain can later be associated with the same dialog.	Dialog
CC1-7	A consumer agent is required to be able to present the scope of authority the consumer granted it, and the brand agent is required to be able to verify that scope before taking an action with effect, such as a cancellation or refund. See B2-6 and B3-1 to B3-4.	Security, Authentication

Escalation from an AI Agent to a Human Representative

Description For economic and performance reasons, a brand may use a doorman to identify and route inbound communications to the appropriate resource. The doorman handles a call until it reaches something it is not permitted or able to do: a policy exception, a complaint, a vulnerable customer, or a consumer who asks for a person. The brand agent hands the dialog to a human representative using one of the topologies in , most often a supervised transfer, in which the brand agent introduces the call and then drops. The dialog may sit in a queue for minutes or longer, with only hold audio flowing, before a representative is available. The representative may work for the brand, or for an outsourcer in a different administrative domain and a different country. The representative works in a contact center application, not an agent runtime, and needs to see the history of the call on arrival so the customer does not repeat themselves. If no representative is available, or the target rejects the transfer, the dialog returns to the brand agent rather than dropping.

Interaction Flow | Human | . | | . | Agent | . same . | Representative| . +----------+ . +-----+-----+ . dialog. +-------+-------+ . . | . ID . | . . +-----+-----+ . . +-------+-------+ . . | Queue | . . | Contact Center| . . +-----------+ . . | Application | . ................... . +---------------+ . ....................... ]]>

Protocol Requirements Escalation to a human representative

REQ-ID	Description	Tag
CC2-1	The protocol is required to support replacing a participant, including replacing an AI agent with a human representative, as a modification of an existing dialog that keeps its dialog identifier. This applies to blind, supervised and conference transfer. Extends CMN-11.	Dialog
CC2-2	The protocol is required to allow dialog context to be delivered to a participant that is a human working through an application, not an AI agent.	Dialog
CC2-3	When a dialog crosses into another administrative domain, the receiving domain is required to receive the dialog context without receiving the sending domain's task context. The receiving participant is required to be able to use the dialog identifier to request task context through a separate, authorized exchange.	Dialog, Security
CC2-4	When a participant leaves a dialog, the protocol is required to end that participant's authority to act in the dialog while the dialog continues.	Security
CC2-5	The protocol is required to support a lifecycle state in which a dialog is waiting, such as queued or on hold, for a potentially long period with no participant actively exchanging content, subject to the dialog lifetime and local policy.	Dialog
CC2-6	When a transfer fails and the transferring participant remains available, the protocol is required to return control of the dialog to that participant with the dialog intact. The protocol is required to signal the reason, distinguishing at minimum rejection by the target from no target available.	Dialog

Interrupted Call Resumed on Another Channel

Description Many inbound calls originate on mobile phones, where coverage changes as the caller moves. A consumer may be on a call with a brand agent that has started an operation with effect, such as a payment or an order change, when the call drops. The consumer calls back from a different phone or moves to the brand's chat or messaging channel. The consumer does not hold the dialog identifier and cannot be asked for it. The brand authenticates the consumer and uses local policy to match the new contact to an interrupted, unterminated dialog. The protocol then resumes the selected dialog. Alternatively, after a disconnection, the brand agent calls the consumer back at the number the consumer gave, or sends a message, carrying the original dialog identifier through the brand's outbound dialing system. On resumption, the brand agent may not know whether the payment went through. As Section 4.2 notes, resuming the dialog does not settle an operation that was in flight. The application checks the operation before retrying it.

Interaction Flow Brand Agent (dialog D established) t1 Consumer ==voice=X Brand Agent (media lost; D interrupted, payment operation in flight) t2 Consumer ==chat===> Brand Agent (new channel; consumer authenticated; re-associated with D) t3 Brand Agent -> Payment tool (outcome of operation queried by dialog D and operation ID) ]]>

Protocol Requirements Interrupted call resumed on another channel

REQ-ID	Description	Tag
CC3-1	The protocol is required to support resuming a dialog through a different channel, device or network attachment from the one on which it was interrupted. Extends B1-6.	Dialog
CC3-2	After a serving participant has authenticated a returning user and used local policy to select an interrupted dialog, the protocol is required to support resumption when the user does not hold the dialog identifier. The checks in B1-7 are required before the dialog resumes.	Dialog, Security
CC3-3	The protocol is required to support resumption initiated by the serving participant toward the user, such as a callback, carrying the original dialog identifier.	Dialog
CC3-4	The protocol is required to distinguish an interrupted dialog from a terminated one, and to signal a distinct reason when resumption is refused because the dialog's lifetime has expired. Extends CMN-11.	Dialog
CC3-5	The protocol is required to allow an application protocol to associate an operation-status request and response with a dialog identifier and an operation identifier. The application response needs to distinguish completed, not completed, and unknown. The agentic dialog management protocol does not define operation semantics.	Dialog

Voice Through Speech Recognition and Synthesis

Description It is common, and in some cases required, for contact center calls to be transcribed. A consumer speaks on a phone call, and a speech recognizer turns the audio into text. The brand agent reads the text and writes a reply. A text-to-speech synthesizer turns the reply into audio. Each function may be a separate service run by a different provider. Other services may also participate:

• A live translator may sit between the consumer and the agent.
• A supervisor may watch a live transcript and step in.
• A recorder may keep the audio and the transcript for quality review and regulatory retention.
• A quality-scoring service may read the transcript in real time.

The consumer interrupts the agent mid-sentence. The synthesizer stops, the agent abandons the rest of its reply, and the recognizer starts on the new utterance. This is a real-time requirement because it has to happen quickly enough to preserve an interactive conversation. provides guidance for one-way transmission delay. It does not set an end-to-end budget for speech recognition, agent processing, and speech synthesis, but it shows why each added processing stage has to control its delay. requirement A1-10 already requires dialog context to survive a change of modality. This use case adds a chain of transformers, passive participants, and the need to tie an output to the input it came from.

Interaction Flow | ASR |----->| Brand |----->| TTS |------> Consumer +----------+ +-----+ | Agent | +-----+ +---+---+ | dialog context and +---------------+---------------+ | | | +-----+-----+ +-----+----+ +------+-----+ | Supervisor| | Recorder | | Quality | | (human) | | | | scoring | +-----------+ +----------+ +------------+ ]]>

Protocol Requirements Voice through speech recognition and synthesis

REQ-ID	Description	Tag
CC4-1	Each transformer is required to preserve the dialog identifier and the integrity of the dialog context it receives while carrying authorized context changes to its output. Each transformer is required to be identifiable as an intermediary in the dialog. Extends A1-10.	Dialog
CC4-2	The protocol is required to support identifiers for individual exchanges within a dialog, such as a single utterance or turn, so that a transformer's output can be associated with the input it was derived from.	Dialog
CC4-3	The protocol is required to support a participant signaling that an exchange in progress is abandoned, such as when a user interrupts synthesized speech, with bounded latency suitable for interactive voice.	Transport, Dialog
CC4-4	The protocol is required to support receive-only participants, such as a recorder, a monitoring supervisor, or an analytics service. These participants receive authorized dialog context and lifecycle events but are not authorized to modify the dialog.	Dialog, Security
CC4-5	The protocol is required to support a receive-only participant becoming an active one, such as a supervisor who barges in, as a modification of the dialog that is authorized under CMN-12.	Dialog, Security
CC4-6	The protocol is required to carry dialog context and lifecycle changes reliably while allowing real-time media in the same dialog to be carried without reliability, consistent with Section 3.1 of .	Transport

Dialog Across a SIP and PSTN Network

Description SIP trunks carry contact center voice traffic between carriers, and some of it starts on the PSTN. A consumer agent that places a phone call hands its audio to a carrier. Between the two agents sit session border controllers, back-to-back user agents, carrier interconnects, and sometimes a TDM segment. These systems do not necessarily understand agentic dialogs, and deployed back-to-back user agents may remove header fields they do not recognize. Inside the brand, the contact center platform transfers calls with REFER , each transfer creating a new SIP dialog, and forks media to a recorder using SIPREC . SIP has addressed a related correlation problem. The Session-ID header field identifies a communication session across SIP intermediaries, including back-to-back user agents. The User-to-User header field carries application data between endpoints across intermediaries. Neither field carries agentic dialog context, but both provide useful design and deployment experience. Number attestation with STIR tells the called party that the caller is authorized to use the calling number. It says nothing about whether an AI agent is on the call or who operates that agent.

Interaction Flow | Carrier |------>| B2BUA/ |----->| Brand |-----> | Agent | | A | | SBC | | SBC | +----------+ +---------+ +--------+ +---+----+ | +-------------------+------------------+------+ | | | +-----+-----+ +------+-----+ +------+------+ | Brand | | Human | | SIPREC | | Agent |----->| Rep. | | Recorder | +-----------+ REFER+------------+ +-------------+ ]]>

Protocol Requirements Dialog across a SIP and PSTN network

REQ-ID	Description	Tag
CC5-1	The working group's evaluation criteria for transport bindings are required to consider SIP because it is widely deployed for contact center voice traffic.	Transport
CC5-2	A SIP binding, if specified, is required to preserve dialog-context continuity across back-to-back user agents and session border controllers that support the binding, taking the Session-ID header field as prior art.	Transport
CC5-3	The protocol is required to treat an agentic dialog as independent of any single SIP dialog or call, so that one dialog can span the several SIP dialogs created by transfer, callback and reconnection.	Dialog
CC5-4	When dialog continuity is expected and a path segment cannot carry dialog context, such as a TDM segment, the binding is required to expose the continuity failure to participants or gateways that support the binding rather than silently treating the call as a new dialog.	Dialog
CC5-5	The protocol is required to allow an agent identity to be conveyed with a call independently of telephone number attestation.	Authentication
CC5-6	A recorder receiving media through SIPREC is required to be able to receive the dialog identifier, for example in recording metadata , so that recordings can be associated with the dialog.	Dialog

Dialog Identifiers and Conversation Records Contact centers keep conversation records for quality review, dispute resolution, training, and regulatory retention. Depending on the jurisdiction and purpose, they may also need evidence of notice, consent, or another lawful basis for recording and processing. When agents take part in those conversations, the records grow to include what each agent was told, what it did and on whose authority. The use cases above show that records about one dialog are kept in several places: the consumer agent's domain, the brand, an outsourcer, a recorder. The agentic dialog management protocol does not carry these records and this document asks for no record format. Audit data structures are out of scope for agentproto. The protocol's contribution is the dialog identifier: a value each participant holds and can write into its own records, so that records kept separately can later be associated. Requirements CC1-6, CC2-3, CC4-4 and CC5-6 exist for this purpose. The vCon format , developed in the IETF vCon working group, is one representation of such a record. It holds the parties to a conversation, its media and transcripts, analysis, and attachments such as a record of the lawful basis for processing . The agentproto charter lists vCon under coordination, on conversation representation and its relationship to dialog context. A system that indexes vCons by dialog identifier can find a record from that identifier. A party that reads the identifier from a vCon can use it, subject to authorization, to request related records held by other participants. Defining how a vCon carries a dialog identifier is work for the vCon working group. For , the author suggests the following text to resolve the editor's note in its Section 6:

• Audit and provenance representation is addressed by existing work, including W3C provenance (PROV), Trace Context, and, for conversations among users, agents and human representatives, the IETF vCon format . Dialog identifiers can be used to correlate these records across the participants in a dialog, including across administrative domains. This document does not define a record format.

Security Considerations The security considerations of apply. Contact center deployments add the following. Resuming a dialog on a new channel (CC3-1, CC3-2) is a takeover risk. An attacker who can re-associate with an interrupted dialog inherits whatever authority the consumer had established on it, which may include a half-completed payment. Re-association needs to rest on authentication at least as strong as the dialog required before the interruption. Participant replacement (CC2-1) and passive-to-active promotion (CC4-5) let a party gain the ability to act in a dialog. Each needs to be authorized at the time it happens, as CMN-12 requires, and the departing participant's authority needs to end (CC2-4). Passive participants (CC4-4) receive dialog context and usually sensitive media. Their presence in a dialog is itself information the consumer may be entitled to know, and many jurisdictions require notice before a call is recorded. Learning whether the peer is an AI agent (CC1-3) depends on the peer telling the truth. The protocol can authenticate a declaration and bind it to a participant identity. It cannot, by itself, prove how the peer is implemented or force a dishonest peer to declare itself. Operation-status checks under CC3-5 need replay protection and idempotency at the application layer. Resuming a dialog must not cause an operation with external effect to run a second time. Carrying a dialog identifier over a SIP or PSTN path can expose a correlation handle to intermediaries. A binding needs to provide the confidentiality and integrity required by CMN-3 where the path supports it, limit disclosure where it does not, and prevent an intermediary from substituting an identifier without detection.

Privacy Considerations A dialog identifier written into a brand's recordings, an outsourcer's records and a consumer agent's logs links those records by design. The same property lets anyone holding two of those records link them. Dialog identifiers need to be unpredictable, scoped to one dialog, and free of any encoding of a telephone number, customer account or agent identity. A consumer agent that calls many brands for one consumer can let those brands correlate the consumer if it reuses identifiers, agent credentials or delegation tokens across dialogs. The mapping that lets a brand re-associate a returning consumer with an interrupted dialog (CC3-2) belongs to the brand alone and needs no counterpart in the dialog context. Requirement CC2-3 keeps task context, which carries the personal data, out of the dialog context when a dialog crosses into another domain. The receiving domain fetches only what it is authorized to see.

IANA Considerations This document has no IANA actions.

Informative References Nokia Nokia China Mobile This document describes use cases for agentic AI communication systems and derives protocol requirements from those use cases. The requirements are intended to guide IETF standardization work on protocols in the context of agent-to-agent communication, agent-to- tool communication, with focus on dialog management, transport, multimodal communication, communication security, agent identity and authentication. Five9 Cisco AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. SIPez LLC vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. VCONIC This document defines a lawful basis extension for Virtualized Conversations (vCon) that provides standardized mechanisms for recording, verifying, and managing the lawful basis for processing data within conversation containers. The lawful basis extension addresses privacy compliance challenges through structured attachment metadata, including the specific lawful basis being asserted, temporal validity periods where applicable, and cryptographic proof mechanisms. The extension is designed as a Compatible vCon extension that introduces lawful basis management capabilities without altering existing vCon semantics. It defines a "lawful_basis" attachment (identified by the attachment "purpose" value "lawful_basis") with structured records for each of the six lawful bases defined in regulations like GDPR, including consent, contract, legal obligation, vital interests, public task, and legitimate interests. Key features include automated lawful basis detection during conversation processing, auditable records with cryptographic proofs, granular purpose-based permissions for all lawful bases, documented justifications for other lawful bases, and integration with privacy regulations including GDPR, CCPA, and HIPAA. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK] This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format. This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real-time Transport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document. This document describes an end-to-end session identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the Session Initiation Protocol (SIP). This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document. This document obsoletes RFC 7329. The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. ITU-T ITU-T

Use of Artificial Intelligence AI tools were used to research source material, criticize drafts, and check grammar. The author reviewed the resulting text and takes responsibility for the document's technical content, claims, and references.

Mapping to the Agentproto Use Cases Document The table maps each requirement in this document to the requirement it extends in . Mapping of requirements

This document	Relationship to the agentproto use cases document
CC1-4	Extends A1-5 and CMN-11 to mid-dialog modality change
CC1-7	Instance of B2-6 and B3-1 to B3-4 across a domain boundary
CC2-1	Extends CMN-11 to participant replacement
CC2-5	Applies the CMN-11 dialog lifetime to a waiting state
CC2-6	Specializes CMN-5 for a failed transfer
CC3-1	Extends B1-6 to a change of channel
CC3-2	Applies B1-7 when the user does not hold the identifier
CC3-4	Applies B1-8 and extends CMN-11 with an interrupted state
CC3-5	Correlates an application-layer outcome check with the dialog; operation semantics remain out of scope
CC4-1	Extends A1-10 to chained transformers
CC4-5	Instance of CMN-12
CC4-6	Consistent with Section 3.1
All others	New