session i5 creating secure services for internet telephony

IEEE NJ Coast Section Seminar on Wireless LAN &

IP Telephony

Session I5Creating Secure Services for Internet Telephony

Henning SchulzrinneColumbia [email protected]

March 28, 2002 2 IEEE NJ Coast Section seminar on Wireless LAN & IP Telephony

Overview

What are IP telephony services? Where do services reside? How to create services?

– basic “fixed” services (call forwarding, follow me, ...)– registration-based services: caller preferences– sip-cgi model– Call Processing Language (CPL)– sip servlets & JAIN

Event notification and presence Example of an enterprise IP telephony platform Billing in IP telephony


Overview

Security in IP telephony– dealing with NATs and firewalls– differences to classical PSTN networks– threats

• theft of service• registration impersonation• denial of service• privacy

– current SIP approaches Summary and conclusion


Aside: evolution of SIP

Not quite what we had in mind– initially, SIP for initiating multicast conferencing

• in progress since 1992• still small niche• even the IAB and IESG meet by POTS conference…

– then VoIP• written-off equipment (circuit-switched) vs. new equipment (VoIP)• bandwidth is (mostly) not the problem• “can’t get new services if other end is POTS’’ “why use VoIP if I

can’t get new services”


Evolution of SIP

VoIP: avoiding the installed base issue– cable modems – lifeline service– 3GPP – vaporware?

Finally, IM/presence and events– probably, first major application– offers real advantage: interoperable IM– also, new service


VoIP at Home

Lifeline (power) Multiple phones per household

– expensive to do over PNA or 802.11– BlueTooth range too short– need wireless SIP base station + handsets– PDAs with 802.11 and GSM? (Treo++)

Incentives– SMS & IM services


SIP phones

Hard to build really basic phones– need real multitasking OS– need large set of protocols:

• IP, DNS, DHCP, maybe IPsec, SNTP and SNMP• UDP, TCP, maybe TLS• HTTP (configuration), RTP, SIP

– user-interface for entering URLs is a pain see “success” of Internet appliances “PCs with handset” cost $500 and still have a Palm-

size display thus, offer services

– Java-programmable– XML forms input


Example SIP phones


What are IP telephony services?

Services (features) modify basic call behavior Can be

– invoked by user– pre-programmed into network elements (e.g., SIP proxies)– programmable feature logic

PSTN: CLASS (Custom local area signaling services) features– call waiting– call forwarding– caller ID (calling number delivery)– distinctive ringing– selective call rejection– three-way calling, ...

PSTN: pre-subscribed for feature access codes (e.g., *66)


IP telephony services

Call routing services: pre-call, one party

– speed dial– click-to-dial– call forwarding– “follow me”– call filtering/blocking (in/out)– do not disturb– distinctive ringing– call prioritization– feature-based agent selection– call return

Call handling features– hotline– autoanswer– intercom

Multi-party features– call waiting– whispered call waiting– blind transfer: no confirmation of

success– attended transfer– consultative transfer: three-party

conference transfer– conference call– call park– call pickup– music on hold– call monitoring– barge-in– speakerphone paging– single-line extension


IP telephony features – Internet-specific

Presence-enabled calls– place call only if callee is available

Presence-enabled conferencing– call conference participants when all are online and not busy

IM conference alerts– receive IM when someone joins a conference

Unified messaging– receive email with new voice message– IM alert for voicemails


Voice-enabled features

Interactive Voice Response (IVR)– VoiceXML– voice browser

Voice-enabled features: VoiceXML

<?xml version="1.0"?><vxml version="2.0"><form id="basic">

<field name="acctnum" type="digits"><prompt> What is your account number? </prompt>

</field><field name="acctphone" type="phone">

<prompt> What is your home telephone number?</prompt><filled>



<return namelist="acctnum acctphone"/> </filled></field>

</form></vxml>


PSTN vs. Internet Telephony

Number of lines or pending calls

is virtually unlimited

Single line, 12 buttons and

hook flash to signal

More intelligence, PCs can be considered to be

end-user devices

PSTN Internet Telephony end system


PSTN vs. Internet Telephony

Signaling & Media Signaling & Media

Signaling Signaling

Media

PSTN:

Internettelephony:


Service provider architectures

Models of providing services:– IP PBX– IP Centrex (and cable/DSL)– Carrier / 3G

