[Resolved] *98 does not access voicemail, or voicemail does not respond to DTMF tones

[Kwyjor]

Since my phone line resumed operation after yesterday's outage, I get a stutter tone before dialing a number. I presume that, as per viewtopic.php?p=82218 , this means someone attempted to leave me a voicemail while the line was down. (I normally have an answering machine that I'm perfectly happy with.)

At this point my primary concern is making the annoying stutter tone go away.

Dialing *98 does not access voicemail and only produces an error tone, i.e. like one would get after leaving the phone off the hook for too long. I might guess that *98 is reserved somehow by my Mediatrix ATA box.

Fortunately I have Mizudroid on my smartphone as an alternative. Placing a call to *98 on Mizudroid brings up my voicemail, and I can press 1 to listen to the message. (It is a few seconds of silence.) Unfortunately, after pressing 1, the voicemail ceases to be responsive and I can neither delete the message or use any of the other menu functions.

I tried holding the speaker of my cordless phone up to the microphone on my smartphone and pressing the 7 key, but that yields no result.

Is there a solution here that I am overlooking?

[Liptonbrisk]

(I normally have an answering machine that I'm perfectly happy with.)

There's no way to completely avoid Freephoneline's voicemail system. When your ATA is offline, not registered, or if there's a problem with the proxy server being used (voip.freephoneline.ca, for example) incoming calls will go straight to Freephoneline's voicemail system. Failover is Freephoneline's voicemail system.

I'm in the middle of something at the moment. You can check and delete voicemail here in the interim: login at https://www.freephoneline.ca/mailbox.

[Kwyjor]

You can check and delete voicemail here in the interim: login at https://www.freephoneline.ca/mailbox.

Oh geez. I'd hoped I wasn't overlooking something so obviously apparent. How embarrassing. Thank you.

I've gone this long being blissfully unaware of voicemail and I doubt it will be a problem again, though I am a little curious about what the other solutions may be.

[Liptonbrisk]

Dialing *98 does not access voicemail and only produces an error tone, i.e. like one would get after leaving the phone off the hook for too long. I might guess that *98 is reserved somehow by my Mediatrix ATA box.

I can't say I'm having an easy time trying to find relevant information in the manual: https://archive.org/details/manualzilla ... 1/mode/2up (possibly because I'm pretty tired, my eyes are blurry, and I'm unfamiliar with your ATA)

I'm not sure. Let's trying something like this:

1) Click on the main "Telephony" menu item in the top navigation bar. Once you are in the "Telephony" section, look for a sub-menu or tab on the left or within the main content area. It will most likely be called "Digit Maps" (as per Chapter 18 of the manual) or possibly "Dial Plan". Click on it.

2) Enter Your Dial Plan.

On the Digit Maps configuration page, find the section for "Allowed Digit Maps".
In the primary field for the allowed plan, carefully paste this (don't copy extra blank spaces):

Code: Select all

([2345689]11|988|*98|[2-9]xxxxxxxxx|1[2-9]xxxxxxxxx|011x.#)

3) Ensure this rule is "Enabled".

4) Navigate to Check Internal Codes. Still likely within the main "Telephony" menu section, look for sub-menus named "Subscriber Services", "Telephony Features", or potentially "Feature Codes". Click into these sections.

5) Check for a *98 internal conflict. Look through the lists of internal features (such as Call Forward, Call Waiting codes shown in Chapter 20).
Verify that *98 is NOT assigned as the activation code for any internal ATA feature. If it is assigned, you must disable that specific feature or change its activation code (if possible) to something else (*97 maybe) to avoid the conflict. If *98 is not listed for internal features, then, theoretically, you're okay.

6) Navigate to DTMF Settings. Still likely within the main "Telephony" menu section, look for sub-menus related to media or voice configuration. Common names include "Media", "Voice", "Codec Settings", or specifically "DTMF".

7) Set DTMF Transport Method. Find the setting labeled "DTMF Transport Method", "DTMF Mode", or similar (corresponding to MIB voiceIfDtmfTransport). Select the option for RFC 2833. This might be explicitly named "RFC2833" or described as "RTP Payload" or "Out of Band using RTP". Make sure this specific method is selected.

