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 SBC issues a reINVITE 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 SBC sends the ACK to the core side.
6. The SBC issues a reINVITE 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 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 when a reINVITE is Issued after the Modem Tone Session is Established

The following figure shows the call flow when a reINVITE is issued after the modem tone session is established. 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 rejected with 488 Not Acceptable Here.

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 for any reason, including a refresh reINVITE with no change to session version or SDP.
3. The SBC rejects the reINVITE with a 488 Not Acceptable Here response.
4. The call is ended as normal, in this case with BYE and 200 OK on both sides.

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 SBC issues a reINVITE 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 SBC sends the ACK to the core side.
6. The SBC issues a reINVITE 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 SBC sends the ACK to the access side and disconnects the call, sending BYE to both sides.

Note:

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

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 SBC issues a reINVITE 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 SBC sends the ACK to the core side.
6. The SBC issues a reINVITE 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 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 SBC issues a reINVITE 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 SBC sends the ACK to the core side.
6. The SBC issues a reINVITE 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 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 SBC issues a reINVITE 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 SBC sends the ACK to the core side.
6. The SBC issues a reINVITE 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 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 SBC detects VBD tones
• After VBD tones are detected, before the reINVITE is complete on either side, when the newly active 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 SBC issues a reINVITE 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 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 SBC issues a reINVITE 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 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 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 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 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 SBC issues a reINVITE 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 SBC.

6. The newly-active SBC detects VBD tones and resends the reINVITE to the core side.
7. The core side sends a 200 OK with G711A.
8. The 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 SBC issues a reINVITE 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 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 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 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 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 SBC issues a reINVITE 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 SBC, it does not detect any VBD tones within the window configured for the flow guard timer.
3. The newly-active SBC ends the call by sending BYE to both sides.