rutgers by qingyunliuliu

VIEWS: 9 PAGES: 104

									VoIP: Not your grandmother's phone
any more
                                Henning Schulzrinne
                   Dept. of Computer Science, Columbia University, New York
   (based on work in collaboration with IRT students & staff, as well as the IETF GEOPRIV and
                                          SIMPLE WGs)
                                   hgs@cs.columbia.edu

                                     Rutgers University
                                        April 2009
Outline

• VoIP maturing: vision vs. reality
   – presence and location-based services
   – user-programmable services
• VoIP challenges
   –   scaling
   –   peer-to-peer systems
   –   spam/SPIT
   –   emergency calling
• The state of SIP standardization, year 11
   – developments in 2006 & upcoming highlights
   – trouble in standards land
   – interoperability

                                                  2
The three Cs of Internet applications

                              grossly simplified...




 communications        commerce                 community



            research           what users care about
              focus

                                                        3
Killer Application

• Carriers looking for killer application
   – justify huge infrastructure investment
   – “video conferencing” (*1950 – †2000)
   – ?
• “There is no killer application”
   – Network television block buster  YouTube hit
   – “Army of one”
   – Users create their own custom applications that are important to
     them
   – Little historical evidence that carriers (or equipment vendors) will
     find that application if it exists
• Killer app = application that kills the carrier
                                                                            4
Collaboration in transition

                                           inter-organization
                                                 multiple
                                               technology
                                              generations
                                           diverse end points
  intra-organization;
   small number of                                standards-based
                                                      solutions
  systems (meeting
        rooms)

                        proprietary (single-
                         vendor) systems



                                                                    5
          Evolution of VoIP

                                                                      “Can it really
                                                                       replace the
                                                                         phone
                                                   “How can             system?”
                                                   I make it
long-distance calling,                                stop            replacing the
      ca. 1930               “does it do           ringing?”
                                                                  global phone system
                            call transfer?”      going beyond
      “amazing
        – the                                   the black phone
        phone                catching up
        rings”           with the digital PBX



  1996-2000               2000-2003                2004-2005           2006-

                                                                                       6
 IETF VoIP efforts

          ECRIT                                                                            ENUM
    (emergency calling)                                     SIMPLE                    (E.164 translation)
                                                            (presence)
                                                                                    uses
         uses                    GEOPRIV                                                       SPEERMINT
                                (geo + privacy)                                                   (peering)
                                                              may use      uses
   XCON
(conf. control)
                                                                                                      uses
                                             SIP                          SIPPING
                     provides            (protocol)                (usage, requirements)
            IPTEL
           (tel URL)
                                                                                                  SPEECHSC
                                                  usually                                       (speech services)
                                                  used
                                                  with

                                 AVT                                    MMUSIC
                                                                  (SDP, RTSP ICE)
                                                                            ,
                                                                                                SIGTRAN
                           ,    ,
                       (RTP SRTP media)                                                    (signaling transport)

     IETF RAI area
                                                                                                               7
Old vs. new
           old reality         new idea             new reality
service    ILEC, CLEC          email-like, run by   E.164-driven; MSOs, some
provider                       enterprise, homes    ILECs, Skype, European SIP
                                                    providers, Vonage, SunRocket
media      4 kHz audio         wideband audio,      4 kHz audio
                               video, IM, shared
                               apps, …
services   CLASS (CLID, call   user-created         still CLASS
           forwarding, 3-way   services
           calling, ...)       (web model)
                               presence
user IDs   E.164               email-like           E.164
                                                    IM handles




                                                                                   8
SIP Overview

               9
Internet services – the missing
entry
     Service/delivery   synchronous             asynchronous
     push               instant messaging       messaging
                        presence
                        event notification
                        session setup
                        media-on-demand

     pull               data retrieval          peer-to-peer file sharing
                        file download
                        remote procedure call




                                                                        10
Filling in the protocol gap

Service/delivery   synchronous           asynchronous
push               SIP                   SMTP
                   RTSP, RTP
pull               HTTP                  (not yet standardized)
                   ftp
                   SunRPC, Corba, SOAP




                                                                  11
SIP as service enabler

•   Rendezvous protocol
     – lets users find each other by only
       knowing a permanent identifier
•   Mobility enabler:
     – personal mobility
          • one person, multiple terminals
     – terminal mobility
          • one terminal, multiple IP
            addresses
     – session mobility
          • one user, multiple terminals in
            sequence or in parallel
     – service mobility
          • services move with user




                                              12
What is SIP?

                Session Initiation Protocol  protocol that
                establishes, manages (multimedia) sessions
                    also used for IM, presence & event notification
                     uses SDP to describe multimedia sessions

                   Developed at Columbia U. (with others)
                             Standardized by
                              IETF (RFC 3261-3265 et al)
                                3GPP (for 3G wireless)

                                     PacketCable

               About 100 companies produce SIP products
                 Microsoft’s Windows Messenger (≥4.7)
                               includes SIP

                                                                 13
Philosophy

• Session establishment & event notification
• Any session type, from audio to circuit emulation
• Provides application-layer anycast service
• Provides terminal and session mobility
• Based on HTTP in syntax, but different in protocol
  operation
• Peer-to-peer system, with optional support by proxies
    – even stateful proxies only keep transaction state, not call
      (session, dialogue) state
    – transaction: single request + retransmissions
    – proxies can be completely stateless



                                                                    14
Basic SIP message flow




                         15
