siemens.ppt - PowerPoint Presentation

Document Sample
siemens.ppt - PowerPoint Presentation Powered By Docstoc
					VoIP - Moving from
protocols to architecture(s)




       Henning Schulzrinne
     Dept. of Computer Science
        Columbia University
          September 2005
Overview
   The big transitions in VoIP
   An Internet protocol framework
   Open issues in VoIP and interactive
    multimedia communications
       service creation and programmable systems
       VoIP: poll model  presence model
       application sharing
   SIP architecture and design philosophy
   Philosophies: Skype, IETF, NGS, …


September 2005                                      2
Philosophy transition
                                 PC era
One computer/phone,         cell phone era
     many users
                        One computer/phone,
    mainframe era
     home phone
                              one user
      party line
                                              Many computers/phones,
                                                     one user

                                               ~ ubiquitous computing




                                                  right place (device),
            anywhere,                                   right time,
             any time                                  right media
            any media



  September 2005                                                          3
     Evolution of VoIP

                                                “how can I make it
                                                  stop ringing?”

long-distance calling,
      ca. 1930             “does it do            going beyond
                          call transfer?”        the black phone

  “amazing – the
                             catching up
   phone rings”
                         with the digital PBX



  1996-2000                2000-2003                  2004-


    September 2005                                                 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




  September 2005                                                  5
Current challenges
   Protocol (point)               System challenges
    challenges                         9-1-1
       9-1-1 support                  reliability (incl.
            location mapping           consistent QoS)
       presence                       manageability
        configuration and                   by non-experts
        policy                         cross-domain AAA
       automated system               inter-domain trust
        configuration




September 2005                                                6
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




September 2005                                                       7
Filling in the protocol gap

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




  September 2005                                                  8
An eco system, not just a
protocol
                  configures


 XCAP                       XCON                   SIMPLE
                                                    policy
(config)                (conferencing)              RPID
                                                     ….


                                initiates               carries



    RTSP                 SIP                   SDP


                                                    carries
   controls                                   provide addresses

                                            STUN
                  RTP
                                            TURN
 September 2005                                                   9
            A constellation of SIP RFCs
                                 Request routing
Non-adjacent (3327)
Symmetric resp. (3581)
Service route (3608)                                               Resource mgt. (3312)
User agent caps (3840)                                             Reliable prov. (3262)
Caller prefs (3841)                                                INFO (2976)
                                                                   UPDATE (3311)
                                      SIP (3261)                   Reason (3326)
                                      DNS for SIP (3263)
 ISUP (3204)                          Events (3265)                          Mostly PSTN
 sipfrag (3240)                       REFER (3515)
  Content types                                    Core



                  Digest AKA (3310)
                  Privacy (3323)                           DHCP (3361)
                  P-Asserted (3325)                        DHCPv6 (3319)
                Agreement (3329)
                Media auth. (3313)                                         Configuration
                AES (3853)
              September 2005       Security & privacy                                      10
     SIP – a bi-cultural protocol



• overlap dialing              • multimedia
• DTMF carriage                • IM and presence
• key systems                  • location-based service
• notion of lines              • user-created services
• per-minute billing           • decentralized operation
• early media                  • everyone equally suspect
• ISUP & BICC interoperation
• trusted service providers



       September 2005                                       11
                                 SIP is PBX/Centrex ready
                                                                                                  boss/admin features
                         call waiting/multiple RFC 3261                 simultaneous             RFC 3261
                         calls                                          ringing
                         hold                    RFC 3264               basic shared lines       dialog/reg. package
                         transfer                RFC 3515/Replaces      barge-in                 Join
centrex-style features




                         conference              RFC 3261/callee caps   “Take”                   Replaces

                         message waiting         message summary        Shared-line              dialog package
                                                 package                “privacy”
                         call forward            RFC 3261               divert to admin          RFC 3261

                         call park               RFC 3515/Replaces      intercom                 URI convention

                         call pickup             Replaces               auto attendant           RFC 3261/2833

                         do not disturb          RFC 3261               attendant console        dialog package

                         call coverage           RFC 3261               night service            RFC 3261

                                                                                        attendant features
                                                                                           from Rohan Mahy’s VON Fall 2003 talk
                                     September 2005                                                                   12
