asterisk users - Mar 2005 - Broadvoice's changes last week broke call forwarding

Like everyone else who used asterisk with broadvoice, my outgoing calls
died last week. I made the appropriate changes, and now basic incoming
and outgoing calls are working. However, I have a few call-forwarding
rules that are no longer working. It's certainly no coincidence. I can
dial to all these number directly, but the problem only appears when
there is an incoming broadvoice call, and I am try to forward that call
out to another number. The most basic scenario where the issue appears
is as follows:

call comes in on broadvoice
rings the ata in my apartment Dial(SIP/sipura)
	(no one picks up)
tries to forward to my cell, Dial(SIP/broadvoice/714#######)
	(call dies here)

Curiously, the call does ring my cell, but when I pick up there is no
audio for either party in any direction. The console shows an SIP 400
error "Bad Request-URI" followed by several 404 "Not Found"
errors. The
first error that sip debug shows is the following:

Sip read: 
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 164.67.195.23:5060;received=164.67.195.23;
branch=z9hG4bK68a91703;rport=5060
From: "310XXXYYYY"
<sip:310XXXXXXX@sip.broadvoice.com>;tag=as14f78807
To: <sip:8886831000@sip.broadvoice.com>;tag=SD5894199-
Call-ID: 213480db053b77d6797973362cb20554@sip.broadvoice.com
CSeq: 102 INVITE
WWW-Authenticate: DIGEST realm="BroadWorks",algorithm=MD5,
nonce="1110838927310"
Content-Length: 0

Somewhere the invite is breaking up, but I can't figure out where. It's
especially peculiar because it's only on my forwarded calls, normal
outgoing calls work just fine. I'm not sure how to fix this, I've been
fiddling with sip.conf options for a while, but to no avail. Below is
the relevant sections of my sip.conf:

[general]
port = 5060
context = incoming
autocreatepeer = yes
srvlookup = yes
dtmfmode = inband
register => 310XXXXXXX@sip.broadvoice.com:
xxxxxxx:310XXXXXXX@sip.broadvoice.com
;this is all one line, it just got broken up by the email client

[broadvoice]
type = peer
context = incoming
username = 310XXXXXXX
fromuser = 310XXXXXXX
authname = 310XXXXXXX
regexten = 310XXXXXXX
secret = xxxxxxx
host = sip.broadvoice.com
fromdomain = sip.broadvoice.com
qualify = yes
nat = no
canreinvite = yes
disallow = all
allow = ulaw,gsm
permit = 147.135.8.128/32
insecure = very


Any suggestions would be most appreciated,

Paul

I'm guessing it's the sudafed that caused me to wildly try this, but
I'm
glad I did, because though it creates a new concern, it solved my
problem. Just for kicks I tried setting the canreinvite parameter to no
for the broadvoice peer, and that fixed everything.

My server is on a live ip, no nat, and reinvite had worked before (pre
last weeks change), so I had figured why not save bandwidth when
possible? The question now is, why does reinvite capability have to be
disabled for broadvoice to allow asterisk to forward my calls? This
appears to be entirely an internal maneuver on my side, so why can't my
asterisk server perform (re)invite authentication to broadvoice on two
channels that it handles completely (one incoming and one outgoing)?

I don't understand enough about the intricacies of SIP and invite, but
something doesn't seem right. I should be allowed to have reinvite
capability here.



Any thoughts?


Paul