[Asterisk-Users] Did the Broadvoice patch break asterisk ?

[Rich Adamson]

> I think it might have. My understanding is BV does not require username and secret for 
incoming calls from BV to Asterisk, so
> a patch was written and then included in Asterisk to fix this.
> 
> I have been testing for 4 weeks now, and have been shot down once in the digium bug tracker 
and pretty much blown off, but
> I'll try again here to see if I get anywhere.
> 
> I and others noticed that we get pretty weird and annoying interactions between incoming 
Broadvoice calls and Asterisk.
> 
> Specifically...
> 
> The CDR is wrong, shows the wrong Broadvoice Number (the username in the trunk setup)
> 
> The Asterisk system follows the wrong context for the trunk.
> 
> After a LOT of testing what I seemed to have found is that Asterisk has been programmed to 
cache the information for the first
> incoming Broadvoice call, the number and the context.
> 
> All subsequent calls from Broadvoice will use this number and context REGARDLESS of what the 
other Broadvoice trunks
> have been programmed with no matter how wrong the settings are for them, no errors, just chugs 
along using the info for the
> first trunk that rings in.
> 
> So if the first trunk has a context that tells it to use the auto attendant, then ALL BV 
trunks will use the AA even if their context
> is to do something else. You can give all the other BV trunks a non-existent context and their 
is no error when they ring in, they
> just follow the valid context from the first trunk that rang in.
> 
> The work aorund has been to use the /EXT option in the registration, but that is not a good 
fix, as other interactions are
> occuring as well.
> 
> I have 14 BV trunks, and I have repeatedly proven that Asterisk will ignore ALL cutomizations 
for their username and context
> and instead will follow the settings for the first one that rings in following a reboot.
> 
> Am I missing something here, or is this indeed a problem ?
> 
> Our logs files and CDR are all screwed up and meaningless with respect to tracking back to the 
actual SIP CHANNEL
> activity as they always reflect the first trunk that rang in for all BV trunk activity.
> 
> I am using the most current release of Asterisk.

If I recall correctly (and I'm not a BV user), incoming sip calls to 
asterisk do not use all the parameters as one would expect. I think
Olle posted something in the last month or two that such incoming
calls attempt to find the first context that matches IP Address (or
something like that) regardless of other parameters passed.

The sip.conf.sample file includes the following comment:
; For incoming calls only. Example: FWD (Free World Dialup)
; We match on IP address of the proxy for incoming calls
; since we can not match on username (caller id)

You might try to find that post and review the exact sequence of
parameters that asterisk uses for incoming sip calls.