8) Save Changes. Click the "Apply" or "Save" button on each page where you made modifications (Digit Maps, possibly Subscriber Services, DTMF/Media).

9) Reboot the ATA. Navigate to the "Reboot" tab (visible under the "SIP" menu or possibly under an "Administration" / "System" main menu) and restart the Mediatrix 2102 to ensure all settings are applied correctly. Alternatively, if the option doesn't exist, you can probably just power cycle (turn off and on) the ATA.

[Liptonbrisk]

By the way, I would enable voicemail to email if you haven't done so yet: https://support.freephoneline.ca/hc/art ... l-to-Email. I use the "Copy" option to ensure I don't lose the original voicemail message if there's an email issue.

[Liptonbrisk]

Code: Select all

([2345689]11|988|*98|[2-9]xxxxxxxxx|1[2-9]xxxxxxxxx|011x.#)

The purpose of a dial plan (or "Digit Map" as the manual calls it) is to tell your VoIP adapter (the Mediatrix 2102) what sequences of dialed digits are valid phone numbers and when it should send the call out.

The entire string is enclosed in parentheses () and uses the pipe | symbol to separate different possible dialing patterns. The ATA will try to match the digits you dial against each pattern separated by the |, using the first complete match it finds.

Here's what each pattern means:

1) [2345689]11
[2345689] matches a single digit that must be one of the characters inside the brackets: 2, 3, 4, 5, 6, 8, or 9.

11 matches the literal digits 11.

This allows you to dial 3-digit service codes like 211 (community info), 311 (city services), 411 (directory assistance), 511 (traffic/travel info), 611 (telco support), 811 (health line/dig safe), and 911 (emergency). The ATA will send the call immediately after you dial the third digit.

2) 988
Matches the literal digits 9, 8, 8.

Allows dialing the 3-digit code 988, which is the National Suicide Prevention Lifeline in North America. The call is sent immediately after the third digit.

3) *98

* matches the literal star symbol *.

98 matches the literal digits 98.

Allows dialing *98, the code you typically use to access your Freephoneline voicemail. The call is sent immediately after you dial the 8.

4) [2-9]xxxxxxxxx

[2-9] matches a single digit that must be in the range 2 through 9.

xxxxxxxxx matches nine occurrences of x. The x character is a wildcard matching any single digit from 0 to 9.

This permits dialing standard 10-digit North American phone numbers (Area Code + Exchange + Number), where the area code doesn't start with 0 or 1. The call is sent immediately after the 10th digit.

5) 1[2-9]xxxxxxxxx

1 matches the literal digit 1.
[2-9]xxxxxxxxx matches a 10-digit number as described above.

This allows dialing 11-digit North American numbers (1 + Area Code + Exchange + Number), typically used for long distance or some mobile calls. The call is sent immediately after the 11th digit.

6) 011x.#

011 matches the literal digits 011, which is the standard prefix for dialing internationally from North America.
x matches any digit 0-9 followed by . (zero or more occurrences of the preceding element, which is x). Basically, x. means one or more digits.

# matches the literal hash symbol #.

This allows dialing international numbers. You dial 011, followed by the country code and the rest of the number (which must be at least one digit long), and then you must press the # key to signal the end of the number. The call is sent immediately after you press #, avoiding the potential timeout delay (waiting for more digits to be pressed).

Ultimately, this dial plan should allow your Mediatrix 2102 to correctly recognize and immediately dial common North American number formats (service codes, 10-digit, 1+10 digit), your voicemail code (*98), the 988 hotline, and international numbers (when you signal the end by pressing #).

Granted, I'm guessing this works, I suppose, since I can't test.

[Liptonbrisk]

Also, ensure G.711u codec is used when possible, which sounds better than G.729a. Freephoneline doesn't support any other audio codecs.

Chapter 12 - Voice Transmissions: This chapter details the voice codecs supported by the ATA.
Page 147
https://archive.org/details/manualzilla ... 1/mode/2up

This page contains Table 97 ("Enabling Voice Codecs") which lists the MIB variables like voiceIfCodecPcmuEnable (for G.711u) and voiceIfCodecG729Enable. It also describes the voiceIfCodecPreferred variable for setting the preferred codec.

1) Click on the main "Telephony" menu item in the top navigation bar.

