Geographical distribution of Media Relays

1. Geographical distribution of Media Relays Part of Global SIP framework Adrian Georgescu ag@ag-projects.com Dan Pascu dan@ag-projects.com

2. NAT traversal - best practices • The general principle of Internet (end-to-end communication) should apply for media exchanged between SIP User Agents. SIP User Agents should have ICE support and try to exchange RTP packets directly by using STUN techniques described by ICE methodology. • If ICE capability does not exist or does not work, a TURN (media relay) solution will be used.

3. Reserving media sessions • The SIP Proxy instead of the SIP User Agent should do the session reservation on the media relay. • This approach allows per call allocation of a media relay session in an optimum place on the Internet (based on any programmable criteria that may take into account geo-location of both parties, bandwidth availability, etc…) and solves the load balancing and scalability of the media relay function.

4. Trust model • The TURN servers will have a trust relationship with the SIP cloud. • The SIP User Agents have a trust relationship with the SIP Cloud the chain of trust is thus complete. • SIP UAs do not have to have TURN capability built-in, a database with user credentials does not need to be stored on the TURN server, configuration or TURN credentials are not stored in the client.

5. Media relay - lookup algorithm • For finding the closest media relay for mobile subscribers we use an algorithm similar with the SIP Proxy/Registrar location lookup. It is a two-step process involving only DNS queries. • SIP User Agent either registers with the SIP Proxy or sends for each INVITE its current Time zone (e.g Europe/Amsterdam). The Time zone may be inherited from the host Operating System, which in terms might have it set manually or obtained via DHCP during IP acquisition.

6. Lookup algorithm - step 1 A NAPTR query is performed based on key MinorTimeZone (the full Timezone) and as fail-over on the Major Timezone: adigeo@pmac2:~$dig NAPTR amsterdam.europe.example.com ;; QUESTION SECTION: ;amsterdam.europe.example.com. IN NAPTR ;; ANSWER SECTION: amsterdam.europe.example.com. 38364 IN NAPTR 0 0 "S" "TZ+turn" "" _mediaproxy._tcp.europe.example.com. ;; AUTHORITY SECTION: europe.example.com. 38103 IN NS ns7.dns-hosting.info. europe.example.com. 38103 IN NS ns1.dns-hosting.info. europe.example.com. 38103 IN NS ns2.dns-hosting.info. adigeo@pmac2:~$dig NAPTR europe.example.com

7. Lookup algorithm - step 2 A DNS SRV query is performed with the result of the NAPTR query. The results set contains the addresses of media relays that can be loaded with RTP traffic based on SRV weight/priority algorithm. adigeo@pmac2:~$dig SRV _mediaproxy._tcp.ag-projects.com ;; reply from unexpected source: 24.94.163.34#53, expected 24.26.163.24#53 ;; QUESTION SECTION: ;_mediaproxy._tcp.ag-projects.com. IN SRV ;; ANSWER SECTION: _mediaproxy._tcp.ag-projects.com. 300 IN SRV 20 25 25060 ns6.dns-hosting.info. _mediaproxy._tcp.ag-projects.com. 300 IN SRV 20 50 25060 ns7.dns-hosting.info. _mediaproxy._tcp.ag-projects.com. 300 IN SRV 5 50 25060 vm02.dns-hosting.info. _mediaproxy._tcp.ag-projects.com. 300 IN SRV 10 0 25060 ns3.dns-hosting.info. _mediaproxy._tcp.ag-projects.com. 300 IN SRV 10 50 25060 ns4.dns-hosting.info. _mediaproxy._tcp.ag-projects.com. 300 IN SRV 20 25 25060 ns5.dns-hosting.info.

8. It works today! The solution has been implemented with SIP Express Router, MediaProxy and Managed DNS

9. March 10, 2005 IEFT 62 Minneapolis Thank you, Adrian Georgescu ag@ag-projects.com