SIP design objectives
    new features and services
          support features not available in PSTN
          e.g., presence and IM, session mobility
    not a PSTN replacement
          not just SS7-over-IP
          even similar services use different models (e.g., call transfer)
    client heterogeneity
          clients can be smart or dumb (terminal adapter)
          mobile or stationary
          hardware or software
    client multiplicity
          one user – multiple clients – one address
    multimedia
          nothing in SIP assumes a particular media type

    Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00

September 2005                                                                13
SIP architectural principles (1)
   proxies are for routing                       endpoint fate sharing
       do not maintain call state                      call fails only if endpoints
            availability                                fail
            scalability                          component-based
            flexibility                           design
            extensibility (new                         building blocks
             methods, services)
                                                         call features =
    end point call state and
                                                     
                                                        notification and
    features                                             manipulation
   dialog models, not call                       logical components, not
    models                                         physical
       does not standardize                            UA, proxy, registrar,
        features                                         redirect server
                                                        can be combined into
                                                         one box
Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00

September 2005                                                                   14
SIP architectural principles (2)
   designed for the (large)               generality over
    Internet                                efficiency
       does not assume                        focuses on algorithm
        particular network                      efficiency, not constant-
        topology                                factor encoding efficiency
       congestion-controlled                  “efficiency penalty is
       deals with packet loss                  temporary, generality is
       uses core Internet                      permanent”
        services:                              text encoding
            DNS for load balancing            extensibility
            DHCP for configuration            use shim layer for
            S/MIME for e2e security            compression where
            TLS for channel security           needed
                                               allow splitting of
                                                functionality for scaling



September 2005                                                       15
SIP architectural principles (3)
   separation of signaling and media
       path followed by media packets independent of
        signaling path
       allows direct routing of latency-sensitive media
        packets (10 ms matters)
            without constraining service delivery (1s matters)
       facilitates mobility
            avoid “hair pinning”, “tromboning”
       facilitates vertical split between ISP and VSP




September 2005                                                    16
SIP design principles (1)
   Proxies are method, body                Full-state nature of INVITE
    and header independent                       each (re)INVITE contains
       does not depend on method                 full session state
            except CANCEL, ACK                  facilitates MIDCOM-style
            can add new methods                  interactions
             without upgrading proxies           allows session transfer
       primarily rely on URI, Via,         SIP URIs identify resources
        Route and Record-Route
        header fields                            can be device instance,
                                                  service, person
       extensions: Accept-
                                                       but cannot tell from URI
        Contact and Request-
                                                   

                                                       which (good!)
        Disposition
                                                 can specify services and
       may use anything to guide                 service parameters
        routing decision




September 2005                                                               17
SIP design principles (2)
     Extensibility and compatibility                   Internationalization
          can define new methods,                           UTF-8 for freeform text
           header fields, body types,                        negotiation of languages
           parameters
                                                        Explicit intermediaries
          supported by OPTIONS,
           Accept, Accept-Language,                          = SIP proxies
           Allow, Supported, Require,                        unlike transparent HTTP proxies
           Proxy-Require, Accept-                             or NAT boxes, announce
           Encoding and Unsupported                           themselves
          “asking permission”                                    Via, Record-Route
                OPTIONS, dialog establishment               only involved if asked by UA or
          “asking forgiveness”                               proxy
                use extension without asking                should ask endpoints, rather
                (Proxy)-Require: “please reject              than just do
                 if you don’t understand it”                      e.g., session policy
          “use if you like”
                allow recipients to safely ignore
                 information
          must provide fallback!




    September 2005                                                                        18