Similar equipment (logically), but– different trust models– sharing of resources (SIP proxies, gateways)


IP PBX


IP Centrex


IP Carrier


3G Architecture (Registration)

visited IM domain

home IM domain

servingCSCF

interrogating

proxy

interrogating

mobility managementsignaling

registration signaling (SIP)_


Service models & protocols

Master-slave protocols (MGCP, Megaco)– feature logic in media gateway controller (MGC)– send detailed behavioral commands to MG

• send ring tone• expect dialed digit string• play announcement

– MG can only “guess” what is meant– assembly-language instructions

Peer-to-peer protocols (SIP, H.323)– more like function calls– methods (SIP method, H.323 request) and parameters (SIP

headers, H.323 ASN.1 variables)– H.323: per-feature specification (H.450.x)– SIP: building blocks (Headers, REFER, JOIN, ...)


Combining peer-to-peer and master-slave


CLASS services: Caller-ID

SIP To/From headers (+ Organization) Also: Call-Info

Call-Info: http://alice.com/photo.jpg ;purpose=icon,

<http://alice.com/> ;purpose=info Can be “anonymous’’ Cannot necessarily be trusted, since inserted by user

Remote-Party-ID: "John Doe" <sip:[email protected]>;party=calling; idtype=subscriber;privacy=full;screen=yes


CLASS services: call forwarding, follow-me

Built into core SIP Call forwarding:

– either at proxy or at end system– 302 + Contact: temporary forwarding– 301 + Contact: permanent forwarding

Follow me:– REGISTER using single identifier– with different temporary IP addresses– “adopt” different hardware via (e.g.,) i-button


SIP personal mobility


Call filtering (in/out)

Outbound call filtering done by outbound proxy Often, outbound proxy controls firewall Inbound call filtering at any of the stages:

– e.g., sip:[email protected] sip:[email protected]– proxies can do filtering at

• bigcorp.com• eng.bigcorp.com• paris.eng.bigcorp.com

Fixed or programmable rules (later)


Call routing -- forking


Call routing -- ENUM

Translation between E.164 telephone numbers and URIs (e.g., SIP URIs)

RFC 2916 +46-8-9761234 becomes

4.3.2.1.6.7.9.8.6.4.e164.arpa Look up using (new) NAPTR DNS record Example contact 1st using SIP, 2nd using

email:$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:[email protected]!" .IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:[email protected]!" .


Call routing – TRIP and SLP

TRIP (RFC 3219) allows routing of SIP requests to the “best” IP telephony gateway

Based on BGP model of route propagation


Do not disturb & distinctive ringing

End system or proxy features Distinctive ringing inserted by proxy:Alert-Info: http://www.example.com/sounds/moo.wav

Do not disturb:– 600 (Busy)– 603 (Decline)– with Retry-After


Call prioritization

SIP Priority headerSubject: A tornado is heading our way!Priority: emergency

Can be inserted or removed by proxy Useful for call routing


Caller preferences

One SIP address many destinations:– home vs. office– cell phone vs. landline– PC video phone vs. black phone

Callee’s proxy decides, but caller preferences mechanism allows caller to influence choices

Can influence:– whether to proxy or redirect– which URI to proxy or redirect to– whether to fork or not– whether to search recursively or not– whether to search in parallel or sequentially


Caller preferences

Adds parameters to Contact headers describing properties of location:

Carol speaks English, Spanish and German and can send/receive audio + video, but only wants this address to be used for urgent calls: Contact: Carol <sip:[email protected]> ;language="en,es,de";media="audio/*,video/*,application/chat";duplex="full";priority="urgent“

INVITE request then contains headers:Accept-Contact: sip:user@host;feature="voicemail&attendant"Accept-Contact: sip:[email protected];mobility="!fixed"


Using URIs for SIP Service Control

RFC 3087 User part is left to local configuration Voice mail servicessip:[email protected];mode=depositsip:[email protected]

Ad-hoc conferences Invoke VoiceXML scripts

sip:dialog.vxml.http%3a//dialogs.server.com/[email protected]


Using SIP events for services

Many telecom services generate asynchronous events:– participant joined or left conference– message waiting– call leg completed or terminated

SIP defines event notification requests: SUBSCRIBE and NOTIFY

