SIP for VoIP and Presence

Jiri Kuthan, iptel.org/FhG With additions by Henning Schulzrinne sip:jiri@iptel.org September 2003, December 2005

Example: Web Integration, Missed Calls/Click-to-Dial

Click To Dial

Motivation: Applications

SIP & ENUM

Motivation: Scenarios

Scenario: Internet Telephony Providers

Borderless customer base: Services available anywhere on the public Internet to subscribers very much like Email. IP Telephony Users With Softphones and Low CAPEX and OPEX. Hardphones PSTN connectivity typically offered as an extra option; (example: deltathree charges Providers SIP Server <$.1 per US2UK minute and keeps track of users and Powers services $11 a month for a US 800 number) Freebies: FWD, PCH, iptel Gateways Terminate SipPhone. And Initate Calls in PSTN PSTN-termination: deltathree, packet8, Vonage
SIP & ENUM

Motivation: Scenarios

Scenario: Use In Enterprises

PSTN

E1

DSL

Services available to all companys users, on-site, offsite and multi-site toll RIPE Meeting bypass. No telephone line required for home-workers and remote offices. WaveLAN Single infrastructure for data and voice. T1 Effectiveness tools. Service operation can be outsourced in a Centrex-like manner (MCI Advantage). Like with web/email, single server may host multiple domains.
SIP & ENUM

Basic SIP Call-Flow

Technology: SIP

SIP is HTTP-like, textual, client-server protocol, using email-like addresses So-called Proxy server takes care of setting up sessions between users Signaling independent on media both take different path
#0 DNS SRV Query ? iptel.org Reply: IP Address of iptel.org SIP Server

INVITE sip:jiri@iptel.org From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org #1 Call-ID: 345678@sip.com OK 200 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org;tag=34 Call-ID: 345678@sip.com

INVITE sip:jiri@195.37.78.173 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org #2 Call-ID: 345678@sip.com

#4

Proxy

#3 OK 200 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org;tag=34 Call-ID: 345678@sip.com

Caller@sip.com
Media streams #5 SIP & ENUM

sip:jiri@195.37.78.173

Technology: SIP

Basic Server Element: SIP Proxy

PSTN Gateway SMS Gateway

Applications IP Phone Pool

proxy

Proxy servers maintain central role in SIP networks: They glue SIP components such as phones, gateways, applications and other domains They provide place for service implementation (missed calls, forwarding, screening, etc.) and service access control SER: www.iptel.org/ser/

Other domains
SIP & ENUM

Technology: SIP

What Is SIP Good In?

Easy service integration: its design roots in SNMP and HTTP protocols; it integrates easily with applications built on top of them. Reusability, e.g., instant messaging and presence can be ran with the same protocol and infrastructure. High scalability: protocol maintains only transaction state in network. With SER, we achieve thousands of calls per second on a PC. Affordability: Free SIP servers and softphones exist.

Technology: Concern Stack

Things That Work

Basic VoIP services work, so do complementary integrated services such as instant messaging, voicemail, etc. Numbering plans easy to maintain and they complement domain names well. QoS mostly pleasant. (Most broadband calls feature ~150 ms RTT and packet loss close to zero.) Solid SIP implementations interoperate fairly well. Billing machinery works too: Accounting easy, though not standardized. Gateways with accounting support exist today Interoperation with other technologies works too, PSTN gateway market established (single-vendor dominance too).

SIP & ENUM

Technology: Concern Stack

Concern: Performance
Performance are you really able to process all the crap messages you receive over the public Internet? iptel.orgs operational observation: 80% of traffic is invalid messages caused by misconfigured or broken devices. Use of applications such as presence increase per-user load compared to VoIP roughly by factor of 100. Other stress factors: reboot avalanches, DoS. Nevertheless we have the capacity today: our measurements indicate proxy transactional throughput of hundreds to thousands of calls per second. Sufficient to power large subscriber populations.

SIP & ENUM

History
Carrying voice on IP-based packet networks first identified by Cohen in 1977* Commercialization and standardization began in 1995; Vocaltec the first company to ship IP2PSTN gateways (proprietary) SIP standardization began in IETF in 1995 Adoption of SIP for use in 3GPP in late nineties Motivation:
Cost saving through telco by-passing Service Integration
* D. Cohen, Issues in transnet packetized voice communications, In Proceedings of the 5th Data Communications Symposium

