In this section:
The SBC Core relays the INVITE requests it receives. Egressing INVITE may/may not have SDP depending on presence of SDP in the received INVITE and late offer interworking configuration. TheSBC inserts Allow header containing the following methods: INVITE, ACK, CANCEL, BYE, REGISTER, REFER, INFO, SUBSCRIBE, NOTIFY, PRACK, UPDATE, MESSAGE, PUBLISH and OPTIONS. There are configurable options for the support of REFER, SUBSCRIBE, NOTIFY, OPTIONS, MESSAGE, PUBLISH and INFO, and when these methods are configured as not supported, these methods are not added in the Allow header.
The SBC adds a Supported header containing the following extensions: "100rel", "timer" and "path" extensions. Addition of “100rel”, “timer” and “path” extensions is configurable. As a part of RCS support, SBC relays “Require” header with “recipient-list-invite” option-tag.
The SBC can be configured to transparently pass the “From’ and “To” headers from ingress to egress call-leg. Additionally, for access deployments, the SBC can be configured to use Username in the To header instead of the Request-URI, while terminating calls to IP-PBX.
The SBC supports processing or relaying the ‘replaces header’ received in the incoming SIP request. This done based on the ‘Relay Replaces Header flag’ in SIP service on the SBC. If the SBC is configured to process INVITE with Replaces locally and if the dialog doesn’t exist, the INVITE is rejected with 481 response. the SBC processes INVITE with Replaces locally only on confirmed dialogs.
The SBC supports reception of INVITE with and without SDP Offer.
Even though the SBC sends Allow and Supported headers by default in the outgoing INVITE, it does not discard an incoming INVITE if these headers are NOT present.
The SBC supports up to nine call transfers for a call.
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. This request may be forwarded by proxies, eventually arriving at one or more User Agent Servers (UASs) that can potentially accept the invitation. These UASs will frequently need to query the user about whether to accept the invitation. After some time, those UASs can accept the invitation (meaning the session is to be 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.
Do not use deriveFromOtherLeg
when configuring H.323 or SIP trunk groups to use INVITEs with no SDPs.
Reference: RFC 6141
The SBC does not provide any interworking between an error response and 200 (OK) for a reINVITE.
No state changes are performed in the SBC if a reINVITE is rejected by the downstream entity.
The SBC supports the following UAS behavior for a call which is set up with only an audio stream:
When a reINVITE is received adding a video stream (SDP has both audio and video components), and if the reINVITE is rejected by the downstream entity, the audio stream remains intact and is still active.
When a reINVITE is received adding a video stream and also updating the IP address for the audio stream (SDP has both audio and video components), and if the corresponding reINVITE on the other leg is rejected by the downstream entity, the SBC continues to use the old IP address for the audio stream.
When a reINVITE is received adding a video stream and also updating the IP address for the audio component (SDP has both audio and video components), and if the corresponding reINVITE on the other leg is replied with 200 (OK), but video component has port=0. The SBC replies with 200 (OK), video stream is not created and the new IP address is used for audio.
The SBC does not generate a reINVITE/UPDATE upon receipt of an error response for a reINVITE. It is assumed that downstream entity is RFC6131 compliant and keeps session characteristics the same as before the rejected reINVITE transaction.
The SBC replies with 491 (Request Pending) if a reINVITE is received while a previous one is still pending.
When canceling reINVITES, the SBC always replies with 487 (Request Terminated).
The SBC supports refreshing a dialog's target and its subsections as well as updating remote target based on an unreliable response.