SIP design principles (3)
   Guided proxy routing                Protocol reuse
       predetermine a set of               MIME for body transport
        downstream proxy resource           S/MIME for end-to-end
        that must be visited                 security
       supported by Record-                HTTP header field and
        Route, Path, Service-                semantics
        Route                               HTTP digest authentication
   Transport protocol                      URI framework
    independence                            non-SIP URIs (e.g., tel:)
       can use UDP, TCP, SCTP, …           re-use TLS for channel
       only requires packet-based           security
        (unreliable) delivery               use DNS SRV and NAPTR
       design decision that comes           for server failover and
        with some regret                    reliability




September 2005                                                      19
SIP division of labor
                 proxy             B2BUA                UA
 State           stateless         call stateful        call stateful
                 transaction-
                 stateful
 Headers         inspect           inspect              inspect
                 insert            insert               reflect
                 modify (rarely)   modify
 Bodies          ignore            inspect              inspect
                 some inspect      insert
                                   modify
 Fork            yes               separate call legs   no
 Media           no                maybe                yes
 Services        rendezvous        call stateful        media-related
                 call routing
September 2005                                                          20
Interconnection approaches
Property                 NGN, 3GPP            “Internet”
interconnection          per service          service neutral
end device control       carrier-controlled   user-provided
end device type          mostly hardware      software, maybe hardware
state preference         call state-full      stateless
                                              transaction-stateful
interconnect             pre-arranged         serendipitous
arrangement
interconnect discovery   pre-configured       DNS
billing preference       per service          bandwidth-based
                         usage-based          services fixed-rate or ad-
                                              supported
billing arrangement      clearing house       sender keeps
                                              independent



  September 2005                                                      21
           IETF “4G” (access-neutral) model
                                                                          Check
                                                                      reputation of
                                                                      columbia.edu
sip:alice@columbia.edu 
                                                       TLS
  sip:bob@example.com


                                columbia.edu                 example.com


               Visited
               network

                                           NSIS NTLP
          802.1x                           for QoS
                                                                           DIAMETER
                           AP                                                server

     alice@isp.net


                                                                            isp.net




              September 2005                                                          22
Session Border Controllers (SBCs)
   Provider border element
   SIP terms: either B2BUA or proxies
       but often ill-defined (may change roles)
   Functions differ
       similar definitional problem as “soft
        switches”
   May force convergence of media and
    signaling path

September 2005                                     23
SBCs: High-level motivations
   Why application-layer elements in SIP that are not quite
    proxies?
   SMTP has various MTAs, but they are just MTAs (e.g., spam
    filter)
   Guesses:
       media vs. control separation
            good idea in theory, harder in today’s limited-functionality Internet
            force media through single control point (IP address)
                  rather than from millions of sources
            see Asterix, Skype
       proxy model of no content (SDP) inspection or modification too
        limited
       CALEA (needs to be invisible)
       charging for services
            not an issue for email and web




September 2005                                                                       24
SBC functionality, cont’d
     Signaling functionality:                Media functionality:
          Protocol Conversion H.323             Codec conversion
           SIP                                     SLA enforcement
          Protocol integrity - SIP                Legal Intercept & CALEA
           normalization                            compliance
          ENUM – SIP redirect                     Bandwidth Management
          Policy enforcement and access           Packet marking
           control                                 QoS guarantees
          CDR creation                            Packet steering
          Firewall (dest. port, source)           Media encryption
          Least-cost routing                      Firewall (pinholes)
          Certificate handling                    DoS attack mitigation
          Caller-ID authorization
          Signaling encryption
          S/MIME encapsulation
          TCP/UDP-TLS bridging
          DoS attack mitigation




    September 2005                                                            25
SBC: Network evolution
                          stand-alone networks
                          (Vonage, Skype)

                 media


                          earlier: email, IM

                    SBC



                          only IP-level
                          (with filter)


September 2005                                 26
SBC: Concerns
   Common concerns:
       may drop some header fields
       may fail to understand some request
        methods
       may modify headers inserted by others
       may modify session descriptions
       may inspect session descriptions
   Not all SBCs do this all the time, but
    some do some of this sometimes…

