Resultant INVITE Traversing Device

The device can handle SIP 3xx responses so that the new INVITE message sent as a result of the 3xx traverses the device. The reasons for enforcing resultant INVITEs to traverse the device may vary:

■

The user that receives the 3xx is unable to route to the 3xx contact (i.e., the user is on the LAN and the new contact is on the WAN). In such a scenario, the device enables the user to reach the WAN contact and overcome NAT problems.

■

Enforce certain SBC policies (e.g., call admission control, header manipulation) on the resultant INVITE.

The device enforces this by modifying each Contact in the 3xx response as follows:

■

Changes the host part to the device's IP address – this change causes the remote user agent to send the INVITE to the device.

■

Adds a special prefix ("T~&R_") to the Contact user part – to identify the new INVITE as a 3xx resultant INVITE.

The SBC handling for the 3xx resultant INVITE is as follows:

1.

The incoming INVITE is identified as a 3xx resultant INVITE according to the special prefix.

2.

The device automatically replaces the SBC host part (in the Request-URI) with the host from the 3xx Contact.

3.

The prefix ("T~&R_") remains in the user part for the classification, manipulation, and routing mechanisms.

4.

The classification, manipulation, and routing processes are done exactly like any other INVITE handling. The special prefix can be used for specific routing rules for 3xx resultant INVITEs.

5.

The prefix is removed before the resultant INVITE is sent to the destination.

The process of this feature is described using an example:

1.

The device receives the Redirect server's SIP 3xx response (e.g., Contact: <sip:User@IPPBX:5060;transport=tcp;param=a>;q=0.5).

2.

The device replaces the Contact header value with the special prefix and database key value as user part, and with the device's URL as host part (e.g., Contact: <sip:Prefix_Key_User@SBC:5070;transport=udp>;q=0.5).

3.

The device sends this manipulated SIP 3xx response to the Far-End User (FEU).

4.

The FEU sends a new request with the Request-URI set to the value of the received 3xx response's Contact header (e.g., RequestURI: sip:Prefix_Key_User@SBC:5070;transport=udp).

5.

Upon receipt of the new request from the FEU, the device replaces the Request-URI with the new destination address (e.g., RequestURI: sip:Prefix_User@IPPBX:5070;transport=tcp;param=a).

6.

The device removes the user prefix from the Request-URI, and then sends this Request-URI to the new destination (e.g., RequestURI: sip:User@IPPBX:5070;transport=tcp;param=a).