SIP trapezoid
                                                        destination proxy
                   outbound proxy
                                                (identified by SIP URI domain)

     1st request


                                       SIP
                                    trapezoid
                     2nd, 3rd, … request



                      a@foo.com:
                      128.59.16.1




                    registrar
                                                                 voice traffic
                                                                     RTP
                                                                           16
SIP message format
  request line


                                    request                                       response
                    INVITE sip:bob@there.com SIP/2.0                            SIP/2.0 200 OK


                     Via: SIP/2.0/UDP here.com:5060                  Via: SIP/2.0/UDP here.com:5060
    header fields




                    From: Alice <sip:alice@here.com>                From: Alice <sip:alice@here.com>
                      To: Bob <sip:bob@there.com>                     To: Bob <sip:bob@there.com>
                         Call-ID: 1234@here.com                          Call-ID: 1234@here.com
                             CSeq: 1 INVITE                                  CSeq: 1 INVITE
                           Subject: just testing                           Subject: just testing
                     Contact: sip:alice@pc.here.com                  Contact: sip:alice@pc.here.com
                      Content-Type: application/sdp                   Content-Type: application/sdp
                           Content-Length: 147                             Content-Length: 134
  message body




                                          v=0                                            v=0
                    o=alice 2890844526 2890844526 IN IP4 here.com   o=bob 2890844527 2890844527 IN IP4 there.com
                                    s=Session SDP                                  s=Session SDP
                               c=IN IP4 100.101.102.103                       c=IN IP4 110.111.112.113
                                         t=0 0                                          t=0 0
                               m=audio 49172 RTP/AVP 0                        m=audio 3456 RTP/AVP 0
                                a=rtpmap:0 PCMU/8000                           a=rtpmap:0 PCMU/8000



                                                                                                                   17
  SDP
PSTN vs. Internet Telephony

PSTN:


                Signaling & Media            Signaling & Media


                                            China
 Internet
telephony:
                   Signaling                   Signaling




                                    Media

    Belgian customer,                                       Australia
   currently visiting US
                                                                        18
SIP addressing

   •   Users identified by SIP or tel URIs
       –   sip:alice@example.com
   •   tel: URIs describe E.164 number, not dialed
       digits (RFC 2806bis)
   •   tel URIs  SIP URIs by outbound proxy
   •   A person can have any number of SIP URIstel:110   sip:sos@domain
   •   The same SIP URI can reach many different
       phones, in different networks
       –   sequential & parallel forking
   •   SIP URIs can be created dynamically:
       –   GRUUs
       –   conferences
       –   device identifiers (sip:foo@128.59.16.15)
   •   Registration binds SIP URIs (e.g., device
       addresses) to SIP “address-of-record”                  domain 
       (AOR)                                                 128.59.16.17
                                                          via NAPTR + SRV



                                                                          19
3G Architecture (Registration)


                                mobility management
                                       signaling




         serving                interrogating                    interrogating
         CSCF

         proxy                                             home IM domain

                                                      registration signaling (SIP)_



                 visited IM domain



                                                                                      20
Presence and event notification
We need glue!

• Lots of devices and services
   – cars
   – household
   – environment
• Generally, stand-alone
   – e.g., GPS can’t talk to camera
• Home
   – home control networks have generally
     failed
       • cost, complexity
• Environment
   – “Internet of things”
   – tag bus stops, buildings, cars, ...



                                            22
Left to do: event notification

•   notify (small) group of users when something of interest happens
     –   presence = change of communications state
     –   email, voicemail alerts
     –   environmental conditions
     –   vehicle status
     –   emergency alerts
•   kludges
     – HTTP with pending response
     – inverse HTTP --> doesn’t work with NATs
•   Lots of research (e.g., SIENA)
•   IETF efforts starting
     – SIP-based
     – XMPP



                                                                       23
Context-aware communication
     •    context = “the interrelated conditions in which something
          exists or occurs”
     •    anything known about the participants in the (potential)
          communication relationship
     •    both at caller and callee



   time                          CPL
   capabilities                  caller preferences

   location                      location-based call routing
                                 location events

   activity/availability         presence
   sensor data (mood, bio)       privacy issues similar to location data


                                                                           24
The role of presence

•   Guess-and-ring                             • Presence-based
     – high probability of failure:               – facilitates unscheduled
          • “telephone tag”                         communications
          • inappropriate time (call during
            meeting)                              – provide recipient-specific
          • inappropriate media (audio in           information
            public place)                         – only contact in real-time if
     – current solutions:                           destination is willing and able
          • voice mail  tedious, doesn’t         – appropriately use
            scale, hard to search and
            catalogue, no indication of when        synchronous vs.
            call might be returned                  asynchronous communication
          • automated call back  rarely          – guide media use (text vs.
            used, too inflexible
                                                    audio)
     –  most successful calls are now
       scheduled by email                         – predict availability in the near
                                                    future (timed presence)


                      Prediction: almost all (professional) communication
                          will be presence-initiated or pre-scheduled
                                                                                   25
GEOPRIV and SIMPLE architectures


       DHCP
                                                    rule
                                                   maker
                                 XCAP
                                 (rules)

              publication   location       notification    location
 target       interface                    interface                   GEOPRIV
                             server                        recipient

                                           SUBSCRIBE
                            presence                                   SIP
