Overview
The
relays the INVITE requests it receives.
Egressing 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.
TheThe inserts
the Allow header containing the following methods:
, , , , , , , , , , , , When the methods and OPTIONS. There are configurable options for the support of REFER, SUBSCRIBE, NOTIFY, OPTIONS, MESSAGE, PUBLISH and INFO, and when these methods INFO are configured as not supported, these methods they are not added in the Allow header.
The
adds a
Supported supported header containing the following extensions: "100rel", "timer" and "path" extensions.
Addition of “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 The
can be configured to
transparently pass the “From’ and “To”
headers headers transparently from ingress to egress call
- leg. Additionally, for access deployments,
you can configure the
can be configured 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
. This done , based on the ‘Relay Replaces
Header flag’ Header’ flag in
the SIP service on the
. If the
is configured to process INVITE with Replaces locally and if the dialog
doesn’t does not exist, the INVITE is rejected with 481 response.
the The processes INVITE
with Replaces with replaces locally only on confirmed dialogs.
The
supports
the reception of INVITE with and without SDP Offer.
- If the INVITE is received with 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 does not contain an without the SDP offer, the it sends the SDP offer in the first reliable 18x or 200 OK response, and the answer is expected in PRACK or ACK method (asappropriate)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.
This request may be forwarded by proxiesThe proxies may forward the request , eventually arriving at one or more User Agent Servers (UASs) that can potentially accept the invitation. These UASs
will frequently need to query queries the user
about whether frequently to accept the invitation
or not. 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.
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
No There are no state changes are performed in the
if if the downstream entity rejects a reINVITE
is rejected by the downstream entity.
The
supports the following UAS behavior for a call which is set up with only an audio stream:
When a reINVITE is received adding with a video stream (SDP has both audio and video components), and if the reINVITE is rejected by the downstream entity rejects the reINVITE , the audio stream remains intact and is still active.
Caption |
---|
0 | Figure |
---|
1 | Call Flow Example |
---|
|
|
- When the receives a reINVITE to add a video stream but does not have enough bandwidth to do so , 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 (e.g. 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 can cause problems if the challenges the INVITE/Re-INVITE is challenged INVITE for authentication or because if the endpoints change Secure Real-Time Transport Protocol (SRTP) keys for every new SDP offer. In these scenarioscases, the updates the SDP in 200 OK itself.
UAC Behavior
The
does not generate a reINVITE/UPDATE
upon on receipt of an error response for a reINVITE.
It is assumed that The assumes that the downstream entity is RFC6131
-compliant and keeps
the session
characteristics the characteristics same as before the rejected reINVITE transaction.
Glare Situations
The
replies with 491 (Request Pending) if
it receives a reINVITE
is received while a previous one is still 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 | Non-reliable 18x with SDP |
---|
|
Image Added |
Caption |
---|
0 | Figure |
---|
1 | Reliable 18x with SDP |
---|
|
Image Added |