[Home]

Summary:ASTERISK-06475: [patch][post 1.4] Don't change NATed address on re-invites
Reporter:Paul Cadach (pcadach)Labels:
Date Opened:2006-03-04 22:15:21.000-0600Date Closed:2011-06-07 14:02:43
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) capture_call_dropped.txt
( 1) rtp.diff
( 2) sip-trace.txt
Description:When SIP/H.323 endpoint located behind NAT, RTP will negotiate its real IP address and port by listening for incoming RTP packets and remember this address for sending data to this endpoint. When re-invite (native bridge) is happens with such endpoint, endpoint will reports its address behind NAT, and chan_sip will update RTP information with this address, what will cause to re-invite for peer side. If peer side located behind NAT too this will provide looping by permanent chaning of RTP addresses by one then other side.

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

Attached patch addressed to resolve described issue by disabling update of RTP address/port pair if one specified with previous call to ast_set_rtp_peer() isn't changed.
Comments:By: Olle Johansson (oej) 2006-03-05 02:26:40.000-0600

Can we get SIP debug output on a situation like this?
By: Olle Johansson (oej) 2006-03-05 02:27:56.000-0600

If we have NAT support turned on, re-invites will not be issued. There's something I don't understand here.
By: Serge Vecher (serge-v) 2006-05-01 15:21:04

PCadach: did you have a chance to produce SIP debug log for Olle?
By: Paul Cadach (pcadach) 2006-05-12 22:49:33

I'll provide long H.323/SIP trace after next week when I'll have a free time.
By: Serge Vecher (serge-v) 2006-05-30 09:49:59

*ping*
By: Jeff Siddall (jsiddall) 2006-06-22 11:15:52

I'm having a problem that seems to match this bug so I'll upload a SIP debug trace in hopes it will help get this fixed.  Here's some background:
A is a UAC user behind a NAT, PUB-IP-OF-A is the UAC's public NATed address, PRIV-IP-OF-A is the UAC's private (configured) address.
B is the Asterisk box and IP-OF-B is it's public address
C is a UAS user, IP-OF-C is the UAS's public address

The trace starts at the Asterisk box's (B) native bridge attempt.  The first reinvite goes to C and correctly contains PUB-IP-OF-A (see line 22).

Next B reinvites A, which is also done correctly.  However, A's 200 OK contains the private address (see line 85) which seems to trigger Asterisk to incorrectly reinvite C again with the wrong address (PRIV-IP-OF-A) this time (see line 127), and thus audio stops working towards A.
By: Serge Vecher (serge-v) 2006-06-22 15:33:40

jsiddall: we also need debug log for this

1) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
2) Restart asterisk
3) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
4) Save complete log to file and _attach_ said file to the bug
By: Olle Johansson (oej) 2006-06-22 16:14:27

Well, why do you even try running re-invites when a NAT is involved? You should have nat=yes and not do *any* reinvites at all. It simply does not work...

Or am I totally misunderstanding here? If a client is behind NAT, we should configure it as NAT=yes.
By: Jeff Siddall (jsiddall) 2006-06-22 16:34:46

vechers, I'll try to get a complete debug log soon.

oej, Yes, it can work for certain types of NAT.  That's what nat=yes is for.  All Asterisk needs to do is take the information it has learned about the public address of the NATed UAC's and re-invite the other leg of the call with this information.  The strange thing here is that it appears that it does this correctly initially, but then undoes all it's good work by doing it again incorrectly.  I think this may have been working correctly in the past, but it has definitely not worked for a number of months now.
By: Olle Johansson (oej) 2006-06-23 03:10:32

Well, we've never supported re-invites over NATs. If it has worked, it's not by design. I can't see this as a bug to fix, more of a feature request. There is a reason why nat=yes turns off re-invites.
By: Olle Johansson (oej) 2006-10-29 14:57:49.000-0600

pcadach: This needs to be looked into again - when do you have nat and re-invites?
By: Anthony LaMantia (alamantia) 2006-12-15 19:09:02.000-0600

*poke* pcadach
By: Paul Cadach (pcadach) 2006-12-22 14:30:36.000-0600

I had it when tried to play with video between H.323 video-capable endpoint and SIP softphone connected together over ADSL NAT'ed link.
By: lukaso (lukaso) 2007-01-19 12:57:05.000-0600

I tested this patch, and (sadly) it did not work. What happened was that the call did not properly connect (no sound, no video).
By: Paul Cadach (pcadach) 2007-01-21 00:14:51.000-0600

lukaso, could you please provide rtp debug/etc. for your calls to check why it is not work?
By: lukaso (lukaso) 2007-01-21 08:05:09.000-0600