September 2005                                  27
SBC: The dangers
      May not be present in all instances

          SBCs are a box description, not a
                                                      Lack of security
           function description                           Inherent conflict between
      Lack of visibility

           cannot tell where SBC is located
                                                           need for media session
                                                           inspection and session
       
                hard to diagnose failures
          see HTTP “transparent proxy”                    privacy
           experience
                one example: TP thought SIP was          Session description
                 HTTP
          hard to address content                         modification removes
           cryptographically to such box                   accountability
      Lack of transparency
                                                       Lack of scalability

          not all features make it through SBC    
           header support
       

          copying content
                                                          needs to handle all media
          routing loops                                   packets
                                                          often, call stateful
                                                               rather than stateless or
                                                                transaction-stateful


    September 2005                                                                  28
What’s left to do?
   Transition from “poll” model to context-based
    communications
   Higher-level service creation in end systems
   Dealing with NATs
       STUN (and SIP modifications) as first step
       ICE and BEHAVE WG as longer-term solutions
   The role of intermediaries
       session-border controllers
       end-to-middle security
       session policies
   Conference control
   Application sharing
   Security issues (spam, spit --> identity and
    reputation management)
September 2005                                       29
The role of presence
     Guess-and-ring                                  Presence-based
          high probability of failure:                    facilitates unscheduled
                “telephone tag”                            communications
                inappropriate time (call during           provide recipient-specific
                 meeting)                                   information
                inappropriate media (audio in             only contact in real-time if
                 public place)                              destination is willing and able
          current solutions:                              appropriately use synchronous
                voice mail  tedious, doesn’t              vs. asynchronous
                 scale, hard to search and
                 catalogue, no indication of                communication
                 when call might be returned               guide media use (text vs.
                automated call back  rarely               audio)
                 used, too inflexible                      predict availability in the near
           most successful calls are                      future (timed presence)
           now scheduled by email



                 Prediction: almost all (professional) communication
                     will be presence-initiated or pre-scheduled


    September 2005                                                                      30
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

September 2005                                         31
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

September 2005                                                    32
                Presence data model

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

(views)

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




devices


                September 2005                                                 33
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



September 2005                                                                                34
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




September 2005                                                                   35
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, …)


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


September 2005                                      37
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                           NOTIFY
             and still call when you’re   translate
             in a 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



September 2005                                                    38
Presence and privacy

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

    is 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

    control                                  </gp:retransmission-allowed>
                                         <gp:retention-expiry>2003-06-23T04:57:29Z

       who can subscribe to                 </gp:retention-expiry>

        my presence
                                      </gp:usage-rules>
                                    </gp:geopriv>

       who can see what          </status>

        when
                                  <timestamp>2003-06-22T20:57:29Z</timestamp>
                                </tuple>




September 2005                                                                   39
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



September 2005                                                      40
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




September 2005                                                             41
Program location-based services




September 2005                42
Service creation
    Tailor a shared infrastructure to individual users
    traditionally, only by vendors (and sometimes carriers)
    learn from web models: killer app vertical apps


                       programmer,         end user
                       carrier
    network            SIP servlets,       CPL
    servers            sip-cgi
    end system         VoiceXML            VoiceXML (voice),
                       scripting, RPC      LESS


September 2005                                                 43
Automating media interaction –
service examples
   If call from my boss, turn off the stereo  call
    handling with device control
   As soon as Tom is online, call him  call handling
    with presence information
   Vibrate instead of ring when I am in movie theatre 
    call handling with location information
   At 9:00AM on 09/01/2005, find the multicast session
    titled “ABC keynote” and invite all the group
    members to watch  call handling with session
    information
   When incoming call is rejected, send email to the
    callee  call handling with email


September 2005                                      44
LESS: simplicity
   Generality (few and simple concepts)
   Uniformity (few and simple rules)
                                             modifiers
       Trigger rule
       Switch rule
       Action rule     trigger   switches    actions

       Modifier rule
   Familiarity (easy for user to understand)
   Analyzability (simple to analyze)