presentity                                                 watcher
              PUBLISH        agent                                     presence
                                           NOTIFY


 caller                                                     callee     SIP
               INVITE                      INVITE                      call
                                                                              26
           Presentity and Watchers

         Bob’s                                                                   SUBSCRIBE
                                                          Presence
       Presentity                        PUBLISH                                                      Watchers
                                                           Server                                    Watchers
                                                                                                     Watchers
                                                            (PS)                     NOTIFY
                                                                                 Available, Busy,
                                Bob’s
                                                                               Somewhat available,
                                status,                                             Invisible
                               location
                                                             Bob’s
                                                             Filters
                                                            (Rules),
                                                                                                             wife
                                                            PIDF *)
                  PUBLISH

                                                                                                             son
                           R u there ?


                         BUZZ                                                                                friend
Cell
       Phone   PC-IM Client Bob’s play station

       Bob’s Presence User                                                                                   external
          Agents (PUA)                                                                                       world
                                          *) - PIDF = Presence Information Data Format                           27
Basic presence

• Role of presence
   – initially: “can I send an instant message and expect a response?”
   – now: “should I use voice or IM? is my call going to interrupt a
     meeting? is the callee awake?”
• Yahoo, MSN, Skype presence services:
   – on-line & off-line
       • useful in modem days – but many people are (technically) on-line
         24x7
       • thus, need to provide more context
   – + simple status (“not at my desk”)
       • entered manually  rarely correct
       • does not provide enough context for directing interactive
         communications


                                                                            28
Presence data architecture


     presence sources

       PUBLISH

                                         raw
              create
               view
                                      presence                                privacy
            (compose)                 document                                filtering


                    XCAP                                 depends on watcher        XCAP
                               select best source
                               resolve contradictions


            composition                                                       privacy
              policy                                                           policy

           (not defined yet)
                                                        draft-ietf-simple-presence-data-model
                                                                                                29
Presence data architecture


     candidate                               raw
     presence                 watcher     presence              post-processing
                                                                 composition
     document                  filter     document                (merging)




                                  SUBSCRIBE
         remove data not of
         interest                        difference
                                         to previous notification


                                                                  final
                                                                presence
              watcher                                           document
                                        NOTIFY


                                                                                  30
    Presence data model


 person         “calendar”              “cell”           “manual”
 (presentity)

(views)

                      alice@example.com          r42@example.com
services               audio, video, text             video




devices

                                                                    31
Rich presence

• More information
• automatically derived from
   – sensors: physical presence, movement
   – electronic activity: calendars
• Rich information:
   – multiple contacts per presentity
        • device (cell, PDA, phone, …)
        • service (“audio”)
   –   activities, current and planned
   –   surroundings (noise, privacy, vehicle, …)
   –   contact information
   –   composing (typing, recording audio/video IM, …)


                                                         32
RPID: rich presence
                       <person>   <tuple>   <device>
     <activities>
     <class>
     <mood>
     <place-is>
     <place-type>
     <privacy>
     <relationship>
     <service-class>
     <sphere>
     <status-icon>
     <time-offset>
     <user-input>



                                                       33
RPID = rich presence

• Provide watchers with better information about the what,
  where, how of presentities
• facilitate appropriate communications:
   – “wait until end of meeting”
   – “use text messaging instead of phone call”
   – “make quick call before flight takes off”
• designed to be derivable from calendar information
   – or provided by sensors in the environment
• allow filtering by “sphere” – the parts of our life
   – don’t show recreation details to colleagues


                                                         34
CIPID: Contact Information

• More long-term identification of contacts
• Elements:
  –   card – contact Information
  –   home page
  –   icon – to represent user
  –   map – pointer to map for user
  –   sound – presentity is available




                                              35
The role of presence for call routing
                                              PUBLISH
• Two modes:
   – watcher uses presence
     information to select suitable
     contacts
                                                        PA
       • advisory – caller may not
         adhere to suggestions and                           NOTIFY
         still call when you’re in a      translate
         meeting                            RPID
   – user call routing policy
     informed by presence
       • likely less flexible – machine
         intelligence
       • “if activities indicate
                                           CPL          LESS
         meeting, route to tuple
         indicating assistant”
       • “try most-recently-active
         contact first” (seq. forking)


                                                         INVITE

                                                                  36
Presence and privacy

• All presence data,          <tuple id="sg89ae">
  particularly location, is     <status>

  highly sensitive                <gp:geopriv>
                                     <gp:location-info>

• Basic location object                 <gml:location>
                                          <gml:Point gml:id="point1“
  (PIDF-LO) describes                                   srsName="epsg:4326">
                                             <gml:coordinates>37:46:30N 122:25:10W
   – distribution (binary)                     </gml:coordinates>

   – retention duration                     </gml:Point>
                                        </gml:location>

• Policy rules for more              </gp:location-info>
                                    <gp:usage-rules>
  detailed access                      <gp:retransmission-allowed>no
                                           </gp:retransmission-allowed>
  control                              <gp:retention-expiry>2003-06-23T04:57:29Z

   – who can subscribe to                  </gp:retention-expiry>
                                    </gp:usage-rules>
     my presence                  </gp:geopriv>

   – who can see what           </status>
                                <timestamp>2003-06-22T20:57:29Z</timestamp>
     when                     </tuple>



                                                                                37
Privacy policy relationships


                             common policy




   geopriv-specific          presence-specific           future



                      RPID                       CIPID




                                                                  38
Privacy rules

• Conditions                           • User gets maximum of
   –   identity, sphere                  permissions across all
   –   time of day                       matching rules
   –   current location
                                         – privacy-safe composition:
   –   identity as <uri> or <domain>       removal of a rule can only
       + <except>
                                           reduce privileges
• Actions
   – watcher confirmation              • Extendable to new
• Transformations                        presence data
   – include information                 – rich presence
   – reduced accuracy                    – biological sensors
                                         – mood sensors



                                                                        39
       Example rules document
                <conditions>


                                  <rule id=1>

                                  <identity><id>user@example.com</id></identity>
            <actions>




                                  <sub-handling>allow</sub-handling>