2) Find Codec Settings. Look for a sub-menu related to voice codecs or media configuration, possibly called "Media", "Voice", or "Codec Settings". Click on it.

Configure Codec Enable/Disable Status.

a) Find the list of available voice codecs.
b) Ensure G.711u (PCMU) is set to Enabled.
c) Ensure G.729 is also set to Enabled.
e) Ensure G.711a (PCMA) is set to Disabled.
f) Ensure G.723.1 is set to Disabled. (This configuration keeps both FPL-supported codecs active but removes others that might cause issues).

3) Set Preferred Codec.
Locate the setting labelled "Preferred Codec" (or similar).
From the dropdown list for this setting, select PCMU (or G.711u). This tells the ATA to offer G.711u first during call negotiation.

4) Save Changes. Click the "Apply" or "Save" button on the codec configuration page.

5) Reboot the ATA or power cycle it.

This setup should help ensure your Mediatrix 2102 will always try to use the higher-quality G.711u codec first when making or receiving calls via Freephoneline, but it still has G.729 available as a backup if needed. More importantly, the G.711u audio codec being prioritized matters if we want to try Inband DTMF later. Plus, the G.729a audio codec sounds inferior.

[Kwyjor]

I can't saying I'm having an easy time trying to find relevant information in the manual: https://archive.org/details/manualzilla ... 1/mode/2up (possibly because I'm pretty tired, my eyes are blurry, and I'm unfamiliar with your ATA)

I truly appreciate your willingness to delve into such a triviality. I thought it would be something more obvious than that.

2) Enter Your Dial Plan:

On the Digit Maps configuration page, find the section for "Allowed Digit Maps".
In the primary field for the allowed plan, carefully paste this (don't copy extra blank spaces):

Code: Select all

([2345689]11|988|*98|[2-9]xxxxxxxxx|1[2-9]xxxxxxxxx|011x.#)

3) Ensure this rule is "Enabled".

That did the trick. I saved settings and rebooted, and *98 worked normally, including all the menus.

I did not see any other assignments for *98 in any of the menus.

6) Navigate to DTMF Settings. Still likely within the main "Telephony" menu section, look for sub-menus related to media or voice configuration. Common names include "Media", "Voice", "Codec Settings", or specifically "DTMF".

As per my first message, the DTMF issue is a separate issue with MizuDroid. MizuDroid does offer quite the range of options:


Alas, selecting NTE (RFC 2833 / RFC 4733) instead of "Auto" still does not enable the voicemail menu to function beyond the first keypress. I am mildly concerned that this could be a problem with a wider variety of menus beyond this particular voicemail provider, but then I don't expect to be making much use of this feature. It could very well just be a bug in the software.

[Liptonbrisk]

That did the trick. I saved settings and rebooted, and *98 worked normally, including all the menus.

Great!

6) Navigate to DTMF Settings. Still likely within the main "Telephony" menu section, look for sub-menus related to media or voice configuration. Common names include "Media", "Voice", "Codec Settings", or specifically "DTMF".

I meant in your ATA.

As per my first message, the DTMF issue is a separate issue with MizuDroid. MizuDroid does offer quite the range of options: Alas, selecting NTE (RFC 2833 / RFC 4733) instead of "Auto" still does not enable the voicemail menu to function beyond the first keypress.

Okay, I have no way of testing MizuDroid currently and have also never used it (I use Groundwire, a paid app, instead--and mostly on iOS). I would have suggested NTE. Maybe try INFO (SIP signalling INFO message). Inband doesn't work well with the G.729a audio codec because it's a very lossy codec, and I'm pretty sure Inband doesn't work reliably with Freephoneline's voicemail system. RFC 2833 (NTE) is the standard recommendation. You could try SIP INFO, I suppose. I don't think I've tested that option with FPL's voicemail system. You can test the other options. When testing, ensure that you're not using speakerphone and that you're using the G.711u audio codec.