September 2005                                           45
     LESS: Decision tree
No loops
Limited variables
Not necessarily
 Turing-complete




      September 2005       46
LESS: Safety
   Type safety
        Strong typing in XML schema
        Static type checking
   Control flow safety
        No loop and recursion
        One trigger appear only once, no feature interaction for a defined
         script
   Memory access
        No direct memory access
   LESS engine safety
        Ensure safe resource usage
   Easy safety checking
        Any valid LESS scripts can be converted into graphical
         representation of decision trees.




September 2005                                                          47
 LESS snapshot                                      incoming call
<less>
 <incoming>                               If the call from my boss
  <address-switch>
   <address is=“sip:myboss@abc.com">
    <device:turnoff                              Turn off the stereo
      device=“sip:stereo_room1@abc.com”/>
    <media media=“audio”>
      <accept/>                         Accept the call with only audio
    </media>
   </address>
  </address-switch>
 </incoming>
</less>
                         trigger, switch, modifier, action




  September 2005                                                    48
LESS packages
                    Use packages to group elements

                                    SIP user agent
    im      email       web               SIP

                                   Basic user agent
 Presence presence
 agent                            Generic Media UI
            Event

  calendar conference
                                    x10         vcr
    session          location        Device agent

September 2005                                        49
When Tom is online, …
<less>
<EVENT:notification>
 <address-switch>
   <address is="sip:tom@example.com">
    <EVENT:event-switch>
     <EVENT:event is="open">
       <location url="sip:tom@example.com">
        <IM:im message="Hi, Tom"/>
       </location>
     </EVENT:event>
    </EVENT:event-switch>
    ………
</less>




September 2005                                50
When I am in a movie theatre, …
<less>
<incoming>
 <location-switch>
    <location placetype=“quiet”>
      <alert sound=“none” vibrate=“yes”/>
    </location>
 </location-switch>
</incoming>
</less>

September 2005                              51
Programming VoIP clients
   Precursor: CTI
       but rarely used outside call centers
   Call external programs
       e.g., Google maps, local search
   Scripting APIs
       e.g., call Tcl or PHP scripts  sip-cgi
   Controllable
       COM, XML RPC
            used for media agents in sipc
   Embeddable
       no UI, just signaling and media
September 2005                                    53
Interfacing with Google
                 911: caller location
                 IM/presence: location of friends
                 call: “I’m here”




September 2005                                      54
Interfacing with Google
                     show all files from
                     caller Xiaotao Wu




September 2005                         55
Embedding VoIP: FAA training
                      controls pilot
                     and ATC agents
                         – using
                      multicast and
                         unicast
                      (“landlines”)




September 2005                     56
Conference control
   Setting up parameterized conferences
       SIP INVITE and NOTIFY suffice for basic
        dial-in conference functionality and change
        notification
   IETF XCON WG struggling with model
    and complexity




September 2005                                  57
XCON System
Logical XCON Server
                                                       TEMPLATE
     TEMPLATE Policy:                                  Of the SYSTEM:
     •Of TYPE RULES                                 •Pre-configured
                                                    •Initial/Default values
                                               RESERVATION
  RESERVATION Policy:
                                               Of the INSTANCE:
  •Of TYPE RULES
                                               •Of TYPE CONFERENCE-INFO
CURRENT Policy:                             STATE
•Of TYPE RULES                              Of the CURRENT INSTANCE:
                                            •Of TYPE CONFERENCE-INFO




 CPCP            CCCP         Focus           Conf Event          Floor
 Server          Server                       Notification        Control
                                              Server              Server
                                   SIP/
                                   PSTN/            SIP NOTIFY/
    CPCP              CCCP         H.323                               BFCP
                                                    Etc.
                                   T.120/
                                   Etc.                             Floor
 CPCP            CCCP           Call          Notification
 Client          Client      Signaling                             Control
                                                Client
                               Client                               Client
 Logical XCON
