[Asterisk-Users] Changing DTMF mode depending on codec chosen

Tue Apr 12 14:22:45 MST 2005

Hi Rich,

Thanks for the very detailed way to setup BV with *.. Actually, I've had
asterisk and BV working both incoming and outgoing since May of last year..
You are quite correct, though.. I'm by no means an expert in *, but there
was a good week or two of scratching my head back then to try and get it to
work reliably with BV.. I have to admit, once it works, it just works,
though (Minus the irriating sound problems, but that isn't a BV specific
problem)..

I was more curious if there was a way to detect which codec was chosen for a
specific call, and be able to adjust the dtmfmode accordingly.. If you know
of any way to have * detect the codec and switch dtmfmode on the fly (per
call), I'd love to hear how to do that.

As you aptly pointed out, BV isn't consistant in their g.729 implementation.
It works sometimes, others I get ulaw.  As with you, bandwidth is precious,
so I would love to save it whenever possible.. But, if I cannot make the
dtmfmode reliable, I'll have to stick with ulaw.

Thanks again,
         - Andre

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com]On Behalf Of Rich
Adamson
Sent: Tuesday, April 12, 2005 8:58 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: RE: [Asterisk-Users] Changing DTMF mode depending on codec
chosen

> Thanks for writing back to me.  Yep, just like you, I too am looking for a
> lower bandwidth codec for my outbound.  And, yes, broadvoice only
officially
> supports G.711.  That being said, is there even a way to do this scenario
in
> asterisk?

Yes, there are frequently multiple ways to do things in asterisk.
Here's one example that was working before I discontinued their service.
(Note: since discontinuing their service, I deleted all of my old
extensions.conf entries, so I'm not able to include those below. This
particular * system was on a registered IP address with no firewall
or nat box; if it were behind a nat box, then additional statements
would be required for that.)

; register=myphonenum:mysecret at sip.broadvoice.com	; form #1
; register=myphonenum:mysecret at sip.broadvoice.com/1234 	; form #2

The register statement is _only_ needed to tell BV how to contact your
system for incoming calls. Without it, you won't get any incoming calls.
Notes for the two forms shown above include:
 Form #1: required an entry in /etc/hosts like:
	147.135.8.128 sip.broadvoice.com
	Specifically note there is no parameter behind sip.broadvoice.com,
	so all incoming calls will match exten=>s in extensions.conf.
 Form #2: The same statement but note the "/1234" at the end. This
	form requires an exten=>1234 in the extensions.conf in order
	to complete calls.

In the sip.conf section noted below, the "type=friend" is used as this
section was referenced for incoming calls (from BV), and for outgoing
calls to BV. (One could separate this section into type=user for incoming
calls, and type=peer for outgoing calls, and then specify different
parameters for each. There's no reason to do that since BV supports
only a very specific set of parameters for both incoming and outgoing
calls.)

; [broadvoice]  ; this is referenced for outgoing calls to Broadvoice.com
; type=friend
; username=myphonenum
; secret=mysecret
; host=sip.broadvoice.com
; insecure=very
; canreinvite=no
; dtmfmode=inband
; fromuser=myphonenum
; fromdomain=sip.broadvoice.com
; context=from-broadvoice
; disallow=all
; allow=ulaw
; deny=0.0.0.0/0.0.0.0
; permit=147.135.8.129/255.255.255.0
; permit=147.135.0.129/255.255.255.0
; permit=147.135.4.128/255.255.255.0

Note that incoming calls are sent to the [from-broadvoice] context in
extensions.conf, however the incoming call is already negotiated with
allow=ulaw only.  The deny and permit statements are there because you
don't know which of the various BV systems will actually be completing
calls to your * system, so I included all of them (that I could find
a few months ago). They may have added others by now, don't know.
The deny and permit statements are really there for basic security
purposes.

For outgoing calls, your extensions.conf would have an entry like:

[broadvoice-out]
exten => _1NXXXXXXXXX,1,SetCallerID(myDIDnum|a)
exten => _1NXXXXXXXXX,2,SetCIDName(myCallerIDname|a)
exten => _1NXXXXXXXXX,3,Dial(SIP/myphonenum:mysecret at broadvoice/${EXTEN})
exten => _1NXXXXXXXXX,4,Congestion

The "broadvoice" keyword in the above refers back to the [broadvoice]
context in sip.conf (shown above). So when you make a call via BV, the
parameters in that context are used (including allow=ulaw and
dtmf=inband).

Again, keep in mind that I have deleted my extensions.conf entries, so
the above statements may have syntax errors, etc. I simply typed the
above from memory. Don't be cutting/pasting it into your system
without understanding what you're doing.

Other things to keep in mind about BV:

1. BV does not use asterisk for their switch (or if they do, its highly
modified). What you've learned about asterisk does _not_ necessarily
apply to their soft switch. Their switch may negotiate things differently
then *, etc.

2. One of the BV employees implemented asterisk at his home, got it to
work, and published the parameters he used to make it work. His
implementation (and published parameters) is specific to "his" system,
which no one knows whether he's on a registered IP, behind a nat box,
etc. So, his published parameters are _only_ a starting point, not a
firm recommendation that anyone could cut/paste. That's one of the
reasons why so many people have setup problems with asterisk (combined
with a lack of knowledge/experience as to how to diagnose problems).

3. BV had a problem with the way asterisk systems would re-register
every minute or two, and Olle wrote a patch for asterisk that reduced
that re-register traffic. (BV was being pounded by all of the remote
asterisk systems beating on their systems with that re-register traffic,
and threatened to discontinue everyone's service that continued to do that.
That patch only applied to those systems that were located behind a nat
box, but the patch didn't damage anything if you had a registered IP
address. I believe the patch made it into both cvs-head and stable.)

4. One of the reasons why BV doesn't support asterisk is they have
elected not to implement (or test) an asterisk system within their own
environment. Their target customers are those using ATA's, Sipura
boxes, etc. Since asterisk's capabilities change on a day-to-day basis,
you really can't blame them for not supporting it. If the asterisk
development community would get real serious (and professional) about
testing and formally releasing a Stable version, I think you'd see a
lot more itsp's supporting it. In the mean time, all asterisk systems
are considered unsupported by every itsp regardless of what their web
pages say.

5. In previous postings to this list, you noted that sometimes g729
would work and other times it would not. That is indicating that BV
is not consistent in the way they have set up their soft switches.
All that says is that when a call is being completed to your * from
one BV switch, it might support g729. But, their next switch does not
support that codec and your calls fail. Since they stated very openly
they support ulaw and dtmf=inband only, that's your clue to stick
with those parameters if you want your system to function correctly.

Now, if you don't like their default supported parameters, your only
option is to change service providers. Since a couple of ulaw calls
consumed all of my broadband bandwidth, I elected to move on to
another provider that supported iax/gsm and have been very happy ever
since. (My broadband provider has since increased their bandwidth to
my location, but I'm not going back to BV regardless.)

Hopefully the above will help others understand some of the history
and options available when using BV. For those that _still_ have
problems, be sure to post relavent sections of sip.conf (including
the register statement), extensions.conf, cli output from actual call
attempts, and the results from "sip debug".

_______________________________________________
Asterisk-Users mailing list
Asterisk-Users at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users