Navigate to Advanced/Media Settings. I don't know what the exact path is.

Maybe Advanced -> More Settings -> Advanced Settings -> Media Settings
Or perhaps Settings -> Your Account -> Advanced Settings -> Media Settings / Codec Settings

Then find Codec Configuration within the "Media Settings" or "Codec Settings" area. Look for a list of available audio codecs.

Make sure G.711u (PCMU) is Enabled (checked or toggled on).
Make sure G.729 is also Enabled (as you wanted to keep it as a fallback).
Disable other codecs you don't need, such as G.711a (PCMA), G.723.1, Speex, GSM, iLBC, etc. Uncheck or toggle them off.

Then set Codec Preference. Look for an option labelled "Preferred Codec" or similar. Select PCMU (or G.711u). Alternatively, some apps allow you to order the enabled codecs by dragging or using arrows. If so, make sure G.711u (PCMU) is at the top of the list, followed by G.729.

Save Changes. Apply or save the codec settings within the app.
Restart Mizudroid. Close Mizudroid completely (you might need to force stop it via your phone's app settings), and reopen it to ensure the new codec preferences are loaded.

Then you can try various DTMF settings.

I tend to use https://thetestcall.blogspot.com/ for testing DTMF, but I appreciate you're having problems specifically with FPL's voicemail menu. Absolutely do not use speakerphone when testing DTMF. Use the G.711u (PCMU) audio codec. Call 416-342-9562 or 250-412-5922 from https://thetestcall.blogspot.com/. Call the number, wait for the beep, press #, and then press 2. Then press every single digit on your phone. Then press #. Wait to hear if each button was successfully pressed. Then end the call.

[Liptonbrisk]

You could try SIP INFO, I suppose. I don't think I've tested that option with FPL's voicemail system.

I just did in Groundwire. I disabled all other DTMF methods. SIP INFO worked with FPL's voicemail system. G.711u audio codec was used, although that doesn't matter with SIP INFO.

SIP INFO also works with Obihai ATAs and IP Phones with Freephoneline's voicemail system.

So in Mizudroid, I would try SIP INFO, and if that doesn't work, try "SIP INFO + NTE".

NTE should work. I'm not sure why it's not, unless there's some bug in Mizudroid.

When speakerphone is on, the app might use aggressive Acoustic Echo Cancellation (AEC) and noise suppression algorithms to prevent feedback loops and filter background noise. It's possible that this processing is somehow interfering with the correct timing or triggering of the NTE packet generation, even though NTE data itself isn't audio. Anyway, keep speakerphone off when testing DTMF.

[Liptonbrisk]

I tried holding the speaker of my cordless phone up to the microphone on my smartphone and pressing the 7 key, but that yields no result.

By the way, trying to send DTMF tones by holding the speaker of one phone (your cordless phone) up to the microphone of another device making the VoIP call (your smartphone running Mizudroid) is an attempt to use In-Band DTMF, and I've never had In-band DTMF work well with Freephoneline's voicemail system, at least not years ago when I tested.

[Kwyjor]

I would be pained to leave you hanging after writing all that up.

Okay, I have no way of testing MizuDroid currently and have also never used it (I use Groundwire, a paid app, instead--and mostly on iOS).

Well, if by that you mean you don't have an Android phone, they do have iPhone and Windows versions.
https://www.mizu-voip.com/Software/Soft ... phone.aspx

Somewhat regrettably, I must report that trying MizuDroid again with "NTE (RFC 2833 / RFC 4733)" appears to offer full access to the voicemail menu. I am unsure what might have changed.

I tend to use https://thetestcall.blogspot.com/ for testing DTMF, but I appreciate you're having problems specifically with FPL's voicemail menu. Absolutely do not use speakerphone when testing DTMF. Use the G.711u (PCMU) audio codec. Call 416-342-9562 or 250-412-5922 from https://thetestcall.blogspot.com/. Call the number, wait for the beep, press #, and then press 2. Then press every single digit on your phone. Then press #. Wait to hear if each button was successfully pressed. Then end the call.

I was also initially having problems getting "#" to be accepted here with MizuDroid, but that also unexpectedly resolved itself after I selected "NTE (RFC 2833 / RFC 4733)". Perhaps the setting was initially not saved properly.

Alas, a problem remains: my analog phone connected to my ATA box cannot get past the recording phase by pressing #. (My memory may be playing tricks on me, but I do seem to recall I may have encountered this problem once before.) I emphasize that this same phone can access the *98 voicemail menu without difficulty.

Herewith the Mediatrix default "CODEC" settings. I shall experiment with altering them later.

(I should emphasize that I have been absolutely satisfied with the sound quality I've gotten from this ATA over the many years I've used it.)

[Liptonbrisk]

Well, if by that you mean you don't have an Android phone, they do have iPhone and Windows versions.
https://www.mizu-voip.com/Software/Soft ... phone.aspx

I meant on Android since I felt the problem might be specific to that version, but you've stated the issue is resolved.

Perhaps the setting was initially not saved properly.

I suspect so.

Alas, a problem remains: my analog phone connected to my ATA box cannot get past the recording phase by pressing #. (My memory may be playing tricks on me, but I do seem to recall I may have encountered this problem once before.) I emphasize that this same phone can access the *98 voicemail menu without difficulty.

This is the most probable cause: DTMF Transport Type is currently set to InBand. I probably wasn't clear enough previously. InBand DTMF sends the tones as audio, which you don't want. This method is unreliable, especially if a compressed codec such as G.729 is potentially used during the call. The tones may become distorted and unrecognizable by the voicemail system (or whatever system is being called).

1. Locate the DTMF Transport Type dropdown menu (currently showing InBand).

Change this setting to the option corresponding to RFC 2833/NTE. Based on the manual (page 149), this option is likely named outOfBandUsingRtp, but look for labels containing "RFC 2833" or "NTE", or "RTP". Choose that option.

2.Adjust Packetization Time (PTime): Freephoneline recommends 20ms.
https://support.freephoneline.ca/hc/en- ... redentials
"Suggested RTP Packet size (psize): 0.020 - This ensures audio packets every 20 milliseconds, achieving better quality (trade-off: bandwidth)"


I use 10, which is a lower latency. Since the ATA sends out audio data every 10 milliseconds instead of waiting for 20 milliseconds worth of audio to accumulate, the delay added by the packetization process itself is reduced. This can make the conversation feel slightly more immediate and responsive, closer to a traditional phone line. The tradeoff is the amount of bandwidth used, and lower packetization periods may strain jitter buffers somewhat in ATAs (increased processing load), but that was more of an issue with old hardware.

If you have problems with 10 ms, then use 20 ms, as Freephoneline guidelines recommend.


a) In the Voice - G.711 section,
Set G.711 u-Law minimum packetization time to 20 ms.
Set G.711 u-Law maximum packetization time to 20 ms.