Event packages for call legs, conferences, message waiting, IM, DTMF, ...NOTIFY sip:[email protected] SIP/2.0To: <sip:[email protected]>;tag=78923From: <sip:[email protected]>;tag=4442Event: message-summaryContent-Type: application/simple-message-summary

Messages-Waiting: yesVoicemail: 4/8 (1/2)


Call waiting

Talk on line 1

Line 2 ringing

Press line 2

INVITE180 RingingINVITE,SDP’s c=0

200 OK

Wait 2 minutes

182 Wait 2 minutes

A

B C

no notion of “lines” unlimited number of line presences


200 OKTalk on line 2

Hold on line 1

A

B C

Call waiting


Call transfer (unsupervised)

3

A

B1

B2

INVITE B2Referred-By: B1

2

Referred-By: B1REFER B21

BYE A


Multi-party features

Permanently or temporarily mixing multiple media streams

Generally, combinations of– adding conference servers (ad-hoc conferences)– transfer: use REFER to ask other party to do something– combinations of who asks whom to do what recipient just follows

instructions


Third-party call control

Separate signaling and media endpoints Also sometimes called back-to-back UA (B2BUA) but some B2BUA’s handle media, too

RTP

SIP

SIP

2

4

INVITE

ACKno SDP 1

6

3INVITE

5

SDP (from 4)

SDP (from 2)

ACK

200200


End system vs. Network server

Network serverPermanent IP addressAlways on(User can have unique address and can always be reached)

Ample computational capacityHigh bandwidth(Conference)

Indirect user interactionUsually only deals with signaling(Based on predefined mechanisms,or indirect user interaction, likethrough web page)

End systemTemporary IP addressPowered off so often(User’s address always changed and can not be reached sometime)

Limited computational capacityLow bandwidth(One to one or small size conf.)

Direct user interactionSignal and media converge(easier to deal with human interaction, easier to deal with interaction with media)


End system vs. Network server

Network serverInformation hiding

Logical call distribution

Gateway

End systemBusy handling

Call transfer

Distinctive ringing


Service location examples

Service End system Network (proxy) Network with Media (UA)

Distinctive ringing Yes Can assist Can assist

Visual call id Yes Can assist Can assist

Call waiting Yes No Yes(*)

CF busy Yes Yes(*) Yes(*)

CF no answer Yes Yes Yes

CF no device No Yes Yes

Location hiding No Yes Yes

Transfer Yes No No

Conference bridge Yes No Yes

Gateway to PSTN No No Yes

Firewall control No No Yes

Voicemail Yes No Yes

(*) = with information provided by end system


Service architectureProgramming language model

SIP Server Function

Requests

Responses Responses

Requests

Service Logic

ProgrammingInterface


Programmable service creation

Can’t win by (just) recreating PSTN services Programmable services:

– equipment vendors, operators: JAIN– local sysadmin, vertical markets: sip-cgi– proxy-based call routing: CPL– voice-based control: VoiceXML


Programmable service creation

API servlets sip-cgi CPL

language-independent

no Java only yes own

secure no mostly can be yes

end user service creation

no yes power users yes

GUI tools no no no yes

Multimedia some yes yes yes

call creation yes no no no


APIs (e.g., JAIN) Tradition of TAPI,

JTAPI, ... Typically, call model Treat calls as objects

to be manipulated e.g., JAIN:

– bearer independent (PSTN, IP, ATM)

– protocol-independent (ISUP, SIP, H.323, BICC, ...)

– protocol APIs and application APIs


SIP servlets

Servlet runs in SIP server Receives SIP objects and processes them Example: call rejection applicationimport org.ietf.sip.*;public class RejectServlet extends SipServletAdapter { protected int statusCode; protected String reasonPhrase; public void init(ServletConfig config) { super.init(config); try { statusCode = Integer.parseInt(getInitParameter("status-code")); reasonPhrase = getInitParameter("reason-phrase"); } catch (Exception _) {...} } public boolean doInvite(SipRequest req) { SipResponse res = req.createResponse(); res.setStatus(statusCode, reasonPhrase); res.send(); return true; } }


sip-cgi

web common gateway interface (cgi):– oldest (and still most commonly used) interface for dynamic content

generation– web server invokes process and passes HTTP request via

• stdin (POST body)• environment variables HTTP headers, URL• arguments as POST body or GET headers (?arg1=var1&arg2=var2)