<ruleset>




                                   <provide-services>
              <transformations>




                                     <service-uri-scheme>sip</service-uri-scheme>
                                     <service-uri-scheme>mailto</service-uri-scheme>
                                   </provide-services>
                                   <provide-person>true</provide-person>
                                   <provide-activities>true</provide-activities>
                                   <provide-user-input>bare</provide-user-input>


                                                                                       40
Creating and manipulating rules

•   Uploaded in whole or part via XCAP
•   XML not user-visible
•   Web or application UI, similar to mail filtering
•   Can also be location-dependent
    – “if at home, colleagues don’t get presence information”
• Possibly implementation-defined “privacy levels”




                                                                41
Location-based services
Location-based services

• Finding services based on location
   – physical services (stores, restaurants, ATMs, …)
   – electronic services (media I/O, printer, display, …)
   – not covered here
• Using location to improve (network) services
   – communication
       • incoming communications changes based on where I am
   – configuration
       • devices in room adapt to their current users
   – awareness
       • others are (selectively) made aware of my location
   – security
       • proximity grants temporary access to local resources

                                                                43
Location-based SIP services

• Location-aware inbound routing
   – do not forward call if time at callee location is [11 pm, 8 am]
   – only forward time-for-lunch if destination is on campus
   – do not ring phone if I’m in a theater
• outbound call routing
   – contact nearest emergency call center
   – send delivery@pizza.com to nearest branch
• location-based events
   – subscribe to locations, not people
   – Alice has entered the meeting room
   – subscriber may be device in room  our lab stereo changes
     CDs for each person that enters the room

                                                                       44
Location delivery
     GPS




               HELD
                       HTTP

                                 wire
                                 map
                       DHCP




                      LLDP-MED
                                        45
             Location-based service language
     NOTIFY
       true

        false

       action       alert             IM
                                           alert               incoming
                proximity                  message             outgoing

conditions      occupancy   actions        log        events   notify
                                           call
                                                               message
                time
                                           transfer
                                                               subscription
                                           join                         46
Program location-based services




                                  47
48
Application: Verizon SABIT PALS

• SABIT = web-based mobile employee productivity
  management system
• PALS - Presence-Aware Location-Based Service
   – Advanced communication services based on aggregation of
     presence information
   – Enhanced vehicle management system
• Presence/availability information of a user is combined
  with the location information (of the vehicle) to achieve
  an integrated communication environment
   – “only call when vehicle is stopped”



                 *) - Verizon Service Assurance Business Intelligence Toolkit   49
SABIT PALS Solution

Integrates:
• Status and diagnostic information of the vehicle
• Mobile employee’s location data obtained from a GPS
   device in a vehicle
• Mobile employee’s presence information data obtained
   from his/her cell-phone
• Laptop-based IM/VoIP soft client




                                                         50
Components of PALS architecture

•   Integrated In-Vehicle Device (IIVD –
    Vehicle Events)
•   SABIT System
•   HTTP-SIP Gateway (LBS Presence User
    Agent)
•   Media Server
•   Watcher or Supervisor Application    Field Tech     VZ Data/Real Time
•   Presence Server (PS)               Laptop-Connect          VZ VPN
                                         via WiFi or
                                          Ethernet
                                                                   GPS
                                                                      EVDO
                                                                            WiFi




                                                                            51
SABIT PALS Architecture

        Location from vehicle                   DB                           DB
  GPS
                                   SABIT
                                   System

                      EVDO


                                                                                   SUBSCRIBE    Watcher

                                             HTTP/ SIP      PUBLISH     Presence
                                      HTTP                                         NOTIFY      Watcher
                                             Gateway                    Server




                           MSC/HLR                                                     Media Server
                                                                                       Gateway




                                             PUBLISH


                                SIP Proxy
                                                                                      SABIT Supervisor “sees”
               Mobile Employee’s status is                                            mobile employees via the
               relayed through multiple                                               web-interface
               devices

                                                         Systems View
                                                                                                                 52
SABIT PALS Supervisor Application




                                    53
Communications Webpage




                         54
Roadmap

•   Introduction
•   Presence
•   Location-based services
•   Server scaling
•   P2P SIP
•   Standardization and interoperability


                                           55
SIP server overload

                                                    overloaded
 Springsteen tickets!!
      earthquake
vote for your favorite…          INVITE

                                          503
                                                     overloaded




                                                     overloaded




                          • Proxies will return 503 --> retry elsewhere
                          • Just adds more load
                          • Retransmissions exacerbate the problem
                                                                          56
Avalanche restart

•   Large number of terminals all start at once
•   Typically, after power outage
•   Overwhelms registrar
•   Possible loss of registrations due to retransmission time-out

                         #1
                                     REGISTER




                       #300,000

                                       reboot after
                                      power outage

                                                                    57
 Overload control

  •   Current discussion in design team
  •   Feedback control: rate-based or window-based
  •   Avoid congestion collapse
  •   Deal with multiple upstream sources

goodput

                                                       S1

                                                            S4
                                 capacity
                                                       S2


                                                            S5

                                                       S3        UA

                                                  UA




                                   offered load

                                                                  58
Coordinated Overload Control Architecture

                                  Overload Feedback



                                                                       Overload Detection
                                                                                                 Control          Feedback          Control
