INVITE and reINVITE Support

Overview

The SBC Core 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 SBC 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 SBC adds a supported header containing the following extensions: "100rel", "timer" and "path" extensions.which is configurable. As a part of RCS support, SBC relays “Require” header with “recipient-list-invite” option-tag.

You can  configure the SBC  to pass the “From’ and “To” headers  transparently from ingress to egress call leg. Additionally, for access deployments, you can configure the SBC to use Username in the To header instead of the Request-URI, while terminating calls to the IP-PBX.

The SBC 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 SBC. If the SBC is configured to process INVITE with Replaces locally and if the dialog does not exist, the INVITE is rejected with 481 response. The SBC processes INVITE with  replaces locally only on confirmed dialogs.

The SBC supports the reception of INVITE with and without SDP Offer.

• If the SBC receives the INVITE with the SDP offer, the SBC 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 SBC ignores any changes in the SDP when compared with the initial INVITE on receiving the authentication INVITE from the ingress peer.

INVITE Support

The SBC Core 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 SBC 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 SBC if the downstream entity rejects a reINVITE. 

The SBC 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.
  
  Figure 1: Call Flow Example

  
  

• When the SBC 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 SBC continues to use the old IP address for the audio stream.
  
  Figure 2: Call Flow Example

  
  

• When the SBC 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 SBC uses the new IP address for audio.
  
  Figure 3: Call Flow Example

  
  

• When the SBC receives a reINVITE to add a video stream but does not have enough bandwidth , the SBC generates a 200 (OK) response with port=0 for video stream.
  
  
• The SBC 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 SBC 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 SBC 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 SBC updates the SDP in 200 OK itself.

UAC Behavior

The SBC does not generate a reINVITE/UPDATE on receipt of an error response for a reINVITE. The SBC assumes that the downstream entity is RFC6131-compliant and keeps the session characteristics  same as before the rejected reINVITE transaction.

Glare Situations

The SBC 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 SBC always replies with 487 (Request Terminated).

Refreshing a Dialog’s Target and its Subsections

The SBC 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 SBC 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 SBC (UAS) sends the answer in non-reliable provisional response to the INVITE , and  Send SDP in Subsequent 18x  is enabled, the SBC 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.

Figure 4: Non-reliable 18x with SDP

Figure 5: Reliable 18x with SDP