– new process for each request not very efficient– but easy to learn, robust (no state)– support from just about any programming language (C, Perl, Tcl,

Python, VisualBasic, ...) Adapt cgi model to SIP sip-cgi RFC 3050


sip-cgi

Designed for SIP proxies and end systems:– call routing– controlling forking– call rejection– call modification (Priority, Call-Info, Alert-Info)

cgi: once per HTTP request sip-cgi: maintain state via an opaque token script gets body of request on stdin script gets SIP headers via environment variables initiates actions via stdout:

– proxy request– return response– generate request– generate response


sip-cgi examples

Block *@vinylsiding.com:if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~

"sip:*@vinylsiding.com") { print "SIP/2.0 600 I can't talk right now\n\

n";} Make calls from boss urgent:if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM}

=~ /sip:[email protected]/) { foreach $reg (get_regs()) { print "CGI-PROXY-REQUEST $reg SIP/2.0\n"; print "Priority: urgent\n\n"; }}


Call Processing Language (CPL)

XML-based “language” for processing requests intentionally restricted to branching and subroutines no variables, no loops thus, easily represented graphically mostly used for SIP, but protocol-independent integrates notion of calendaring (time ranges) structured tree describing actions performed on call

setup event top-level events: incoming and outgoing


CPL

Location set stored as implicit global variable– operations can add, filter and delete entries

Switches:– address– language– time, using CALSCH notation (e.g., exported from Outlook)– priority

Proxy node proxies request and then branches on response (busy, redirection, noanswer, ...)

Reject and redirect perform corresponding protocol actions

Supports abstract logging and email operation


CPL example

String-switchfield: from

match:*@example.com

otherwise

proxytimeout: 10s

locationurl: sip:jones@

example.comvoicemail.

merge: clear

locationurl: sip:jones@

example.com

redirect

Call

busy

timeout

failure


CPL example

<?xml version="1.0" ?><!DOCTYPE call SYSTEM "cpl.dtd">

<cpl> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?

user=jones" timeout="8"> <success> <proxy /> </success> <failure> <mail url="mailto:[email protected]&Subject=lookup

%20failed" /> </failure> </lookup> </incoming></cpl>


CPL example: anonymous call screening

<cpl><incoming>

<address-switch field="origin" subfield="user"><address is="anonymous">

<reject status="reject"reason="I don't accept anonymous

calls" /></address>

</address-switch></incoming>

</cpl>


Billing

PSTN: evolution from distance/time-sensitive per-minute billing– bucket of minutes– flat-rate plans (“all you can eat”): Canada, AT&T

Per-minute billing doesn’t fit well:– SIP sessions can remain open for months, without sending a single

packet– voice silence suppression unfair to charge for both directions for

large conferences– incremental value is

non-linear– thus, video unlikely

bit rate

utility


Billing and charging

What are we billing for?– infrastructure– services

• unlikely to be able to charge for call forwarding for corporate users• but Yahoo might for residential users

– traffic• but network cost depends on peak usage, not average usage• treat all traffic the same?• 3G: charge more for data traffic than voice traffic?

– escalation of traffic cloaking and detection

A simple billing model– bill per-minute for calls gatewayed into the PSTN– bill for services on a subscription basis (e.g., as part of ISP service)– bill for traffic

• independent of traffic type• by volume, 95th percentile, congestion pricing


Open Settlement Protocol (OSP)

clearing-house model


AAA = Authentication, Authorization, Accounting

separate SIP protocol elements from making authentication/authorization decisions

allow visited proxy to ask home proxy of visitor whether visitor is legit

accounting:– resource dimensioning– apportionment of charges– commercial billing

three primary protocols:– RADIUS – used for dial-up servers, popular with ISPs

• can lose data (UDP)– DIAMETER – successor of RADIUS

• will be used in 3G for AAA


Challenges: Security

Classical model of restricted access systems cryptographic security

Objectives:– identification for access control & billing– phone/IM spam control (black/white lists)– call routing– privacy


SIP security

Bar is higher than for email – telephone expectations (albeit wrong)

SIP carries media encryption keys Potential for nuisance – phone spam at 2 am Safety – prevent emergency calls


System model

SIP trapezoid

outbound proxy

[email protected]: 128.59.16.1

registrar


Threats

Bogus requests (e.g., fake From) Modification of content