Overload Enforcement
                                                                                                Function                           Function

                                                                                             Throttle                                     Load
                                                                                                                                         Sample
                       Overload                            Overload
                        Control                             Control
                                                                                                Actuator                            Monitor



                        SIP                                  SIP

              Sending Entity (SE)                     Receiving Entity (RE)                       SIP                                SIP

                                                                                            Sending Entity (SE)              Receiving Entity (RE)


            Coordinated overload control
                                                                                                        ietf-hilt draft model
               with explicit feedback

                       Feedback scope: explicit feedback treated hop-by-hop vs. end-to-end
                       hop-by-hop feedback is generally believed to be more feasible

                                                                                                                                                     59
Scaling servers & TCP

• Need TCP                            •   Concern: TCP (and TLS) much
   – TLS support: customer                less efficient than UDP
     privacy, theft of service, …          – running series of tests to identify
                                             differences
       • particularly for WiFi
                                           – difference mainly in
   – many SIP messages now                      • connection setup cost
     exceed reasonable UDP size                 • message splitting (may need pre-
     (fragmentation)                              parsing or incremental parsers)
       • e.g., INVITE for IMS: 1182             • thread count (one per socket?)
         bytes                        •   Our model:
• Concern: UA support                      – 300,000 customers/servers
   – improving: 82% of systems at               • 0.1 Erlang, 180 sec/call
     recent SIPit’19 had TCP               – 600,000 BHCA --> 167 req/sec
     support                               – 300,000 registrations --> 83
                                             req/sec
   – only 45% support TLS
                                           – $0.001/subscriber

                                                                                   60
SIP server measurements

                TCP                                    • Initial INVITE measurements
                                                              – OpenSER
                                                              – 400 calls/sec for TCP
                                                              – roughly 260 calls/sec for TLS




 sipd REGISTER test




                      Kumiko Ono, Charles Shen, Erich Nahum
                                                                                            61
Roadmap

•   Introduction
•   Presence
•   Location-based services
•   Server scaling
•   P2P SIP
•   Standardization and interoperability


                                           62
P2P SIP
                                                    generic DHT service
•   Why?                                                                   p2p network
     – no infrastructure available: emergency
       coordination
                                                                          P2P provider B
     – don’t want to set up infrastructure: small
       companies
     – Skype envy :-)
•   P2P technology for                                                                 DNS
     – user location
          • only modest impact on expenses
          • but makes signaling encryption cheap    P2P provider A
     – NAT traversal
          • matters for relaying
                                                                                traditional provider
     – services (conferencing, …)
          • how prevalent?
•   New IETF working group formed                                               zeroconf
     – likely, multiple DHTs
     – common control and look-up protocol?                   LAN

                                                                                              63
P2P SIP -- components

• Multicast-DNS (zeroconf) SIP
  enhancements for LAN
   – announce UAs and their
     capabilities
• Client-P2P protocol
   – GET, PUT mappings
   – mapping: proxy or UA
• P2P protocol
   – get routing table, join, leave, …
   – independent of DHT?
   – replaces DNS for SIP, not proxy

                                         64
Zeroconf: solution for bootstrapping

  •   Three requirements for zero configuration networks:
      1)   IP address assignment without a DHCP server
      2)   Host name resolution without a DNS server
      3)   Local service discovery without any rendezvous server
  •   Solutions and implementations:
      –    RFC3927: Link-local addressing standard for 1)
      –    DNS-SD/mDNS: Apple’s protocol for 2) & 3)
      –    Bonjour: DNS-SD/mDNS implementation by Apple
      –    Avahi: DNS-SD/mDNS implementation for Linux and BSD




                                                                   65
DNS-SD/mDNS overview

  •   DNS-Based Service Discovery (DNS-SD) adds a level of
      indirection to SRV using PTR:
      _daap._tcp.local.     PTR   Tom’s Music._daap._tcp.local.   1:n mapping
      _daap._tcp.local.     PTR   Joe’s Music._daap._tcp.local.
      Tom’s Music._daap._tcp.local. SRV
                             0 0 3689 Toms-machine.local.
      Tom’s Music._daap._tcp.local. TXT
                 "Version=196613" "iTSh Version=196608"
                 "Machine ID=6070CABB0585" "Password=true”
      Toms-machine.local.    A    160.39.225.12

  •   Multicast DNS (mDNS)
      –   Run by every host in a local link
      –   Queries & answers are sent via multicast
      –   All record names end in “.local.”



                                                                         66
z2z: Zeroconf-to-Zeroconf interconnection



                rendezvous point - OpenDHT

      Import/export                     Import/export
      services                          services


                z2z                    z2z




       Zeroconf subnet A        Zeroconf subnet B
                                                        67
 Demo: global iTunes sharing

• Exporting iTunes shares under key “columbia”:
      $ z2z --export:opendht _daap._tcp --key “columbia”


• Importing services stored under key “columbia”:
      $ z2z --import:opendht --key “columbia”




                                                           68
 How z2z works (exporting)

                     OpenDHT                   1) Send browse request
put:                                              (i.e., PTR query) for
key=                                              service type: _daap._tcp
 z2z._daap._tcp.columbia
value=
 Tom’s Music                                   2) Send resolve request
                                                  (i.e., SRV, A, and TXT
 160.39.225.12:3689     z2z                       query) for each service
 Password=true
 ……
         Tom’s Music.       Joe’s Music.       3) Export them by putting
                                                  into OpenDHT
         _daap._tcp.local   _daap._tcp.local

        160.39.225.12         160.39.225.13
        Tom’s Computer        Joe’s Computer
        Password=true         Password=false
        ……                    ……                                     69
  How z2z works (importing)

                       OpenDHT                 1) Issue get call into
