Heres my understanding...hope it helps (may even confuse), and looking for corrections...its a long read
1. There are 4 different types of NAT a) Full Cone b) restricted cone c) port restricted d) symmetric
a,b,c are also referred to as asymmetric NAT.
2. SIP has a problem because the siganalling uses one path and the media stream another.
3. Full cone - Anyone of the internet can send packets to the IP:port combo, this is mapped to a internal IP:port.
4. Restricted Cone - Only those external PC which have been contacted are ALLOWED to contact via the mapping, i.e if I contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on that NAT mapping, PC(b) cannot
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) If pc(b) sends to 202.70.65.78:10000 there will be nothing sent through to 10.1.1.1:123
5. Port restricted Cone - Same as restricted but instead of just detecting that the source IP is that of pc(a), it also looks to see if the source port is the same
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) [213.123.324.34:8000]
The nat will only accept inbound from 213.123.324.34 and if it comes from port 8000
6. Symmetric - This is the easy one, 10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a) 10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
In the NAT the IP:port pair is different for each external client, so eeach external client has a mapping of its own
7. The problem RTP
In RTP the message body has the info needed for the UA to communicate successfully. This body is called the SDP message. The problem is that the client doesnt know anything about the NAT, hence the IP addresses which are contained in the SDP are usually the internal ones, i.e what the client knows....so when the endpoints want to "talk" they look at the IP in the message and you get nothing because these are usually internal IP addresses.
EG
INVITE sip:040600@192.168.20.2:5060 SIP/2.0. Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. To: sip:040600@sip.dom.com. Contact: sip:040618@223.178.140.109:1024. Supported: replaces. Call-ID: 7f2c327896a5b0e1@192.168.20.3. CSeq: 8717 INVITE. User-Agent: Grandstream HT487 1.0.5.18. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 343. . v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
This header is just like email headers hence u read it backwards, so if you look at the line above the From: line you see the first Via, which is what the client thinks it is i.e 192.168.20.3, BUT the proxy is clever, it knows where it received the message from , and it adds the rport and received tags
Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
Soooo the proxy can talk SIP fine, because it knows these IP addresses.
BUT...poor old RTP is stuck because its headers or should I say direction is held lower down :
v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
The client expects to receive on port m=38660 and IP c= 192.168.20.3, which is where the other endpoint will try to send "voice" to.
8 Solution - You need to tell the client, not to act so dumb, and work out what the NAT settings are and put them in the SDP section of the message. So the client can ask the NAT....or it can ask someone on the outside what it should be.
9. Ask the NAT - use UPnP...I dont have much info on this..:-)
10. Ask someone on the outside -- You send a probe packet to the server sitting outside, it then sends a message back, with the details it received, the client then decides if its behind a NAT. This can be used for all 4 cases of NAT.
EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP message m=1000 and c=10.1.1.1, but if I send out a probe first, and I get back 212.134.123.23:12345 then I can rewrite the SDP so m=12345 and c=10.1.1.1 , simple
Problem -- Since NAT settings are dynamic, and hence tend to change, you really need to get the SIP message out very soon after sending the probing message out,
The client send and receive ports must be the same
And....if you recall the restricted cones (port restricted included) will not allow replies unless there has been a packet sent out to that destination first, hence the client needs to send a packet out to the endpoint, b4 he can be allowed in via the NAT (but we dont need to worry about that)
IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because the external UA IP:port is different to that where we sent the probe, hence the voice packet coming back will not have the correct path set.
11. The above is usually done with a STUN server, and sending the packet out to this server
12. Symmetric NAT--- use a relay in the middle...Nathelper+ rtpproxy or mediaproxy
13 Nathelper a) fix_nated_contact - rewrites contact Hf to source IP:port b) fix_nated_sdp - rewritres media IP and also direction ???? c) force_rtp_proxy - forces media to go through proxy d) nat_uac_test - mode=1 then as shown above the "received" header is compared to c= in sdp mode=2 then the Contact header is looked at to see if its private mode=3 (1+2) means it does both of the above
14) mediaproxy is much the same...and good examples are available
15)Summary
4 types of NAT, which can be combined into 2 main sets, asymmetric and symmetric.
Asymmetric issues can be resolved by using STUN, hence no need for mediaproxy/nathelper Symmetric clients cant use STUN, hence u need to use mediaproxy/nathelper (or some other server end...also known as far-end nat traversal solution)
However if you didnt want to use STUN and mediaproxy/nathelper, then you could just use mediaproxy/nathelper and setup port forwarding on your NAT device.
I think that covers most, any suggestions let me know, I wrote this for my own use, but if its useful, I'll tidy it up.
One question....
Is there any way via a debug log, albeit, ngrep, tcpdump, sip_scenario display that I can from the server side detect if the NAT is asymmetric or Symmetric.
tks Iqbal
Very nice and well written, Many many thanks.
One question, If a client from Assymetric NAT and it comes through STUN, does SER see that client as a *nated* client? And, if a client from Symentric NAT and it still comes through STUN, SER see that client as Nated client, right?
See below:
Iqbal wrote:
Heres my understanding...hope it helps (may even confuse), and looking for corrections...its a long read
- There are 4 different types of NAT
a) Full Cone b) restricted cone c) port restricted d) symmetric
a,b,c are also referred to as asymmetric NAT.
- SIP has a problem because the siganalling uses one path and the media
stream another.
- Full cone - Anyone of the internet can send packets to the IP:port
combo, this is mapped to a internal IP:port.
- Restricted Cone - Only those external PC which have been contacted are
ALLOWED to contact via the mapping, i.e if I contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on that NAT mapping, PC(b) cannot
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) If pc(b) sends to 202.70.65.78:10000 there will be nothing sent through to 10.1.1.1:123
- Port restricted Cone - Same as restricted but instead of just
detecting that the source IP is that of pc(a), it also looks to see if the source port is the same
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) [213.123.324.34:8000]
The nat will only accept inbound from 213.123.324.34 and if it comes from port 8000
- Symmetric - This is the easy one,
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
^^ you mean 10.1.1.x ( x is other than 1), right? I think, this was a typo.
Thanks, Mohammad
In the NAT the IP:port pair is different for each external client, so eeach external client has a mapping of its own
- The problem RTP
In RTP the message body has the info needed for the UA to communicate successfully. This body is called the SDP message. The problem is that the client doesnt know anything about the NAT, hence the IP addresses which are contained in the SDP are usually the internal ones, i.e what the client knows....so when the endpoints want to "talk" they look at the IP in the message and you get nothing because these are usually internal IP addresses.
EG
INVITE sip:040600@192.168.20.2:5060 SIP/2.0. Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. To: sip:040600@sip.dom.com. Contact: sip:040618@223.178.140.109:1024. Supported: replaces. Call-ID: 7f2c327896a5b0e1@192.168.20.3. CSeq: 8717 INVITE. User-Agent: Grandstream HT487 1.0.5.18. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 343. . v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
This header is just like email headers hence u read it backwards, so if you look at the line above the From: line you see the first Via, which is what the client thinks it is i.e 192.168.20.3, BUT the proxy is clever, it knows where it received the message from , and it adds the rport and received tags
Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
Soooo the proxy can talk SIP fine, because it knows these IP addresses.
BUT...poor old RTP is stuck because its headers or should I say direction is held lower down :
v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
The client expects to receive on port m=38660 and IP c= 192.168.20.3, which is where the other endpoint will try to send "voice" to.
8 Solution - You need to tell the client, not to act so dumb, and work out what the NAT settings are and put them in the SDP section of the message. So the client can ask the NAT....or it can ask someone on the outside what it should be.
Ask the NAT - use UPnP...I dont have much info on this..:-)
Ask someone on the outside --
You send a probe packet to the server sitting outside, it then sends a message back, with the details it received, the client then decides if its behind a NAT. This can be used for all 4 cases of NAT.
EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP message m=1000 and c=10.1.1.1, but if I send out a probe first, and I get back 212.134.123.23:12345 then I can rewrite the SDP so m=12345 and c=10.1.1.1 , simple
Problem -- Since NAT settings are dynamic, and hence tend to change, you really need to get the SIP message out very soon after sending the probing message out,
The client send and receive ports must be the same
And....if you recall the restricted cones (port restricted included) will not allow replies unless there has been a packet sent out to that destination first, hence the client needs to send a packet out to the endpoint, b4 he can be allowed in via the NAT (but we dont need to worry about that)
IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because the external UA IP:port is different to that where we sent the probe, hence the voice packet coming back will not have the correct path set.
- The above is usually done with a STUN server, and sending the packet
out to this server
- Symmetric NAT--- use a relay in the middle...Nathelper+ rtpproxy or
mediaproxy
13 Nathelper a) fix_nated_contact - rewrites contact Hf to source IP:port b) fix_nated_sdp - rewritres media IP and also direction ???? c) force_rtp_proxy - forces media to go through proxy d) nat_uac_test - mode=1 then as shown above the "received" header is compared to c= in sdp mode=2 then the Contact header is looked at to see if its private mode=3 (1+2) means it does both of the above
- mediaproxy is much the same...and good examples are available
15)Summary
4 types of NAT, which can be combined into 2 main sets, asymmetric and symmetric.
Asymmetric issues can be resolved by using STUN, hence no need for mediaproxy/nathelper Symmetric clients cant use STUN, hence u need to use mediaproxy/nathelper (or some other server end...also known as far-end nat traversal solution)
However if you didnt want to use STUN and mediaproxy/nathelper, then you could just use mediaproxy/nathelper and setup port forwarding on your NAT device.
I think that covers most, any suggestions let me know, I wrote this for my own use, but if its useful, I'll tidy it up.
One question....
Is there any way via a debug log, albeit, ngrep, tcpdump, sip_scenario display that I can from the server side detect if the NAT is asymmetric or Symmetric.
tks Iqbal
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
maybe well written but I have come across another question, in the ser.cfg file on onsip it mentions that with correct use of the mediaproxy you can deal with asymmetric and symmetric, hence my summary may be wrong.
Symmetric CANNOT go through STUN, it wont work. hence the STUN is no use, and yes then ser will see it as natted.
If asymmetric comes via STUN, and the client understands what the STUN server has sent back, and can fix itself then ser will NOT see it has natted, since its been fixed
Iqbal
On 4/2/2005, "Mohammad Khan" info@beeplove.com wrote:
Very nice and well written, Many many thanks.
One question, If a client from Assymetric NAT and it comes through STUN, does SER see that client as a *nated* client? And, if a client from Symentric NAT and it still comes through STUN, SER see that client as Nated client, right?
See below:
Iqbal wrote:
Heres my understanding...hope it helps (may even confuse), and looking for corrections...its a long read
- There are 4 different types of NAT
a) Full Cone b) restricted cone c) port restricted d) symmetric
a,b,c are also referred to as asymmetric NAT.
- SIP has a problem because the siganalling uses one path and the media
stream another.
- Full cone - Anyone of the internet can send packets to the IP:port
combo, this is mapped to a internal IP:port.
- Restricted Cone - Only those external PC which have been contacted are
ALLOWED to contact via the mapping, i.e if I contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on that NAT mapping, PC(b) cannot
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) If pc(b) sends to 202.70.65.78:10000 there will be nothing sent through to 10.1.1.1:123
- Port restricted Cone - Same as restricted but instead of just
detecting that the source IP is that of pc(a), it also looks to see if the source port is the same
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) [213.123.324.34:8000]
The nat will only accept inbound from 213.123.324.34 and if it comes from port 8000
- Symmetric - This is the easy one,
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
^^you mean 10.1.1.x ( x is other than 1), right? I think, this was a typo.
Thanks, Mohammad
In the NAT the IP:port pair is different for each external client, so eeach external client has a mapping of its own
- The problem RTP
In RTP the message body has the info needed for the UA to communicate successfully. This body is called the SDP message. The problem is that the client doesnt know anything about the NAT, hence the IP addresses which are contained in the SDP are usually the internal ones, i.e what the client knows....so when the endpoints want to "talk" they look at the IP in the message and you get nothing because these are usually internal IP addresses.
EG
INVITE sip:040600@192.168.20.2:5060 SIP/2.0. Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. To: sip:040600@sip.dom.com. Contact: sip:040618@223.178.140.109:1024. Supported: replaces. Call-ID: 7f2c327896a5b0e1@192.168.20.3. CSeq: 8717 INVITE. User-Agent: Grandstream HT487 1.0.5.18. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 343. . v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
This header is just like email headers hence u read it backwards, so if you look at the line above the From: line you see the first Via, which is what the client thinks it is i.e 192.168.20.3, BUT the proxy is clever, it knows where it received the message from , and it adds the rport and received tags
Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
Soooo the proxy can talk SIP fine, because it knows these IP addresses.
BUT...poor old RTP is stuck because its headers or should I say direction is held lower down :
v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
The client expects to receive on port m=38660 and IP c= 192.168.20.3, which is where the other endpoint will try to send "voice" to.
8 Solution - You need to tell the client, not to act so dumb, and work out what the NAT settings are and put them in the SDP section of the message. So the client can ask the NAT....or it can ask someone on the outside what it should be.
Ask the NAT - use UPnP...I dont have much info on this..:-)
Ask someone on the outside --
You send a probe packet to the server sitting outside, it then sends a message back, with the details it received, the client then decides if its behind a NAT. This can be used for all 4 cases of NAT.
EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP message m=1000 and c=10.1.1.1, but if I send out a probe first, and I get back 212.134.123.23:12345 then I can rewrite the SDP so m=12345 and c=10.1.1.1 , simple
Problem -- Since NAT settings are dynamic, and hence tend to change, you really need to get the SIP message out very soon after sending the probing message out,
The client send and receive ports must be the same
And....if you recall the restricted cones (port restricted included) will not allow replies unless there has been a packet sent out to that destination first, hence the client needs to send a packet out to the endpoint, b4 he can be allowed in via the NAT (but we dont need to worry about that)
IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because the external UA IP:port is different to that where we sent the probe, hence the voice packet coming back will not have the correct path set.
- The above is usually done with a STUN server, and sending the packet
out to this server
- Symmetric NAT--- use a relay in the middle...Nathelper+ rtpproxy or
mediaproxy
13 Nathelper a) fix_nated_contact - rewrites contact Hf to source IP:port b) fix_nated_sdp - rewritres media IP and also direction ???? c) force_rtp_proxy - forces media to go through proxy d) nat_uac_test - mode=1 then as shown above the "received" header is compared to c= in sdp mode=2 then the Contact header is looked at to see if its private mode=3 (1+2) means it does both of the above
- mediaproxy is much the same...and good examples are available
15)Summary
4 types of NAT, which can be combined into 2 main sets, asymmetric and symmetric.
Asymmetric issues can be resolved by using STUN, hence no need for mediaproxy/nathelper Symmetric clients cant use STUN, hence u need to use mediaproxy/nathelper (or some other server end...also known as far-end nat traversal solution)
However if you didnt want to use STUN and mediaproxy/nathelper, then you could just use mediaproxy/nathelper and setup port forwarding on your NAT device.
I think that covers most, any suggestions let me know, I wrote this for my own use, but if its useful, I'll tidy it up.
One question....
Is there any way via a debug log, albeit, ngrep, tcpdump, sip_scenario display that I can from the server side detect if the NAT is asymmetric or Symmetric.
tks Iqbal
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Iqbal wrote:
maybe well written but I have come across another question, in the ser.cfg file on onsip it mentions that with correct use of the mediaproxy you can deal with asymmetric and symmetric, hence my summary may be wrong.
No, your summary is correct. The config files in the onsip.org document have the assumptions that STUN is NOT used. Hence, all NATed devices will be proxied. When STUN is used, it is transparent and the config files will see the client as non-NATed.
Symmetric CANNOT go through STUN, it wont work. hence the STUN is no use, and yes then ser will see it as natted.
One big problem is that many clients have faulty STUN implementations, even specific firmware can have problems (Grandstream changed its behavior to wrong handling of symmetric NAT in 10.5.16, I think).
In fact, it is possible both to detect (some of) these faulty implementations (i.e. faulty handling of symmetric NAT, ex. using test 16 in nathelper), but not if ex. a full-cone is detected when in fact, it's a restricted NAT. (Let me add that there also are many mutations/implemenations of the four NAT types that can confuse STUN...)
Conclusion: ALWAYS test the clients you want to use with STUN!
We are considering adding an appendix with advanced NAT techniques in ser.cfg including on where you can use STUN (test your clients) as well as direction=active supported PSTN gateways (used to allow non-proxied outgoing calls from a call behind a symmetric NAT) to reduce the proxied calls to the following: - SIP-SIP when one or both are behind symmetric - PSTN-SIP when the SIP client is behind symmetric
We'll see when we get the time. There are lots of more basic stuff we need to do first. g-)
If asymmetric comes via STUN, and the client understands what the STUN server has sent back, and can fix itself then ser will NOT see it has natted, since its been fixed
Iqbal
On 4/2/2005, "Mohammad Khan" info@beeplove.com wrote:
Very nice and well written, Many many thanks.
One question, If a client from Assymetric NAT and it comes through STUN, does SER see that client as a *nated* client? And, if a client from Symentric NAT and it still comes through STUN, SER see that client as Nated client, right?
See below:
Iqbal wrote:
Heres my understanding...hope it helps (may even confuse), and looking for corrections...its a long read
- There are 4 different types of NAT
a) Full Cone b) restricted cone c) port restricted d) symmetric
a,b,c are also referred to as asymmetric NAT.
- SIP has a problem because the siganalling uses one path and the
media stream another.
- Full cone - Anyone of the internet can send packets to the
IP:port combo, this is mapped to a internal IP:port.
- Restricted Cone - Only those external PC which have been
contacted are ALLOWED to contact via the mapping, i.e if I contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on that NAT mapping, PC(b) cannot
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) If pc(b) sends to 202.70.65.78:10000 there will be nothing sent through to 10.1.1.1:123
- Port restricted Cone - Same as restricted but instead of just
detecting that the source IP is that of pc(a), it also looks to see if the source port is the same
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) [213.123.324.34:8000]
The nat will only accept inbound from 213.123.324.34 and if it comes from port 8000
- Symmetric - This is the easy one,
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
^^you mean 10.1.1.x ( x is other than 1), right? I think, this was a typo.
Thanks, Mohammad
In the NAT the IP:port pair is different for each external client, so eeach external client has a mapping of its own
- The problem RTP
In RTP the message body has the info needed for the UA to communicate successfully. This body is called the SDP message. The problem is that the client doesnt know anything about the NAT, hence the IP addresses which are contained in the SDP are usually the internal ones, i.e what the client knows....so when the endpoints want to "talk" they look at the IP in the message and you get nothing because these are usually internal IP addresses.
EG
INVITE sip:040600@192.168.20.2:5060 SIP/2.0. Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. To: sip:040600@sip.dom.com. Contact: sip:040618@223.178.140.109:1024. Supported: replaces. Call-ID: 7f2c327896a5b0e1@192.168.20.3. CSeq: 8717 INVITE. User-Agent: Grandstream HT487 1.0.5.18. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 343. . v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
This header is just like email headers hence u read it backwards, so if you look at the line above the From: line you see the first Via, which is what the client thinks it is i.e 192.168.20.3, BUT the proxy is clever, it knows where it received the message from , and it adds the rport and received tags
Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
Soooo the proxy can talk SIP fine, because it knows these IP addresses.
BUT...poor old RTP is stuck because its headers or should I say direction is held lower down :
v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
The client expects to receive on port m=38660 and IP c= 192.168.20.3, which is where the other endpoint will try to send "voice" to.
8 Solution - You need to tell the client, not to act so dumb, and work out what the NAT settings are and put them in the SDP section of the message. So the client can ask the NAT....or it can ask someone on the outside what it should be.
Ask the NAT - use UPnP...I dont have much info on this..:-)
Ask someone on the outside --
You send a probe packet to the server sitting outside, it then sends a message back, with the details it received, the client then decides if its behind a NAT. This can be used for all 4 cases of NAT.
EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP message m=1000 and c=10.1.1.1, but if I send out a probe first, and I get back 212.134.123.23:12345 then I can rewrite the SDP so m=12345 and c=10.1.1.1 , simple
Problem -- Since NAT settings are dynamic, and hence tend to change, you really need to get the SIP message out very soon after sending the probing message out,
The client send and receive ports must be the same
And....if you recall the restricted cones (port restricted included) will not allow replies unless there has been a packet sent out to that destination first, hence the client needs to send a packet out to the endpoint, b4 he can be allowed in via the NAT (but we dont need to worry about that)
IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because the external UA IP:port is different to that where we sent the probe, hence the voice packet coming back will not have the correct path set.
- The above is usually done with a STUN server, and sending the
packet out to this server
- Symmetric NAT--- use a relay in the middle...Nathelper+
rtpproxy or mediaproxy
13 Nathelper a) fix_nated_contact - rewrites contact Hf to source IP:port b) fix_nated_sdp - rewritres media IP and also direction ???? c) force_rtp_proxy - forces media to go through proxy d) nat_uac_test - mode=1 then as shown above the "received" header is compared to c= in sdp mode=2 then the Contact header is looked at to see if its private mode=3 (1+2) means it does both of the above
- mediaproxy is much the same...and good examples are available
15)Summary
4 types of NAT, which can be combined into 2 main sets, asymmetric and symmetric.
Asymmetric issues can be resolved by using STUN, hence no need for mediaproxy/nathelper Symmetric clients cant use STUN, hence u need to use mediaproxy/nathelper (or some other server end...also known as far-end nat traversal solution)
However if you didnt want to use STUN and mediaproxy/nathelper, then you could just use mediaproxy/nathelper and setup port forwarding on your NAT device.
I think that covers most, any suggestions let me know, I wrote this for my own use, but if its useful, I'll tidy it up.
One question....
Is there any way via a debug log, albeit, ngrep, tcpdump, sip_scenario display that I can from the server side detect if the NAT is asymmetric or Symmetric.
tks Iqbal
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Thanks Greg, so from what I understand its better NOT to use STUN, and do fat end traversal all the time, i.e do it at SER level whether its asymmetric or symmetric
Iqbal
On 4/3/2005, "Greger V. Teigre" greger@teigre.com wrote:
Iqbal wrote:
maybe well written but I have come across another question, in the ser.cfg file on onsip it mentions that with correct use of the mediaproxy you can deal with asymmetric and symmetric, hence my summary may be wrong.
No, your summary is correct. The config files in the onsip.org document have the assumptions that STUN is NOT used. Hence, all NATed devices will be proxied. When STUN is used, it is transparent and the config files will see the client as non-NATed.
Symmetric CANNOT go through STUN, it wont work. hence the STUN is no use, and yes then ser will see it as natted.
One big problem is that many clients have faulty STUN implementations, even specific firmware can have problems (Grandstream changed its behavior to wrong handling of symmetric NAT in 10.5.16, I think).
In fact, it is possible both to detect (some of) these faulty implementations (i.e. faulty handling of symmetric NAT, ex. using test 16 in nathelper), but not if ex. a full-cone is detected when in fact, it's a restricted NAT. (Let me add that there also are many mutations/implemenations of the four NAT types that can confuse STUN...)
Conclusion: ALWAYS test the clients you want to use with STUN!
We are considering adding an appendix with advanced NAT techniques in ser.cfg including on where you can use STUN (test your clients) as well as direction=active supported PSTN gateways (used to allow non-proxied outgoing calls from a call behind a symmetric NAT) to reduce the proxied calls to the following:
- SIP-SIP when one or both are behind symmetric
- PSTN-SIP when the SIP client is behind symmetric
We'll see when we get the time. There are lots of more basic stuff we need to do first. g-)
If asymmetric comes via STUN, and the client understands what the STUN server has sent back, and can fix itself then ser will NOT see it has natted, since its been fixed
Iqbal
On 4/2/2005, "Mohammad Khan" info@beeplove.com wrote:
Very nice and well written, Many many thanks.
One question, If a client from Assymetric NAT and it comes through STUN, does SER see that client as a *nated* client? And, if a client from Symentric NAT and it still comes through STUN, SER see that client as Nated client, right?
See below:
Iqbal wrote:
Heres my understanding...hope it helps (may even confuse), and looking for corrections...its a long read
- There are 4 different types of NAT
a) Full Cone b) restricted cone c) port restricted d) symmetric
a,b,c are also referred to as asymmetric NAT.
- SIP has a problem because the siganalling uses one path and the
media stream another.
- Full cone - Anyone of the internet can send packets to the
IP:port combo, this is mapped to a internal IP:port.
- Restricted Cone - Only those external PC which have been
contacted are ALLOWED to contact via the mapping, i.e if I contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on that NAT mapping, PC(b) cannot
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) If pc(b) sends to 202.70.65.78:10000 there will be nothing sent through to 10.1.1.1:123
- Port restricted Cone - Same as restricted but instead of just
detecting that the source IP is that of pc(a), it also looks to see if the source port is the same
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) [213.123.324.34:8000]
The nat will only accept inbound from 213.123.324.34 and if it comes from port 8000
- Symmetric - This is the easy one,
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
^^you mean 10.1.1.x ( x is other than 1), right? I think, this was a typo.
Thanks, Mohammad
In the NAT the IP:port pair is different for each external client, so eeach external client has a mapping of its own
- The problem RTP
In RTP the message body has the info needed for the UA to communicate successfully. This body is called the SDP message. The problem is that the client doesnt know anything about the NAT, hence the IP addresses which are contained in the SDP are usually the internal ones, i.e what the client knows....so when the endpoints want to "talk" they look at the IP in the message and you get nothing because these are usually internal IP addresses.
EG
INVITE sip:040600@192.168.20.2:5060 SIP/2.0. Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. To: sip:040600@sip.dom.com. Contact: sip:040618@223.178.140.109:1024. Supported: replaces. Call-ID: 7f2c327896a5b0e1@192.168.20.3. CSeq: 8717 INVITE. User-Agent: Grandstream HT487 1.0.5.18. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 343. . v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
This header is just like email headers hence u read it backwards, so if you look at the line above the From: line you see the first Via, which is what the client thinks it is i.e 192.168.20.3, BUT the proxy is clever, it knows where it received the message from , and it adds the rport and received tags
Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
Soooo the proxy can talk SIP fine, because it knows these IP addresses.
BUT...poor old RTP is stuck because its headers or should I say direction is held lower down :
v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
The client expects to receive on port m=38660 and IP c= 192.168.20.3, which is where the other endpoint will try to send "voice" to.
8 Solution - You need to tell the client, not to act so dumb, and work out what the NAT settings are and put them in the SDP section of the message. So the client can ask the NAT....or it can ask someone on the outside what it should be.
Ask the NAT - use UPnP...I dont have much info on this..:-)
Ask someone on the outside --
You send a probe packet to the server sitting outside, it then sends a message back, with the details it received, the client then decides if its behind a NAT. This can be used for all 4 cases of NAT.
EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP message m=1000 and c=10.1.1.1, but if I send out a probe first, and I get back 212.134.123.23:12345 then I can rewrite the SDP so m=12345 and c=10.1.1.1 , simple
Problem -- Since NAT settings are dynamic, and hence tend to change, you really need to get the SIP message out very soon after sending the probing message out,
The client send and receive ports must be the same
And....if you recall the restricted cones (port restricted included) will not allow replies unless there has been a packet sent out to that destination first, hence the client needs to send a packet out to the endpoint, b4 he can be allowed in via the NAT (but we dont need to worry about that)
IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because the external UA IP:port is different to that where we sent the probe, hence the voice packet coming back will not have the correct path set.
- The above is usually done with a STUN server, and sending the
packet out to this server
- Symmetric NAT--- use a relay in the middle...Nathelper+
rtpproxy or mediaproxy
13 Nathelper a) fix_nated_contact - rewrites contact Hf to source IP:port b) fix_nated_sdp - rewritres media IP and also direction ???? c) force_rtp_proxy - forces media to go through proxy d) nat_uac_test - mode=1 then as shown above the "received" header is compared to c= in sdp mode=2 then the Contact header is looked at to see if its private mode=3 (1+2) means it does both of the above
- mediaproxy is much the same...and good examples are available
15)Summary
4 types of NAT, which can be combined into 2 main sets, asymmetric and symmetric.
Asymmetric issues can be resolved by using STUN, hence no need for mediaproxy/nathelper Symmetric clients cant use STUN, hence u need to use mediaproxy/nathelper (or some other server end...also known as far-end nat traversal solution)
However if you didnt want to use STUN and mediaproxy/nathelper, then you could just use mediaproxy/nathelper and setup port forwarding on your NAT device.
I think that covers most, any suggestions let me know, I wrote this for my own use, but if its useful, I'll tidy it up.
One question....
Is there any way via a debug log, albeit, ngrep, tcpdump, sip_scenario display that I can from the server side detect if the NAT is asymmetric or Symmetric.
tks Iqbal
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Ask Paul and he'll say yes, but he mostly supports ATAs with public IPs and only occasionally meet an IP phone behind a NAT. I actually use STUN, but I have tested the behavior for each client (and each firmware). This reduces the number of proxied sessions to those where a symmetric NAT is involved. g-)
Iqbal wrote:
Thanks Greg, so from what I understand its better NOT to use STUN, and do fat end traversal all the time, i.e do it at SER level whether its asymmetric or symmetric
Iqbal
On 4/3/2005, "Greger V. Teigre" greger@teigre.com wrote:
Iqbal wrote:
maybe well written but I have come across another question, in the ser.cfg file on onsip it mentions that with correct use of the mediaproxy you can deal with asymmetric and symmetric, hence my summary may be wrong.
No, your summary is correct. The config files in the onsip.org document have the assumptions that STUN is NOT used. Hence, all NATed devices will be proxied. When STUN is used, it is transparent and the config files will see the client as non-NATed.
Symmetric CANNOT go through STUN, it wont work. hence the STUN is no use, and yes then ser will see it as natted.
One big problem is that many clients have faulty STUN implementations, even specific firmware can have problems (Grandstream changed its behavior to wrong handling of symmetric NAT in 10.5.16, I think).
In fact, it is possible both to detect (some of) these faulty implementations (i.e. faulty handling of symmetric NAT, ex. using test 16 in nathelper), but not if ex. a full-cone is detected when in fact, it's a restricted NAT. (Let me add that there also are many mutations/implemenations of the four NAT types that can confuse STUN...)
Conclusion: ALWAYS test the clients you want to use with STUN!
We are considering adding an appendix with advanced NAT techniques in ser.cfg including on where you can use STUN (test your clients) as well as direction=active supported PSTN gateways (used to allow non-proxied outgoing calls from a call behind a symmetric NAT) to reduce the proxied calls to the following:
- SIP-SIP when one or both are behind symmetric
- PSTN-SIP when the SIP client is behind symmetric
We'll see when we get the time. There are lots of more basic stuff we need to do first. g-)
If asymmetric comes via STUN, and the client understands what the STUN server has sent back, and can fix itself then ser will NOT see it has natted, since its been fixed
Iqbal
On 4/2/2005, "Mohammad Khan" info@beeplove.com wrote:
Very nice and well written, Many many thanks.
One question, If a client from Assymetric NAT and it comes through STUN, does SER see that client as a *nated* client? And, if a client from Symentric NAT and it still comes through STUN, SER see that client as Nated client, right?
See below:
Iqbal wrote:
Heres my understanding...hope it helps (may even confuse), and looking for corrections...its a long read
- There are 4 different types of NAT
a) Full Cone b) restricted cone c) port restricted d) symmetric
a,b,c are also referred to as asymmetric NAT.
- SIP has a problem because the siganalling uses one path and the
media stream another.
- Full cone - Anyone of the internet can send packets to the
IP:port combo, this is mapped to a internal IP:port.
- Restricted Cone - Only those external PC which have been
contacted are ALLOWED to contact via the mapping, i.e if I contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on that NAT mapping, PC(b) cannot
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) If pc(b) sends to 202.70.65.78:10000 there will be nothing sent through to 10.1.1.1:123
- Port restricted Cone - Same as restricted but instead of just
detecting that the source IP is that of pc(a), it also looks to see if the source port is the same
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) [213.123.324.34:8000]
The nat will only accept inbound from 213.123.324.34 and if it comes from port 8000
- Symmetric - This is the easy one,
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
^^you mean 10.1.1.x ( x is other than 1), right? I think, this was a typo.
Thanks, Mohammad
In the NAT the IP:port pair is different for each external client, so eeach external client has a mapping of its own
- The problem RTP
In RTP the message body has the info needed for the UA to communicate successfully. This body is called the SDP message. The problem is that the client doesnt know anything about the NAT, hence the IP addresses which are contained in the SDP are usually the internal ones, i.e what the client knows....so when the endpoints want to "talk" they look at the IP in the message and you get nothing because these are usually internal IP addresses.
EG
INVITE sip:040600@192.168.20.2:5060 SIP/2.0. Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. To: sip:040600@sip.dom.com. Contact: sip:040618@223.178.140.109:1024. Supported: replaces. Call-ID: 7f2c327896a5b0e1@192.168.20.3. CSeq: 8717 INVITE. User-Agent: Grandstream HT487 1.0.5.18. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 343. . v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
This header is just like email headers hence u read it backwards, so if you look at the line above the From: line you see the first Via, which is what the client thinks it is i.e 192.168.20.3, BUT the proxy is clever, it knows where it received the message from , and it adds the rport and received tags
Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
Soooo the proxy can talk SIP fine, because it knows these IP addresses.
BUT...poor old RTP is stuck because its headers or should I say direction is held lower down :
v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
The client expects to receive on port m=38660 and IP c= 192.168.20.3, which is where the other endpoint will try to send "voice" to.
8 Solution - You need to tell the client, not to act so dumb, and work out what the NAT settings are and put them in the SDP section of the message. So the client can ask the NAT....or it can ask someone on the outside what it should be.
Ask the NAT - use UPnP...I dont have much info on this..:-)
Ask someone on the outside --
You send a probe packet to the server sitting outside, it then sends a message back, with the details it received, the client then decides if its behind a NAT. This can be used for all 4 cases of NAT.
EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP message m=1000 and c=10.1.1.1, but if I send out a probe first, and I get back 212.134.123.23:12345 then I can rewrite the SDP so m=12345 and c=10.1.1.1 , simple
Problem -- Since NAT settings are dynamic, and hence tend to change, you really need to get the SIP message out very soon after sending the probing message out,
The client send and receive ports must be the same
And....if you recall the restricted cones (port restricted included) will not allow replies unless there has been a packet sent out to that destination first, hence the client needs to send a packet out to the endpoint, b4 he can be allowed in via the NAT (but we dont need to worry about that)
IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because the external UA IP:port is different to that where we sent the probe, hence the voice packet coming back will not have the correct path set.
- The above is usually done with a STUN server, and sending the
packet out to this server
- Symmetric NAT--- use a relay in the middle...Nathelper+
rtpproxy or mediaproxy
13 Nathelper a) fix_nated_contact - rewrites contact Hf to source IP:port b) fix_nated_sdp - rewritres media IP and also direction ???? c) force_rtp_proxy - forces media to go through proxy d) nat_uac_test - mode=1 then as shown above the "received" header is compared to c= in sdp mode=2 then the Contact header is looked at to see if its private mode=3 (1+2) means it does both of the above
- mediaproxy is much the same...and good examples are available
15)Summary
4 types of NAT, which can be combined into 2 main sets, asymmetric and symmetric.
Asymmetric issues can be resolved by using STUN, hence no need for mediaproxy/nathelper Symmetric clients cant use STUN, hence u need to use mediaproxy/nathelper (or some other server end...also known as far-end nat traversal solution)
However if you didnt want to use STUN and mediaproxy/nathelper, then you could just use mediaproxy/nathelper and setup port forwarding on your NAT device.
I think that covers most, any suggestions let me know, I wrote this for my own use, but if its useful, I'll tidy it up.
One question....
Is there any way via a debug log, albeit, ngrep, tcpdump, sip_scenario display that I can from the server side detect if the NAT is asymmetric or Symmetric.
tks Iqbal
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greger is correct about me "mostly supporting" ATAs with public IPs.
Our approach is the 80/20 rule. We ship UTstarcom iAN-02EX ATAs which have full router support (ie, they have a WAN and LAN interface). We encourage our customers to connect the WAN port directly to their broadband router and then connect their home network to the LAN port of the ATA.
This allows us to route most RTP traffic away from our network, which is smart for scaling your VoIP platform.
In cases where a customer connectes their WAN port of the ATA to their home network, the ATA then gets an RFC1918 IP address, and we must proxy all RTP streams for that customer.
Again, we're shooting for the 80/20 rule. If we convince 80% of our customers to hook up their ATA "correctly" then our infrastructure is less stressed.
Regards, Paul
On Apr 4, 2005 2:03 AM, Greger V. Teigre greger@teigre.com wrote:
Ask Paul and he'll say yes, but he mostly supports ATAs with public IPs and only occasionally meet an IP phone behind a NAT. I actually use STUN, but I have tested the behavior for each client (and each firmware). This reduces the number of proxied sessions to those where a symmetric NAT is involved. g-)
Iqbal wrote:
Thanks Greg, so from what I understand its better NOT to use STUN, and do fat end traversal all the time, i.e do it at SER level whether its asymmetric or symmetric
Iqbal
On 4/3/2005, "Greger V. Teigre" greger@teigre.com wrote:
Iqbal wrote:
maybe well written but I have come across another question, in the ser.cfg file on onsip it mentions that with correct use of the mediaproxy you can deal with asymmetric and symmetric, hence my summary may be wrong.
No, your summary is correct. The config files in the onsip.org document have the assumptions that STUN is NOT used. Hence, all NATed devices will be proxied. When STUN is used, it is transparent and the config files will see the client as non-NATed.
Symmetric CANNOT go through STUN, it wont work. hence the STUN is no use, and yes then ser will see it as natted.
One big problem is that many clients have faulty STUN implementations, even specific firmware can have problems (Grandstream changed its behavior to wrong handling of symmetric NAT in 10.5.16, I think).
In fact, it is possible both to detect (some of) these faulty implementations (i.e. faulty handling of symmetric NAT, ex. using test 16 in nathelper), but not if ex. a full-cone is detected when in fact, it's a restricted NAT. (Let me add that there also are many mutations/implemenations of the four NAT types that can confuse STUN...)
Conclusion: ALWAYS test the clients you want to use with STUN!
We are considering adding an appendix with advanced NAT techniques in ser.cfg including on where you can use STUN (test your clients) as well as direction=active supported PSTN gateways (used to allow non-proxied outgoing calls from a call behind a symmetric NAT) to reduce the proxied calls to the following:
- SIP-SIP when one or both are behind symmetric
- PSTN-SIP when the SIP client is behind symmetric
We'll see when we get the time. There are lots of more basic stuff we need to do first. g-)
If asymmetric comes via STUN, and the client understands what the STUN server has sent back, and can fix itself then ser will NOT see it has natted, since its been fixed
Iqbal
On 4/2/2005, "Mohammad Khan" info@beeplove.com wrote:
Very nice and well written, Many many thanks.
One question, If a client from Assymetric NAT and it comes through STUN, does SER see that client as a *nated* client? And, if a client from Symentric NAT and it still comes through STUN, SER see that client as Nated client, right?
See below:
Iqbal wrote:
Heres my understanding...hope it helps (may even confuse), and looking for corrections...its a long read
- There are 4 different types of NAT
a) Full Cone b) restricted cone c) port restricted d) symmetric
a,b,c are also referred to as asymmetric NAT.
- SIP has a problem because the siganalling uses one path and the
media stream another.
- Full cone - Anyone of the internet can send packets to the
IP:port combo, this is mapped to a internal IP:port.
- Restricted Cone - Only those external PC which have been
contacted are ALLOWED to contact via the mapping, i.e if I contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on that NAT mapping, PC(b) cannot
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) If pc(b) sends to 202.70.65.78:10000 there will be nothing sent through to 10.1.1.1:123
- Port restricted Cone - Same as restricted but instead of just
detecting that the source IP is that of pc(a), it also looks to see if the source port is the same
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) [213.123.324.34:8000]
The nat will only accept inbound from 213.123.324.34 and if it comes from port 8000
- Symmetric - This is the easy one,
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
^^you mean 10.1.1.x ( x is other than 1), right? I think, this was a typo.
Thanks, Mohammad
In the NAT the IP:port pair is different for each external client, so eeach external client has a mapping of its own
- The problem RTP
In RTP the message body has the info needed for the UA to communicate successfully. This body is called the SDP message. The problem is that the client doesnt know anything about the NAT, hence the IP addresses which are contained in the SDP are usually the internal ones, i.e what the client knows....so when the endpoints want to "talk" they look at the IP in the message and you get nothing because these are usually internal IP addresses.
EG
INVITE sip:040600@192.168.20.2:5060 SIP/2.0. Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. To: sip:040600@sip.dom.com. Contact: sip:040618@223.178.140.109:1024. Supported: replaces. Call-ID: 7f2c327896a5b0e1@192.168.20.3. CSeq: 8717 INVITE. User-Agent: Grandstream HT487 1.0.5.18. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 343. . v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
This header is just like email headers hence u read it backwards, so if you look at the line above the From: line you see the first Via, which is what the client thinks it is i.e 192.168.20.3, BUT the proxy is clever, it knows where it received the message from , and it adds the rport and received tags
Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
Soooo the proxy can talk SIP fine, because it knows these IP addresses.
BUT...poor old RTP is stuck because its headers or should I say direction is held lower down :
v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
The client expects to receive on port m=38660 and IP c= 192.168.20.3, which is where the other endpoint will try to send "voice" to.
8 Solution - You need to tell the client, not to act so dumb, and work out what the NAT settings are and put them in the SDP section of the message. So the client can ask the NAT....or it can ask someone on the outside what it should be.
Ask the NAT - use UPnP...I dont have much info on this..:-)
Ask someone on the outside --
You send a probe packet to the server sitting outside, it then sends a message back, with the details it received, the client then decides if its behind a NAT. This can be used for all 4 cases of NAT.
EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP message m=1000 and c=10.1.1.1, but if I send out a probe first, and I get back 212.134.123.23:12345 then I can rewrite the SDP so m=12345 and c=10.1.1.1 , simple
Problem -- Since NAT settings are dynamic, and hence tend to change, you really need to get the SIP message out very soon after sending the probing message out,
The client send and receive ports must be the same
And....if you recall the restricted cones (port restricted included) will not allow replies unless there has been a packet sent out to that destination first, hence the client needs to send a packet out to the endpoint, b4 he can be allowed in via the NAT (but we dont need to worry about that)
IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because the external UA IP:port is different to that where we sent the probe, hence the voice packet coming back will not have the correct path set.
- The above is usually done with a STUN server, and sending the
packet out to this server
- Symmetric NAT--- use a relay in the middle...Nathelper+
rtpproxy or mediaproxy
13 Nathelper a) fix_nated_contact - rewrites contact Hf to source IP:port b) fix_nated_sdp - rewritres media IP and also direction ???? c) force_rtp_proxy - forces media to go through proxy d) nat_uac_test - mode=1 then as shown above the "received" header is compared to c= in sdp mode=2 then the Contact header is looked at to see if its private mode=3 (1+2) means it does both of the above
- mediaproxy is much the same...and good examples are available
15)Summary
4 types of NAT, which can be combined into 2 main sets, asymmetric and symmetric.
Asymmetric issues can be resolved by using STUN, hence no need for mediaproxy/nathelper Symmetric clients cant use STUN, hence u need to use mediaproxy/nathelper (or some other server end...also known as far-end nat traversal solution)
However if you didnt want to use STUN and mediaproxy/nathelper, then you could just use mediaproxy/nathelper and setup port forwarding on your NAT device.
I think that covers most, any suggestions let me know, I wrote this for my own use, but if its useful, I'll tidy it up.
One question....
Is there any way via a debug log, albeit, ngrep, tcpdump, sip_scenario display that I can from the server side detect if the NAT is asymmetric or Symmetric.
tks Iqbal
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Okay missed a trick here. On the handytone 488, its has a wan and lan port. Now I tested this with a Kcorp adsl modem/router.
Plugged the wan of ATA into adsl router, and the LAN was disconnected since the Network is connected over wireless to the Kcorp.
In ur setup u say that it gets a external IP, however I cant see how, since the broadband router will get the external IP address, and not whats connected to it. Mine still gets a internal IP address...
Iqbal Java Rockx wrote:
Greger is correct about me "mostly supporting" ATAs with public IPs.
Our approach is the 80/20 rule. We ship UTstarcom iAN-02EX ATAs which have full router support (ie, they have a WAN and LAN interface). We encourage our customers to connect the WAN port directly to their broadband router and then connect their home network to the LAN port of the ATA.
This allows us to route most RTP traffic away from our network, which is smart for scaling your VoIP platform.
In cases where a customer connectes their WAN port of the ATA to their home network, the ATA then gets an RFC1918 IP address, and we must proxy all RTP streams for that customer.
Again, we're shooting for the 80/20 rule. If we convince 80% of our customers to hook up their ATA "correctly" then our infrastructure is less stressed.
Regards, Paul
On Apr 4, 2005 2:03 AM, Greger V. Teigre greger@teigre.com wrote:
Ask Paul and he'll say yes, but he mostly supports ATAs with public IPs and only occasionally meet an IP phone behind a NAT. I actually use STUN, but I have tested the behavior for each client (and each firmware). This reduces the number of proxied sessions to those where a symmetric NAT is involved. g-)
Iqbal wrote:
Thanks Greg, so from what I understand its better NOT to use STUN, and do fat end traversal all the time, i.e do it at SER level whether its asymmetric or symmetric
Iqbal
On 4/3/2005, "Greger V. Teigre" greger@teigre.com wrote:
Iqbal wrote:
maybe well written but I have come across another question, in the ser.cfg file on onsip it mentions that with correct use of the mediaproxy you can deal with asymmetric and symmetric, hence my summary may be wrong.
No, your summary is correct. The config files in the onsip.org document have the assumptions that STUN is NOT used. Hence, all NATed devices will be proxied. When STUN is used, it is transparent and the config files will see the client as non-NATed.
Symmetric CANNOT go through STUN, it wont work. hence the STUN is no use, and yes then ser will see it as natted.
One big problem is that many clients have faulty STUN implementations, even specific firmware can have problems (Grandstream changed its behavior to wrong handling of symmetric NAT in 10.5.16, I think).
In fact, it is possible both to detect (some of) these faulty implementations (i.e. faulty handling of symmetric NAT, ex. using test 16 in nathelper), but not if ex. a full-cone is detected when in fact, it's a restricted NAT. (Let me add that there also are many mutations/implemenations of the four NAT types that can confuse STUN...)
Conclusion: ALWAYS test the clients you want to use with STUN!
We are considering adding an appendix with advanced NAT techniques in ser.cfg including on where you can use STUN (test your clients) as well as direction=active supported PSTN gateways (used to allow non-proxied outgoing calls from a call behind a symmetric NAT) to reduce the proxied calls to the following:
- SIP-SIP when one or both are behind symmetric
- PSTN-SIP when the SIP client is behind symmetric
We'll see when we get the time. There are lots of more basic stuff we need to do first. g-)
If asymmetric comes via STUN, and the client understands what the STUN server has sent back, and can fix itself then ser will NOT see it has natted, since its been fixed
Iqbal
On 4/2/2005, "Mohammad Khan" info@beeplove.com wrote:
Very nice and well written, Many many thanks.
One question, If a client from Assymetric NAT and it comes through STUN, does SER see that client as a *nated* client? And, if a client from Symentric NAT and it still comes through STUN, SER see that client as Nated client, right?
See below:
Iqbal wrote:
>Heres my understanding...hope it helps (may even confuse), and >looking for corrections...its a long read > >1. There are 4 different types of NAT >a) Full Cone >b) restricted cone >c) port restricted >d) symmetric > >a,b,c are also referred to as asymmetric NAT. > >2. SIP has a problem because the siganalling uses one path and the >media stream another. > >3. Full cone - Anyone of the internet can send packets to the >IP:port combo, this is mapped to a internal IP:port. > >4. Restricted Cone - Only those external PC which have been >contacted are ALLOWED to contact via the mapping, i.e if I contact >PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on >that NAT mapping, PC(b) cannot > >10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) >If pc(b) sends to 202.70.65.78:10000 there will be nothing sent >through to 10.1.1.1:123 > >5. Port restricted Cone - Same as restricted but instead of just >detecting that the source IP is that of pc(a), it also looks to >see if the source port is the same > >10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) >[213.123.324.34:8000] > >The nat will only accept inbound from 213.123.324.34 and if it >comes from port 8000 > >6. Symmetric - This is the easy one, > > > 10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
^^you mean 10.1.1.x ( x is other than 1), right? I think, this was a typo.
Thanks, Mohammad
>In the NAT the IP:port pair is different for each external client, >so eeach external client has a mapping of its own > >7. The problem RTP > >In RTP the message body has the info needed for the UA to >communicate successfully. This body is called the SDP message. The >problem is that the client doesnt know anything about the NAT, >hence the IP addresses which are contained in the SDP are usually >the internal ones, i.e what the client knows....so when the >endpoints want to "talk" they look at the IP in the message and >you get nothing because these are usually internal IP addresses. > >EG > >INVITE sip:040600@192.168.20.2:5060 SIP/2.0. >Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. >Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. >Via: SIP/2.0/UDP >192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. >From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. >To: sip:040600@sip.dom.com. >Contact: sip:040618@223.178.140.109:1024. >Supported: replaces. >Call-ID: 7f2c327896a5b0e1@192.168.20.3. >CSeq: 8717 INVITE. >User-Agent: Grandstream HT487 1.0.5.18. >Max-Forwards: 16. >Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. >Content-Type: application/sdp. >Content-Length: 343. >. >v=0. >o=040618 8000 1 IN IP4 192.168.20.3. >s=SIP Call. >c=IN IP4 192.168.20.3. >t=0 0. >m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. >a=sendrecv. >a=rtpmap:0 PCMU/8000/3. >a=rtpmap:8 PCMA/8000/3. > > >This header is just like email headers hence u read it backwards, >so if you look at the line above the From: line you see the first >Via, which is what the client thinks it is i.e 192.168.20.3, BUT >the proxy is clever, it knows where it received the message from , >and it adds the rport and received tags > >Via: SIP/2.0/UDP >192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. > >Soooo the proxy can talk SIP fine, because it knows these IP >addresses. > >BUT...poor old RTP is stuck because its headers or should I say >direction is held lower down : > >v=0. >o=040618 8000 1 IN IP4 192.168.20.3. >s=SIP Call. >c=IN IP4 192.168.20.3. >t=0 0. >m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. >a=sendrecv. >a=rtpmap:0 PCMU/8000/3. >a=rtpmap:8 PCMA/8000/3. > >The client expects to receive on port m=38660 and IP c= >192.168.20.3, which is where the other endpoint will try to send >"voice" to. > >8 Solution - You need to tell the client, not to act so dumb, and >work out what the NAT settings are and put them in the SDP section >of the message. So the client can ask the NAT....or it can ask >someone on the outside what it should be. > >9. Ask the NAT - use UPnP...I dont have much info on this..:-) > >10. Ask someone on the outside -- >You send a probe packet to the server sitting outside, it then >sends a message back, with the details it received, the client >then decides if its behind a NAT. This can be used for all 4 >cases of NAT. > >EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP >message m=1000 and c=10.1.1.1, but if I send out a probe first, >and I get back 212.134.123.23:12345 then I can rewrite the SDP so >m=12345 and c=10.1.1.1 , simple > >Problem -- Since NAT settings are dynamic, and hence tend to >change, you really need to get the SIP message out very soon after >sending the probing message out, > >The client send and receive ports must be the same > >And....if you recall the restricted cones (port restricted >included) will not allow replies unless there has been a packet >sent out to that destination first, hence the client needs to send >a packet out to the endpoint, b4 he can be allowed in via the NAT >(but we dont need to worry about that) > >IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because >the external UA IP:port is different to that where we sent the >probe, hence the voice packet coming back will not have the >correct path set. > >11. The above is usually done with a STUN server, and sending the >packet out to this server > >12. Symmetric NAT--- use a relay in the middle...Nathelper+ >rtpproxy or mediaproxy > >13 Nathelper >a) fix_nated_contact - rewrites contact Hf to source IP:port >b) fix_nated_sdp - rewritres media IP and also direction ???? >c) force_rtp_proxy - forces media to go through proxy >d) nat_uac_test - mode=1 then as shown above the "received" header >is compared to c= in sdp >mode=2 then the Contact header is looked at to see if its private >mode=3 (1+2) means it does both of the above > > >14) mediaproxy is much the same...and good examples are available > >15)Summary > >4 types of NAT, which can be combined into 2 main sets, asymmetric >and symmetric. > >Asymmetric issues can be resolved by using STUN, hence no need for >mediaproxy/nathelper >Symmetric clients cant use STUN, hence u need to use >mediaproxy/nathelper (or some other server end...also known as >far-end nat traversal solution) > >However if you didnt want to use STUN and mediaproxy/nathelper, >then you could just use mediaproxy/nathelper and setup port >forwarding on your NAT device. > > >I think that covers most, any suggestions let me know, I wrote >this for my own use, but if its useful, I'll tidy it up. > >One question.... > >Is there any way via a debug log, albeit, ngrep, tcpdump, >sip_scenario display that I can from the server side detect if the >NAT is asymmetric or Symmetric. > >tks >Iqbal > >_______________________________________________ >Serusers mailing list >serusers@lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > > > >
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
.
Okay so in order to get is straight
1. You can use just SER to deal with all types of NAT, this means that mediaproxy will get hit 2. You can use STUN, to get rid of clients which are asymmetric (is there alist of these...in fact will post with new topic) 3. Or you can ensure none of ur clients use NAT :-)
Iqbal
Greger V. Teigre wrote:
Ask Paul and he'll say yes, but he mostly supports ATAs with public IPs and only occasionally meet an IP phone behind a NAT. I actually use STUN, but I have tested the behavior for each client (and each firmware). This reduces the number of proxied sessions to those where a symmetric NAT is involved. g-)
Iqbal wrote:
Thanks Greg, so from what I understand its better NOT to use STUN, and do fat end traversal all the time, i.e do it at SER level whether its asymmetric or symmetric
Iqbal
On 4/3/2005, "Greger V. Teigre" greger@teigre.com wrote:
Iqbal wrote:
maybe well written but I have come across another question, in the ser.cfg file on onsip it mentions that with correct use of the mediaproxy you can deal with asymmetric and symmetric, hence my summary may be wrong.
No, your summary is correct. The config files in the onsip.org document have the assumptions that STUN is NOT used. Hence, all NATed devices will be proxied. When STUN is used, it is transparent and the config files will see the client as non-NATed.
Symmetric CANNOT go through STUN, it wont work. hence the STUN is no use, and yes then ser will see it as natted.
One big problem is that many clients have faulty STUN implementations, even specific firmware can have problems (Grandstream changed its behavior to wrong handling of symmetric NAT in 10.5.16, I think).
In fact, it is possible both to detect (some of) these faulty implementations (i.e. faulty handling of symmetric NAT, ex. using test 16 in nathelper), but not if ex. a full-cone is detected when in fact, it's a restricted NAT. (Let me add that there also are many mutations/implemenations of the four NAT types that can confuse STUN...)
Conclusion: ALWAYS test the clients you want to use with STUN!
We are considering adding an appendix with advanced NAT techniques in ser.cfg including on where you can use STUN (test your clients) as well as direction=active supported PSTN gateways (used to allow non-proxied outgoing calls from a call behind a symmetric NAT) to reduce the proxied calls to the following:
- SIP-SIP when one or both are behind symmetric
- PSTN-SIP when the SIP client is behind symmetric
We'll see when we get the time. There are lots of more basic stuff we need to do first. g-)
If asymmetric comes via STUN, and the client understands what the STUN server has sent back, and can fix itself then ser will NOT see it has natted, since its been fixed
Iqbal
On 4/2/2005, "Mohammad Khan" info@beeplove.com wrote:
Very nice and well written, Many many thanks.
One question, If a client from Assymetric NAT and it comes through STUN, does SER see that client as a *nated* client? And, if a client from Symentric NAT and it still comes through STUN, SER see that client as Nated client, right?
See below:
Iqbal wrote:
Heres my understanding...hope it helps (may even confuse), and looking for corrections...its a long read
- There are 4 different types of NAT
a) Full Cone b) restricted cone c) port restricted d) symmetric
a,b,c are also referred to as asymmetric NAT.
- SIP has a problem because the siganalling uses one path and the
media stream another.
- Full cone - Anyone of the internet can send packets to the
IP:port combo, this is mapped to a internal IP:port.
- Restricted Cone - Only those external PC which have been
contacted are ALLOWED to contact via the mapping, i.e if I contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on that NAT mapping, PC(b) cannot
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) If pc(b) sends to 202.70.65.78:10000 there will be nothing sent through to 10.1.1.1:123
- Port restricted Cone - Same as restricted but instead of just
detecting that the source IP is that of pc(a), it also looks to see if the source port is the same
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) [213.123.324.34:8000]
The nat will only accept inbound from 213.123.324.34 and if it comes from port 8000
- Symmetric - This is the easy one,
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
^^you mean 10.1.1.x ( x is other than 1), right? I think, this was a typo.
Thanks, Mohammad
In the NAT the IP:port pair is different for each external client, so eeach external client has a mapping of its own
- The problem RTP
In RTP the message body has the info needed for the UA to communicate successfully. This body is called the SDP message. The problem is that the client doesnt know anything about the NAT, hence the IP addresses which are contained in the SDP are usually the internal ones, i.e what the client knows....so when the endpoints want to "talk" they look at the IP in the message and you get nothing because these are usually internal IP addresses.
EG
INVITE sip:040600@192.168.20.2:5060 SIP/2.0. Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. To: sip:040600@sip.dom.com. Contact: sip:040618@223.178.140.109:1024. Supported: replaces. Call-ID: 7f2c327896a5b0e1@192.168.20.3. CSeq: 8717 INVITE. User-Agent: Grandstream HT487 1.0.5.18. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 343. . v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
This header is just like email headers hence u read it backwards, so if you look at the line above the From: line you see the first Via, which is what the client thinks it is i.e 192.168.20.3, BUT the proxy is clever, it knows where it received the message from , and it adds the rport and received tags
Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
Soooo the proxy can talk SIP fine, because it knows these IP addresses.
BUT...poor old RTP is stuck because its headers or should I say direction is held lower down :
v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
The client expects to receive on port m=38660 and IP c= 192.168.20.3, which is where the other endpoint will try to send "voice" to.
8 Solution - You need to tell the client, not to act so dumb, and work out what the NAT settings are and put them in the SDP section of the message. So the client can ask the NAT....or it can ask someone on the outside what it should be.
Ask the NAT - use UPnP...I dont have much info on this..:-)
Ask someone on the outside --
You send a probe packet to the server sitting outside, it then sends a message back, with the details it received, the client then decides if its behind a NAT. This can be used for all 4 cases of NAT.
EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP message m=1000 and c=10.1.1.1, but if I send out a probe first, and I get back 212.134.123.23:12345 then I can rewrite the SDP so m=12345 and c=10.1.1.1 , simple
Problem -- Since NAT settings are dynamic, and hence tend to change, you really need to get the SIP message out very soon after sending the probing message out,
The client send and receive ports must be the same
And....if you recall the restricted cones (port restricted included) will not allow replies unless there has been a packet sent out to that destination first, hence the client needs to send a packet out to the endpoint, b4 he can be allowed in via the NAT (but we dont need to worry about that)
IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because the external UA IP:port is different to that where we sent the probe, hence the voice packet coming back will not have the correct path set.
- The above is usually done with a STUN server, and sending the
packet out to this server
- Symmetric NAT--- use a relay in the middle...Nathelper+
rtpproxy or mediaproxy
13 Nathelper a) fix_nated_contact - rewrites contact Hf to source IP:port b) fix_nated_sdp - rewritres media IP and also direction ???? c) force_rtp_proxy - forces media to go through proxy d) nat_uac_test - mode=1 then as shown above the "received" header is compared to c= in sdp mode=2 then the Contact header is looked at to see if its private mode=3 (1+2) means it does both of the above
- mediaproxy is much the same...and good examples are available
15)Summary
4 types of NAT, which can be combined into 2 main sets, asymmetric and symmetric.
Asymmetric issues can be resolved by using STUN, hence no need for mediaproxy/nathelper Symmetric clients cant use STUN, hence u need to use mediaproxy/nathelper (or some other server end...also known as far-end nat traversal solution)
However if you didnt want to use STUN and mediaproxy/nathelper, then you could just use mediaproxy/nathelper and setup port forwarding on your NAT device.
I think that covers most, any suggestions let me know, I wrote this for my own use, but if its useful, I'll tidy it up.
One question....
Is there any way via a debug log, albeit, ngrep, tcpdump, sip_scenario display that I can from the server side detect if the NAT is asymmetric or Symmetric.
tks Iqbal
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
.
Correct, and if you have a GW supporting connection-oriented media, you can use direction=active and get rid of all IP-PSTN, PSTN-IP calls. g-)
Iqbal wrote:
Okay so in order to get is straight
- You can use just SER to deal with all types of NAT, this means that
mediaproxy will get hit 2. You can use STUN, to get rid of clients which are asymmetric (is there alist of these...in fact will post with new topic) 3. Or you can ensure none of ur clients use NAT :-)
Iqbal
Greger V. Teigre wrote:
Ask Paul and he'll say yes, but he mostly supports ATAs with public IPs and only occasionally meet an IP phone behind a NAT. I actually use STUN, but I have tested the behavior for each client (and each firmware). This reduces the number of proxied sessions to those where a symmetric NAT is involved. g-)
Iqbal wrote:
Thanks Greg, so from what I understand its better NOT to use STUN, and do fat end traversal all the time, i.e do it at SER level whether its asymmetric or symmetric
Iqbal
On 4/3/2005, "Greger V. Teigre" greger@teigre.com wrote:
Iqbal wrote:
maybe well written but I have come across another question, in the ser.cfg file on onsip it mentions that with correct use of the mediaproxy you can deal with asymmetric and symmetric, hence my summary may be wrong.
No, your summary is correct. The config files in the onsip.org document have the assumptions that STUN is NOT used. Hence, all NATed devices will be proxied. When STUN is used, it is transparent and the config files will see the client as non-NATed.
Symmetric CANNOT go through STUN, it wont work. hence the STUN is no use, and yes then ser will see it as natted.
One big problem is that many clients have faulty STUN implementations, even specific firmware can have problems (Grandstream changed its behavior to wrong handling of symmetric NAT in 10.5.16, I think).
In fact, it is possible both to detect (some of) these faulty implementations (i.e. faulty handling of symmetric NAT, ex. using test 16 in nathelper), but not if ex. a full-cone is detected when in fact, it's a restricted NAT. (Let me add that there also are many mutations/implemenations of the four NAT types that can confuse STUN...)
Conclusion: ALWAYS test the clients you want to use with STUN!
We are considering adding an appendix with advanced NAT techniques in ser.cfg including on where you can use STUN (test your clients) as well as direction=active supported PSTN gateways (used to allow non-proxied outgoing calls from a call behind a symmetric NAT) to reduce the proxied calls to the following:
- SIP-SIP when one or both are behind symmetric
- PSTN-SIP when the SIP client is behind symmetric
We'll see when we get the time. There are lots of more basic stuff we need to do first. g-)
If asymmetric comes via STUN, and the client understands what the STUN server has sent back, and can fix itself then ser will NOT see it has natted, since its been fixed
Iqbal
On 4/2/2005, "Mohammad Khan" info@beeplove.com wrote:
Very nice and well written, Many many thanks.
One question, If a client from Assymetric NAT and it comes through STUN, does SER see that client as a *nated* client? And, if a client from Symentric NAT and it still comes through STUN, SER see that client as Nated client, right?
See below:
Iqbal wrote:
> Heres my understanding...hope it helps (may even confuse), and > looking for corrections...its a long read > > 1. There are 4 different types of NAT > a) Full Cone > b) restricted cone > c) port restricted > d) symmetric > > a,b,c are also referred to as asymmetric NAT. > > 2. SIP has a problem because the siganalling uses one path and > the media stream another. > > 3. Full cone - Anyone of the internet can send packets to the > IP:port combo, this is mapped to a internal IP:port. > > 4. Restricted Cone - Only those external PC which have been > contacted are ALLOWED to contact via the mapping, i.e if I > contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can > contact me on that NAT mapping, PC(b) cannot > > 10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) > If pc(b) sends to 202.70.65.78:10000 there will be nothing sent > through to 10.1.1.1:123 > > 5. Port restricted Cone - Same as restricted but instead of just > detecting that the source IP is that of pc(a), it also looks to > see if the source port is the same > > 10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) > [213.123.324.34:8000] > > The nat will only accept inbound from 213.123.324.34 and if it > comes from port 8000 > > 6. Symmetric - This is the easy one, > 10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a)
10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
^^you mean 10.1.1.x ( x is other than 1), right? I think, this was a typo.
Thanks, Mohammad
> In the NAT the IP:port pair is different for each external > client, so eeach external client has a mapping of its own > > 7. The problem RTP > > In RTP the message body has the info needed for the UA to > communicate successfully. This body is called the SDP message. > The problem is that the client doesnt know anything about the > NAT, hence the IP addresses which are contained in the SDP are > usually the internal ones, i.e what the client knows....so when > the endpoints want to "talk" they look at the IP in the message > and you get nothing because these are usually internal IP > addresses. EG > > INVITE sip:040600@192.168.20.2:5060 SIP/2.0. > Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. > Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. > Via: SIP/2.0/UDP > 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. > > From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. > To: sip:040600@sip.dom.com. > Contact: sip:040618@223.178.140.109:1024. > Supported: replaces. > Call-ID: 7f2c327896a5b0e1@192.168.20.3. > CSeq: 8717 INVITE. > User-Agent: Grandstream HT487 1.0.5.18. > Max-Forwards: 16. > Allow: > INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. > Content-Type: application/sdp. Content-Length: 343. > . > v=0. > o=040618 8000 1 IN IP4 192.168.20.3. > s=SIP Call. > c=IN IP4 192.168.20.3. > t=0 0. > m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. > a=sendrecv. > a=rtpmap:0 PCMU/8000/3. > a=rtpmap:8 PCMA/8000/3. > > > This header is just like email headers hence u read it > backwards, so if you look at the line above the From: line you > see the first Via, which is what the client thinks it is i.e > 192.168.20.3, BUT the proxy is clever, it knows where it > received the message from , and it adds the rport and received > tags Via: SIP/2.0/UDP > 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. > > > Soooo the proxy can talk SIP fine, because it knows these IP > addresses. > > BUT...poor old RTP is stuck because its headers or should I say > direction is held lower down : > > v=0. > o=040618 8000 1 IN IP4 192.168.20.3. > s=SIP Call. > c=IN IP4 192.168.20.3. > t=0 0. > m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. > a=sendrecv. > a=rtpmap:0 PCMU/8000/3. > a=rtpmap:8 PCMA/8000/3. > > The client expects to receive on port m=38660 and IP c= > 192.168.20.3, which is where the other endpoint will try to send > "voice" to. > > 8 Solution - You need to tell the client, not to act so dumb, > and work out what the NAT settings are and put them in the SDP > section of the message. So the client can ask the NAT....or it > can ask someone on the outside what it should be. > > 9. Ask the NAT - use UPnP...I dont have much info on this..:-) > > 10. Ask someone on the outside -- > You send a probe packet to the server sitting outside, it then > sends a message back, with the details it received, the client > then decides if its behind a NAT. This can be used for all 4 > cases of NAT. > > EG lets say we send out a packet from 10.1.1.1:1000 so in the > SDP message m=1000 and c=10.1.1.1, but if I send out a probe > first, and I get back 212.134.123.23:12345 then I can rewrite > the SDP so m=12345 and c=10.1.1.1 , simple > > Problem -- Since NAT settings are dynamic, and hence tend to > change, you really need to get the SIP message out very soon > after sending the probing message out, > > The client send and receive ports must be the same > > And....if you recall the restricted cones (port restricted > included) will not allow replies unless there has been a packet > sent out to that destination first, hence the client needs to > send a packet out to the endpoint, b4 he can be allowed in via > the NAT (but we dont need to worry about that) > > IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), > because the external UA IP:port is different to that where we > sent the probe, hence the voice packet coming back will not > have the correct path set. > > 11. The above is usually done with a STUN server, and sending > the packet out to this server > > 12. Symmetric NAT--- use a relay in the middle...Nathelper+ > rtpproxy or mediaproxy > > 13 Nathelper > a) fix_nated_contact - rewrites contact Hf to source IP:port > b) fix_nated_sdp - rewritres media IP and also direction ???? > c) force_rtp_proxy - forces media to go through proxy > d) nat_uac_test - mode=1 then as shown above the "received" > header is compared to c= in sdp > mode=2 then the Contact header is looked at to see if its > private mode=3 (1+2) means it does both of the above > > > 14) mediaproxy is much the same...and good examples are > available 15)Summary > > 4 types of NAT, which can be combined into 2 main sets, > asymmetric and symmetric. > > Asymmetric issues can be resolved by using STUN, hence no need > for mediaproxy/nathelper > Symmetric clients cant use STUN, hence u need to use > mediaproxy/nathelper (or some other server end...also known as > far-end nat traversal solution) > > However if you didnt want to use STUN and mediaproxy/nathelper, > then you could just use mediaproxy/nathelper and setup port > forwarding on your NAT device. > > > I think that covers most, any suggestions let me know, I wrote > this for my own use, but if its useful, I'll tidy it up. > > One question.... > > Is there any way via a debug log, albeit, ngrep, tcpdump, > sip_scenario display that I can from the server side detect if > the NAT is asymmetric or Symmetric. > > tks > Iqbal > > _______________________________________________ > Serusers mailing list > serusers@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > >
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
.
Iqbal, Excellent summary! There are many good NAT whitepapers on the net. Here is one that is short and clear that elaborates on your summary: http://corp.deltathree.com/technology/networkaddress.asp g-)
Iqbal wrote:
Heres my understanding...hope it helps (may even confuse), and looking for corrections...its a long read
- There are 4 different types of NAT
a) Full Cone b) restricted cone c) port restricted d) symmetric
a,b,c are also referred to as asymmetric NAT.
- SIP has a problem because the siganalling uses one path and the
media stream another.
- Full cone - Anyone of the internet can send packets to the IP:port
combo, this is mapped to a internal IP:port.
- Restricted Cone - Only those external PC which have been contacted
are ALLOWED to contact via the mapping, i.e if I contact PC(a) from internal Ip 10.1.1.1:123 then PC(a) can contact me on that NAT mapping, PC(b) cannot
10.1.1.1:123 ---NAT ---> 202.70.65.78:10000 ------pc(a) If pc(b) sends to 202.70.65.78:10000 there will be nothing sent through to 10.1.1.1:123
- Port restricted Cone - Same as restricted but instead of just
detecting that the source IP is that of pc(a), it also looks to see if the source port is the same
10.1.1.1:123 --->NAT---->202.70.65.78:10000 -----> pc(a) [213.123.324.34:8000]
The nat will only accept inbound from 213.123.324.34 and if it comes from port 8000
- Symmetric - This is the easy one,
10.1.1.1:1000 ----NAT -----> 200.123.123.34:1234 ----pc(a) 10.1.1.1:1000 ----NAT -----> 200.123.123.34:2222----pc(b)
In the NAT the IP:port pair is different for each external client, so eeach external client has a mapping of its own
- The problem RTP
In RTP the message body has the info needed for the UA to communicate successfully. This body is called the SDP message. The problem is that the client doesnt know anything about the NAT, hence the IP addresses which are contained in the SDP are usually the internal ones, i.e what the client knows....so when the endpoints want to "talk" they look at the IP in the message and you get nothing because these are usually internal IP addresses.
EG
INVITE sip:040600@192.168.20.2:5060 SIP/2.0. Record-Route: sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on. Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0. Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d. From: "Iqbal" sip:040618@sip.dom.com;tag=3a7ceb24a6ac50c4. To: sip:040600@sip.dom.com. Contact: sip:040618@223.178.140.109:1024. Supported: replaces. Call-ID: 7f2c327896a5b0e1@192.168.20.3. CSeq: 8717 INVITE. User-Agent: Grandstream HT487 1.0.5.18. Max-Forwards: 16. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 343. . v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
This header is just like email headers hence u read it backwards, so if you look at the line above the From: line you see the first Via, which is what the client thinks it is i.e 192.168.20.3, BUT the proxy is clever, it knows where it received the message from , and it adds the rport and received tags
Via: SIP/2.0/UDP 192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
Soooo the proxy can talk SIP fine, because it knows these IP addresses.
BUT...poor old RTP is stuck because its headers or should I say direction is held lower down :
v=0. o=040618 8000 1 IN IP4 192.168.20.3. s=SIP Call. c=IN IP4 192.168.20.3. t=0 0. m=audio 38660 RTP/AVP 0 8 4 18 2 15 99. a=sendrecv. a=rtpmap:0 PCMU/8000/3. a=rtpmap:8 PCMA/8000/3.
The client expects to receive on port m=38660 and IP c= 192.168.20.3, which is where the other endpoint will try to send "voice" to.
8 Solution - You need to tell the client, not to act so dumb, and work out what the NAT settings are and put them in the SDP section of the message. So the client can ask the NAT....or it can ask someone on the outside what it should be.
Ask the NAT - use UPnP...I dont have much info on this..:-)
Ask someone on the outside --
You send a probe packet to the server sitting outside, it then sends a message back, with the details it received, the client then decides if its behind a NAT. This can be used for all 4 cases of NAT.
EG lets say we send out a packet from 10.1.1.1:1000 so in the SDP message m=1000 and c=10.1.1.1, but if I send out a probe first, and I get back 212.134.123.23:12345 then I can rewrite the SDP so m=12345 and c=10.1.1.1 , simple
Problem -- Since NAT settings are dynamic, and hence tend to change, you really need to get the SIP message out very soon after sending the probing message out,
The client send and receive ports must be the same
And....if you recall the restricted cones (port restricted included) will not allow replies unless there has been a packet sent out to that destination first, hence the client needs to send a packet out to the endpoint, b4 he can be allowed in via the NAT (but we dont need to worry about that)
IT WILL NOT WORK FOR SYMMETRIC NAT....because it wont :-), because the external UA IP:port is different to that where we sent the probe, hence the voice packet coming back will not have the correct path set.
- The above is usually done with a STUN server, and sending the
packet out to this server
- Symmetric NAT--- use a relay in the middle...Nathelper+ rtpproxy
or mediaproxy
13 Nathelper a) fix_nated_contact - rewrites contact Hf to source IP:port b) fix_nated_sdp - rewritres media IP and also direction ???? c) force_rtp_proxy - forces media to go through proxy d) nat_uac_test - mode=1 then as shown above the "received" header is compared to c= in sdp mode=2 then the Contact header is looked at to see if its private mode=3 (1+2) means it does both of the above
- mediaproxy is much the same...and good examples are available
15)Summary
4 types of NAT, which can be combined into 2 main sets, asymmetric and symmetric.
Asymmetric issues can be resolved by using STUN, hence no need for mediaproxy/nathelper Symmetric clients cant use STUN, hence u need to use mediaproxy/nathelper (or some other server end...also known as far-end nat traversal solution)
However if you didnt want to use STUN and mediaproxy/nathelper, then you could just use mediaproxy/nathelper and setup port forwarding on your NAT device.
I think that covers most, any suggestions let me know, I wrote this for my own use, but if its useful, I'll tidy it up.
One question....
Is there any way via a debug log, albeit, ngrep, tcpdump, sip_scenario display that I can from the server side detect if the NAT is asymmetric or Symmetric.
tks Iqbal
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Greger V. Teigre -
Iqbal -
Java Rockx -
Mohammad Khan