Call Flows for Rerouting on Broken RTP

This topic provides call flows to help clarify how calls are rerouted on when RTP media loss is detected.

Simple Complete Server Reroute Operation

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

When the Enterprise SBC detects RTP loss due to media inactivity timer expiry on the callee side, the Enterprise 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, Enterprise SBC sends a reINVITE to the caller to provide the media IP/port allocated from the steering pool for the new media flows. The Enterprise 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 Enterprise SBC attempts a call for which media from the callee stops. The Enterprise 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 Enterprise 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 Enterprise SBC terminates the call entirely.

Handling Caller ReINVITE within Server Reroute Operation

This next call flow shows the Enterprise 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 Enterprise SBC reroutes the call to SA3. While waiting for SA3 to respond, the caller issues a reINVITE, which the Enterprise 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 Enterprise 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 Enterprise SBC detecting RTP loss and rerouting to SA2. In this case, however, SA2 responds with a 3xx redirect. The Enterprise 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 Enterprise SBC may successfully reach one of those targets and set up the call with the caller. If all of the 3xx targets fail, the Enterprise 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.