get:                                              OpenDHT
key=z2z._daap._tcp.columbia
value=Tom’s Music
        160.39.225.12:3689        “A” record for
        ……                        160.39.225.12 2) Add “A” record into
value=Joe’s Music                                  mDNS
        ……                  z2z      mDNS

                                               3) Import services by
                                                  registering them
             Tom’s Music._daap._tcp.local         (i.e., add PTR, SRV,
             _remote-160.39.225.12.local          TXT records to the local
             ……                                   mDNS)

                                                                        70
z2z implementation

  • C++ Prototype using xmlrpc-c for OpenDHT access
     – Proof of concept
     – Porting problem due to Bonjour and Cygwin incompatibility
  • z2z v1.0 released
     – Rewritten in Java from scratch
     – Open-source (BSD license)
     – Available in SourceForge (https://sourceforge.net/projects/z2z)
  • Paper describing design and implementation detail
     – z2z: Discovering Zeroconf Services Beyond Local Link
         • Lee, Schulzrinne, Kellerer, and Despotovic
     – Submitted to IEEE Globecom’07 Workshop on Service Discovery




                                                                         71
Zeroconf for SIP

• Enable SIP communication when proxy and registrar are
  not available
   – Good use case for z2z
   – Fill in the gap of P2P-SIP effort:
       • local & small scale (10s to 100s)
       • high mobility
       • avoid construction of DHT
• Internet Draft published and presented at IETF-68
   – SIP URI Service Discovery using DNS-SD
       • Lee, Schulzrinne, Kellerer, and Despotovic
       • http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-01




                                                                  72
SIP URI advertisement
  •   Example
      _sipuri._udp.local. PTR sip:bob@a.com._sipuri._udp.local.
      _sipuri._udp.local. PTR sip:joe@a.com._sipuri._udp.local.
      sip:bob@a.com._sipuri._udp.local. SRV
                                       0 0 5060 bobs-host.local.
      sip:bob@a.com._sipuri._udp.local. TXT
             txtvers=1 name=Bob contact=sip:bob@bobs-host.local.
  •   Service instance name: Instance.Service.Domain
       – Instance = ( SIP-URI / SIPS-URI ) [ SP description ]
       – Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp”
       – E.g.) sip:bob@example.com - PDA._sipuri._udp.local.
  •   Contact TXT record attribute
       – Similar to Contact SIP header except:
            • It contains only a single URI
            • Non-SIP URIs are not allowed
       – UA capabilities advertised via field parameters (RFC3840)




                                                                       73
Peer-to-Peer Protocol (P2PP)
   Salman Abdul Baset, Henning Schulzrinne
               Columbia University
Overview

• Objective: key  (opaque) data
    – distributed data structure with O(log N) or O(1) [rarely]
• Practical issues in peer-to-peer systems
• Peer-to-peer systems
    – file sharing
    – VoIP
    – streaming
•   P2PSIP architecture
•   Peer-to-peer protocol (P2PP)
•   P2PP design issues
•   Implementation




                                                                  75
      Practical issues in peer-to-peer systems

• Bootstrap / service discovery

• NAT and firewall traversal
• TCP or UDP?

• Routing-table management
• Operation during churn

• Availability and replication

• Identity and trust management



                                                 76
                           Peer-to-peer systems
Performance impact / requirement




                                                      Service discovery
                                     High    Data size      NAT           Data size
                                                         Replication        NAT

                                   Medium                                 Replication

                                            Replication
                                    Low       NAT          Data size



                                            File sharing     VoIP         Streaming
                                                                                        77
P2PSIP: Concepts

•   Decentralized SIP
    – Replace SIP proxy and registrar with p2p
      endpoints
•   Supernode architecture
    – P2PSIP peers
       •   participate in the p2p overlay
    – P2PSIP clients
       •   use peers to locate users and resources




                                                     78
  P2PSIP architecture
      [ Bootstrap / authentication server ]

                                   alice@example.com
                                       Overlay2
                                                             SIP
          NAT
                   Overlay1                            P2P        STUN

                                                         TLS / SSL
                               NAT
                                                       A peer in P2PSIP

bob@example.com                                        A client


                                                                     79
Peer-to-Peer Protocol (P2PP)

• P2P applications have common requirements such as discovery,
  NAT traversal, relay selection, replication, and churn management.
• Goals
    – A protocol to potentially implement any structured or unstructured
      protocol.
    – Not dependent on a single DHT or p2p protocol
• Not a new DHT!

• It is hard!
    – Too many structured and unstructured p2p protocols
    – Too many design choices!

• Lets consider DHTs



                                                                           80
 DHTs

                                                 Lookup             Lookup
                             Distance
  DHT       Geometry                           correctness        performance
                             function
                                             (neighbor table)    (routing table)


 Chord                    Modulo numeric
               Ring                           Successor list      Finger table
Accordion                   difference


                          Prefix match. If
Tapestry,    Hybrid =       fails, then
 Pastry,                                     Leaf-set (Pastry)   Routing table
            Tree + Ring   modulo numeric
Bamboo
                            difference


Kademlia       XOR        XOR of two IDs          None           Routing table


                                                                             81
   Periodic recovery                                                 Accordion
                               Routing-table stabilization
 Finger table         Tree
                                                                      Kademlia
                                         Lookup correctness

       Parallel requests                                           Prefix-match
                                         Modulo addition
 Routing-table size           OneHop
                                                       Leaf-set
      Recursive routing                     Pastry
                                                            Bootstrapping
 Updating routing-table from lookup requests
                                                 Ring                Bamboo
                              Tapestry
                XOR
                                         Proximity neighbor selection
