Simple Complete Server Reroute Operation

The image below is a simple call flow depicting the SBC responding to media loss from a callee and rerouting the call the next SA in the SAG.

When the SBC detects RTP loss due to media inactivity timer expiry on the callee side, the SBC terminates the call with the callee and initiates a new call with the next SA it finds in the SAG configured in the original SA's reroute-server parameter.

After the call with the new SA is established, SBC sends a reINVITE to the caller to provide the media IP/port allocated from the steering pool for the new media flows. The SBC uses the last negotiated SDP with the caller. It also updates the media IP/port and session version number in this SDP without consulting the egress codec-policy configured on caller’s realm.

Handling Caller 4xx within Server Reroute Operation

This next call flow contrasts the behaviors between call issues on the callee and caller side. As depicted, RTP loss on the callee side generates a reINVITE. In addition, a 4xx reply from the callee side generates another reINVITE. A 4xx reply from the caller, however, results in the SBC terminating the call.

As depicted above, the SBC attempts a call for which media from the callee stops. The SBC responds to this media loss by issuing a BYE towards the first callee and sending a new INVITE to a reroute server in the applicable SAG. This SA responds with a 4xx, triggering the SBC to try to reach a third SA in the SAG. After that attempt, however, the caller responds with a 4xx. This feature is not intended to manage the 4xx issue from the caller, so the SBC terminates the call entirely.

Handling Caller ReINVITE within Server Reroute Operation

This next call flow shows the SBC successfully re-establishing a call despite an interim reINVITE from the caller.

The call flow proceeds like the previous one, except with a reINVITE from the caller while rerouting a call to SA3. In this flow, SA2 issues a 4xx, and the SBC reroutes the call to SA3. While waiting for SA3 to respond, the caller issues a reINVITE, which the SBC handles outside of the scope of rerouting. The 491 request pending message supports the caller's reINVITE successfully, and, independently, the SA3 accepts the reroute server call. The caller's reINVITE does not impact the rerouting and the SBC connects the caller and SA3 transparently.

Handling 3xx Redirect within Server Reroute Operation

This next call flow mixes rerouting with 3xx redirect support from SA2. In this case, reroute ultimately succeeds in re-establishing the call.

This call flow proceeds like the previous ones, with the SBC detecting RTP loss and rerouting to SA2. In this case, however, SA2 responds with a 3xx redirect. The SBC transparently handles the reroute, finding SA3 by the redirect instead of the SAG. As described in the call flow, the 3xx redirect may supply multiple alternate targets. The SBC may successfully reach one of those targets and set up the call with the caller. If all of the 3xx targets fail, the SBC returns to the reroute server SAG to contact the next SA in the SAG list. Either means of contacting SA3 results in a successful reroute procedure.