IETF Where SIP Was Born

The IETF is a large open international community of network

designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. Working Groups related to Internet telephony:
SIP: core Session Initiation Protocol QoS Related: DiffServ, IntServ, SIPPING: Future SIP extensions and RSVP PSTN legacy: SigTran, Megaco related issues and Presence Leveraging ENUM: integration of E.164 numbering with Internet services interaction of PSTN and IP services: PINT,SPIRITS SIMPLE: SIP for Instant

Messaging
IPTEL: Internet Telephony AVT: Audio Video Transport

MMUSIC: Multiparty Multimedia Session Control

MIDCOM: Firewall/NAT Traversal

SIP & ENUM

Refresher: IP Design Concepts

Distributed end-2-end design Intelligence and states resides in end-devices Network maintains almost zero intelligence (except routing) and state (except routing tables). End-devices speak to each other using whatever applications they have. There is almost no logic in the network affecting this behavior. Result:
Flexibility. Introducing new applications is easy. Failure recovery. No state, no problem on failure. Scalability. No state, no memory scalability issues.

SIP & ENUM

What Problems Do Need to Be Solved for VoIP?

Session management
Users may move from terminal to terminal with different capabilities and change their willingness to communicate To set-up a communication session between two or more users, a signaling protocol is needed: Session Initiation Protocol (SIP) supports locating users, session negotiation (audio/video/instant messaging, etc.) and changing session state

Media Transport
Getting packetized voice over lossy and congested network in realtime RTP protocol for transmitting real-time data such as audio, video and games

End-to-end delivery: underlying IP connects the whole world

SIP & ENUM

Technology: Complementary Protocols

Supporting Protocols: How Do I ...

find domain of called party? Like with email, use DNS to resolve address of server responsible for jiri@iptel.org! authenticate users and generate Call Detail Records? Defacto RADIUS standard. get over NATs? STUN. More:
set phone clock: NTP download configuration and firmware: TFTP/FTP/HTTP (no good standard for usage of these protocols) resolve phone numbers to SIP addresses? ENUM

IETF Practice: Decomposition Principle; Separate protocols are used for separate purposes. All of them on top of IP.

SIP & ENUM

Protocol Zoo (Hourglass Model)

ENUM
WWW signaling interdomain AAA

iLBC, G.711, ...

media NAT

HTTP
TLS

SIP TCP

DNS SCTP IPv4/IPv6

RADIUS UDP

RTP

STUN

PPP
Ethernet GPRS SONET V.x

AALx
ATM

SIP & ENUM

Packetized Communication
Signaling Protocol Media Transport
End Users

Call Server
End Users

IP Router

Note: Every packet may take a completely different path Signaling takes typically different path than media does Both signaling and media as well as other applications (FTP, web, email, ) look alike up to transport layer and share the same fate
SIP & ENUM

Given All Supporting Protocols are In Place, What Do I need on SIP Part?
SIP Registrar
accept registration requests from users maintains users whereabouts at a Location Server (like GSM HLR)

SIP Proxy Server

relays call signaling, i.e. acts as both client and server operates in a transactional manner, i.e., it keeps no session state transparent to end-devices does not generate messages on its own (except ACK and CANCEL) Allows for additional services (call forwarding, AAA, forking, etc.)

SIP Redirect Server

redirects callers to other servers Used rather rarely as operators appreciate staying in communication path. May be used to achieve very scalable load distribution.

All of these elements are logical and are typically part of a single server!
SIP & ENUM

SIP Registrar
Location Database
Jiri @ 195.37.78.173

#2

REGISTER sip:iptel.org SIP/2.0 From: sip:jiri@iptel.org To: sip:jiri@iptel.org Contact: <sip:195.37.78.173> #1 Expires: 3600
#3

SIP registrar keeps track of users whereabouts. This registration example establishes presence of user with address jiri@iptel.org for one hour and binds this address to users current location 195.37.78.173.

SIP/2.0 200 OK

SIP Registrar (domain iptel.org)

SIP & ENUM

Basic SIP Call-Flow (Proxy SIP Proxy looks up next hops for requests to Mode) served users in location database and
forwards the requests there.
jiri@195.37.78.173
#2

