Overview
The
relays the INVITE requests it receives. The Egress INVITE may or may not have the SDP depending on the presence of SDP in the received INVITE and late offer interworking configuration. The
inserts the
Allow header containing the following methods:
- INVITE
- ACK
- CANCEL
- BYE
- REGISTER
- REFER
- INFO
- SUBSCRIBE
- NOTIFY
- PRACK
- UPDATE
- MESSAGE
- PUBLISH
- OPTIONS
When the methods REFER, SUBSCRIBE, NOTIFY, OPTIONS, MESSAGE, PUBLISH, and INFO are configured as not supported, they are not added in the Allow header.
The
adds a supported header containing the following extensions: "100rel", "timer" and "path" extensions.which is configurable. As a part of RCS support,
relays “Require” header with “recipient-list-invite” option-tag.
You can configure the
to pass the “From’ and “To” headers transparently from ingress to egress call leg. Additionally, for access deployments, you can configure the
to use Username in the To header instead of the Request-URI, while terminating calls to the IP-PBX.
The
supports processing or relaying the ‘replaces header’ received in the incoming SIP request, based on the ‘Relay Replaces Header’ flag in the SIP service on the
. If the
is configured to process INVITE with Replaces locally and if the dialog does not exist, the INVITE is rejected with 481 response. The
processes INVITE with replaces locally only on confirmed dialogs.
The
supports the reception of INVITE with and without SDP Offer.
- If the receives the INVITE with the SDP offer, the sends the SDP Answer in the first reliable provisional response or in the success final response.
- If the SBC receives the initial INVITE without the SDP offer, it sends the SDP offer in the first reliable 18x or 200 OK response, and the answer is expected in PRACK or ACK method (as appropriate). The ignores any changes in the SDP when compared with the initial INVITE on receiving the authentication INVITE from the ingress peer.
| Info |
|---|
|
Even though the sends Allow and Supported headers by default in the outgoing INVITE, it does not discard an incoming INVITE if these headers are NOT present. |
| Include Page |
|---|
| _call_transfer_for_a_call |
|---|
| _call_transfer_for_a_call |
|---|
|
INVITE Support
The
supports sending SIP INVITE requests to establish VoIP calls. When a User Agent Client (UAC) desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request. The INVITE request asks a server to establish a session. The proxies may forward the request , eventually arriving at one or more User Agent Servers (UASs) that can potentially accept the invitation. These UASs queries the user frequently to accept the invitation or not. After some time, those UASs can accept the invitation (meaning the session is established) by sending a 2xx response.
If the invitation is not accepted, a 3xx, 4xx, 5xx, or 6xx response is sent, depending on the reason for the rejection. Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user.
Sending an INVITE request within an existing dialog to change addresses or ports, add or delete a media stream, and so forth is known as a re-INVITE.
| Include Page |
|---|
| _DeriveFromOtherLeg limitation |
|---|
| _DeriveFromOtherLeg limitation |
|---|
|
reINVITE Handling
The
does not provide any interworking between an error response and 200 (OK) for a reINVITE.
reINVITE Handling by UAS
There are no state changes in the
if the downstream entity rejects a reINVITE.
The
supports the following UAS behavior for a call which is set up with only an audio stream:
- 0
When the
receives a reINVITE with a video stream and the updated IP address for the audio component (SDP has both audio and video components), and replies to the corresponding reINVITE on the other leg with 200 (OK) with video component as port=0, the video stream is not created and the uses the new IP address for audio.| Caption |
|---|
Figure
1 | 3: Call Flow Example
Image Removed
Image Added
- When the receives a reINVITE to add a video stream but does not have enough bandwidth , the generates a 200 (OK) response with port=0 for video stream.
- The does not propagate a reINVITE/UPDATE to the other leg if it does not change any characteristics (For example, codec, digit transfer mode) in the existing streams on the other leg.
- When an egress server changes the SDP from 18x message to 200 OK message (which is a violation of RFC 3261), the interworks by sending the last sent SDP in 200 OK and then sends a RE-INVITE to correct the SDP. This Re-INVITE cause problems if the challenges the INVITE/Re-INVITE for authentication or if the endpoints change Secure Real-Time Transport Protocol (SRTP) keys for every new SDP offer. In these cases, the updates the SDP in 200 OK itself.
UAC Behavior
The
does not generate a reINVITE/UPDATE on receipt of an error response for a reINVITE. The
assumes that the downstream entity is RFC6131-compliant and keeps the session characteristics same as before the rejected reINVITE transaction.
Glare Situations
The
replies with 491 (Request Pending) if it receives a reINVITE when the previous reINVITE is pending.
Clarifications on Canceling re-INVITEs
When canceling the reINVITES, the
always replies with 487 (Request Terminated).
Refreshing a Dialog’s Target and its Subsections
The
supports refreshing a dialog's target and its subsections as well as updating the remote target based on an unreliable response.
Non-reliable provisional response to the INVITE
RFC 6377 requires that, after the
sends an answer in a
reliable provisional response to an INVITE, it does not include any Session Description Protocol (SDP) in subsequent responses to the INVITE.
However, after the
(UAS) sends the answer in non-reliable provisional response to the INVITE , and
Send SDP in Subsequent 18x is enabled, the
resends the SDP in all the subsequent 18x to maximize the possibility for SDP reception.
The call flow depicts the reliable and non-reliable 18x with the SDP call flow.
| Caption |
|---|
| 0 | Figure |
|---|
1 | Figure 4: Non-reliable 18x with SDP
Image Modified| Caption |
|---|
0Figure
1 | 5: Reliable 18x with SDP
Image Modified
