Programmatically determine the Router NAT type - nat

I need to programmatically determine the Router NAT type in my program. I did look at some of the STUN related answers and UPnP related information on SO. But did not get any definitive answers.
I looked at STUN RFC (rfc 5389) and it does not specify how to determine the NAT type. It does mention that it's previous version (RFC 3489) did provide the mechanism to determine NAT type. But also mentions that
Furthermore. classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
Given above, could you please advice on how I should go ahead with determination of router NAT type in my software. Further, now that RFC 3489 is obsoleted is there any other means?
Thanks in advance.

RFC 3489 was split into three different RFCs:
RFC 5389 - basic STUN protocol. Basic protocol of STUN binding request and binding response are largely the same as RFC 3489. The protocol header gets updated with a magic cookie occupying some of the transaction id field. Some STUN attributes get redefined. A few new ones added (specifically - XOR_MAPPED_ADDRESS). Some changes to how STUN auth is done. NAT behavior and classification discussion moved to RFC 5780.
RFC 5780 - "Nat Behavior discovery using STUN". The basic change to NAT type discovery was to distinguish NAT port mapping behavior separate from NAT filtering behavior. Whereas RFC 3489 would try to classify a NAT into one of several buckets ("cone", "port restricted", "symmetric") - which was just too generic to describe a NAT.
RFC 5769 - Just outlines what the hex dump of a few different STUN message types would look like.
Out of curiosity, I suppose knowing if your app is running behind a NAT is useful. But how would knowing the NAT's behavior influence your code path?
Shameless plug - Use my STUN Server code that is hosted on GitHub.

Related

Audio issues with asterisk 13

I have two extensions registered to asterisk (asterisk has a real IP), both of them behind NAT, and every one of them belong to a different LAN network.
The SIP work just fine (i.e: the extensions can call each other), but there is no voice at all.
I configure natting and media in sip.conf in asterisk as follow:
nat=force_rtp,comedia
directrtpsetup=yes
Note: when i put the extensions in the same NAT, there is no problem, both SIP and RTP work just fine.
does anybody knows what is the problem or how to solve it?
thanks in advance.
Asterisk 1.8: The 'nat' option has now been been changed to have yes,
no, force_rport, and comedia as valid values. Setting it to yes forces
RFC 3581 behavior and enables symmetric RTP support. Setting it to no
only enables RFC 3581 behavior if the remote side requests it and
disables symmetric RTP support. Setting it to force_rport forces RFC
3581 behavior and disables symmetric RTP support. Setting it to
comedia enables RFC 3581 behavior if the remote side requests it and
enables symmetric RTP support.
force_rtp is not valid option. Force_rport,comedia are mutially exclusive options.
Directrtpsetup most likly will not work if both clients NATed.
thanks, idescovered the problem and its solution.
first of all, the wright NAT options are:
nat=force_rport,comedia
second, the wright media option is:
directmedia=no
my problem was related to opened port, in rtp.conf i put:
rtpstart=1111
rtpend=2222
but in the server the range of the opened port is {44444 --> 55555}
and because of that there wasn't voice between the callee and the caller.

Is this a reasonable technique to establish P2P connections between two hosts behind a NAT?

In order for two hosts behind two different NATs to be able to establish a P2P connection, they must both have each other's public endpoints (address/port). In order for each host to become aware of its own public endpoint, it can communicate with a known public server that returns to the host its public endpoint as seen by the server. See STUN (RFC5389).
In order for this mechanism to work, the NAT must consistently translate the same private endpoint to the same public endpoint regardless of the destination endpoint.
Would it be a good idea to implement a P2P application that depends on this particular NAT behavior (i.e. is it common enough)? Does Skype and/or other popular P2P applications have other fallback mechanisms?
EDIT: It looks like a NAT in which a different port is chosen per destination is called a "Symmetric NAT". In addition, some symmetric NATs increment the port number enabling a possibility of guessing the proper port.
Now I suppose the question is: Roughly what percentage of NATs are symmetric NATs, and what percentage of those use random port assignments vs. something like incrementing?
You can use standard STUN/TURN/ICE protocols from IETF:
http://rtcbits.blogspot.com/2012/10/what-is-ice-interactive-connectivity.html
According to Google Gtalk statistics these mechanisms solve the P2P connection without relaying traffic in 92% of the cases.
https://developers.google.com/talk/libjingle/important_concepts
STUN can only handle 85% of the cases! TURN can handle 100% but is really expensive to use. So what to use? neither of the two
Use ICE. It is the direct combination of STUN servers and TURN servers! That way you will have 100% reliability but you will only relay on a server 15% of the traffic.

IPv6 Header Priority

