Alan Porter wrote:
Does Gizmo support sending tones?
With Skype, I've had a problem using the dialer to send tones to
phonebots and answering machines, whenever there's a "Press one to
leave a message" situation.
On a side note, when you send tones over a cellular phone,
they don't actually run the DTMF tones through the vocoder.
Instead, they send meta-information "5 key pressed" and
then "5 key released". This way, if your call fades for
a second (you drive through a tunnel), your long keypress
will not be broken into two short keypresses.
I imagine that Skype and VOIP services do not have this
same sort of out-of-band signaling. So I bet they have
to encode the tones (which do not encode very well) and
send them as normal audio.
Interesting problem. I'm looking forward to learning
more about Gizmo and other VOIP goodies. Perhaps Kevin
or one of our other VOIP-masters would like to put
together a presentation for a TriLUG meeting!
This type of signalling is generally referred to as simply 'out of band'
signaling, or sometimes more specifically 'out of band dtmf'. Most of
the VOIP protocols, ala SIP, IAX, etc support out of band DTMF, which is
particularly important for the low bitrate codecs such as g.729, ilbc,
etc which can theoretically make dtmf detection at the other end wonky,
because the dtmf tones are being mangled by the codec. The usual
practice is to support DTMF detection and encoding as close to the PSTN
as possible, and then pass that data along out of band when using VOIP.
So consider these three secnearios.
I call from my Asterisk phone system at home to Cingular, to check my
voicemail. My Cisco SIP phone sends out of band DTMF to Asterisk along
side the G.711 audio. Asterisk sends out of band DTMF along side the
g.729 audio to Broadvoice, who encodes the DTMF and sends it over the
PSTN to Cingular.
Someone calls me from Bell South at my Asterisk phone system at home.
They send DTMF tones from their phone to Bellsouth, who sends the audio
over the PSTN to Broadvoice, who grabs the audio, compresses it with
g.729 and sends it to my Asterisk server. My Asterisk server then has
to decode the dtmf, in order for you to navigate the menu system to
reach an extension. This is suboptimal because the audio has been
encoded with g.729, but in practice is 100% reliable. DTMF is pretty
well suited to computer recognition, and people have been doing it for
many years so it's a very well-solved problem. In a perfect world,
Broadvoice would decode the dtmf streams and send them out of band, in
practice I don't know of a provider that does this.
I call someone else in TriLUG directly from my Asterisk server, to their
Asterisk server, over an IAX tunnel. In the likely case, my phone
transmits DTMF out of band, and both Asterisk servers continue it out of
band all the way to the remote phone, which then (maybe) generates DTMF
tones to play out the handset. Perfection at it's finest, as the remote
generation isn't impeded by what ever codecs or latency problems might
exist in the middle, and you end up with a perfect locally-generated
dtmf tone at the remote end.
Hopefully this short lesson in out-of-band signaling will be useful to
someone, some day. :)
Aaron S. Joyner
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
