Geographical distribution of Media Relays

1
Geographical distribution of Media Relays

• Part of Global SIP framework

Adrian Georgescu ag_at_ag-projects.com Dan Pascu
dan_at_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_at_pmac2dig 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" "TZturn" "" _mediaproxy._tcp.europe.example.c
  om.
• 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_at_pmac2dig 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_at_pmac2dig SRV _mediaproxy._tcp.ag-project
  s.com
• reply from unexpected source 24.94.163.3453,
  expected 24.26.163.2453
• 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_at_ag-projects.com