Home > sip.js > InviteClientTransaction
INVITE Client Transaction.
Signature:
export declare class InviteClientTransaction extends ClientTransaction Extends: ClientTransaction
The INVITE transaction consists of a three-way handshake. The client transaction sends an INVITE, the server transaction sends responses, and the client transaction sends an ACK. https://tools.ietf.org/html/rfc3261\#section-17.1.1
| Constructor | Modifiers | Description |
|---|---|---|
| (constructor)(request, transport, user) | Constructor. Upon construction, the outgoing request's Via header is updated by calling setViaHeader. Then toString is called on the outgoing request and the message is sent via the transport. After construction the transaction will be in the "calling" state and the transaction id will equal the branch parameter set in the Via header of the outgoing request. https://tools.ietf.org/html/rfc3261\#section-17.1.1 |
| Property | Modifiers | Type | Description |
|---|---|---|---|
| kind | string | Transaction kind. Deprecated. |
| Method | Modifiers | Description |
|---|---|---|
| ackResponse(ack) | ACK a 2xx final response. The transaction includes the ACK only if the final response was not a 2xx response (the transaction will generate and send the ACK to the transport automagically). If the final response was a 2xx, the ACK is not considered part of the transaction (the transaction user needs to generate and send the ACK). This library is not strictly RFC compliant with regard to ACK handling for 2xx final responses. Specifically, retransmissions of ACKs to a 2xx final responses is handled by the transaction layer (instead of the UAC core). The "standard" approach is for the UAC core to receive all 2xx responses and manage sending ACK retransmissions to the transport directly. Herein the transaction layer manages sending ACKs to 2xx responses and any retransmissions of those ACKs as needed. |
|
| dispose() | Destructor. | |
| onTransportError(error) | The client transaction SHOULD inform the TU that a transport failure has occurred, and the client transaction SHOULD transition directly to the "Terminated" state. The TU will handle the failover mechanisms described in [4]. https://tools.ietf.org/html/rfc3261\#section-17.1.4 | |
| receiveResponse(response) | Handler for incoming responses from the transport which match this transaction. | |
| typeToString() | For logging. |