b) In the Voice - G.729 section,
Set G.729 minimum packetization time to 20 ms.
Set G.729 maximum packetization time to 20 ms.

3. Verify Other Codec Settings:
Confirm Preferred Codec is G711 PCMU. (Correct).
Confirm G.711 u-Law is Enabled. (Correct).
Confirm G.711 a-Law is Disabled. (Correct).

- G.729 is Enabled. I lean towards disabling that codec. Honestly, I can't stand the audio it produces; the sound quality, to me, is terrible. People tend to use G.729a in situations where cellular data is limited and/or slow (G.729a is a lossy codec that uses less data than G.711u). Your tolerance for it may be better than mine.

Confirm G.723 and G.726 sections show Disabled. (Correct).
Confirm Echo Cancellation is Enabled. (Correct).

4. Save Changes: scroll to the bottom of the page, and click the "Apply" or "Save" button.
5. Reboot the ATA. Navigate to the system/reboot section if it exists or power cycle the ATA.


I'm not sure if "recording phase" means recording a voicemail message on Freephoneline's voicemail system or if you're testing DTMF by calling 416-342-9562 (the test call). Regardless, don't use In-band DTMF. Try RFC 2833/NTE first. Alternatively, you can also try SIP Info and "RFC 2833/NTE + SIP INFO" (the specific labels might be different in the dropdown menu).

