Agent Communication Protocols T. Howe Internet-Draft Vconic Intended status: Informational 25 October 2026 Expires: 28 April 2027 Contact Center Use Cases and Requirements for Agentic Dialogs draft-howe-agentproto-contact-center-usecases-00 Abstract 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 This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-howe-agentproto-contact- center-usecases/. Discussion of this document takes place on the agentproto 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/. 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/. Howe Expires 28 April 2027 [Page 1] Internet-Draft Contact Center Agent Use Cases October 2026 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 28 April 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Consumer Agent Calls a Brand . . . . . . . . . . . . . . 5 3.1.1. Description . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Interaction Flow . . . . . . . . . . . . . . . . . . 5 3.1.3. Protocol Requirements . . . . . . . . . . . . . . . . 6 3.2. Escalation from an AI Agent to a Human Representative . . 7 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Interaction Flow . . . . . . . . . . . . . . . . . . 7 3.2.3. Protocol Requirements . . . . . . . . . . . . . . . . 8 3.3. Interrupted Call Resumed on Another Channel . . . . . . . 9 3.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. Interaction Flow . . . . . . . . . . . . . . . . . . 9 3.3.3. Protocol Requirements . . . . . . . . . . . . . . . . 9 3.4. Voice Through Speech Recognition and Synthesis . . . . . 10 3.4.1. Description . . . . . . . . . . . . . . . . . . . . . 10 3.4.2. Interaction Flow . . . . . . . . . . . . . . . . . . 11 3.4.3. Protocol Requirements . . . . . . . . . . . . . . . . 11 3.5. Dialog Across a SIP and PSTN Network . . . . . . . . . . 12 3.5.1. Description . . . . . . . . . . . . . . . . . . . . . 13 3.5.2. Interaction Flow . . . . . . . . . . . . . . . . . . 13 3.5.3. Protocol Requirements . . . . . . . . . . . . . . . . 13 4. Dialog Identifiers and Conversation Records . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 Howe Expires 28 April 2027 [Page 2] Internet-Draft Contact Center Agent Use Cases October 2026 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Informative References . . . . . . . . . . . . . . . . . . . 17 Use of Artificial Intelligence . . . . . . . . . . . . . . . . . 18 Mapping to the Agentproto Use Cases Document . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. 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 [I-D.agentic-ai-usecases-requirements] describe interaction patterns but do not include a contact center voice scenario. [I-D.rosenberg-agentproto-usecases] 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 [I-D.agentic-ai-usecases-requirements] (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 [I-D.agentic-ai-usecases-requirements]: 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 [I-D.agentic-ai-usecases-requirements]. 2. Terminology This document uses the terms *Dialog*, *Dialog Context*, *Task Context*, *Participant*, *Modality* and *Delegation* as defined in [I-D.agentic-ai-usecases-requirements]. In addition: *Brand*: The business that operates a contact center and the agents Howe Expires 28 April 2027 [Page 3] Internet-Draft Contact Center Agent Use Cases October 2026 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 [H323]. *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 [RFC7866]. *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* [RFC3261] 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* [I-D.ietf-vcon-vcon-core] holds the media segments of a recorded conversation (recordings, text messages, transfers). A record of one agentic dialog can hold many vCon dialog objects. Howe Expires 28 April 2027 [Page 4] Internet-Draft Contact Center Agent Use Cases October 2026 In this document "dialog" alone means an agentic dialog. 3. Use Cases 3.1. Consumer Agent Calls a Brand 3.1.1. 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. 3.1.2. Interaction Flow Consumer domain Brand domain ..................... ............................. . . . . . +----------+ . dialog . +---------+ +--------+ . . | Consumer | . context . | Brand |--| Tools | . . | Agent |<----.--------------.->| Agent | +--------+ . . +----+-----+ . voice, then . +---------+ . . | . structured . . . +----+-----+ . messages . . . | Consumer | . . . . +----------+ . . . ..................... ............................. Howe Expires 28 April 2027 [Page 5] Internet-Draft Contact Center Agent Use Cases October 2026 3.1.3. Protocol Requirements +========+========================================+================+ | REQ-ID | Description | Tag | +========+========================================+================+ | CC1-1 | The protocol is required to support | Dialog, | | | establishing a dialog between | Authentication | | | 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. | | +--------+----------------------------------------+----------------+ | CC1-2 | Each participant is required to be | Authentication | | | 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. | | +--------+----------------------------------------+----------------+ | CC1-3 | The protocol is required to allow each | Dialog, | | | participant to learn whether the peer | Authentication | | | participant is an AI agent or a human. | | +--------+----------------------------------------+----------------+ | CC1-4 | The protocol is required to support | Dialog, | | | changing the active modalities of an | Transport | | | established dialog, including moving | | | | from audio to structured messages | | | | while audio stays available, without | | | | establishing a new dialog. Extends | | | | A1-5 and CMN-11. | | +--------+----------------------------------------+----------------+ | CC1-5 | The protocol is required to support | Dialog | | | signaling that a human user has joined | | | | a dialog or taken over from the agent | | | | acting for them, without terminating | | | | the dialog. | | +--------+----------------------------------------+----------------+ | CC1-6 | Each authorized participant in a | Dialog | | | 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. | | +--------+----------------------------------------+----------------+ | CC1-7 | A consumer agent is required to be | Security, | | | able to present the scope of authority | Authentication | | | the consumer granted it, and the brand | | | | agent is required to be able to verify | | Howe Expires 28 April 2027 [Page 6] Internet-Draft Contact Center Agent Use Cases October 2026 | | that scope before taking an action | | | | with effect, such as a cancellation or | | | | refund. See B2-6 and B3-1 to B3-4. | | +--------+----------------------------------------+----------------+ Table 1: Consumer agent calls a brand 3.2. Escalation from an AI Agent to a Human Representative 3.2.1. 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 [I-D.rosenberg-agentproto-usecases], 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. 3.2.2. Interaction Flow Brand domain Outsourcer domain ................... ....................... . . . . +----------+ . +-----------+ . . +---------------+ . | Consumer |--.--| Brand |--.-------.->| Human | . | | . | Agent | . same . | Representative| . +----------+ . +-----+-----+ . dialog. +-------+-------+ . . | . ID . | . . +-----+-----+ . . +-------+-------+ . . | Queue | . . | Contact Center| . . +-----------+ . . | Application | . ................... . +---------------+ . ....................... Howe Expires 28 April 2027 [Page 7] Internet-Draft Contact Center Agent Use Cases October 2026 3.2.3. Protocol Requirements +========+==============================================+==========+ | REQ-ID | Description | Tag | +========+==============================================+==========+ | CC2-1 | The protocol is required to support | Dialog | | | 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. | | +--------+----------------------------------------------+----------+ | CC2-2 | The protocol is required to allow dialog | Dialog | | | context to be delivered to a participant | | | | that is a human working through an | | | | application, not an AI agent. | | +--------+----------------------------------------------+----------+ | CC2-3 | When a dialog crosses into another | Dialog, | | | administrative domain, the receiving domain | Security | | | 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. | | +--------+----------------------------------------------+----------+ | CC2-4 | When a participant leaves a dialog, the | Security | | | protocol is required to end that | | | | participant's authority to act in the dialog | | | | while the dialog continues. | | +--------+----------------------------------------------+----------+ | CC2-5 | The protocol is required to support a | Dialog | | | 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. | | +--------+----------------------------------------------+----------+ | CC2-6 | When a transfer fails and the transferring | Dialog | | | 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. | | +--------+----------------------------------------------+----------+ Howe Expires 28 April 2027 [Page 8] Internet-Draft Contact Center Agent Use Cases October 2026 Table 2: Escalation to a human representative 3.3. Interrupted Call Resumed on Another Channel 3.3.1. 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 [I-D.agentic-ai-usecases-requirements] Section 4.2 notes, resuming the dialog does not settle an operation that was in flight. The application checks the operation before retrying it. 3.3.2. Interaction Flow t0 Consumer ==voice==> 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) 3.3.3. Protocol Requirements +========+===============================================+==========+ | REQ-ID | Description | Tag | +========+===============================================+==========+ | CC3-1 | The protocol is required to support | Dialog | | | resuming a dialog through a different | | | | channel, device or network attachment | | | | from the one on which it was | | | | interrupted. Extends B1-6. | | Howe Expires 28 April 2027 [Page 9] Internet-Draft Contact Center Agent Use Cases October 2026 +--------+-----------------------------------------------+----------+ | CC3-2 | After a serving participant has | Dialog, | | | authenticated a returning user and | Security | | | 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. | | +--------+-----------------------------------------------+----------+ | CC3-3 | The protocol is required to support | Dialog | | | resumption initiated by the serving | | | | participant toward the user, such as a | | | | callback, carrying the original dialog | | | | identifier. | | +--------+-----------------------------------------------+----------+ | CC3-4 | The protocol is required to | Dialog | | | 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. | | +--------+-----------------------------------------------+----------+ | CC3-5 | The protocol is required to allow an | Dialog | | | 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. | | +--------+-----------------------------------------------+----------+ Table 3: Interrupted call resumed on another channel 3.4. Voice Through Speech Recognition and Synthesis 3.4.1. 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. Howe Expires 28 April 2027 [Page 10] Internet-Draft Contact Center Agent Use Cases October 2026 * 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. [G114] 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. [I-D.agentic-ai-usecases-requirements] 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. 3.4.2. Interaction Flow +----------+ audio +-----+ text +-------+ text +-----+ audio | Consumer |------>| ASR |----->| Brand |----->| TTS |------> Consumer +----------+ +-----+ | Agent | +-----+ +---+---+ | dialog context and +---------------+---------------+ | | | +-----+-----+ +-----+----+ +------+-----+ | Supervisor| | Recorder | | Quality | | (human) | | | | scoring | +-----------+ +----------+ +------------+ 3.4.3. Protocol Requirements +========+===========================================+============+ | REQ-ID | Description | Tag | +========+===========================================+============+ | CC4-1 | Each transformer is required to preserve | Dialog | | | 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. | | +--------+-------------------------------------------+------------+ Howe Expires 28 April 2027 [Page 11] Internet-Draft Contact Center Agent Use Cases October 2026 | CC4-2 | The protocol is required to support | Dialog | | | 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. | | +--------+-------------------------------------------+------------+ | CC4-3 | The protocol is required to support a | Transport, | | | participant signaling that an exchange in | Dialog | | | progress is abandoned, such as when a | | | | user interrupts synthesized speech, with | | | | bounded latency suitable for interactive | | | | voice. | | +--------+-------------------------------------------+------------+ | CC4-4 | The protocol is required to support | Dialog, | | | receive-only participants, such as a | Security | | | 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. | | +--------+-------------------------------------------+------------+ | CC4-5 | The protocol is required to support a | Dialog, | | | receive-only participant becoming an | Security | | | active one, such as a supervisor who | | | | barges in, as a modification of the | | | | dialog that is authorized under CMN-12. | | +--------+-------------------------------------------+------------+ | CC4-6 | The protocol is required to carry dialog | Transport | | | 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 | | | | [I-D.agentic-ai-usecases-requirements]. | | +--------+-------------------------------------------+------------+ Table 4: Voice through speech recognition and synthesis 3.5. Dialog Across a SIP and PSTN Network Howe Expires 28 April 2027 [Page 12] Internet-Draft Contact Center Agent Use Cases October 2026 3.5.1. 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 [RFC3515] [RFC5589], each transfer creating a new SIP dialog, and forks media to a recorder using SIPREC [RFC7866]. SIP has addressed a related correlation problem. The Session-ID header field [RFC7989] identifies a communication session across SIP intermediaries, including back-to-back user agents. The User-to-User header field [RFC7433] 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 [RFC8224] 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. 3.5.2. Interaction Flow +----------+ SIP +---------+ SIP +--------+ TDM +--------+ SIP | Consumer |------>| Carrier |------>| B2BUA/ |----->| Brand |-----> | Agent | | A | | SBC | | SBC | +----------+ +---------+ +--------+ +---+----+ | +-------------------+------------------+------+ | | | +-----+-----+ +------+-----+ +------+------+ | Brand | | Human | | SIPREC | | Agent |----->| Rep. | | Recorder | +-----------+ REFER+------------+ +-------------+ 3.5.3. Protocol Requirements +========+=======================================+================+ | REQ-ID | Description | Tag | +========+=======================================+================+ | CC5-1 | The working group's evaluation | Transport | | | criteria for transport bindings are | | | | required to consider SIP because it | | | | is widely deployed for contact center | | | | voice traffic. | | Howe Expires 28 April 2027 [Page 13] Internet-Draft Contact Center Agent Use Cases October 2026 +--------+---------------------------------------+----------------+ | CC5-2 | A SIP binding, if specified, is | Transport | | | 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 [RFC7989] as | | | | prior art. | | +--------+---------------------------------------+----------------+ | CC5-3 | The protocol is required to treat an | Dialog | | | 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. | | +--------+---------------------------------------+----------------+ | CC5-4 | When dialog continuity is expected | Dialog | | | 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. | | +--------+---------------------------------------+----------------+ | CC5-5 | The protocol is required to allow an | Authentication | | | agent identity to be conveyed with a | | | | call independently of telephone | | | | number attestation. | | +--------+---------------------------------------+----------------+ | CC5-6 | A recorder receiving media through | Dialog | | | SIPREC is required to be able to | | | | receive the dialog identifier, for | | | | example in recording metadata | | | | [RFC7865], so that recordings can be | | | | associated with the dialog. | | +--------+---------------------------------------+----------------+ Table 5: Dialog across a SIP and PSTN network 4. 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 Howe Expires 28 April 2027 [Page 14] Internet-Draft Contact Center Agent Use Cases October 2026 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 [I-D.ietf-vcon-vcon-core], 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 [I-D.howe-vcon-lawful-basis]. 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 [I-D.agentic-ai-usecases-requirements], 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 [I-D.ietf-vcon-vcon-core]. 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. 5. Security Considerations The security considerations of [I-D.agentic-ai-usecases-requirements] 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. Howe Expires 28 April 2027 [Page 15] Internet-Draft Contact Center Agent Use Cases October 2026 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. 6. 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. Howe Expires 28 April 2027 [Page 16] Internet-Draft Contact Center Agent Use Cases October 2026 7. IANA Considerations This document has no IANA actions. 8. Informative References [G114] ITU-T, "One-way transmission time", ITU-T Recommendation G.114, May 2003. [H323] ITU-T, "Packet-based multimedia communications systems", ITU-T Recommendation H.323, March 2022, . [I-D.agentic-ai-usecases-requirements] Reddy.K, T., Sarker, Z., and K. Yao, "Agentic AI Use Cases and Requirements", Work in Progress, Internet-Draft, draft-agentic-ai-usecases-requirements-04, 15 October 2026, . [I-D.howe-vcon-lawful-basis] McCarthy-Howe, T., "vCon Lawful Basis", Work in Progress, Internet-Draft, draft-howe-vcon-lawful-basis-02, 30 May 2026, . [I-D.ietf-vcon-vcon-core] Petrie, D., "The JSON format for vCon - Conversation Data Container", Work in Progress, Internet-Draft, draft-ietf- vcon-vcon-core-04, 7 September 2026, . [I-D.rosenberg-agentproto-usecases] Rosenberg, J. and C. F. Jennings, "Framework, Use Cases and Requirements for AI Agent Protocols", Work in Progress, Internet-Draft, draft-rosenberg-agentproto- usecases-00, 4 July 2026, . [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, . Howe Expires 28 April 2027 [Page 17] Internet-Draft Contact Center Agent Use Cases October 2026 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, . [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, . [RFC7433] Johnston, A. and J. Rafferty, "A Mechanism for Transporting User-to-User Call Control Information in SIP", RFC 7433, DOI 10.17487/RFC7433, January 2015, . [RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", RFC 7865, DOI 10.17487/RFC7865, May 2016, . [RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. Hutton, "Session Recording Protocol", RFC 7866, DOI 10.17487/RFC7866, May 2016, . [RFC7989] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End- to-End Session Identification in IP-Based Multimedia Communication Networks", RFC 7989, DOI 10.17487/RFC7989, October 2016, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . 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 [I-D.agentic-ai-usecases-requirements]. Howe Expires 28 April 2027 [Page 18] Internet-Draft Contact Center Agent Use Cases October 2026 +==========+=====================================================+ | This | Relationship to the agentproto use cases document | | 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 | New | | others | | +----------+-----------------------------------------------------+ Table 6: Mapping of requirements Author's Address Thomas Howe Vconic Email: thomas@vconic.com Howe Expires 28 April 2027 [Page 19]