Call Flows for Modem Tone Detection

The following call flows illustrate how modem tones are detected and transmitted.

Call Flows that Ignore Modem Tones

There are two scenarios where VBD modem tones are ignored:

• When any of the required configuration parameters are missing.
• When all required configuration parameters are present, but VBD tones are sent before the audio call is connected.

The following figure shows the flow when one or more required configuration parameters are missing from the codec-policy, in any of the following scenarios:

• tone-detection-xcode-only is disabled
• tone-detection-xcode-only is enabled but neither G711AOMD nor G711UOMD is added to add-codecs-on-egress
• tone-detection-xcode-only is enabled, either codec is added to add-codecs-on-egress, but neither modem-orig nor modem-ans is added to tone-detection

In the flow, VBD tones are sent on the core side during an ongoing PCMU session. Because one or more of the configuration parameters are missing, the tones are not detected or sent to the access side.

The following figure shows the flow when the required configurations are present, but the VBD tones are sent before the audio call is connected. The exact configuration details are unimportant in this flow; any time VBD tones are sent before the audio call is connected, the tones are ignored.

Call Flow with Modem Tone Detection Configured on Both Sides

The following figure shows the call flow when the modem tone detection is configured on both sides. The codec-policy configuration parameters for modem tone detection are set as follows:

• On the core side:
  • tone-detection-xcode-only is enabled
  • G711AOMD is included in add-codecs-on-egress.
• On the access side:
  • tone-detection-xcode-only is enabled
  • modem-ans or modem-orig is included in tone-detection
  • Both G711AOMD and G711UOMD are included in add-codecs-on-egress

In this flow:

1. The audio call is established as normal, with transcoding between PCMU and G729.
2. When modem tones are received, sipd receives an event notification from MBCD.
3. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the core side to negotiate the modem tone codec. In this example, G711A is supported on the core side.
4. The core side sends a 200 OK with G711A.
5. The Enterprise SBC sends the ACK to the core side.
6. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the access side to negotiate the modem tone codec. In this example, either G711A or G711U is supported on the core side.
7. The core side sends a 200 OK with G711U.
8. The Enterprise SBC sends the ACK to the access side.
9. The call is switched to a modem call, with transcoding between G711A and G711U VBD tones.
10. Detection of any subsequent modem or fax tones is disabled.
11. The call is ended as normal, with BYE and 200 OK on both sides.

The flow is similar when different combinations of the codecs are included in add-codecs-on-egress on either side.

Call Flow with Back to Back SBCs

The following figure shows the call flow when there are two Enterprise SBCs, SBC01 and SBC02, deployed back to back. SBC02 has modem tone detection enabled and configured, but SBC01 does not.

The exact configuration details are unimportant in this flow; the relevant aspect is that when SBC01 receives a reINVITE with the X-SBC-VBD attribute, it applies modem session optimizations to the reINVITE, transparently forwards it on to the core side, and then activates the session optimizations when it receives the 200 OK.

In this flow:

1. The transcoded RTP session is established as normal. (The figure omits this part of the flow.)
2. When modem tones are received, sipd receives an event notification from MBCD.
3. SBC02 issues a reINVITE (which includes the X-SBC-VBD attribute) to the access side to negotiate the modem tone codec.
4. The access side sends a 200 OK to SBC02.
5. SBC02 issues a reINVITE (which includes the X-SBC-VBD attribute) to SBC01 to negotiate the modem tone codec.
6. SBC01 detects the X-SBC-VBD attribute, adds the optimization details to the reINVITE, and passes it on to the core side.
7. The core side sends a 200 OK back to SBC01.
8. SBC01 applies the optimization settings and passes the 200 OK to SBC02.
9. The call is switched to a modem call.

Call Flow when a reINVITE is Received after Modem Tones are Detected

The following figure shows the call flow when a reINVITE is received after modem tones have been detected. In this example, the session has been established when the reINVITE arrives. The exact configuration details are unimportant in this flow; any time a reINVITE is issued after the modem tone session is in progress, it is passed on transparently, without applying egress coded policies or updating SDP. The endpoints can negotiate any SDP changes.

