INVITE and reINVITE Support

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
  Unable to show "metadata-from": No such page "_space_variables"
  receives the INVITE with the SDP offer, the 
  Unable to show "metadata-from": No such page "_space_variables"
  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
  Unable to show "metadata-from": No such page "_space_variables"
  ignores any changes in the SDP when compared with the initial INVITE on receiving the authentication INVITE from the ingress peer.

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.

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:

• When a reINVITE is received with a video stream (SDP has both audio and video components), and if the downstream entity rejects the reINVITE , the audio stream remains intact and is still active.

  Call Flow Example

  

• When the 

  Unable to show "metadata-from": No such page "_space_variables"
  receives the reINVITE with a video stream and the updated IP address for the audio stream (SDP has both audio and video components), and if the downstream entity rejects the corresponding reINVITE on the other leg, the 
  Unable to show "metadata-from": No such page "_space_variables"
  continues to use the old IP address for the audio stream.

  Call Flow Example

  

• When the 

  Unable to show "metadata-from": No such page "_space_variables"
  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 
  Unable to show "metadata-from": No such page "_space_variables"
  uses the new IP address for audio.

  Call Flow Example

  

• When the
  Unable to show "metadata-from": No such page "_space_variables"
  receives a reINVITE to add a video stream but does not have enough bandwidth , the 
  Unable to show "metadata-from": No such page "_space_variables"
  generates a 200 (OK) response with port=0 for video stream.
  
  
• The
  Unable to show "metadata-from": No such page "_space_variables"
  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 
  Unable to show "metadata-from": No such page "_space_variables"
  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
  Unable to show "metadata-from": No such page "_space_variables"
  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 
  Unable to show "metadata-from": No such page "_space_variables"
   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.