Home > sip.js > Inviter > invite
Sends the INVITE request.
Signature:
invite(options?: InviterInviteOptions): Promise<OutgoingInviteRequest>;| Parameter | Type | Description |
|---|---|---|
| options | InviterInviteOptions |
Returns:
Promise<OutgoingInviteRequest>
TLDR... 1) Only one offer/answer exchange permitted during initial INVITE. 2) No "early media" if the initial offer is in an INVITE (default behavior). 3) If "early media" and the initial offer is in an INVITE, no INVITE forking.
- Only one offer/answer exchange permitted during initial INVITE.
Our implementation replaces the following bullet point...
o After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in requests based on rules specified for that method, but only if it has received answers to any previous offers, and has not sent any offers to which it hasn't gotten an answer. https://tools.ietf.org/html/rfc3261\#section-13.2.1
...with...
o After having sent or received an answer to the first offer, the UAC MUST NOT generate subsequent offers in requests based on rules specified for that method.
...which in combination with this bullet point...
o Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the initial INVITE. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction. https://tools.ietf.org/html/rfc3261\#section-13.2.1
...ensures that EXACTLY ONE offer/answer exchange will occur during an initial out of dialog INVITE request made by our UAC.
- No "early media" if the initial offer is in an INVITE (default behavior).
While our implementation adheres to the following bullet point...
o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. https://tools.ietf.org/html/rfc3261\#section-13.2.1
We have made the following implementation decision with regard to early media...
o If the initial offer is in the INVITE, the answer from the UAS back to the UAC will establish a media session only only after the final 2xx response to that INVITE is received.
The reason for this decision is rooted in a restriction currently inherent in WebRTC. Specifically, while a SIP INVITE request with an initial offer may fork resulting in more than one provisional answer, there is currently no easy/good way to to "fork" an offer generated by a peer connection. In particular, a WebRTC offer currently may only be matched with one answer and we have no good way to know which "provisional answer" is going to be the "final answer". So we have decided to punt and not create any "early media" sessions in this case.
The upshot is that if you want "early media", you must not put the initial offer in the INVITE. Instead, force the UAS to provide the initial offer by sending an INVITE without an offer. In the WebRTC case this allows us to create a unique peer connection with a unique answer for every provisional offer with "early media" on all of them.
- If "early media" and the initial offer is in an INVITE, no INVITE forking.
The default behavior may be altered and "early media" utilized if the initial offer is in the an INVITE by setting the earlyMedia options. However in that case the INVITE request MUST NOT fork. This allows for "early media" in environments where the forking behavior of the SIP servers being utilized is configured to disallow forking.