In this flow:

1. The audio call is established then switched to a modem call as described in the previous section.
2. The core side issues a reINVITE. This example includes changes to SDP, with new codec and signaling information, but the same flow applies for a refresh reINVITE with no change to session version or SDP.
3. The Enterprise SBC transparently passes the reINVITE to the access side, without any changes (does not add the X-SBC-VBD attribute, does not validate SDP, does not apply any egress codec policies.)
4. The access side responds with the 200 OK, including the same SDP.
5. The Enterprise SBC transparently passes the 200 OK on to the core side.

   Although the new SDP did not require negotiation in this flow, the Enterprise SBC transparently handles any negotiations between the core and access.

Call Flow when a reINVITE is Received While Modem Tone Session is Being Established

The following figure shows the call flow when the Enterprise SBC receives a reINVITE while it is still waiting to receive a 200 OK in response to a modem tone reINVITE. The exact configuration details are unimportant in this flow; any time a reINVITE is received when the modem tone reINVITE is pending, the other reINVITE is rejected with a 491 Request Pending message.

This usually triggers a retry timer, after which the sender retires the reINVITE. If the modem tone session has been established when the retried reINVITE is received, the logic applies from the call flow described previously in Call Flow when a reINVITE is Received after Modem Tones are Detected.

In this example, there are two Enterprise SBCs, SBC01 and SBC02, deployed back to back, and both have modem tone detection enabled and configured. This is a likely scenario for the a reINVITE to be issued while session establishment is ongoing. The same behavior would apply if the access or core side issued the reINVITE.

In this flow:

1. The transcoded RTP session is established as normal. (The figure omits this part of the flow.)
2. When modem tones are received, sipd receives an event notification from MBCD on SBC02.
3. SBC02 issues a reINVITE (which includes the X-SBC-VBD attribute) to the access side to negotiate the modem tone codec.
4. Before the access side can reply, SBC01 also detects the modem tone and issues a reINVITE (which includes the X-SBC-VBD attribute) to SBC02.
5. Because it is waiting for a 200 OK for the modem tone negotiation reINVITE, SBC02 rejects the new reINVITE with 491 Request Pending.
6. SBC01 starts a retry timer.
7. The access side sends a 200 OK to SBC02.
8. SBC02 issues a reINVITE (which includes the X-SBC-VBD attribute) to SBC01 to negotiate the modem tone codec.
9. Because SBC01 has detected modem tones and is not awaiting a reply to a reINVITE, SBC01 sends the reINVITE on transparently to the core side.
10. The core side sends a 200 OK to SBC01.
11. SBC01 sends the 200OK to SBC02.

    Because SBC01's retry timer has not yet elapsed, SBC01 has not yet reissued the reINVITE for the VBD session, so is not yet in VBD mode.

12. When the retry timer elapses, SBC01 reissues the reINVITE (which includes the X-SBC-VBD attribute) to SBC02.
13. Because SBC02 has and is not awaiting a reply to a reINVITE, it sends the reINVITE on transparently to the access side.
14. The access side responds with 200 OK to SBC02.
15. SBC02 passes the 200OK on to SBC01.
16. SBC01 issues a reINVITE (which includes the X-SBC-VBD attribute) to the core side to negotiate the modem tone codec.
17. The core side responds with 200 OK, and the modem tone session is established.

If SBC01 was not configured for modem tone detection on the side facing SBC02, it would not detect the modem tones, and the flow would proceed as normal, without any 491 rejection.

Call Flows that Disconnect the Call

There are two flows involving modem tone detection where the call will be disconnected:

• When either side rejects the reINVITE
• When either side fails to respond to the reINVITE before the transaction times out

The following figure shows the call flow when the initial reINVITE to establish the modem tone transmission is rejected. The exact configuration details are unimportant in this flow; any time the reINVITE is rejected, the call is disconnected.

In this flow:

1. The audio call is established as normal, with transcoding between PCMU and G729.
2. When modem tones are received, sipd receives an event notification from MBCD.
3. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the core side to negotiate the modem tone codec. In this example, either G711A or G6711U is supported on the core side.
4. The core side sends a 200 OK with G711A.
5. The Enterprise SBC sends the ACK to the core side.
6. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the access side to negotiate the modem tone codec. In this example, either G711A or G6711U is supported on the access side.
7. The access side sends a 4XX response, rejecting the reINVITE.
8. The Enterprise SBC sends the ACK to the access side and disconnects the call, sending BYE to both sides.

Note:

The same flow applies for any 4XX (except 491), 5XX, 6XX error code response sent in response to the reINVITE, from either side. 491 responses are the exception.

The following figure shows the call flow when the access side does not respond to the reINVITE before the transaction times out. The flow is similar if the core side does not respond. The exact configuration details are unimportant in this flow; any time either side fails to respond to the reINVITE within the configured timeout period, the call is disconnected.

In this flow:

1. The audio call is established as normal, with transcoding between PCMU and G729.
2. When modem tones are received, sipd receives an event notification from MBCD.
3. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the core side to negotiate the modem tone codec. In this example, either G711A or G6711U is supported on the access side.
4. The core side sends a 200 OK with G711A.
5. The Enterprise SBC sends the ACK to the core side.
6. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the access side to negotiate the modem tone codec. In this example, either G711A or G6711U is supported on the access side.
7. The access side does not respond within 30 seconds, and the transaction times out.
8. The Enterprise SBC disconnects the call, sending BYE to both sides.

Call Flow when Modem Tones are Detected but Different Codecs are Negotiated

The following figure shows the call flow when modem tones are detected, but a different codec has priority during the SIP negotiation. The configuration parameters for modem tone detection are set as follows:

• On the core side:
  • tone-detection-xcode-only is enabled
  • PCMU and G711AOMD are included in add-codecs-on-egress parameter
• On the access side:
  • tone-detection-xcode-only is enabled
  • modem-ans is included in tone-detection parameter
  • PCMA and G711AOMD are included in add-codecs-on-egress

In this flow:

1. The audio call is established as normal, with transcoding between PCMU and PCMA.
2. When modem tones are received, sipd receives an event notification from MBCD.
3. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the core side to negotiate the modem tone codec.
4. On the core side, PCMU takes priority, so core sends a 200 OK with PCMU.
5. The Enterprise SBC sends the ACK to the core side.
6. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the access side to negotiate the modem tone codec.
7. On the access side, PCMA takes priority, so core sends a 200 OK with PCMA.
8. The Enterprise SBC sends the ACK to the access side.
9. The call is not switched to a modem call; it continues with PCMU-PCMA transcoding as before. Detection of any subsequent modem or fax tones is disabled.
10. The call is ended as normal, with BYE and 200 OK on both sides.

Call Flow for Multimedia Calls

The following figure shows the call flow for a multimedia call, where the SDP contains multiple m= lines.

The configuration parameters for modem tone detection are set as follows:

• On the core side:
  • tone-detection-xcode-only is enabled
  • PCMU and G711AOMD are included in the add-codecs-on-egress
• On the access side:
  • tone-detection-xcode-only is enabled
  • modem-ans is included in the tone-detection parameter
  • PCMA and G711AOMD are included in the add-codecs-on-egress

In this flow:

1. A transcoded multimedia call with audio and video is established as normal.
2. When modem tones are received, sipd receives an event notification from MBCD.
3. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the core side to negotiate the modem tone codec with the port on the video m-line set to 0, inactivating the video component.
4. The core side sends a 200 OK.
5. The Enterprise SBC sends the ACK to the core side.
6. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the access side to negotiate the modem tone codec with the port on the video m-line set to 0, inactivating the video component.
7. The access side sends a 200 OK.
8. The Enterprise SBC sends the ACK to the access side.
9. The call is switched to a modem call, with VBD tones sent on both sides. The video is inactivated.
10. The call is no longer being transcoded, so the DSP resources are released. Detection of any subsequent modem or fax tones is disabled.
11. The call is ended as normal, with BYE and 200 OK on both sides.

Call Flows for HA