I have removed it from my system, so, sorry, not able to do that.
By: Serge Vecher (serge-v) 2007-03-13 10:48:28

Pasha, what do you want to do with this bug?
By: Paul Cadach (pcadach) 2007-03-16 00:44:18

serge-v: Just to integrate it into asterisk because I still think it should be useful. Unfortunately I still do not have repro (this problem was appear on playing with H.323<->SIP native bridging)...

When I'll have a bit of time I'll get back to H.323 native bridge code so this problem will appear again.
By: Amaia Lesta (axolass) 2007-05-07 11:14:40

I have the seame problem as jsiddall.
I have the following scheme design:

Local users --- AsteriskNOW Beta4 --- NAT item --- Internet --- NAT ITEM --- Users

-->I have included the following parameters in each account in the users.conf:
nat = yes
qualify = 3000

--> In sip.conf I have configured
nat = yes
canreinvite = nonat ;also tried no
port =  5060                          
bindaddr = 0.0.0.0              
externip = xxx.xxx.xxx.xxx             ; Public IP
localnet = 192.168.0.0/255.255.255.0   ; several lines with the IPs of the local nets


--> And in rtp.conf:
rtpstart=10000
rtpend=20000

A user outside the local network can call other users (both in the local network and in the Internet), but they can't hear each other, there is no sound.
If a user outside calls the voicemail he can hear the voicemail menu, but after 20seconds the call is finished by Asterisk, this is what I get from Asterisk:
    -- Executing [85000@default:1] VoiceMailMain("SIP/5060-083126d8", "") in new stack
    -- Playing 'vm-login' (language 'en')
[...]
[May  7 13:01:40] WARNING[4750]: chan_sip.c:1881 retrans_pkt: Maximum retries exceeded on transmission 1447a6-c0a80101-0-5@80.24.208.94 for seqno 1 (Critical Response)
[May  7 13:01:40] WARNING[4750]: chan_sip.c:1898 retrans_pkt: Hanging up call 1447a6-c0a80101-0-5@80.24.208.94 - no reply to our critical packet.
  == Spawn extension (default, 85000, 1) exited non-zero on 'SIP/5060-083126d8'


When analysign the call with Ethereal I discovered that the SIP messages are correctly interchanged between the user and Asterisk, but the RTP traffic from the useris destinated to the private IP address of Asterisk instead of to its public IP. I think that this is caused because the Asterisk sends a SIP/SDP Status: 200 OK, with session description message to the user and the Connection informations is "IN IP4 192.168.100.150" instead of "IN IP4 puclic.ip.of.asterisk".

The debug log is attched. 192.168.100.150 is the private IP of Asterisk and !92.50.20.77 is hte privte IP of the VoIP user.


What should I configure to get this scheme work properly?
By: Paul Cadach (pcadach) 2007-05-07 12:43:48

axolass, be noted that 192.50.xxx.xxx is outside of private addresses blocks.
By: Amaia Lesta (axolass) 2007-05-08 02:07:50

Dear PCadach,

Sorry, but I don't understand what you mean. Could you give me more details, please?
By: Paul Cadach (pcadach) 2007-05-08 12:26:12

Citate: "and !92.50.20.77 is hte privte IP of the VoIP user"

If the address is 92.50.20.77, then it is not private. 192.50.20.77 is not in private address space too.

Private address blocks are:
1) 192.168.0.0/16;
2) 172.16.0.0/12;
3) 10.0.0.0/8

I do not remember RFC's number exactly regarding private IP address space.


WBR,
Paul.
By: Amaia Lesta (axolass) 2007-05-09 02:24:17

I have test the same matter in an AsteriskNOW Beta5 and it seems to work properly. In this version I can call form a natted 192.50.20.X to the voicemail and Echo test extension and the call is not dropped. In the Ethereal the Contact Information in the SIP description is correct: the public IP of Asterisk. I can hear the voice mail and the Echo from my own micro

Nevertheless, when I tried to place a call between two extensions behind the same NAT router they couldn't hear each other. The caller sends the RTP traffic to the public IP of the callee and the public IP of Asterisk sends RTP traffic to the caller. To get all the RTP traffic through the Asterisk instead of sending it to the public IP of the callee. To get this I set in every user account in users.conf canreinivite = no. Until not it was only set in the sip.conf.

Now it is working in Beta5.
By: Olle Johansson (oej) 2007-12-16 03:07:22.000-0600

THis is an issue for file, re-assigning to him.
By: Joshua C. Colp (jcolp) 2008-01-31 12:31:11.000-0600

PCadach: I've gone over this many times, reread it a lot, and am extremely hesitant with changing it until I see a SIP trace of the actual issue. Until that time I'm suspending this.