Location Database
#0 DNS SRV Query ? iptel.org Reply: IP Address of iptel.org SIP Server #3

INVITE sip:jiri@iptel.org From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org #1 Call-ID: 345678@sip.com OK 200 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org;tag=34 Call-ID: 345678@sip.com
#7

INVITE sip:jiri@195.37.78.173 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org #4 Call-ID: 345678@sip.com

jiri

#6

Proxy

#5 OK 200 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org;tag=34 Call-ID: 345678@sip.com

ACK sip:jiri@195.37.78.173

Caller@sip.com
Media streams #8 SIP & ENUM

sip:jiri@195.37.78.173

SIP End-devices
User Agent (user application)
UA Client (originates calls) UA Server (listens for incoming calls)

Types of UAs:
Softphone and hardphones Messaging clients PSTN gateways Media servers (voicemail) Etc.

SIP & ENUM

Service composition: Added-value Server Chains

Callers administrative domain Administrative domain of a PSTN gateway operator pstn.com asia.pstn.com

gw01.asia.pstn.com

#2 #1 Callers outbound proxy accomplishes firewall traversal.

#3

#4

Destinations Proxy in the target first-hit proxy area distributes load identifies a proxy in a gateway farm. serving dialed area. Note: signaling (in red) may take a completely different path from media (in blue).
SIP & ENUM

Ability to Try Multiple Destinations: Forking

A proxy may fork a request to multiple destinations either in parallel (reach me everywhere) or serially (forward no reply). A proxy can cancel pending parallel searches after a successful response is received. A proxy can iterate through redirection responses (recursive forking). The first OK is taken.
#1 INVITE #2 Trying #3 INVITE #4 Ringing

#5 CANCEL #6 OK #7 INVITE

SIP & ENUM

Stateful versus Stateless Proxy Operational Mode

SIP Proxies may operate either in stateful or stateless mode; which of the modes is used depends on implementation or configuration. stateless mode:
Usage: good for heavy-load scenarios -- works well for example if they act as application-layer load distributors. Behavior:
proxies just receive messages, perform routing logic, send messages out and forget anything they knew; they should cache results of SIP routing logic as it is not able to distinguish between retransmissions and new requests -- and would result in new execution of SIP routing logic for every retransmission

SIP & ENUM

Stateful versus Stateless Proxy Operational Mode (cont.)

stateful mode:
Usage: good for implementing some services (e.g., forward on no reply) Behavior:
proxies maintain state during entire transaction; they remember outgoing requests as well as incoming requests that generated them until transaction is over; they do not keep state during the whole call a forking proxy should be stateful reduce retransmission time by acting on behalf of sender closer to destination

SIP & ENUM

Stateful Proxy Refers to Transactions

SIP state forgotten as soon as transaction over

Frequently Misunderstood Issue

INVITE a@a.com

OK
Legend SIP signaling SIP state media

SIP proxies deliver a one-time rendezvous service (as opposed to state storage service). Thus a stateful proxy just keeps state during a SIP rendezvous transaction and completely forgets it afterwards. A SIP proxy is not aware of existing calls. In case of failure, existing calls are NOT affected! Subsequent transactions may take a direct path!

SIP & ENUM

Subsequent Transactions Bypass Proxy

Frequently Misunderstood Issue

INVITE

BYE takes direct path

Unless route recording is used, subsequent transactions (e.g., BYE) take a direct path to destination as indicated in Contact: header field. OK Contact: Todays common practice is to sip:jiri@195.3.4.9 turn record-routing ALWAYS on to deal with devices that speak different transport protocols and need a mediator in-between them.

SIP & ENUM

SIP Message Structure

Request
INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:UserA@here.com>;tag=123 To: LittleGuy <sip:UserB@there.com> Call-ID: 12345600@here.com Message CSeq: 1 INVITE Header Subject: Happy Christmas Fields Contact: BigGuy <sip:UserA@here.com> Content-Type: application/sdp Content-Length: 147 SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:UserA@here.com>;tag=123 To: LittleGuy <sip:UserB@there.com>;tag=65a35 Call-ID: 12345600@here.com CSeq: 1 INVITE Subject: Happy Christmas Contact: LittleGuy <sip:UserB@there.com> Content-Type: application/sdp Content-Length: 134

