[Asterisk-Users] broadvoice/asterisk incoming calls problem

[Rich Adamson]

> 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