UNPKG

sip.js

Version:

A SIP library for JavaScript

47 lines (46 loc) 2.32 kB
import { IncomingResponseMessage } from "../messages/incoming-response-message.js"; import { OutgoingRequestMessage } from "../messages/outgoing-request-message.js"; import { Transport } from "../transport.js"; import { Transaction } from "./transaction.js"; import { TransactionState } from "./transaction-state.js"; import { ClientTransactionUser } from "./transaction-user.js"; /** * Client Transaction. * @remarks * The client transaction provides its functionality through the * maintenance of a state machine. * * The TU communicates with the client transaction through a simple * interface. When the TU wishes to initiate a new transaction, it * creates a client transaction and passes it the SIP request to send * and an IP address, port, and transport to which to send it. The * client transaction begins execution of its state machine. Valid * responses are passed up to the TU from the client transaction. * https://tools.ietf.org/html/rfc3261#section-17.1 * @public */ export declare abstract class ClientTransaction extends Transaction { private _request; protected user: ClientTransactionUser; protected constructor(_request: OutgoingRequestMessage, transport: Transport, user: ClientTransactionUser, state: TransactionState, loggerCategory: string); private static makeId; /** The outgoing request the transaction handling. */ get request(): OutgoingRequestMessage; /** * A 408 to non-INVITE will always arrive too late to be useful ([3]), * The client already has full knowledge of the timeout. The only * information this message would convey is whether or not the server * believed the transaction timed out. However, with the current design * of the NIT, a client cannot do anything with this knowledge. Thus, * the 408 is simply wasting network resources and contributes to the * response bombardment illustrated in [3]. * https://tools.ietf.org/html/rfc4320#section-4.1 */ protected onRequestTimeout(): void; /** * Receive incoming responses from the transport which match this transaction. * Responses will be delivered to the transaction user as necessary. * @param response - The incoming response. */ abstract receiveResponse(response: IncomingResponseMessage): void; }