September 2005     Client                                                     58
Open issues: application sharing
   Current: T.120
       doesn’t integrate well with other conference control
        mechanisms
       hard to make work across platforms (fonts)
       ill-defined security mechanisms
   Current: web-based sharing
       hard to integrate with other media, control and record
       generally only works for Windows
       mostly limited to shared PowerPoint
   Current: vnc
       whole-screen sharing only
       can be coerced into conferencing, but doesn’t integrate well
        with control protocols


September 2005                                                   59
IETF effort: standardized
application sharing
   Remote access = application sharing
   Four components:
       window drawing ops  PNG
       keyboard input
       mouse input
       window operations (raise, lower, move)
   Uses RTP as transport
       synchronization with continuous media
       but typically, TCP
       allow multicast  large group sessions


September 2005                                   60
Spam and spit




September 2005   61
SIP unsolicited calls and
messages
   Possibly at least as
    large a problem                       mutual
       more annoying (ring,              PK authentication (TLS)
        pop-up)
       Bayesian content
        filtering unlikely to
        work                             home.com
                                Digest
    identity-based
    filtering
   PKI for every user
    unrealistic
   Use two-stage
    authentication
       SIP identity work


September 2005                                                      62
         Domain Classification
   Classification of domains based on their identity instantiation and
    maintenance procedures plus other domain policies.
        Admission controlled domains
             Strict identity instantiation with long term relationships
                    Example: Employees, students, bank customers
        Bonded domains
             Membership possible only through posting of bonds tied to a expected behavior
        Membership domains
             No personal verification of new members but verifiable identification required such as a
              valid credit card and/or payment
                    Example: E-bay, phone and data carriers
        Open domains
             No limit or background check on identity creation and usage
                    Example: Hotmail
        Open, rate limited domains
             Open but limits the number of messages per time unit and prevents account creation by
              bots
                    Example: Yahoo




         September 2005                                                                            63
  Reputation service
                              has sent
                                          David
                   Carol
                               IM to
                                                  has sent
                                                  email to

                           Emily         Frank




                     is this a spammer?
Alice                                               Bob

  September 2005                                             64
SIP standards & deployment
issues and competition
   Interoperability
   Proprietary systems




September 2005               65
Provider combinations


    Skype
                 software   Cisco
                                     hardware
                             CM
                                                mobile
                                                operators?
                 ISP
                             cable   VSP
                 IAP
                            DSL op




September 2005                                               66
VoIP service providers
                    mostly IM
                  no PSTN (now)
   Google
   MSN                                 AT&T (Vantage)
   Yahoo!                              Verizon (VoiceWing)
   Xbox                                JP SoftBank (8.3m)


                        primary line
                        replacement
                         voice only
    Skype                                Cable (911,000):
    Vonage (1m)                          ComCast




September 2005                                               67
Protocol interoperability problems
   Three core interoperability problems:
       syntactic robustness
            “You mean you could have a space there?”
                 often occurs when testing only against common reference
                  implementations
                 need “stress test” (also for buffer overflows)
            implementation by protocol example
            limiting assumptions (e.g., user name format)
            see “SIP Robustness Testing for Large-Scale Use”,
             First International Workshop on Software Quality
             (SOQA)
       semantic assumptions
            “I didn’t expect this error”
       mutually incompatible extensions
            expect extension to make something work
September 2005                                                       68
Protocol interoperability:
proprietary protocols
     Proprietary protocol
         Example: Skype
         quicker evolution – not dependent on IETF
          “volunteers” with day jobs
         can do “hacks” without IESG objection:
             media over TCP
             inefficient search
             bypass routing policies
             circumvent firewall policies
         Can only reverse-engineer  only backwards-
          compatibility problems
             incentive to force upgrades (see Microsoft Word)
         less Metcalfe’s law value

    September 2005                                               69