Response

v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

Payload

v=0 o=UserB 2890844527 2890844527 IN IP4 there.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000

SDP (RFC2327): receive RTP G.711-encoded audio at 100.101.102.103:49172

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 URIs The same SIP URI can reach many different phones, in different networks
sequential & parallel forking GRUUs conferences device identifiers (sip:foo@128.59.16.15)

tel:110

sip:sos@domain

SIP URIs can be created dynamically:

Registration binds SIP URIs (e.g., device addresses) to SIP address-of-record (AOR)

domain 128.59.16.17 via NAPTR + SRV

SIP & ENUM

SIP Addresses
SIP gives you a globally reachable address.
Callees bind their temporary address to the global one using SIP REGISTER method. Callers use this address to establish real-time communication with callees.

URLs used as address data format; examples: sip:jiri@iptel.org sip:voicemail@iptel.org?subject=callme sip:sales@hotel.xy; geo.position:=48.54_-123.84_120 must include host, may include user name, port number, parameters (e.g., transport), etc. may be embedded in Webpages, email signatures, printed on your business card, etc. address space unlimited non-SIP URLs can be used as well (mailto:, http:, ...)
SIP & ENUM

SIP RFC3261 Methods

INVITE initiates sessions
session description included in message body re-INVITEs used to change session state

ACK confirms session establishment

can only be used with INVITE

CANCEL cancels a pending INVITE BYE terminates sessions REGISTER binds a permanent address to current location;
may convey user data (CPL scripts)

OPTIONS capability inquiry

SIP & ENUM

SIP Extension Methods

SUBSCRIBE/ instant messaging and presence NOTIFY/ (RFC3265, RFC3428, draft-ietf-simple*) MESSAGE REFER call transfer (RFC3515) PRACK provisional reliable responses acknowledgement (RFC3262) INFO mid-call signaling (RFC 2976)
SIP & ENUM

SIP Response Codes

Borrowed from HTTP: xyz explanatory text Receivers need to understand response class (x) x80 and higher codes avoid conflicts with future HTTP response codes 1yz Informational
100 Trying 180 Ringing (ringing tone played locally) 181 Call is Being Forwarded

2yz Success
200 ok

3yz Redirection
300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily
SIP & ENUM

SIP Response Codes (cont.)

4yz Client error
400 Bad Request 401 Unauthorized 482 Loop Detected 486 Busy Here

5yz Server failure

500 Server Internal Error

6yz Global Failure

600 Busy Everywhere

SIP & ENUM

Summary of SIP Properties

Textual (HTTP-like) client-server protocol
Easy to debug, extend and process with textual operating systems

End-2-end
It puts most of intelligence into end-devices (user agents) good for scalability and extensibility The network infrastructure designed to be leight-weighted. Network functionality (registrar, proxy) are typically logical parts of a single server.

Internet addressing using URIs

E.g., sip:jiri@iptel.org Non-SIP URIs possible to (e.g., they may be used to redirect a caller to webpage) Address space unlimited and may be used to create services (sip:sales@hotel.xy; geo.position:=48.54_-123.84_120)

It delivers mobility: User can register from one or more locations with IP connectivity
SIP & ENUM

Example: Call Transfer Call Flow

#1

REFER B To: B Refer-To: C Referred-By: A

