sip.js

import { URI } from "../../grammar/uri.js"; import { Body } from "../messages/body.js"; import { IncomingRequestMessage } from "../messages/incoming-request-message.js"; import { IncomingResponseMessage } from "../messages/incoming-response-message.js"; import { OutgoingRequestMessage } from "../messages/outgoing-request-message.js"; import { UserAgentCore } from "../user-agent-core/user-agent-core.js"; import { DialogState } from "./dialog-state.js"; /** * Dialog. * @remarks * A key concept for a user agent is that of a dialog. A dialog * represents a peer-to-peer SIP relationship between two user agents * that persists for some time. The dialog facilitates sequencing of * messages between the user agents and proper routing of requests * between both of them. The dialog represents a context in which to * interpret SIP messages. * https://tools.ietf.org/html/rfc3261#section-12 * @public */ export declare class Dialog { protected core: UserAgentCore; protected dialogState: DialogState; /** * Dialog constructor. * @param core - User agent core. * @param dialogState - Initial dialog state. */ protected constructor(core: UserAgentCore, dialogState: DialogState); /** * When a UAC receives a response that establishes a dialog, it * constructs the state of the dialog. This state MUST be maintained * for the duration of the dialog. * https://tools.ietf.org/html/rfc3261#section-12.1.2 * @param outgoingRequestMessage - Outgoing request message for dialog. * @param incomingResponseMessage - Incoming response message creating dialog. */ static initialDialogStateForUserAgentClient(outgoingRequestMessage: OutgoingRequestMessage, incomingResponseMessage: IncomingResponseMessage): DialogState; /** * The UAS then constructs the state of the dialog. This state MUST be * maintained for the duration of the dialog. * https://tools.ietf.org/html/rfc3261#section-12.1.1 * @param incomingRequestMessage - Incoming request message creating dialog. * @param toTag - Tag in the To field in the response to the incoming request. */ static initialDialogStateForUserAgentServer(incomingRequestMessage: IncomingRequestMessage, toTag: string, early?: boolean): DialogState; /** Destructor. */ dispose(): void; /** * A dialog is identified at each UA with a dialog ID, which consists of * a Call-ID value, a local tag and a remote tag. The dialog ID at each * UA involved in the dialog is not the same. Specifically, the local * tag at one UA is identical to the remote tag at the peer UA. The * tags are opaque tokens that facilitate the generation of unique * dialog IDs. * https://tools.ietf.org/html/rfc3261#section-12 */ get id(): string; /** * A dialog can also be in the "early" state, which occurs when it is * created with a provisional response, and then it transition to the * "confirmed" state when a 2xx final response received or is sent. * * Note: RFC 3261 is concise on when a dialog is "confirmed", but it * can be a point of confusion if an INVITE dialog is "confirmed" after * a 2xx is sent or after receiving the ACK for the 2xx response. * With careful reading it can be inferred a dialog is always is * "confirmed" when the 2xx is sent (regardless of type of dialog). * However a INVITE dialog does have additional considerations * when it is confirmed but an ACK has not yet been received (in * particular with regard to a callee sending BYE requests). */ get early(): boolean; /** Call identifier component of the dialog id. */ get callId(): string; /** Local tag component of the dialog id. */ get localTag(): string; /** Remote tag component of the dialog id. */ get remoteTag(): string; /** Local sequence number (used to order requests from the UA to its peer). */ get localSequenceNumber(): number | undefined; /** Remote sequence number (used to order requests from its peer to the UA). */ get remoteSequenceNumber(): number | undefined; /** Local URI. */ get localURI(): URI; /** Remote URI. */ get remoteURI(): URI; /** Remote target. */ get remoteTarget(): URI; /** * Route set, which is an ordered list of URIs. The route set is the * list of servers that need to be traversed to send a request to the peer. */ get routeSet(): Array<string>; /** * If the request was sent over TLS, and the Request-URI contained * a SIPS URI, the "secure" flag is set to true. *NOT IMPLEMENTED* */ get secure(): boolean; /** The user agent core servicing this dialog. */ get userAgentCore(): UserAgentCore; /** Confirm the dialog. Only matters if dialog is currently early. */ confirm(): void; /** * Requests sent within a dialog, as any other requests, are atomic. If * a particular request is accepted by the UAS, all the state changes * associated with it are performed. If the request is rejected, none * of the state changes are performed. * * Note that some requests, such as INVITEs, affect several pieces of * state. * * https://tools.ietf.org/html/rfc3261#section-12.2.2 * @param message - Incoming request message within this dialog. */ receiveRequest(message: IncomingRequestMessage): void; /** * If the dialog identifier in the 2xx response matches the dialog * identifier of an existing dialog, the dialog MUST be transitioned to * the "confirmed" state, and the route set for the dialog MUST be * recomputed based on the 2xx response using the procedures of Section * 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be * constructed using the procedures of Section 12.1.2. * * Note that the only piece of state that is recomputed is the route * set. Other pieces of state such as the highest sequence numbers * (remote and local) sent within the dialog are not recomputed. The * route set only is recomputed for backwards compatibility. RFC * 2543 did not mandate mirroring of the Record-Route header field in * a 1xx, only 2xx. However, we cannot update the entire state of * the dialog, since mid-dialog requests may have been sent within * the early dialog, modifying the sequence numbers, for example. * * https://tools.ietf.org/html/rfc3261#section-13.2.2.4 */ recomputeRouteSet(message: IncomingResponseMessage): void; /** * A request within a dialog is constructed by using many of the * components of the state stored as part of the dialog. * https://tools.ietf.org/html/rfc3261#section-12.2.1.1 * @param method - Outgoing request method. */ createOutgoingRequestMessage(method: string, options?: { cseq?: number; extraHeaders?: Array<string>; body?: Body; }): OutgoingRequestMessage; /** * Increment the local sequence number by one. * It feels like this should be protected, but the current authentication handling currently * needs this to keep the dialog in sync when "auto re-sends" request messages. * @internal */ incrementLocalSequenceNumber(): void; /** * If the remote sequence number was not empty, but the sequence number * of the request is lower than the remote sequence number, the request * is out of order and MUST be rejected with a 500 (Server Internal * Error) response. * https://tools.ietf.org/html/rfc3261#section-12.2.2 * @param request - Incoming request to guard. * @returns True if the program execution is to continue in the branch in question. * Otherwise a 500 Server Internal Error was stateless sent and request processing must stop. */ protected sequenceGuard(message: IncomingRequestMessage): boolean; }