Hi,
I am experiencing what seems to be a bug in Asterisk and I just wanted
to throw it out to this list before I post it to the issue tracker just
to see if anybody knows anything more about it. Who knows, it could
turn out to be a "feature".
I am connecting to a remote Asterisk box from behind a NAT. When my SIP
client (xlite 3.0) sends a register message to Asterisk, it appends
;rport to the end of the Via header. According to RFC 3581 [1], Asterisk
should (a) append the port on which it received the request to the Via
header, (b) send the response to the ip and port it received the message
from rather than the ip and port in the original Via header. As far as
I can tell Asterisk is not doing this when I set nat=rfc3581 in
sip.cofd. When I look at the network traffic on the server using
ethereal, it tries to send the SIP responses to my local IP address and
port.
[1] http://www.ietf.org/rfc/rfc3581.txt
This behaviour is likely to affect anybody moving from xlite 2 to xlite
3 who is connecting from behind a NAT and using STUN. When using STUN,
xlite 2 would automatically rewrite the VIA header to use the external
IP and port. This is no longer the case with xlite 3, the private IP is
used and ;rport is appended. So to people who upgrade it looks like
xlite is broken [2], when in fact it seems like Asterisk is failing to
follow the RFC.
[2] http://support.counterpath.com/viewtopic.php?t=6665
In doing a google search on the issue I even ran across what looks to be
the offending line of source code in the auto-generated doxygen page for
chan_sip.c [3]. In the copy_via_headers function on line 04254 the
following test is used to determine whether or not to append the rport
value to the via headers:
if (rport && ast_test_flag(&p->flags[0], SIP_NAT) == SIP_NAT_ALWAYS) {
/* We need to add received port - rport */
My C isn't all that great, but shouldn't they be testing for the
SIP_NAT_RFC3581 constant instead? As far as I can tell SIP_NAT_ALWAYS
is equivalent to nat=yes and SIP_NAT_RFC3581 is equivalent to
nat=rfc3581 [4].
[3] http://www.asterisk.org/doxygen/chan__sip_8c.html#a459
[4] http://www.asterisk.org/doxygen/chan__sip_8c.html#a92
Anybody run across this problem? Is this a known bug? Searches in
Mantis didn't turn anything up.
Marc
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
_______________________________________________
--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