A is having a call with B. A decides to transfer B to C. It sends a REFER to B with Cs address. Eventually, A is notified on successful transfer using NOTIFY (#6).
#3 #4

#2 202 Accept

INVITE C Referred-By: A 200 OK

#6

NOTIFY (OK)
#7

#5

200 ACK

200 OK

media
timeline SIP & ENUM

draft-ietf-sip-cc-transfer, RFC3515

Call Transfer/REFER
Accomplished using the REFER method. The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the method. New header fields: Refer-To, Refer-By. NOTIFY method used to report on result of referral. Note: No changes to proxy behavior required. Variants:
With Consultation Hold (SIP Hold and unattended transfer) Attended Transfer, I.e., with a short conference

Other REFER uses: Click-to-dial

SIP & ENUM

The role of presence

Guess, ring and annoy
high probability of failure:
telephone tag inappropriate time (call during meeting) inappropriate media (audio in public place)

Presence-based
facilitates unscheduled communications provide recipient-specific information only contact in real-time if destination is willing and able appropriately use synchronous vs. asynchronous communication guide media use (text vs. audio) predict availability in the near future (timed presence)

current solutions:
voice mail tedious, doesnt scale, hard to search and catalogue, no indication of when call might be returned automated call back rarely used, too inflexible

most successful calls are now scheduled by email

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

SIP & ENUM

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 capabilities location activity/availability sensor data (mood, bio) CPL caller preferences location-based call routing location events presence privacy issues similar to location data
SIP & ENUM

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, Google, 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 if user has time to update presence, they are not busy enough to use presence does not provide enough context for directing interactive communications

SIP & ENUM

Presence data model

person
(presentity)

calendar

cell

manual

(views) services
alice@example.com audio, video, text r42@example.com video

devices

SIP & ENUM

Presence data architecture

presence sources
PUBLISH create view (compose)

raw presence document

privacy filtering

XCAP
select best source resolve contradictions

depends on watcher

XCAP

composition policy
(not defined yet)

privacy policy
draft-ietf-simple-presence-data-model

SIP & ENUM

Presence data architecture

candidate presence document
watcher filter

raw presence document

post-processing composition (merging)

remove data not of interest

SUBSCRIBE
difference to previous notification

watcher

NOTIFY

final presence document

SIP & ENUM

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, )

SIP & ENUM

RPID: rich presence

<person>
<activities> <class> <mood>

<tuple>

<device>

<place-is>
<place-type> <privacy> <relationship>

<service-class>
<sphere> <status-icon> <time-offset>

<user-input>
SIP & ENUM

The role of presence for call routing

Two modes:
watcher uses presence information to select suitable contacts
advisory caller may not adhere to suggestions and still call when youre in a meeting translate RPID
PUBLISH

PA
NOTIFY

user call routing policy informed by presence

likely less flexible machine intelligence if activities indicate meeting, route to tuple indicating assistant try most-recently-active contact first (seq. forking)

CPL

LESS

INVITE

SIP & ENUM

Presence and privacy

All presence data, particularly location, is highly sensitive Basic location object (PIDF-LO) describes
distribution (binary) retention duration
<tuple id="sg89ae"> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1 srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W </gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no </gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z </gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple>

Policy rules for more detailed access control

who can subscribe to my presence who can see what when

SIP & ENUM

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

SIP & ENUM

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 Im 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

SIP & ENUM

Program location-based services

SIP & ENUM

Instant Messaging and Presence

Idea: Use the same signaling infrastructure for more services SIP already supports:
Notion of presence and user location mechanisms Application-layer routing (incl. forking) and message processing (e.g., CPL) Optimized for speed Scalability by distributed design

SIP & ENUM

RFC3428

Instant Messaging
Goal: deliver short messages rapidly SIP Extension: MESSAGE Method
Message body of any MIME type (including Common Profile for Instant Messaging, draft-ietf-impp-cpim ) im type URLs used
MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/UDP user1pc.domain.com From: im:user1@domain.com To: im:user2@domain.com Contact: sip:user1@user1pc.domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Watson, come here. SIP & ENUM

RFC3265

Subscribe-Notify
Goal: ability to be notified when a condition occurs Applications:
User presence and related applications Call-back (notify when the other party becomes available) VoiceMail Notification (notify when a voicemail message is stored) [draft-ietf-sipping-mwi] Traffic Alerts (notify on traffic jam)

Extensions: SUBSRIBE and NOTIFY methods, Event and Allow-Events headers, 489 Bad Event Response Code Subscription subject to expiration similarly to how REGISTER is
SIP & ENUM

Subscribe-Notify For Presence Services

Step I: subscription to a condition
#1 SUBSCRIBE joe Event: presence Contact: alice #2 202 Accepted #4 OK #3 NOTIFY alice Event: presence
subscriber Presence server

draft-ietf-simplepresence

Step III: event occurs

Step IV: subscriber is notified whenever condition changes

#5 REGISTER joe #6 OK

#7 NOTIFY alice Event: presence #8 OK

Step II: subscriber is immediately notified on current condition

SIP & ENUM

Service Programming

SIP & ENUM

Programming SIP Logic