Why is Skype successful?
   All the advantages of a proprietary protocol
   Peer-to-peer coincidental
   Good out-of-box experience
       Software vendor = service provider
   Didn’t know that you couldn’t do voice quality beyond
    PSTN
       others too focused on PSTN interoperability – why do
        better voice than PSTN?
   Simpler solutions for NAT traversal
       use TCP if necessary
       use port 80
   Did encryption from the very beginning
   Kazaa marketing vehicle
September 2005                                            70
Skype vs. SIP-based systems
                    Skype                              SIP-based providers
Protocol            proprietary, encrypted             open (SIP), often plain-text
                    SIP to gateways                    sometimes IAX to gateway
Business model      prepaid outbound PSTN calls        monthly fee (Vonage)
                    (SkypeOut)                         free (FWD)
                                                       prepaid (SIPgate.de)
Protocol model      single “network”, bridge to PSTN   some closed
                                                       some semi-open (*-codes)
Allow federation?   not currently                      yes
NAT traversal       integrated                         separated (STUN)
User agent          software only                      software and hardware
                    (USB phones)                       primarily market hardware
User interface      presence-like                      phone-like




 September 2005                                                                       71
Open standard, dominant
vendor
   Example: H.323
   doesn’t matter what the standard says
   NetMeeting and H.323  test with
    Microsoft implementation
   limits feature evolution to dominant
    vendor speed and interests



September 2005                          72
Open standard, multiple
vendors
   Example: SIP
   More than just one application:
      Software UAs, proxies, phones, gateways, media servers,
       test tools, OA&M, …
   interoperability problems likely until product maturity
   harder to test internally against all (competing) products
   divergent views and communities in IETF and other SDOs
      likely have to support union of requirements
      emphasis on extensibility, modularity and protocol re-use
            temptation to not implement everything
      security
   SIP: generality over efficiency
   better long-term outcome, but slower




September 2005                                                     73
The SIP complexity fallacy
   IAX (for example) is simpler than
    SIP
   but you could build the IAX                        IAX model
    functionality in SIP at just about the
    same complexity:
        no proxies
                                             Signaling & Media      Signaling & Media
        no codec negotiation
        no distributed services
   Difficulty: extracting those simple
    pieces from 269 pages of
    specification (+ SDP + RTP) 
   SIP still more complex due to               Signaling            Signaling
    signaling-data separation

                                                            Media

                                              SIP, H.323, MCGP model


September 2005                                                                74
Does it have to be that
complicated?




• highly technical parameters, with differing names
• inconsistent conventions for user and realm
• made worse by limited end systems (configure by multi-tap)
• usually fails with some cryptic error message and no indication which
  parameter
•September 2005
  out-of-box experience not good                                       75
Solving the configuration mess
   Initial development assumed enterprise deployment
       pre-configured via tftp or (rarely) DHCP
       not suitable for residential use, except if box is shipped
       pathetic security – password accessible to anybody
        who knows MAC address of phone
   Short term
       adopt simple default conventions
       should only need SIP URI (AoR), display name and
        password
           realm = URI
           outbound proxy = domain
       provide and expose error feedback
           not “authentication failure”
           but “realm not recognized – change to user@domain format”
       use DNS NAPTR and SRV for STUN server

September 2005                                                          76
Solving the configuration mess
– longer term
   IETF efforts on configuration management
       retrieve via HTTP (+ TLS)
       change notification via SIP event notification
       problem of configuring initial secret remains
       probably need embedded public keys
   Still need better diagnostics
       one-way voice issues
       authentication failures




September 2005                                           77
Conclusion
   Slow transition from emulating PSTN to new services
       presence-based
       embedded (e.g., games)
   Emphasis moving from protocol mechanics to
    architecture
       slow transition to open systems
       different combinations of software vendors, IAP/ISP, VSP,
        hardware vendors
   Still need to fill out infrastructure for collaboration
    and presence
   Standardization bodies face challenges of overlap
    and resource exhaustion

September 2005                                                 78

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:357
posted:12/14/2010
language:English
pages:77