<html><div style='background-color:'><DIV class=RTE>
<P>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.</P>
<P>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.</P>
<P>I and others noticed that we get pretty weird and annoying interactions between incoming Broadvoice calls and Asterisk.</P>
<P>Specifically...</P>
<P>The CDR is wrong, shows the wrong Broadvoice Number (the username in the trunk setup)</P>
<P>The Asterisk system follows the wrong context for the trunk.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>Am I missing something here, or is this indeed a problem ?</P>
<P>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.</P>
<P>I am using the most current release of Asterisk.</P>
<P>Thanks<BR><BR></P></DIV></div></html>