[Asterisk-Dev] Re: [Asterisk-Users] Asterisk and SIP phones

[John Paul Morrison]

I thought about this at first but didn't like it for the following reasons:

- it means digging deeper into packet/header to find the IP where the packet
came from
and making some guesses about when to re-invite or not. You could have two
cheap Linksys NAT routers on the *same* cable/DSL subnet, with sip phones
*behind* those NATs, also using the *same* private IPs/subnetworks, so you
really have no information about whether those phones can talk directly or
not. 

- a config file option is completely deterministic, no guessing involved
about subnets, and if you
are providing services to customers - you would know that Customer A has
it's router/NAT/firewall, and that those phones can't (easily) talk to
Customer B's. This option would allow all of Customer A's phones to talk
directly to each other using the reinvite. 

- It was harder to do. I did a quick hack to make this work in a line or two
of code - I (a)bused  the "context" field  in the the
sip.conf/extensions.conf to decide whether to reinvite, and it was quite
simple, probably simpler than looking at the IP addresses. 
 
It would be easy to add a global config flag to say: use the defaults, or
overload/abuse the context when considering when to reinvite (basically if
phones are in a different context, either use the defaults, or assume they
can not reinvite). This is probably not the "correct" or most elegant way to
do it. 

But adding the code to handle "natcontext=blah" is pretty basic as well (cut
and paste), my only concern would be if any of the various structures used
by the shared libraries are fixed in stone - do I have to worry about binary
compatibility?  My hack was done in rtp.c, since that was easiest :-) but
reinvites get handled by other channels (mgcp, possibly sccp etc) and maybe
there's a more correct way to shove this in to chan_sip.c

> On Behalf Of 
> Benjamin on Asterisk Mailing Lists
> Sent: Thursday, October 07, 2004 12:10 PM
> 
> 
> On Thu, 7 Oct 2004 11:17:51 -0700, John Paul Morrison 
> <jmorrison at bogomips.com> wrote:
> > I think the best approach is to create a new sip.conf entry like 
> > "natcontext" so you can have "natcontext=customer-1" for a group of 
> > devices, "natcontext=customer-2" etc. so that an Asterisk 
> adminstrator 
> > can better control the way reinvites are issued.
> 
> I think the idea to selectively set when reinvites are 
> allowed is a good idea and I have myself been asking why 
> there is no such thing. However, I don't think you should 
> make this as complicated as you seem to be doing.
> 
> There should be a simple-and-stupid-covers-90%-of-cases 
> setting and a more sophisticated but still relatively simple 
> way for the remaining 10%.
> 
> I venture to say that in most cases the requirement will be 
> extremely simple:
> 
> "allow reinvites between anything on the same subnet and 
> disallow to anywhere else"
> 
> this setting should be configurable with something like
> 
> reinvite=local
> 
> So, if we have Asterisk A and two phones B and C, ...
> 
> [remote SIP gw]----SIP---[A]-----B-and-C
> 
> then sip.conf should have
> 
> [PhoneB]
> reinvite=local   ; allow reinvites if both parties are on the 
> local subnet
> 
> [PhoneC]
> reinvite=local   ; allow reinvites if both parties are on the 
> local subnet
> 
> [remoteSIPgw]
> reinvite=yes   ; setting if Asterisk has its own public IP
> OR
> renivte=no      ; setting if Asterisk is behind NAT
> 
> The other 10% would be cases where it is not obvious what is 
> local and what is not, as would be the case with a number of 
> VPN tunnels of which the Asterisk server is not an end point 
> and therefore could not know what the routing table of the 
> router says.
> 
> But here again, the configuration could be made fairly easy 
> by simply telling Asterisk who is local and who is not, 
> replicating the information in the router's routing table so to speak.
> 
> This could look like the following in sip.conf ...
> 
> [SIPphoneB]
> reinvite=1.2.3.4/29,5.6.7.8/24,192.168.0.0/16
> ALSO
> reinvite=sip.server.net
> 
> In any event, it may be best to implement the local subnet 
> only method first and have a play with it for a while, then 
> look at more sophisticated scenarios with the experience gained.
> 
> just my 2 yen.
> 
> rgds
> benjk
> 
> -- 
> Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 
> Shibuya, Tokyo, Japan.
> 
> NB: Spam filters in place. Messages unrelated to the * 
> mailing lists may get trashed. 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com 
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>