Lookup performance
                         Successor           Reactive recovery
 Hybrid                                                               Chord
          Strict vs. surrogate routing               Proximity route selection

                                                           Routing-table exploration
                                                                                   82
How to design P2PP?

• Structured
   – Identify commonalities in DHTs
        • Routing table (finger table)
        • Neighbor table (successor list, leaf-set)
   – Separate core routing mechanisms from from DHT-independent issues.
• Unstructured
   – may not always find all keys
• Incorporate mechanisms for
   –   discovery
   –   NAT / firewall traversal
   –   churn, identity and trust management
   –   request routing (recursive / iterative / parallel)




                                                                      83
       How to design P2PP?
 DHT-independent               DHT-specific                   DHT-specific
                               Not restricted to
Bootstrapping
                               one DHT                        Bamboo      Chord
                               Lookup performance             Tapestry    Kademlia
Routing-table stabilization
                               Lookup correctness             Pastry      OneHop
Reactive vs. periodic
recovery                                                      Accordion
                                  Successor / leaf-set
Parallel requests                 Finger table / routing      Modulo addition
                                  table
Recursive routing                                             Prefix-match
                                  Routing-table size
Proximity neighbor selection                                  XOR
                                                                          Geometry
Proximity route selection
                               Updating routing-table                     Ring
                               from lookup requests
                                                                          Hybrid
                               Strict vs. surrogate routing               Tree   84

                               Routing-table exploration
        Chord
        (Strict routing-table management)



                                            id=x
                                               Neighbor table
                                               (successor)


                                                      Routing table
                                                                x+2i

                                                                x+2i+1
Immediately
succeeds                                                        x+2i+2
routing-table id                                                x+2i+3




                                                                    85
                                                                Node
Peer-to-Peer Protocol (P2PP)

• A binary protocol
• Geared towards IP telephony but equally applicable to file sharing,
  streaming, and p2p-VoD
• Multiple DHT and unstructured p2p protocol support
• Application API
• NAT traversal
    – using STUN, TURN and ICE
    – ICE encoding in P2PP
• Request routing
    – recursive, iterative, parallel
    – per message
• Supports hierarchy (super nodes [peers], ordinary nodes [clients])
• Reliable or unreliable transport (TCP or UDP)



                                                                        86
Peer-to-Peer Protocol (P2PP)

• Security
   – DTLS, TLS, signatures
• Multiple hash function support
   – SHA1, SHA256, MD4, MD5
• Diagnostics
   – churn rate, messages sent/received
• Node capabilities
   – bw determination, CPU utilization, number of neighbors, mobility




                                                                    87
Join
JP                  BS                      P5                       P7           P9
       1. Query

       2. 200
 P5, P30, P2P-Options

       3+. STUN (ICE candidate gathering)

                    4. Join
                                                           5. Join

                                                           6. 200          JP
                    7. 200                            N(P9, P15)          (P10)
                  N(P9, P15)
                                                 8. Join

                                                 9. 200

                                                 10. Transfer

                                                 11. 200

                                                                                   88
Call establishment
      P1                   P3                     P5                         P7
       1. Lookup-Peer (P7)
                               2. Lookup-Peer (P7)     3. Lookup-Peer (P7)

                                                       4. 200 (P7 Peer-Info)
                               5. 200 (P7 Peer-Info)
       6. 200 (P7 Peer-Info)


                                  7. INVITE

                                  8. 200 Ok

                                  9. ACK

                                  Media




                                                                                  89
Implementation

•   Chord, Kademlia, Bamboo (in-progress)
•   SHA1, SHA256, MD5, MD4
•   Windows, Linux
•   Integrated with OpenWengo (VoIP phone)

• Available for download (Linux + Windows)
    http://www1.cs.columbia.edu/~salman/p2pp/setupp2pp.html




                                                              90
 Implementation
   insert (key, value, callback)
                                                        callback (resp)
   lookup (key, callback)


Bootstrap             Client       ChordPeer        KadPeer          OtherPeer



                                     Node

            Distance             Routing table        Parser / encoder

             BigInt             Neighbor table        Transactions


                  Sys          Transport / timers

                               UDP          TCP
                                                                                 91
Screen snapshot
   • Alice and Bob are
     part of Kademlia
     network
   • Alice calls Bob
   • The lookup is
     performed using
     P2PP
   • Call is established
     using SIP


                           92
P2P summary

• P2P techniques now becoming mainstream
   – motivated by low opex, ease of deployment
   – building block, rather than application
• Many operational issues
   – interconnection: z2z
   – local peering: Bonjour for SIP
   – start-up and recovery: cf. Skype failure
• P2PP: Common platform protocol
   – application-neutral
   – extensible mechanism



                                                 93
Roadmap

•   Introduction
•   Presence
•   Location-based services
•   Server scaling
•   P2P SIP
•   Standardization and interoperability


                                           94
SIP, SIPPING & SIMPLE –00 drafts


       80
       70
       60
       50
                                                           SIP
       40
                                                           SIPPING
       30                                                  SIMPLE
       20
       10
        0
            1999 2000 2001 2002 2003 2004 2005 2006

        includes draft-ietf-*-00 and draft-personal-*-00
                                                              95
RFC publication

  14

  12

  10

   8                                             SIP
                                                 SIPPING
   6
                                                 SIMPLE
   4

   2

   0
       2001   2002   2003   2004   2005   2006


                                                       96
IETF WG: SIP in 2006 & 2007