From this site (http://www.ipv6.com/articles/general/IPv6-Header.htm) , it says:
Packet priority/Traffic class (8 bits) The 8-bit Priority field in the IPv6 header can assume different values to enable the source node to differentiate between the packets generated by it by associating different delivery priorities to them. This field is subsequently used by the originating node and the routers to identify the data packets that belong to the same traffic class and distinguish between packets with different priorities.
I was wondering, if it is possible to actually "hack" the TCP/IP stack in order to give your packets higher priority. Would you get any substantial gain in network performance. Also, if it is possible, how is it prevented?
Yes, it's possible, but it's not really hacking. There is a standard programming interface that will allow your program to indicate to the stack how it would like the Traffic Class header field to be populated.
Whether or not you will measure any performance difference depends on the network that handles your packets. Think of the Traffic Class field as a hint for the network; a suggestion for how you would like your packet to be handled. The network might ignore it, or even change it to a different code point. Furthermore, the notion of "priority" (also known as "precedence") as an interpretation of the Traffic Class field has receded into a much richer collection of Per Hop Behaviors (PHBs).
See IETF RFC 3542 Advanced Sockets Application Program Interface (API) for IPv6. In particular, read the first part of Section 4, Access to IPv6 and Extension Headers, and Section 6.5, Specifying/Receiving the Traffic Class value.
Here is a code snippet that sets the Traffic Class field to the integer MY_TCLASS for all packets sent on the socket sk.
int tclass;
tclass = MY_TCLASS;
setsockopt(sk, IPPROTO_IPV6, IPV6_TCLASS, &tclass, sizeof(int));
Related reading:
IETF RFC 3493 Basic Socket Interface Extensions for IPv6
Section 5 talks about basic socket options
IETF RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
Section 7.1 discusses Theft and Denial of Service, which, from the point of view of a network operator, is what what you're asking about.
IETF RFC 2475 An Architecture for Differentiated Services
Section 2.1 covers a whole bunch of terminology.
I don't understand the question. You don't need to hack anything. There's an API provided for setting the TC on a socket. What effect it has depends on the cooperation of the intervening routers.
The source can change the priority but the routers and gateway will can change the priority depending upon the type of packet that is

Asterisk + NAT. Either get called or be called

My Asterisk set up is as follows:
- I have 2 grandstream GXP 2000 phones connected to my router
- My small linux server (with asterisk) is connected to the router as well
I have a dynamic ip from my isp provider, but I signed up for DynDNS
When I started I could call people and talk to them. If people rang me, the phone would ring, and I could hear them speak. They could not hear me. I found out this was because of the directmedia / canreinvite setting. So I set this to:
canreinvite=no
directmedia=no
Now, people could call me and I could answer. However, due to this change I can call people, but as soon as they answer, I can't hear them, I only hear static. When I remove the two lines I add, everything is back as it was before.
What could be the issue ? The 5060 port is forwarded to my server ,as well as the 1000 - 2000 udp rang.
Regards,
Digits
First of all, you should probably read the sip.conf.sample file delivered with Asterisk. Specifically, read the NAT SUPPORT section. canreinvite and directmedia (which are the same setting by the way) attempt to set up the RTP streams directly between the UAs involved in a call, bypassing Asterisk. Thus, while that setting is affected by NAT, it does not necessarily control the channel driver behavior with respect to NAT - so its not surprising you're still having issues.
Without knowing whether or not the UAs in question are sending rport, its difficult to know for sure what your settings should be. That being said, based on your problem description, you may want to set the 'nat' parameter in your [general] section to either:
nat = force_rport,comedia
; or, depending your version
nat = yes
Note that you can set nat on a peer by peer basis, but that's discouraged for security reasons.
Additionally, you may also need to explore the extern* settings, such as externhost.
Ok, some information for other people in the same situation:
- check your codecs, make sure you get no errors in the Asterisk CLI (command line interface). I got errors, but it worked, so I didn't care. That was a mistake
- upgrade to asterisk 1.8
- set directmedia = no
- it's upd range 10000 to 20000 (I missed a 0).
This all fixed this problem.

How do applications know which OSI protocol to use?

I would like to understand what happens when we type "google.com" in our browser wrt OSI model. What all protocols comes into picture AT EACH LAYER any how does they know which one to be used?
Also I would like to know, TCP/UDP which one to be used in Transport layer is decided for network/application? That is for a normal web page like google.com TCP must be used but for video streaming UDP. how is this conveyed to network?
Is the browser also part of this as it is helping. Should it also come under application layer?
Http comes under Application layer of OSI model. now for this particular example, what will come under Presentation and Session layers? Will the sessions be maintained in session layer or HTTP will be doing it on their behalf?
It sounds like you would like a tutorial on TCP/IP. May I suggest a couple of good books
URLs in webpages have a prefix that tells the applications what to do with that link. For instance, ftp:// opens an ftp session, which uses tcp (ref RFC 959 - File Transfer Protocol). As a general rule, the URL prefixes correspond to a standardized protocol, which was specified via RFC. The RFC denotes which transport protocol is used.
EDIT
In the case of youtube, their videos have a http:// URL prefix, but after you make the request, it is redirected to a rtsp:// URL. RTSP can be streamed over UDP.
To answer questions like this, you may find that wireshark is very useful to investigate these things... keep in mind that wireshark works best on wired connections.
Applications don't use any layer of the OSI protocol stack. They use TCP or UDP from the TCP/IP stack, and they 'know which' because of they are programmed to use one or the other or both. The OSI model is obsolete and certainly doesn't apply to TCP/IP.
EDIT: The OSI layer model is a Procrustean bed into which TCP/IP does not fit. You should forget about OSI immediately. It doesn't describe anything in the real world.

Resources