– REGISTER Contact– SDP to redirect media

Insertion of requests into existing dialogs: BYE, re-INVITE

Bid-down attacks: attacker gets to pick algorithm Denial of service (DoS) attacks Privacy: SDP may include media session keys Inside vs. outside threats Trust domains – can proxies be trusted?


Threats

third-party– not on path– can generate requests

passive man-in-middle (MIM)– listen, but not modify

active man-in-middle replay cut-and-paste


L3/L4 security options

IPsec Provides keying mechanism but IKE is complex and has interop problems works for all transport protocol (TCP, SCTP, UDP, …) no credential-fetching API

TLS provides keying mechanism good credential binding mechanism no support for UDP; SCTP in progress


Hop-by-hop security: TLS

Server certificates well-established for web servers Per-user certificates less so

– email return-address (class 1) certificate not difficult (Thawte, Verisign)

Server can challenge client for certificate last-hop challenge


HTTP Digest authentication

Allows user-to-user (registrar) authentication– mostly client-to-server– but also server-to-client (Authentication-Info)

Also, Proxy-Authenticate and Proxy-Authorization– May be stacked for multiple proxies on path


HTTP Digest authentication

REGISTERTo: sip:[email protected]: Digest username="alice", nc=00000002, cnonce="abcd", response="6629"

REGISTERTo: sip:[email protected]: Digest username="alice", nc=00000001, cnonce="defg", response="9f01"

401 UnauthorizedWWW-Authenticate: Digest realm="[email protected]", qop=auth, nonce="dcd9"

REGISTERTo: sip:[email protected]

mailto:realm%[email protected]




End-to-end authentication

What do we need to prove?– Person sending BYE is same as sending INVITE– Person calling today is same as yesterday– Person is indeed "Alice Wonder, working for Deutsche Bank"– Person is somebody with account at MCI Worldcom


End-to-end authentication

Why end-to-end authentication?– prevent phone/IM spam– nuisance callers– trust: is this really somebody from my company asking about the

new widget? Problem: generic identities are cheap

– filtering [email protected] doesn't prevent calls from [email protected] (new day, sam person)


End-to-end authentication and confidentiality

Shared secrets– only scales (N2) to very small groups

OpenPGP chain of trust S/MIME-like encapsulation

– CA-signed (Verisign, Thawte)• every end point needs to have list of Cas• need CRL checking

– ssh-style


Ssh-style authentication

Self-signed (or unsigned) certificate Allows active man-in-middle to replace with own

certificate– always need secure (against modification) way to convey public key

However, safe once established


DOS attacks

CPU complexity: get SIP entity to perform work Memory exhaustion: SIP entity keeps state (TCP

SYN flood) Amplification: single message triggers group of

message to target– even easier in SIP, since Via not subject to address filtering


DOS attacks: amplification

Normal SIP UDP operation:– one INVITE with fake Via– retransmit 401/407 (to target) 8 times

Modified procedure:– only send one 401/407 for each INVITE

Suggestion: have null authentication– prevents amplification of other responses– E.g., user "anonymous", password empty


DOS attacks: memory

SIP vulnerable if state kept after INVITE Same solution: challenge with 401 Server does not need to keep challenge nonce, but

needs to check nonce freshness


Challenges: NATs and firewalls

NATs and firewalls reduce Internet to web and email service– firewall, NAT: no inbound connections– NAT: no externally usable address– NAT: many different versions -> binding duration– lack of permanent address (e.g., DHCP) not a problem -> SIP

address binding– misperception: NAT = security


Challenges: NAT and firewalls

Solutions:– longer term: IPv6– longer term: MIDCOM for firewall control?

• control by border proxy?– short term:

• NAT: STUN and SHIPWORM• send packet to external server• server returns external address, port• use that address for inbound UDP packets


Emergency calls

Opportunity for enhanced services:– video, biometrics, IM

Finding the right emergency call center (PSAP)– VoIP admin domain may span multiple 911 calling areas

Common emergency address User location

– GPS doesn’t work indoors– phones can move easily – IP address does not help


Emergency calls

EPAD

INVITE sip:[email protected]: 07605

REGISTER sip:sosLocation: 07605

302 MovedContact: sip:[email protected]: tel:+1-201-911-1234

SIP proxyINVITE sip:sos