•   ~ 44 SIP-related RFCs published in 2006      – security:
       –   BFCP, conferencing
       –   SDP revision                              •   end-to-middle security
       –   rich presence                             •   certificates
•   Activities:
       –   hitchhiker’s guide
                                                     •   SAML
       –   infrastructure:                           •   sips clarification
             •    GRUUs (random identifiers)
             •    URI lists                      – NAT:
             •    XCAP configuration
             •    SIP MIB                            • connection re-use
       –   services:                                 • SIP outbound
             •    rejecting anonymous requests
             •    consent framework                  • ICE (in MMUSIC)
             •    location conveyance
             •    session policy




                                                                   see http://tools.ietf.org/wg/sip’/
                                                                                                  97
IETF WG: SIPPING

• 31 RFCs published in 2006      • Testing and operations
• Policy                            –   IPv6 transition
   – media policy                   –   race condition examples
   – SBC functions                  –   IPv6 torture tests
• Services                          –   SIP offer-answer examples
   –   service examples             –   overload requirements
   –   call transfer                –   configuration
   –   configuration framework      –   voice quality reporting
   –   spam and spit
   –   text-over-IP
   –   transcoding




                                                                    98
Interoperability                                       SIPREAL BOF
                                                        at IETF 70?



• Generally no interoperability problems for basic SIP functionality
    – basic call, digest registration (mostly...), call transfer, voice mail
• Weaker in advanced scenarios and backward compatibility
    –   handling TCP, TLS
    –   NAT support (symmetric RTP, ICE, STUN, ...)
    –   multipart bodies
    –   SIP torture tests
    –   call transfer, call pick-up
    –   video and voice codec interoperability (H.264, anything beyond G.711)
• SIPit useful, but no equivalent of WiFi certification
    – most implementations still single-vendor (enterprise, carrier) or vendor-
      supplied (VSP)
    – SFTF (test framework) still limited
• Need profiles to guide implementers

                                                                                99
Trouble in Standards Land

•   Proliferation of transition standards: 2.5G,
    2.6G, 3.5G, …                                     OASIS                data
                                                                           formats
     – true even for emergency calling…
                                                       W3C                 data
•   Splintering of standardization efforts
                                                    ISO (MPEG)             exchange
    across SDOs
     – primary:                                                            L2.5-L7
          • IEEE, IETF, W3C, OASIS, ISO                   IETF             protocols
     – architectural:
          • PacketCable, ETSI, 3GPP, 3GPP2, OMA,
            UMA, ATIS, …                                  IEEE             L1-L2
     – specialized:
          • NENA
     – operational, marketing:




                                                             PacketCable
          • SIP Forum, IPCC, …




                                                   3GPP
                                                                           100
IETF issues

•   SIP WGs: small number (dozen?)          •   Stale IETF leadership
    of core authors (80/20)                      – often from core equipment
     – some now becoming managers…                 vendors, not software vendors or
     – or moving to other topics                   carriers
•   IETF: research  engineering           •   fair amount of not-invented-here
    maintenance                                 syndrome
                                                     • late to recognize wide usage of
     – many groups are essentially                     XML and web standards
       maintaining standards written a               • late to deal with NATs
       decade (or two) ago
                                                     • security tends to be per-protocol
          • DNS, IPv4, IPv6, BGP, DHCP;                (silo)
            RTP, SIP, RTSP                                – some efforts such as SAML and
          • constrained by design choices                   SASL
            made long ago
                                            •   tendency to re-invent the wheel in
     – often dealing with transition to         each group
       hostile & “random” network
     – network ossification




                                                                                       101
IETF issue: timeliness

•   Most drafts spend lots of time in 90%-       •   IETF meetings are often not
    complete state                                   productive
     –   lack of energy (moved on to new -00)         – most topics gets 5-10 minutes 
     –   optimizers vs. satisfiers                      lack context, focus on minutiae
           •   multiple choices that have non-
               commensurate trade-offs                – no background  same people as
•   Notorious examples:                                 on mailing list
     –   SIP request history: Feb. 2002 – May         – 5 people discuss, 195 people read
         2005 (RFC 4244)                                email
     –   Session timers: Feb. 1999 – May 2005    •   No formal issue tracking
         (RFC 4028)
                                                      – some WGs use tools, haphazardly
     –   Resource priority: Feb. 2001 – Feb
         2006 (RFC 4412)                         •   Gets worse over time:
•   New framework/requirements phase                  – dependencies increase,
    adds 1-2 years of delay                             sometimes undiscovered
•   Three bursts of activity/year, with               – backwards compatibility issues
    silence in-between                                – more background needed to
     –   occasional interim meetings                    contribute




                                                                                         102
IETF issues: timeliness

• WG chairs run meetings, but are not managing WG
  progress
   – very little control of deadlines
       • e.g., all SIMPLE deadlines are probably a year behind
   – little push to come to working group last call (WGLC)
   – limited timeliness accountability of authors and editors
   – chairs often provide limited editorial feedback
• IESG review can get stuck in long feedback loop
   – author – AD – WG chairs
   – sometimes lack of accountability (AD-authored documents)
• RFC editor often takes 6+ months to process document
   – dependencies; IANA; editor queue; author delays
   – e.g., session timer: Aug. 2004 – May 2005


                                                                 103
Conclusion

• Even after 10+ years, VoIP mostly still “cheaper calls”
• New services and models:
   –   (rich) presence
   –   location-based services
   –   user-programmable services
   –   P2P SIP
• Scaling to carrier-scale and under duress
• Current standardization processes slow and complexity-
  inducing



                                                            104

								
To top