Home > sip.js > SessionDialog
Session Dialog.
Signature:
export declare class SessionDialog extends Dialog implements Session Extends: Dialog
Implements: Session
| Constructor | Modifiers | Description |
|---|---|---|
| (constructor)(initialTransaction, core, state, delegate) | Constructs a new instance of the SessionDialog class |
| Property | Modifiers | Type | Description |
|---|---|---|---|
| answer | Body | undefined | The current answer. Undefined unless signaling state Stable. | |
| delegate | SessionDelegate | undefined | ||
| offer | Body | undefined | The current offer. Undefined unless signaling state HaveLocalOffer, HaveRemoteOffer, of Stable. | |
| reinviteUserAgentClient | ReInviteUserAgentClient | undefined | ||
| reinviteUserAgentServer | ReInviteUserAgentServer | undefined | ||
| sessionState | SessionState | ||
| signalingState | SignalingState | The state of the offer/answer exchange. |
| Method | Modifiers | Description |
|---|---|---|
| ack(options) | The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE. If the 2xx contains an offer (based on the rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately. https://tools.ietf.org/html/rfc3261\#section-13.2.2.4 | |
| bye(delegate, options) | Terminating a Session This section describes the procedures for terminating a session established by SIP. The state of the session and the state of the dialog are very closely related. When a session is initiated with an INVITE, each 1xx or 2xx response from a distinct UAS creates a dialog, and if that response completes the offer/answer exchange, it also creates a session. As a result, each session is "associated" with a single dialog - the one which resulted in its creation. If an initial INVITE generates a non-2xx final response, that terminates all sessions (if any) and all dialogs (if any) that were created through responses to the request. By virtue of completing the transaction, a non-2xx final response also prevents further sessions from being created as a result of the INVITE. The BYE request is used to terminate a specific session or attempted session. In this case, the specific session is the one with the peer UA on the other side of the dialog. When a BYE is received on a dialog, any session associated with that dialog SHOULD terminate. A UA MUST NOT send a BYE outside of a dialog. The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs. However, the callee's UA MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out. If no SIP extensions have defined other application layer states associated with the dialog, the BYE also terminates the dialog. https://tools.ietf.org/html/rfc3261\#section-15 FIXME: Make these proper Exceptions... |
|
| confirm() | Confirm the dialog. Only matters if dialog is currently early. | |
| dispose() | ||
| info(delegate, options) | An INFO request can be associated with an Info Package (see Section 5), or associated with a legacy INFO usage (see Section 2). The construction of the INFO request is the same as any other non-target refresh request within an existing invite dialog usage as described in Section 12.2 of RFC 3261. https://tools.ietf.org/html/rfc6086\#section-4.2.1 |
|
| invite(delegate, options) | Modifying an Existing Session A successful INVITE request (see Section 13) establishes both a dialog between two user agents and a session using the offer-answer model. Section 12 explains how to modify an existing dialog using a target refresh request (for example, changing the remote target URI of the dialog). This section describes how to modify the actual session. This modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE. Note that a single re-INVITE can modify the dialog and the parameters of the session at the same time. Either the caller or callee can modify an existing session. https://tools.ietf.org/html/rfc3261\#section-14 |
|
| message(delegate, options) | A UAC MAY associate a MESSAGE request with an existing dialog. If a MESSAGE request is sent within a dialog, it is "associated" with any media session or sessions associated with that dialog. https://tools.ietf.org/html/rfc3428\#section-4 | |
| notify(delegate, options) | The NOTIFY mechanism defined in [2] MUST be used to inform the agent sending the REFER of the status of the reference. https://tools.ietf.org/html/rfc3515\#section-2.4.4 | |
| prack(delegate, options) | Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition. https://tools.ietf.org/html/rfc3262\#section-4 | |
| 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. https://tools.ietf.org/html/rfc3261\#section-12.2.2 | |
| reConfirm() | Re-confirm the dialog. Only matters if handling re-INVITE request. | |
| refer(delegate, options) | REFER is a SIP request and is constructed as defined in [1]. A REFER request MUST contain exactly one Refer-To header field value. https://tools.ietf.org/html/rfc3515\#section-2.4.1 | |
| reliableSequenceGuard(message) | Guard against out of order reliable provisional responses and retransmissions. Returns false if the response should be discarded, otherwise true. | |
| signalingStateRollback() | If not in a stable signaling state, rollback to prior stable signaling state. | |
| signalingStateTransition(message) | Update the signaling state of the dialog. |