Tilghman Lesher wrote:
On Tuesday 27 December 2005 14:15, James Sizemore wrote:
I think I found what is munging up the peer lookup:
This call from another Asterisk box starts:
<-- SIP read from 192.168.69.254:5060:
The peer lookup that fail reads:
<-- SIP read from 192.168.7.250:52141:
Asterisk seem to be thrown off by the fact that the return port is
not 5060, and fails the peer lookup. This is a * bug then. I have
documented it with both 1.0.9 and 1.2.1. Time to dig through the sip
code.
No, this is actually sane. This is necessary behavior in order to
support multiple SIP clients from behind the same NAT. Asterisk needs
to know the control port for your host, and it needs to stay consistent
between a REGISTER and an INVITE. If Asterisk sees a different control
port, it quite naturally assumes that that's a different client.
Thanks for the reply
I do not see this as sane, this is not a register, this is a peer
statement, and needs to be treated differently then a register. Any
call from this peer should be allowed regardless of the port used. I
agree that if I had registered and given a port that I should continue
to use said port. But in this case I never registered and calls from
192.168.7.250 should be allowed with out restriction. I am not a big
fan of the way cisco does a lot of stuff, but in this case using a
random port for an out going calls from the device to 5060 on the
receiving device is pretty normal way to establish a out going connection.
Although I think I can get the Cisco to always use 5060 as it's out
going port (and there work around the problem) I still think the error
is on the Asterisk side.
[bna-vonx-iad]
type=peer
context=trusted-out
host=192.168.7.250
canreinvite=no
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
