[Asterisk-Users] broadvoice/asterisk incoming calls problem

[Chris Shaw]

---- Original Message -----
From: "Rich Adamson" <radamson at routers.com>
To: <asterisk-users at lists.digium.com>
Sent: Thursday, July 29, 2004 5:02 AM
Subject: Re: [Asterisk-Users] broadvoice/asterisk incoming calls problem


> > This is what my configuration is:
> >
> > xxx is my phone
> > yyy is my secret
> >
> > [general]
> > externip=lexon.ws
> > port=5060
> > disallow=all
> > allow=ulaw
> > context=from-broad
> > dtmfmode=inband
> > register => xxx:yyy at sip.broadvoice.com
> > tos=0x18
> > srvlookup=yes
> >
> > [Broadvoice]
> > type=peer
> > username=xxx
> > fromuser=xxx
> > secret=yyy
> > host=sip.broadvoice.com
> > context=from-broad
> > fromdomain=sip.broadvoice.com
> > nat=yes
> > canreinvite=no
> > dtmfmode=inband
> > insecure=yes
> >
> > Incomming calls still fails.
> > NO SOUND AT ALL!!!
>
> The above [Broadvoice] context with type=peer is generally used
> for 'outbound' calls only; something like:
>  exten => _1.,3,Dial,Sip/Broadvoice/${EXTEN}
>
> However, for inbound calls from Broadvoice, I think you'll need
> something like the following in sip.conf:
>  [sip-broadvoice]
>  type=user       ; handles inbound calls from Broadvoice
>  context=from-broadvoice
>  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
>
> There seems to have been two changes initiated at Broadvoice on
> Sunday: 1) Registration, and, 2) no authentication on incoming
> calls. (Keep in mind that I just signed up for Broadvoice service
> on Saturday, and then experienced the changes/failures on Sunday.)
>
> The majority of discussion and fixes suggested on the list lately
> pertains to #1, however a fair number of users have mentioned #2
> with very few (if any) responses to those issues.
>
> As I understand #1, the issue is that Broadvoice is providing two
> IP addresses with their DNS responses for sip.broadvoice.com, however
> asterisk 'always' uses the first entry in the response and never
> the second. They might also be using round robin DNS responses,
> where in theory their DNS response alternates between two addresses.
> Some of the postings have suggested that only one of their two sip
> registration servers handle asterisk's registration, and one of the
> fixes was to hard code the IP address in /etc/hosts.conf. It sounds
> like most folks have worked around the registration issue without
> knowing exactly they did (or what additional issues they just added).
> The hard coded Ip now limits that * machine to using only one of
> the two sip registration servers at Broadvoice, and if that server
> happens to be unavailable, * has no where to go.
>
> If anyone has a different interpretation of #1, I'd like to hear it.
>
> Issue #2 is different. Based only on my limited experience from
> Saturday (before the changes), incoming * calls from broadvoice
> use to include a userid & secret to authenticate the session with *.
> That appears to have changed on Sunday, and now calls arrive without
> the authentication function. Therefore, a section in sip.conf like
> the  [sip-broadvoice] above that includes type=user is now needed
> to handle those calls. If the deny and permit statements are not
> included in that context, then calls from any source on the Internet
> can be completed via such an open ended context.
>
> There's certainly nothing wrong with allowing such incoming calls
> "if" your dialplan adequately restricts what those calls can reach.
> However, if the dialplan allows unrestricted calling, then sooner
> or later you might find a hacker making calls through your system.
>
> As I mentioned earlier, I only had a few hours of experience with
> the broadvoice config before the changes occurred, so if I've
> mis-represented either of the above would someone correct me.
>
> Rich

Hmmmm as for #2, I've NEVER used authentication on my inbound calls, even
before they made the change and it has always worked... I use a bogus
context as my default context (I don't want unrouted calls) and I've set up
the correct context for my broadvoice-incoming contexts.. As far as
INSECURE=YES or VERY, I don't use that at all and it still works fine...

I'm a little concerned by the NAT=YES in the sip.conf sample below. That
could be the culprit for the no audio problem right there, especially if the
RTP stream doesn't know where to go... If you really really MUST use NAT,
why not try using port forwarding on your router and forward UDP port 5060
and the RTP ports that you have set in your rtp.conf directly to your *
server, then set NAT=NO or NAT=NEVER and try that...

Also I don't see any localnet entries or externip entries... if you're using
nat, you kinda need those...

NAT is evil and should be destroyed and sent back to hell from whence it
came...

Here's a sample of my sip.conf in case this helps you...

[general]
port=5060
bind=0.0.0.0
externip=24.20.x.x (why not try using an ip instead of a hostname...)
localnet=10.100.5.0/24 (not sure if this is needed anymore...)
context=bogus
srvlookup=yes
tos=0x18
maxexpirey=3600
defaultexpirey=120
progressinband=no

disallow=all
allow=gsm
allow=alaw
allow=ulaw
allow=adpcm
allow=speex
allow=ilbc
allow=slinear

register => 5035551212:supersecretpassword at sip.broadvoice.com:5060

[broadvoice-out]
type=peer
dtmfmode=inband
host=147.135.0.129
user=5035551212 (not sure if this is necessary, I like to be thorough)
username=5035551212
authuser=5035551212 (not sure if these 2 are necessary but again, thorough)
fromuser=5035551212
fromdomain=sip.broadvoice.com
context=shawhome
md5secret=supersecretpassword
qualify=yes
canreinvite=no
disallow=all
allow=ulaw

[broadvoice-out2]
type=peer
dtmfmode=inband
host=147.135.8.129
user=5035551212
username=5035551212
authuser=5035551212
fromuser=5035551212
fromdomain=sip.broadvoice.com
context=shawhome
md5secret=supersecretpassword
qualify=yes
canreinvite=no
disallow=all
allow=ulaw

[broadvoice-incoming]
type=peer
dtmfmode=inband
host=147.135.8.128
context=incoming
qualify=yes
canreinvite=no
disallow=all
allow=ulaw

[broadvoice-incoming2]
type=peer
dtmfmode=inband
host=147.135.0.128
context=incoming
qualify=yes
canreinvite=no
disallow=all
allow=ulaw


The reason I did 2 contexts for incoming/outgoing is to overcome the DNS
problem for peers until it gets resolved...

Also in my extensions.conf I use failover in case one of the
[broadvoice-out] peers is down...

exten => _9NXXNXXXXXX,1,Dial(SIP/${EXTEN:1}@broadvoice-out,60)
exten => _9NXXNXXXXXX,2,Dial(SIP/${EXTEN:1}@broadvoice-out2,60)
exten => _9NXXNXXXXXX,3,Congestion()

Mind you I'm not saying that I'm right, I've only been using asterisk for
about 4  months now, but THIS WORKS FOR ME(tm)

    -Chris