[asterisk-dev] Asterisk, rport and RFC 3581 problems - Is this a bug?

Marc contact_marcos at yahoo.es
Tue Jun 27 22:10:58 MST 2006


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



More information about the asterisk-dev mailing list