After the ATA reboots, try calling voicemail (*98) from your phone again. Once the recording starts, press #. With the DTMF Transport Type correctly set to RFC 2833 (outOfBandUsingRtp), the voice system should now recognize the # press reliably. If not, try another phone or handset to ensure your "#" button isn't faulty.

[Liptonbrisk]

I should probably explain what happens better.

Your voice is digitized, encoded (using an audio codec such as G.711u, which is closer to POTS or plain old telephone service, or G.729a, which sounds worse and uses less data), and broken into small chunks that are, in turn, put into data packets using RTP (Real-time Transport Protocol). The continuous flow of these RTP packets carrying the voice audio data is commonly called the RTP stream, media stream, or voice stream.

Currently, Freephoneline RTP IPs are 208.85.218.149 and 208.85.218.150 (subject to change). So the audio stream reaches your ATA from a different IP address than the proxy server the ATA is registering with (voip.freephoneline.ca:5060, voip2.freephoneline.ca:5060, or voip4.freephoneline.ca:6060). What follows after the colon is the respective server's UDP port (on the WAN side--not locally).

A) In-band (avoid, unless testing or if out-of-band methods fail first)

This method sends the DTMF tones as actual audio sounds mixed directly into the voice (RTP) stream, using the same audio codec (G.711u or G.729a) that your voice is using.

This is generally considered the least reliable method, especially if a compressed audio codec (such as G.729a, which you have enabled--but not preferred, thankfully) is being used. The compression process can distort the precise tone frequencies, making them unrecognizable to the receiving system (such as a voicemail menu). Inband might work passably well if G.711u is being used exclusively, but network issues, such as packet loss, can still degrade the tones. I haven't been very successful getting In-band DTMF to work reliably, at least when I was testing years ago, with FPL's voicemail system.

There are certain circumstances where using Inband DTMF may be necessary. For example, some door-entry or intercom systems use access panels that require audible DTMF tones to unlock doors or activate gates. Those panels lack SIP-info or RFC 2833 stacks, so in-band audio is the only way to use them properly.

If an older alarm panel or the central station receiver doesn't properly support RFC 2833 signals coming via Freephoneline, communication will fail. In that case, if you were using the G.711u audio codec for the connection, trying Inband DTMF might be a last-resort troubleshooting step, as it sends the tones as audio. Most alarm communicators simply dial in DTMF over the line. They do not support RFC 2833 or SIP INFO natively. Here's an example: viewtopic.php?p=75441#p75441.

You may come across an Interactive Voice Response (IVR) system (such as phone banking with customer service menus) that is older or poorly configured and doesn't recognize the standard RFC 2833 signals being sent. If your key presses aren't registering on a specific system when using RFC 2833, and you are using the G.711 codec, switching to inband might work for interacting with that specific system.

However, generally, avoid InBand DTMF unless out-of-band methods are failing first.


B) outOfBandUsingRtp or RFC 2833/RFC 4733/NTE (most reliable)

This method sends the DTMF tones out-of-band as specially formatted data within RTP packets, separate from the voice audio packets. It uses a specific payload type defined by the RFC 2833 standard (sometimes called NTE or Named Telephone Events). The receiving end reconstructs the tone based on this data.

RFC 2833 is considered the most compatible method for VoIP. Since the tones are sent as data separate from the audio stream, they are not affected by audio codec compression or typical levels of packet loss/jitter. This is the standard method providers tend to recommend.

RFC 4733 replaced 2833:

