[Home]

Summary:ASTERISK-07276: Asterisk fails to follow RFC3581 when SIP client sends ;rport in REGISTER message
Reporter:mrichar1 (mrichar1)Labels:
Date Opened:2006-07-03 22:51:43Date Closed:2006-11-28 15:34:53.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 1.2.9.1_console_debug.txt
( 1) sip_debug_with_nat_equals_no.txt
Description: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=no (a.k.a nat=rfc3581) in sip.conf. 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


I have attached the output of the debugging info from the asterisk console.  Pretty much just a series of register request and 401 responses that never make it back to the client.  Unique info has been X'd out to protect the innocent.


****** ADDITIONAL INFORMATION ******

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.  In the copy_via_headers function 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=no (a.k.a nat=rfc3581).


One more thing.  In reading over RFC 3581 I got the impression that Asterisk should ALWAYS (rport or no rport) send SIP responses to the IP address it receives the request from.  The only piece of information that it should get from the SIP headers is the port number.  Here is the relevant bit of text from the RFC 3581 Introduction:

  "The Session Initiation Protocol (SIP) [1] operates over UDP and TCP.
  When used with UDP, responses to requests are returned to the source
  address the request came from, and to the port written into the
  topmost Via header field value of the request.  This results in a
  "hybrid" way of computing the destination of the response.  Half of
  the information (specifically, the IP address) is taken from the IP
  packet headers, and the other half (specifically, the port) from the
  SIP message headers."

Comments:By: Serge Vecher (serge-v) 2006-07-05 10:20:03

Ok, a couple of things:
1. chan_sip has received many bugfixes between 1.2.7.1 and 1.2.9.1. Please update and redo your test;
2. There is no debug log in sip_debug_with_nat_equals_no.txt. Please do the following to get debug log from 1.2.9.1.
a) Prepare test environment (reduce the ammount of unrelated traffic on the server);
b) Make sure your logger.conf has the following line:
   console => notice,warning,error,debug
c) restart Asterik.
d) Enable SIP transaction logging with the following CLI commands:
   set debug 4
   set verbose 4
   sip debug
e) Save complete log to file and _attach_ said file to the bug.
By: mrichar1 (mrichar1) 2006-07-09 12:56:59

>> 1. chan_sip has received many bugfixes between 1.2.7.1 and 1.2.9.1. Please update and redo your test;

Done.  No change.


>> ... e) Save complete log to file and _attach_ said file to the bug.

Done. See attached.
By: Serge Vecher (serge-v) 2006-09-01 14:11:05

oej ping
By: Anthony LaMantia (alamantia) 2006-10-30 16:30:40.000-0600

mrichar1, over the past week there have been some functionality changes to chan_sip that may have resolved this issue, i am going to lab up this situation on my own here and see what the results are, have you noticed this behaviour changes with the latest release of asterisk 1.2.13 or the 1.2svn branch?
By: Olle Johansson (oej) 2006-10-31 02:40:31.000-0600

Haven't touched this area lately. Symmetric sip is a an option. If we do that by default, we would not be able to talk with a lot of devices.

We need to fix rport for REGISTER. I don't think the NAT settings for the device is handled in the REGISTER, so that the ;rport is not treated at all.
By: Olle Johansson (oej) 2006-10-31 02:43:06.000-0600

We run check_via in handle_request_register *before* we match the peer. So when running the check_via, we have no idea of the NAT setting, unless it's a global option.
By: Olle Johansson (oej) 2006-10-31 02:49:58.000-0600

I've added the flags needed. Please try with latest 1.2 from subversion to see if we now have proper ;rport for REGISTER requests.

[serge-v edit]: r.46610+


By: Olle Johansson (oej) 2006-11-12 13:46:50.000-0600

I need a confirmation from you that this has been fixed. Thank you!
By: Anthony LaMantia (alamantia) 2006-11-28 11:15:08.000-0600

my testing shows this issue to be resolved.
By: Anthony LaMantia (alamantia) 2006-11-28 15:33:21.000-0600

fixed in r.46610.. testing confirms the rport responses are accurate..
but feel free to reopen this issue if you are still having problems.