|
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 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.
| 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 state changes are performed in the
if 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 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.
| Caption |
|---|
| 0 | Figure |
|---|
| 1 | Call Flow Example |
|---|
|
 Image Modified
|
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
continues to use the old IP address for the audio stream.| Caption |
|---|
| 0 | Figure |
|---|
| 1 | Call Flow Example |
|---|
|
Image Modified |
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
replies with 200 (OK), video stream is not created and the new IP address is used for audio.| Caption |
|---|
| 0 | Figure |
|---|
| 1 | Call Flow Example |
|---|
|
Image Modified |
- 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. 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 INVITE/Re-INVITE is challenged for authentication or because the endpoints change Secure Real-Time Transport Protocol (SRTP) keys for every new SDP offer. In these scenarios, the