In HA deployments, the flow changes depending on when the switchover from active to standby happens:

• After VBD tones are detected, the reINVITE is complete on both sides, and the modem tone session is established
• After VBD tones are detected, before the reINVITE is complete on either side, when the newly active Enterprise SBC detects VBD tones
• After VBD tones are detected, before the reINVITE is complete on either side, when the newly active Enterprise SBC does not detect VBD tones

The following figure shows the flow when the switchover happens after the VBD reINVITE is complete on both sides. The exact configuration details are unimportant in this flow; any time the switchover happens after the modem tone session is established, the call continues as normal on the newly active machine.

In this flow:

1. The audio call is established as described in previous sections.
2. When modem tones are received, sipd receives an event notification from MBCD.
3. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the core side to negotiate the modem tone codec.
4. The call state in the redundancy journal indicates that the reINVITE has been sent to the caller.
5. The core side sends a 200 OK with G711A.
6. The Enterprise SBC sends the ACK to the core side.
7. The call state in the redundancy journal indicates that the reINVITE been completed by the caller.
8. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the access side to negotiate the modem tone codec.
9. The call state in the redundancy journal indicates that the reINVITE has been sent to the receiver.
10. The access side sends a 200 OK with G711U.
11. The Enterprise SBC sends the ACK to the access side.
12. The call state in the redundancy journal indicates that the reINVITE has completed on both sides.
13. The call is switched to a modem call, with transcoding between G711A and G711U VBD tones.
14. Detection of any subsequent modem or fax tones is disabled.
15. Switchover from active to standby happens.
16. The call continues between core and access sides.
17. The call is ended as normal, with the newly-active Enterprise SBC managing BYE and 200 OK on both sides.

    Note:

    The call could also end in other ways, such as one side issuing a reINVITE, which the newly-active Enterprise SBC would handle with a 488 Not Acceptable Here response.

The following figure shows the call flow when the switchover happens after VBD tones are detected, but before the reINVITE is complete on the access side, when the newly active Enterprise SBC detects VBD tones. The exact configuration details are unimportant in this flow.

In this flow:

1. The audio call is established as described in previous sections.
2. When modem tones are received, sipd receives an event notification from MBCD.
3. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the core side to negotiate the modem tone codec.
4. The call state in the redundancy journal indicates that the reINVITE has been sent to the caller.
5. Switchover from active to standby happens.

   The DSP resources were not released, and modem tone detection remains active on the newly-active Enterprise SBC.

6. The newly-active Enterprise SBC detects VBD tones and resends the reINVITE to the core side.
7. The core side sends a 200 OK with G711A.
8. The Enterprise SBC sends the ACK to the core side.
9. The call state in the redundancy journal indicates that the reINVITE has been completed by the caller.
10. The Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the access side to negotiate the modem tone codec.
11. The call state in the redundancy journal indicates that the reINVITE has been sent to the receiver.
12. The access side sends a 200 OK with G711U.
13. The Enterprise SBC sends the ACK to the access side.
14. The call state in the redundancy journal indicates that the reINVITE has completed on both sides.
15. The call is switched to a modem call, with transcoding between G711A and G711U VBD tones.
16. Detection of any subsequent modem or fax tones is disabled.
17. The call is ended as normal, with the newly-active Enterprise SBC managing BYE and 200 OK on both sides.

    Note:

    The call could also end in other ways, such as one side issuing a reINVITE, which the newly-active Enterprise SBC would handle with a 488 Not Acceptable Here response.

The following figure shows the call flow when the switchover happens after VBD tones are detected, but before the reINVITE is complete on the access side, when the newly active Enterprise SBC does not detect any VBD tones. The exact configuration details are unimportant in this flow.

In this flow:

1. The audio call is established, VBD tones are detected, the Enterprise SBC issues a reINVITE (which includes the X-SBC-VBD attribute) to the core side, and switchover happens as described in the previous section.
2. Although modem tone detection is still enabled on the newly-active Enterprise SBC, it does not detect any VBD tones within the window configured for the flow guard timer.
3. The newly-active Enterprise SBC ends the call by sending BYE to both sides.