Dialog.
Signature:
export declare class Dialog 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
| Constructor | Modifiers | Description |
|---|---|---|
| (constructor)(core, dialogState) | Dialog constructor. |
| Property | Modifiers | Type | Description |
|---|---|---|---|
| callId | string | Call identifier component of the dialog id. | |
| core | UserAgentCore | ||
| dialogState | DialogState | ||
| early | boolean | 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). |
|
| id | string | 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 | |
| localSequenceNumber | number | undefined | Local sequence number (used to order requests from the UA to its peer). | |
| localTag | string | Local tag component of the dialog id. | |
| localURI | URI | Local URI. | |
| remoteSequenceNumber | number | undefined | Remote sequence number (used to order requests from its peer to the UA). | |
| remoteTag | string | Remote tag component of the dialog id. | |
| remoteTarget | URI | Remote target. | |
| remoteURI | URI | Remote URI. | |
| routeSet | Array<string> | 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. | |
| secure | boolean | If the request was sent over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to true. *NOT IMPLEMENTED* | |
| userAgentCore | UserAgentCore | The user agent core servicing this dialog. |
| Method | Modifiers | Description |
|---|---|---|
| confirm() | Confirm the dialog. Only matters if dialog is currently early. | |
| createOutgoingRequestMessage(method, options) | 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 | |
| dispose() | Destructor. | |
| initialDialogStateForUserAgentClient(outgoingRequestMessage, incomingResponseMessage) | static |
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 |
| initialDialogStateForUserAgentServer(incomingRequestMessage, toTag, early) | static |
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 |
| receiveRequest(message) | 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. |
|
| recomputeRouteSet(message) | 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. |
|
| sequenceGuard(message) | 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 |