[Asterisk-Users] 2 Sip phones behind un-natted Asterisk

[John Fraizer]

Since I always use canreinvite=no, you're probably right.

John

Bruce Komito wrote:

> Not to beat a dead horse, but I had the problem even with the two lines on
> different ports.  The canreinvite=no thing solved the problem.
> 
> Bruce Komito
> High Sierra Networks, Inc.
> www.servers-r-us.com
> (775) 284-5800 ext 115
> 
> 
> On Mon, 24 May 2004, John Fraizer wrote:
> 
> 
>>Bruce Komito wrote:
>>
>> > In sip.conf, try setting canreinvite=no for both lines.
>> >
>> > Bruce Komito
>> > High Sierra Networks, Inc.
>> > www.servers-r-us.com
>> > (775) 284-5800 ext 115
>>
>>canreinvite=no will sometimes make a difference but, I believe that what
>>most people are running into is what I described in my previous post.
>>NAT devices track IP flows.  When you have two "flows" from the asterisk
>>server that look like:
>>
>>ast.erisk.serv.er:5060<->nat.wan.ip.addr:5060<->NAT<->10.1.1.1:5060
>>ast.erisk.serv.er:5060<->nat.wan.ip.addr:5060<->NAT<->10.1.1.2:5060
>>
>>The NAT device has no way of deciding which of the two or more SIP
>>devices (hardphone or softphone) on the inside the flow is supposed to
>>go to.  It looks through it's flow database and sees that there are two
>>potential candidates on the inside that could be the owner of the flow.
>>
>>When you make sure that your SIP devices behind the NAT use unique
>>source ports, you end up with this:
>>
>>ast.erisk.serv.er:5060<->nat.wan.ip.addr:5061<->NAT<->10.1.1.1:5061
>>ast.erisk.serv.er:5060<->nat.wan.ip.addr:5062<->NAT<->10.1.1.2:5062
>>
>>I guess that many people don't really truly understand how the NAT works
>>on the raw level and it's a plug and play device to them.  For that
>>matter, I have been running large scale networks for nearly 16 hears and
>>I got bit by the same thing because I assumed that the Cisco would do
>>the "Right_Thing" (TM) and choose a random source port.  Once I
>>discovered that it didn't do that, it was a simple matter of telling it
>>to do so.
>>
>>I suppose that this is also somewhat the fault of the NAT device
>>(linksys/cisco) as well since it should have noticed that there were two
>>devices on the inside of the NAT trying to create identical flows.  It
>>could have easilly done some mapping to change the source port on the
>>WAN side of the connection of one of the flows.
>>
>>OK.  This is the * list and not routing 701 so, I'll stop now.  Suffice
>>it to say that it is a good idea to have unique source ports if you have
>>multiple devices on the inside contacting the same device:port on the
>>outside.
>>
>>John Fraizer
>>EnterZone, Inc
>>http://www.enterzone.net/
>>
>>
>>