Services examples
discard all calls from Monica during my business hours redirect authenticated friends to my cell phone, anyone else to my secretary

Programming SIP services

is not easy (our SIP Proxy server has 100k lines of code!) lot of timers, dynamic allocation, parsing and other inconveniences Some companies and standardization bodies have been seeking to standardize APIs (JTAPI, CTI, JAIN, PARLAY) however, they APIs still feature lot of programming difficulties and are tightly coupled to specific programming environments such as Java IETF: follow the textual interface tradition used in HTTP (CGI, CPL)

They key is efficiency of service programming. Dont be worried about buzzword compliance too much.
SIP & ENUM

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, carrier network servers SIP servlets, sip-cgi

end user CPL

end system

VoiceXML scripting, RPC

VoiceXML (voice), LESS

SIP & ENUM

Service Execution Layering

User Code
CGI Scripts (Perl, Python, C, )

CPL scripts

Servlets

Interpreters

SIP-CGI

Java Servlets

CPL

SIP Messages

SIP Actions SIP

Protocol stack

Call Processing Logic Example

The call processing logic may be designed using various mechanisms: CPL, SIPCGI, servlet, proprietary ones.

Jkus call processing logic: If ($caller is in {Jane, Bob}) proxy to jku@cell.com else proxy to voicemail@trash.com

Jkus call processing logic: If ($caller ==Jane) play Mozart else play Smetana

#2 pass invitation to call processing logic

#3 return an action #4a INVITE jku@cell #5

#1 INVITE jku

#4b INVITE voicemail@trash

SIP & ENUM

Where May Signaling Services Live?

Some services have to live in the network:
call distribution services for dial-up users without always-on IP connectivity network servers may be located on users premises (PBX-like) or operators premises (Web-hosting-like, NetCentrex-like)

Some services can be implemented in both places:

forward on busy

Some services work best in end-devices:

distinctive ringing

SIP & ENUM

Service Location Examples

Feature Distinctive Ringing Visual call id Call Waiting CF Busy CF No Answer CF No Device Location hiding Transfer Conference Bridge Gateway to PSTN Firewall Control Voicemail End-device Yes Yes Yes Yes Yes No No Yes Yes Yes No Yes Proxy Can assist Can assist No Yes Yes Yes Yes No No No No No

Source: H. Schulzrinne: Industrial Strength IP Telephony

SIP & ENUM

SIP Common Gateway Interface (CGI)

RFC 3050

Follows Web-CGI. Unlike Web-CGI, SIP-CGI supports proxying and processes responses as well. Language-indpendent (Perl, C, ...) Communicates through input/output and environment variables. CGI programs unlimited in their power. Drawback: Buggy scripts may affect server behavior easily. Persistency token (cookie) is passed between SIP server and CGI to keep state across requests and related responses.

SIP & ENUM

SIP-CGI I/O
Script input: environment variables (AUTH_TYPE, CONTENT_LENGTH, REQUEST_URI, etc.) and SIP message on stdin Script output: set of messages consisting of action lines, CGI header fields and SIP header fields on stdout Action lines:
Generating a response: status line Proxying:
CGI-PROXY-REQUEST <dest-url> <sip-version> Additional header fields may be followed they will be merged with the original request.

Forward response: CGI-FORWARD-RESPONSE <token> <sipversion> Set cookie for subsequent messages: CGI-SET-COOKIE <token> <sipversion> Determine if the script should be called for the next message belonging to the same transaction: CGI-AGAIN ("yes" | "no") <sipversion>
SIP & ENUM

draft-ietf-iptel-cpl

Call Processing Language

Special-purpose call processing language. CPL scripts define a decision tree which may result in signaling (proxy, redirect, reject) or non-signaling (mail, log) action. CPL scripts triggered by SIP messages. May be used by both SIP and H.323 servers. Target scenario: users determine call processing logic executed at a server. Limited languages scope makes sure servers security will not get compromised. Portability allows users to move CPL scripts across servers. Scripts may be manually written, generated using convenient GUI tools, supplied by 3rd parties, ...

SIP & ENUM

CPL Example
<incoming> <address-switch field="origin" subfield="host"> <address subdomain-of="example.com"> <location url="sip:jones@example.com"> <proxy timeout="10"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <sub ref="voicemail" /> </noanswer> <failure> <sub ref="voicemail" /> </failure> </proxy> </location> </address> <otherwise> <sub ref="voicemail" /> </otherwise> </address-switch> </incoming>