"RFC 4733 is a technical document from the Internet Engineering Task Force (IETF) titled "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals," published in December 2006. It specifies how devices should package touch-tones (DTMF), dial tones, busy signals, and other telephone-related sounds into data packets for transmission over IP networks using the Real-time Transport Protocol (RTP). RFC 4733 officially replaces (or "obsoletes") the earlier standard RFC 2833 by expanding and clarifying its framework. Although RFC 2833 has been formally replaced, the method is still commonly referred to as "RFC 2833" in practice, and most implementations remain backward compatible. Like its predecessor, RFC 4733 defines a reliable way to send DTMF tones out-of-band relative to the audio stream—meaning as separate data packets rather than audio mixed with voice—thereby avoiding problems caused by voice compression. Key changes introduced by RFC 4733 include removing the strict requirement that all compliant devices must support DTMF events, making support negotiable during call setup; adding procedures for handling long events through segmentation, reporting multiple events in a single packet, and reporting "state events"; and establishing a formal registry, managed by IANA, for assigning new telephony event codes. In essence, RFC 4733 serves as the updated standard for reliably transmitting DTMF tones and other telephony signals within RTP data streams for VoIP communications." (An A.I. explanation)

https://datatracker.ietf.org/doc/html/rfc4733

C) outOfBandUsingSignalingProtocol or SIP INFO/RFC 2976 (try if RFC 2833/NTE doesn't work)

This method also sends the DTMF tones out-of-band, but instead of using RTP packets, it uses SIP INFO messages, which are part of the call (Session Initiation Protocol or SIP) control signalling.

SIP INFO is generally reliable as it also avoids audio codec issues. However, support for SIP INFO for DTMF is less universal across all providers and equipment compared to RFC 2833. I've tested SIP INFO DTMF and found it works with FPL's voicemail system, but RFC 2833 is usually preferred for broader compatibility.

When VoIP and SIP were first developed in the late 1990s and early 2000s, many technical standards were still incomplete. At that time, voice calls used RTP streams to carry audio, but there was no standard method for sending key presses needed for phone menus. To address this, SIP INFO was introduced (RFC 2976). It allowed phones to send key press information as separate SIP messages during a call. For example, when a person pressed "5," the phone would send a special SIP INFO packet to inform the system. However, in real-world VoIP networks, SIP signalling often travels separately from audio streams and can experience delays, packet loss, or be blocked by firewalls and other network devices. Some systems require multiple SIP messages for a single key press, while others expect only one, leading to compatibility problems, especially with automated systems such as banking menus. A better method was later developed, called RFC 2833 (also known as out-of-band RTP). It sends key press signals as special RTP packets separate from the regular audio data but within the same RTP stream. Because these signals are not treated as audio, they avoid distortion from voice compression and are much more reliable, even under less-than-ideal network conditions. Today, most phone systems and automated menus expect key presses to be transmitted using RFC 2833/RFC 4733 (NTE).


D) signalingProtocolDependent (RFC 2833 + SIP INFO)

This isn't a distinct transmission method itself. Instead, the Mediatrix ATA advertises support for both outOfBandUsingRtp (RFC 2833) and outOfBandUsingSignalingProtocol (SIP INFO) during call setup. It lets the call negotiation process determine which method to use, with a stated preference for RFC 2833.

Reliability for this method depends on successful negotiation. Since it prefers RFC 2833, it should default to the most reliable method if the other end supports it. This method offers flexibility but relies on both ends handling the negotiation correctly.



Anyway, NTE (RFC 2833/RFC 4733) is the option you should ideally use. If you have issues when using NTE specifically from the ATA (when trying to use FPL's voicemail system), then I would try signalingProtocolDependent. There should be no reason why NTE (outOfBandUsingRtp) wouldn't work for you with FPL's voicemail system.

[Kwyjor]

I should probably explain what happens better.

Oh, rest assured you have written more than enough to satisfy me, at least. I hope this information serves others in the future. I am grateful for your enthusiasm.

Merely changing the DTMF Transport from "InBand" to "outOfBandUsingRtp" indeed allows my analog phone to function normally with The Test Call, so I guess everything does what I need it to now.

Thanks again.

[Liptonbrisk]

Merely changing the DTMF Transport from "InBand" to "outOfBandUsingRtp" indeed allows my analog phone to function normally with The Test Call, so I guess everything does what I need it to now.

Thanks again.

Great! You're welcome!

By the way, I would enable voicemail to email if you haven't done so yet: https://support.freephoneline.ca/hc/art ... l-to-Email. Login at https://www.freephoneline.ca/voicemailSettings. I use the "Copy" option to ensure I don't lose the original voicemail message if there's an email issue.