20160502

Mon May 2 07:52:17 EDT 2016 Slept from about eleven to seven. High of fifty-eight. Rainy in the morning. Goals: Work: - Order more SIP phones - Read about STUN Done. Session Traversal of UDP through NAT - The STUN server allows clients to find: - the public address - the type of NAT they're behind - the Internet-side port associated by the NAT with a particular local port - Clients use this info to set up UDP communication to establish a call. - Can do keep-alive to hold particular NAT'd ports associated with particular client devices - The STUN protocol is defined in RFC 3489. - STUN server listens on port 3478 for both TCP and UDP Example session: - Internal client hits the STUN server's port 5060 - The STUN server sees that the firewall has set the source port as 15391 (or whatever) - The STUN server reports the external source port and IP to the client - The client uses that port number and IP to register with the SIP server https://en.wikipedia.org/wiki/Network_address_translation [Hmm. That doesn't seem like it would really work with symmetric NAT.... Why would the firewall use the same source port when talking to the SIP server that it does when talking to the STUN server?] Answer: yes, STUN can't work around symmetric NAT. STUN is a no-go. Amazon EC2 doesn't appear to support IPv6, so that's not a viable alternative (even if I wanted to go down that road now, which I don't). http://rtcquickstart.org/guide/multi/index.html http://rtcquickstart.org/guide/multi/turn.html https://tools.ietf.org/html/rfc5766 https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+to+work+through+NAT https://wiki.asterisk.org/wiki/display/AST/Interactive+Connectivity+Establishment+%28ICE%29+in+Asterisk Intro to RFC 5766 (TURN) A host behind a NAT may wish to exchange packets with other hosts, some of which may also be behind NATs. To do this, the hosts involved can use "hole punching" techniques (see [RFC5128]) in an attempt discover a direct communication path; that is, a communication path that goes from one host to another through intervening NATs and routers, but does not traverse any relays. As described in [RFC5128] and [RFC4787], hole punching techniques will fail if both hosts are behind NATs that are not well behaved. For example, if both hosts are behind NATs that have a mapping behavior of "address-dependent mapping" or "address- and port- dependent mapping", then hole punching techniques generally fail. When a direct communication path cannot be found, it is necessary to use the services of an intermediate host that acts as a relay for the packets. This relay typically sits in the public Internet and relays packets between two hosts that both sit behind NATs. This specification defines a protocol, called TURN, that allows a host behind a NAT (called the TURN client) to request that another host (called the TURN server) act as a relay. The client can arrange for the server to relay packets to and from certain other hosts (called peers) and can control aspects of how the relaying is done. The client does this by obtaining an IP address and port on the server, called the relayed transport address. When a peer sends a packet to the relayed transport address, the server relays the packet to the client. When the client sends a data packet to the server, the server relays it to the appropriate peer using the relayed transport address as the source. A client using TURN must have some way to communicate the relayed transport address to its peers, and to learn each peer's IP address and port (more precisely, each peer's server-reflexive transport address, see Section 2). How this is done is out of the scope of the TURN protocol. One way this might be done is for the client and peers to exchange email messages. Another way is for the client and its peers to use a special-purpose "introduction" or "rendezvous" protocol (see [RFC5128] for more details). If TURN is used with ICE [RFC5245], then the relayed transport address and the IP addresses and ports of the peers are included in the ICE candidate information that the rendezvous protocol must carry. For example, if TURN and ICE are used as part of a multimedia solution using SIP [RFC3261], then SIP serves the role of the rendezvous protocol, carrying the ICE candidate information inside the body of SIP messages. If TURN and ICE are used with some other rendezvous protocol, then [MMUSIC-ICE-NONSIP] provides guidance on the services the rendezvous protocol must perform. Though the use of a TURN server to enable communication between two hosts behind NATs is very likely to work, it comes at a high cost to the provider of the TURN server, since the server typically needs a high-bandwidth connection to the Internet. As a consequence, it is best to use a TURN server only when a direct communication path cannot be found. When the client and a peer use ICE to determine the communication path, ICE will use hole punching techniques to search for a direct path first and only use a TURN server when a direct path cannot be found. TURN was originally invented to support multimedia sessions signaled using SIP. Since SIP supports forking, TURN supports multiple peers per relayed transport address; a feature not supported by other approaches (e.g., SOCKS [RFC1928]). However, care has been taken to make sure that TURN is suitable for other types of applications. TURN was designed as one piece in the larger ICE approach to NAT traversal. Implementors of TURN are urged to investigate ICE and seriously consider using it for their application. However, it is possible to use TURN without ICE. TURN is an extension to the STUN (Session Traversal Utilities for NAT) protocol [RFC5389]. Most, though not all, TURN messages are STUN-formatted messages. A reader of this document should be familiar with STUN. https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip+to+work+through+NAT https://wiki.asterisk.org/wiki/display/AST/Interactive+Connectivity+Establishment+%28ICE%29+in+Asterisk So, it looks like Asterisk might have a built-in ICE server. But we would also need to run a TURN server. Home: - Work on B/X analysis, decide fatality thresholds Done. - Buy food for lunches for the week Done. - Email Ed to see if he wants to host and/or DM this Saturday Done. - Laundry Done. Fascinating photo essay of trucking on frozen rivers in Siberia: http://www.rferl.org/fullinfographics/infographics/on-siberias-ice-highway/27706633.html# https://www.openstreetmap.org/export#map=16/42.4947/-83.2729 Valley Woods Nature Preserve Huh. I wondered what that was. It's not labeled on Google Maps. Watched a few episodes of Adventure Time.

< ^ txt