SIP & ENUM

Example: Creating CPL Scripts

iptel.org: CPL Composer

SIP & ENUM

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

SIP & ENUM

LESS: simplicity
Generality (few and simple concepts) Uniformity (few and simple rules)
Trigger rule Switch rule Action rule Modifier rule
modifiers

trigger

switches

actions

Familiarity (easy for user to understand) Analyzability (simple to analyze)

SIP & ENUM

LESS: Decision tree

No loops Limited variables Not necessarily
Turing-complete

SIP & ENUM

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.

SIP & ENUM

LESS snapshot

incoming call

<less> If the call from my boss <incoming> <address-switch> <address is=sip:myboss@abc.com"> Turn off the stereo <device:turnoff 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

SIP & ENUM

LESS packages

Use packages to group elements SIP user agent

im

email

web

SIP Basic user agent Generic Media UI x10 vcr

Presence presence agent Event calendar conference session location

SIP & ENUM

Device agent

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>

SIP & ENUM

When I am in a movie theatre,

<less> <incoming> <location-switch> <location placetype=quiet> <alert sound=none vibrate=yes/> </location> </location-switch> </incoming> </less>
SIP & ENUM

Interfacing with Google

911: caller location IM/presence: location of friends call: Im here

SIP & ENUM

Interfacing with Google

show all files from caller Xiaotao Wu

SIP & ENUM

Embedding VoIP: FAA training

controls pilot and ATC agents using multicast and unicast (landlines)

SIP & ENUM

RFC2916

ENUM
Problem: caller is in PSTN (can use only digit keys) and would like to reach a SIP callee Answer: ENUM. Create a global directory with telephone numbers that map to SIP addresses (or email, etc.). Lookup mechanism: DNS maps E.164 numbers to a set of user-provisioned URIs The E.164 number queries are formed as a reversed dot-separated number digits, to which string .e164.arpa is appended, e.g.:
+4319793321 1.2.3.3.9.7.9.1.3.4.e164.arpa

SIP & ENUM

ENUM Call Flow

DNS/ ENUM ?...7.1.9.4.e164.arpa

DNS/ENUM helps ingress gateway to resolve SIP address from E.164 number Typically, owner of an ENUM entry can manipulate the address association through a web provisioning interface

! sip:jiri@iptel.org

PSTN: +4917
INVITE sip:jiri@iptel.org

Gateway with ENUM resolution

SIP & ENUM

Who Owns ENUM?

ENUM Authority over is *.e164.arpa is IAB jointly with the ITU-TSB Operation of the domain carried out by RIPE-NCC: http://www.ripe.net/enum/ Country codes delegated through RIPE to national providers subject to ITU-T TSBs decision. Deployment problem: number validation. How does an ENUM provider know you can claim a number?

SIP & ENUM

SIP Security Tools

Most commonly use security protocol: digest
Based on private shared secret Allows to establish user identity Does not provide message integrity or privacy

TLS addresses shortcomings of digest but not widely deployed yet

It is based on a transitive trust model: upstream client trusts downstream proxy servers, which again trust their servers downstream from them Servers see SIP in plain-text

End-2-end security delivered with S/MIME

With e2e security, proxy servers in the middle do not see plain-text message bodies

Alternate security protocols for 3GPP (AKA, RFC3310)

SIP & ENUM

Disclaimer: Security Protocols Dont Implement Social Engineering

SIP INVITE w/JPEG
INVITE sip:UserB@there.com SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:UserA@here.com> To: LittleGuy <sip:UserB@there.com> Call-ID: 12345600@here.com ...

200 OK w/JPEG
SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:UserA@here.com> To: LittleGuy <sip:UserB@there.com> Call-ID: 12345601@here.com...

SIP & ENUM

RFC 2617

SIP Digest Authentication

Required for user identification and admission control for services. Protocol:
challenge-response using MD5 Based on secret shared between client and server No message integrity provided

1. REGISTER

2. 407 Challenge (nonce,realm)

3. REGISTER w/credentials

4. OK

1. Request w/o credentials 2. Challenge: authenticate yourself 3. Request resubmitted w/credentials

