On 12/18/2011 01:22 PM, José Pablo Méndez Soto wrote:
Embarrassingly enough, I just tried the nat=no again both in the
general and peer sections and the blessed phone registered.... My
apologies, again, I wrote the thread late at night probably this blinded me.
No problem, we've all done that :-)
Now, one question about a previous answer from you ("It is exactly that;
'force_rport' is now the default....."):
is the trigger for using the source UDP port from the REGISTER, inside
the rport field and inside the destination UDP port of the 200 OK:
1. The mismatch between the UDP source port of the REGISTER and the VIA
port? Or
2. The fact that the other entity sends an empty rport?
3. Or any of the above?
Its a difficult question to ask/describe, so if I am not asking
correctly please let me know. Thanks a lot, really.
Not at all. The trigger for Asterisk to respond to the port that the
request was sent from, instead of the port listed in the top-most Via
header, is *exactly* 'force_rport'. This causes Asterisk to behave as if
the 'rport' parameter was included in the top-most Via header, which
would be an explicit request from the sending UA for Asterisk to respond
to the sending port (and also report back what the sending port was, but
that's not part of the problem here).
So, if the sending UA include an empty 'rport' parameter in its top-most
Via header, *or* if the Asterisk has been told to act as if one had been
included even if it wasn't, then Asterisk will respond to the perceived
sending port; otherwise, it will respond to the port listed in the
top-most Via header.
As far as we know from our research before making this change, the Cisco
phones in question are the only ones that send their requests from one
port and require the responses to go back to a different port. All other
phones that we (and others) use with Asterisk use the same port for
both, which makes them quite easy to use behind NAT devices. The Cisco
phone models you are dealing with won't work behind a NAT device unless
that NAT device has a 'helper' that understands SIP and can fix up this
situation (and of course many Cisco phone users have Cisco routers that
do exactly this).
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email protected] | SIP: [email protected] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
