[Asterisk-Users] Broadvoice's changes last week brokecallforwarding

[Marios Andreou]

Let me rephrase this:

"If yes then canreinvite=no/yes has no meaning."

Actually it does have a meaning but in this context it doesn't affect the ability to place a call.

So:
We start from:
SIPPhone -> Asterisk -> SIP Provider

If canreinvite=yes then after the initial INVITE you get:
SIPPhone -> SIP Provider

If SIPPhone is internal (NATed) then you have NAT problems

If canreinvite=no then after the initial INVITE everything stays the same:
SIPPhone -> Asterisk -> SIP Provider

This is good for The NATing if and only if Asterisk is your NAT/Firewall machine.


-----Original Message-----
From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Marios Andreou
Sent: Tuesday, March 15, 2005 11:55 AM
To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
Subject: RE: [Asterisk-Users] Broadvoice's changes last week brokecallforwarding

Well are you calling directly from your *?
Like you use a soft phone on the same machine?

If yes then canreinvite=no/yes has no meaning.

If you have an extension and you go like this:
SIPPhone -> Asterisk -> Broadvoice

Then is SIPPhone on a NATed IP?
Like 10.10.10.10 is the SIPPhone.
12.12.12.12 is the *.

Then you DO NEED canreinvite=no for the SIPPhone.
Because if it tries to connect SIPPHone directly with Broadvoice
then * is out of the picture and Broadvoice cannot see your SIPPhone except if you have the NAT configured correctly.



-----Original Message-----
From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Rich Adamson
Sent: Tuesday, March 15, 2005 3:32 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Broadvoice's changes last week broke callforwarding

> 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?

Broadvoice doesn't use asterisk for their switches, and whatever they
happen to use might not be rfc compliant. Who knows. Asterisk itself
isn't rfc compliant, so there's probably no way to ever answer your
question without just simply doing the trial and error thingie.


_______________________________________________
Asterisk-Users mailing list
Asterisk-Users at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


_______________________________________________
Asterisk-Users mailing list
Asterisk-Users at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users