SIP & ENUM

Proxy

Caution: No Relationship Between URIs and Identity

REGISTER sip:iptel.org SIP/2.0 From: <sip:a@bc.de>;tag=c775 To: <sip:a@bc.de> Authorization: Digest username="gh", realm=bc.de", algorithm="md5", uri="sip:bc.de", nonce="3edab81b7a8427be362c2a924f3171d215a8f7d3" , response="4a868f9cbffd2b1f39c778abca78f75b".

Cheating attempt: user gh with tries to register as user a To do so, the cheater submits proper ghs credentials but uses as address of record in To header field Registrar must enforce a policy that links digest identity to permissible addresses of records

SIP & ENUM

Record-Routing

SIP & ENUM

Record-Routing
Refresher: by default, only the initial request (INVITE) visits a proxy, subsequent requests (BYE) travel directly to offload servers Problems:
some applications need to see all signaling, accounting for example UAs may live in different protocol realms (TCP vs UDP, IPv4 versus v6) and can communicate only through the proxy server

Solution: record-routing: proxy servers append a hint to processed requests which advices phones to keep the servers in path for subsequent communication

SIP & ENUM

Record-Routing Example
INVITE sip:jiri@iptel.org From: joe@abc.com;tag=12 Contact: <sip:joe@1.2.3.4> INVITE sip:jiri@iptel.org From: joe@abc.com;tag=12 Record-route: <sip:rr@1.2.3.4;lr>

BYE sip:joe@abc.com From: joe@abc.com;tag=12 Route: <sip:rr@1.2.3.4;lr>

BYE sip:joe@abc.com From: joe@abc.com;tag=12 Route: <sip:rr@1.2.3.4;lr>

SIP & ENUM

Record-Routing Apps
Record-Routing can be also use to piggy-back session-state in SIP messages to leave server stateless Example:
A RR-parameter can include timestamp for initial invite When CDRs are generated on receipt of BYE, the call duration is calculated as current_time()rr_timestamp_parameter() Note: In security-sensitive application like above, it is necessary to introduce message integrity

SIP & ENUM

3GPP: Architecture
Alternative Access Network Applications & Services *) SCP Mh CAP Gn Gp TE R MT Um
ERAN Legacy mobile signaling Network CSCF

GGSN Other PLMN

SGSN HSS *) Gr EIR Gf SGSN

R-SGW Ms Cx
CSCF

Multimedia IP Networks

Mw Mm Mg

Gi Gc

Mr MRF Gi GGSN

Gi MGCF Mc T-SGW *)

Iu-ps' Iu Iu1

Gn MGW Iu 2 Nb Mc Nc MSC server

Gi MGW Mc GMSC server MAP T-SGW PSTN/ Legacy/External

TE R
1 2

MT Uu

UTRAN

Iu = Iucs (RTP, AAL2) Iu = Iu(RANAP)

MAP Applications & Services HSS

Mh R-SGW

Signalling Interface Signalling and Data Transfer Interface

SIP & ENUM

Information Resources
Author: jiri@iptel.org Related IETF work: http://www.iptel.org/ietf/ SIP Express Router: http://www.iptel.org/ser/ SIP Products: http://www.iptel.org/info/products SIP Tutorial: http://www.iptel.org/sip/ SIP Site: http://www.cs.columbia.edu/sip/

SIP & ENUM

Glossary
ALG Application-Level-Gateway CDR Call Detail Record CGI Common Gateway Interface CPL Call Processing Language DTMF Dual Tone Multi-Frequency ETSI European Telecommunications Standards Institute IETF Internet Engineering Task Force ITSP Internet Telephony Service Providers ITU International Telecommunication Union IVR Interactive Voice Reponse JAIN Java APIs for Integrated Network Framework LEC Local Exchange Carrier LNP Local Number Portability NAT Network Address Translation MGCP Media Gateway Control Protocol OSP Open Settlement Protocol PSTN Public Switched Telephone Network QoS Quality of Service RTCP RTP Control Protocol RTP Real-Time Transport Protocol RTSP Real-Time Streaming Protocol SDP Session Description Protocol SIP Session Initiation Protocol SS7 Signaling System Nr. 7 TRIP Telephony Routing over IP VoIP Voice over IP

SIP & ENUM