Location: 07605

common emergency identifier: sos@domain

mailto:[email protected]


Scaling and redundancy

Single host can handle 10-100 calls + registrations/second 18,000-180,000 users– 1 call, 1 registration/hour

Conference server: about 50 small conferences or large conference with 100 users

For larger system and redundancy, replicate proxy server


Scaling and redundancy

DNS SRV records allow static load balancing and fail-over– but failed systems increase call setup delay– can also use IP address “stealing” to mask failed systems, as long

as load < 50% Still need common database

– can separate REGISTER– make rest read-only


Large system

_sip._udp SRV 0 0 sip1.example.com

0 0 sip2.example.com

0 0 sip3.example.com

a2.example.comsip2.example.co

m

sip3.example.com

a1.example.com

sip1.example.com

b1.example.com

b2.example.com

sip:[email protected]

sip:[email protected]

_sip._udp SRV 0 0 b1.example.com

0 0 b2.example.com

stateless proxies


Enterprise VoIP

Allow migration of enterprises to IP multimedia communication

Add capacity to existing PBX, without upgrade Allow both

– IP centrex: hosted by carrier– “PBX”-style: locally hosted– Unlike classical centrex, transition can be done transparently


Motivation

Not cheaper phone calls Single number, follow-me – even for analog phone

users Integration of presence

– person already busy – better than callback– physical environment (IR sensors)

Integration of IM– no need to look up IM address– missed calls become IMs– move immediately to voice if IM too tedious


Migration strategy

1. Add IP phones to existing PBX or Centrex system – PBX as gateway

– Initial investment: $2k for gateway

2. Add multimedia capabilities: PCs, dedicated video servers

3. “Reverse” PBX: replace PSTN connection with SIP/IP connection to carrier

4. Retire PSTN phones


Example: Columbia Dept. of CS

About 100 analog phones on small PBX– DID– no voicemail

T1 to local carrier Added small gateway and T1 trunk Call to 7134 becomes sip:7134@cs Ethernet phones, soft phones and conference room CINEMA set of servers, running on 1U rackmount

server


CINEMA components

RTSP

sipum

Cisco 7960

sipvxmlSIP

rtspdsipconfLDAP server

MySQL

PhoneJack interface

sipc

T1T1

sipd

mediaserver

RTSP

SIP-H.323converter

messagingserver

unified

server(MCU)

user database

conferencing

sip-h323

VoiceXMLserver

proxy/redirect server

Cisco2600

Pingtel

wireless802.11b

PBX

MeridianNortel

plug'n'sip


Experiences

Need flexible name mapping– Alice.Cueba@cs alice@cs– sources: database, LDAP, sendmail aliases, …

Automatic import of user accounts:– In university, thousands each September

• /etc/passwd• LDAP, ActiveDirectory, …

– much easier than most closed PBXs Integrate with Ethernet phone configuration

– often, bunch of tftp files Integrate with RADIUS accounting

mailto:Alice.Cueba@cs

mailto:alice@cs


Experiences

Password integration difficult– Digest needs plain-text, not hashed

Different user classes: students, faculty, admin, guests, …

Who pays if call is forwarded/proxied?– authentication and billing behavior of PBX and SIP system may

differ– but much better real-time rating


SIP doesn’t have to be in a phone


Event notification

Missing new service in the Internet Existing services:

– get & put data, remote procedure call: HTTP/SOAP (ftp)– asynchronous delivery with delayed pick-up: SMTP (+ POP, IMAP)

Do not address asynchronous (triggered) + immediate


Event notification

Very common:– operating systems (interrupts, signals, event loop)– SNMP trap– some research prototypes (e.g., Siena)– attempted, but ugly:

• periodic web-page reload• reverse HTTP


SIP event notification

Uses beyond SIP and IM/presence:– Alarms (“fire on Elm Street”)– Web page has changed

• cooperative web browsing• state update without Java applets

– Network management– Distributed games


Conclusion

Service creation as central reason for IP telephony Beyond replication of PSTN services:

– modularity– easy interface to external databases– user-created services– interface to web services (SOAP)– event model as versatile service component

Security as core component– protect users against impersonation, phone/IM spam– user privacy– operator protection often secondary

• unless SIP is used in billing

Deploying SIP services– example of a PBX-like service

session i5 creating secure services for internet telephony

Documents