[Asterisk-Dev] Multiple IP's For sip.

[Alberto Fernandez]

So what can we do about it, so that we can have 1 or more IP address,
and asterisk working.

Best Regards


On Wed, 2004-07-14 at 18:08, Tilghman Lesher wrote:
> On Wednesday 14 July 2004 12:57, Wolfgang S. Rupprecht wrote:
> > tilghman at mail.jeffandtilghman.com (Tilghman Lesher) writes:
> > > On Tuesday 13 July 2004 14:07, Alberto Fernandez wrote:
> > > > Correct In sip.conf i bind the ip to 0.0.0.0 and it still doesnt let
> > > > the phones register. Im not folowing what you are trying to tell me.
> > > > Please elaborate.
> > >
> > > I suspect I have already been too elaborate, and you actually want a more
> > > simplistic explanation:  the IP that Asterisk uses for SIP is based upon
> > > your route table.  If there is no explicit route for a destination, then
> > > Asterisk will use the device associated with the default route to specify
> > > that IP.
> >
> > I think he might be seeing the same bug I see here, but haven't
> > bothered to track down further.  When Asterisk does a wildcard bind,
> > something screws up.  I solved it by the expediency of simply choosing
> > my outside interface and limiting asterisk to binding to that one.
> >
> > If asterisk really does choose (or let the kernel choose) the source
> > IP based only on routing then I think I see the problem.  Asterisk
> > must take the src/dest addresses from the incoming packet and flip
> > them around (along with flipping the port numbers).  Doing otherwise
> > prevents the other side from associating the reply packet with its
> > query packet.
> 
> It does.  I wrote the code.  See acl.c.  And the only problem with your
> approach is that Asterisk may or may not have corresponding incoming
> packet headers when it chooses to send a packet to a remote host.  What
> should Asterisk do in that case?
> 
> And this masks the real problem, here:  the SIP protocol has a braindead
> way of operating:  namely, by encoding data from a lower level protocol
> into a higher level protocol, which, as you correctly pointed out, breaks
> stuff.  There's an interesting document that came out from ICANN this week
> which said much the same about Verisign's SiteFinder, but I digress.