SIP 1

The Session Initiation Protocol

(SIP)
Henning Schulzrinne
Columbia University, New York
schulzrinne@[Link]
[Link]

c 1998-1999, Henning Schulzrinne

January 18, 2000

SIP 2

Overview

 proxy and redirect modes

 registration

 reliability

 forking and loop detection

 forced routing

 hold and mute

 authentication and anonymity

 third-party call control

January 18, 2000

SIP 3

SIP Basics

January 18, 2000

SIP 4

SIP: Session Initiation Protocol

IETF-standardized peer-to-peer signaling protocol (RFC 2543):

 call user

 re-negotiate call parameters

 manual and automatic forwarding

 call center: reach first (load distribution) or reach all (department

conference)

 personal mobility (complements data link/IP mobility) ➠ change of

terminal (PC, digital cordless, palmtop), location

 “forking” of calls

January 18, 2000

SIP 5

 terminate and transfer calls

 web security, cookies

January 18, 2000

SIP 6

SIP Features, cont’d.

 provides call control (hold, forward, transfer, media changes, . . . )

 leverages web infrastructure: security, “cgi-bin”, electronic

payments, PICS, cookies, . . .

 web-oriented: return HTML pages (“web IVR”)

 network-protocol independent: UDP or TCP (or AAL5 or X.25)

 easily extends to presence information (“buddy lists”) and event

notification

January 18, 2000

SIP 7

SIP for H.323 experts

H.323 SIP + SDP
H.225.0 + RAS SIP
H.245 SDP, SMIL, . . .
gatekeeper proxy

January 18, 2000

SIP 8

SIP architecture: peer-to-peer

SIP
redirect server

[Link]
Internet

RTP audio

[Link]

CATV
Ethernet

January 18, 2000

SIP 9

SIP architecture: carrier

authenticate
anonymize

SIP SIP
proxy proxy

[Link]

firewall RTP audio

firewall
NAPT NAPT
[Link] [Link]
edge router edge router
[Link]
CATV
Ethernet

(Firewall is controlled by SIP proxy and enforces its policy.)

January 18, 2000

SIP 10

SIP addresses food chain

yellow pages “president of the United States”

# WWW search engines
common names “Bill Clinton, Whitehouse”
# directory services
host-independent president@[Link]
. SIP & SIP
host-specific sip:bubba@[Link] sip:+1-202-456-1111@[Link]
# DNS
IP address [Link]

January 18, 2000

SIP 11

SIP: basic operation

1. use directory service (e.g., LDAP) to map name to user@domain
2. locate SIP servers using DNS SRV, CNAME
3. called server may map name to user@host using aliases, LDAP,
canonicalization program, . . .
4. callee accepts, rejects, forward (! new address)
5. if new address, go to step 2
6. if accept, caller confirms
7. . . . conversation . . .
8. caller or callee sends BYE

January 18, 2000

SIP 12

SIP–DNS interaction
extended email-like domain resolution ➠ try until success:

1. try SRV DNS record for “[Link]” and “[Link]” in domain, with
priority and weights for randomized load balancing

2. DNS CNAME or A record

3. may try SMTP EXPN command to get new address; goto (1)

4. if all else fails, send SIP request via MIME

January 18, 2000

SIP 13

SIP operation in proxy mode

January 18, 2000

SIP 14

[Link]

? location server
1
4
INVITE
[Link] INVITE hgs@play 5

hgs@play
henning
henning@[Link] 2
3
200 OK
200 OK
cz@[Link] 6
7 play

tune 9
8
ACK hgs@play
ACK
henning@[Link]

10 media stream

January 18, 2000

SIP 15

SIP operation in redirect mode

[Link]
? location
server

[Link]
1
[Link] INVITE henning@[Link] 2

henning
3

302 Moved temporarily

Contact: hgs@[Link]
4

5 ACK henning@[Link]

[Link]
6 INVITE hgs@[Link]

7 200 OK

8 ACK hgs@[Link] hgs

January 18, 2000

SIP 16

(302: redirection for single call; 301 permanently)

January 18, 2000

SIP 17

SIP operation in redirect mode

INVITE alice@[Link]

302 Moved temporarily

ACK

INVITE a12@[Link]

100 Trying

180 Ringing

200 OK

ACK

UAC redirect server UAS

[Link] a12@[Link]

January 18, 2000

SIP 18

Interaction with resource reservation

avoid “fast busy” after ringing ➠ interleave
INVITE

YESSIR?
SR
reserve
RR (no traffic - no charge)
SR

RR

200

ACK or BYE

January 18, 2000

SIP 19

Invitation modes
invitation conference
unicast multicast
unicast telephony MBone session
multicast reach first dept. conference
➠ SIP for all modes, SAP also for multicast/multicast

January 18, 2000

SIP 20

SIP servers and clients

UAC: user-agent client (caller application)

UAS: user-agent server ➠ accept, redirect, refuse call

redirect server: redirect requests

proxy server: server + client

registrar: track user locations

often combine registrar + proxy or redirect server

January 18, 2000

SIP 21

Proxy and redirect servers

proxy: may fork requests ➠ parallel or sequential search

 near-end proxy: outgoing calls ➠ address lookup, policy,

firewalls
 far-end proxy: closer to callee ➠ callee firewall, call path hiding

redirect server: lower state overhead, more messages

January 18, 2000

SIP 22

SIP requests and responses

 HTTP look-alike

 provisional and final responses:

– 1xx = searching, ringing, queueing, . . .

– 2xx = success
– 3xx = forwarding
– 4xx = client mistakes
– 5xx = server failures
– 6xx = busy, refuse, not available anywhere

January 18, 2000

SIP 23

SIP protocol request

INVITE sip:schulzrinne@[Link] SIP/2.0
From: Christian Zahl <sip:cz@[Link]>
To: Henning Schulzrinne <sip:schulzrinne@[Link]>
Via: SIP/2.0/UDP [Link], SIP/2.0 [Link]
Call-ID: 3678134014@[Link]
Content-Type: application/sdp
Content-Length: 187
CSeq: 8348 INVITE
Subject: New error codes

session description

January 18, 2000

SIP 24

SIP requests

 call leg: From, To, Call-ID

 requests from callee to caller reverse To and From

 caller and callee keep their own CSeq space

 either side can send more INVITEs or BYE

January 18, 2000

SIP 25

SIP URLs
sip:[user:pw@]host:[port]
;transport=UDP;maddr=[Link]

 used in Request-URI, Contact headers (redirect, registration),

web pages

 transport and maddr specify transport

 can specify methods, header and body in web pages, email

 example: sip:[Link]@[Link]

January 18, 2000

SIP 26

SIP Protocol Design

January 18, 2000

SIP 27

SIP protocol design

SIP and RTSP are not HTTP ➠

support UDP: no data stream, low latency desired

multicast: group signaling, user location

avoid HTTP mistakes: e.g.,

 ! always absolute (virtual hosts)

relative request paths
 no extension mechanism ! Require:
 8859.1 coding ! Unicode (ISO 10646)

January 18, 2000

SIP 28

SIP protocol design: robustness

SIP is designed to be robust against server failures:

 no state in proxy servers during call (cf. H.323 GK)

 responses are “self-routing”

 subsequent requests and retransmissions can take different path

(backup server)

 proxy servers can “lose memory” any time ➠ still function

 UDP ➠ less state than TCP, no time-wait

January 18, 2000

SIP 29

SIP and RTSP protocol design: encoding

 “Internet binary”

 ASN.1

 textual

 Jini/RMI, Corba, DCOM

January 18, 2000

SIP 30

Protocol design: internet binary

IP, TCP, RTP, RSVP, Q.931, . . . ➠

 fixed fields and/or type-length-value (TLV)

 efficient if aligned

 fewer ambiguities

 nesting, options tedious

 simple applications are hard

 not self-describing

January 18, 2000

SIP 31

Protocol design: ASN.1

SNMP (BER), H.323/H.245 (PER) ➠

 not self-describing ➠ need external description

 BER: inefficient, lots of options

 PER: external description needed even for data types

 internationalization not clear

January 18, 2000

SIP 32

Protocol design: textual

SMTP, HTTP, SIP, RTSP;

 random textual: ftp, POP, IMAP, gopher, . . . ➠ new parser for each
protocol
 SMTP, HTTP, SIP, RTSP
– C ! S : method, object, attribute: value;parameter, [body]
– S ! C : status code, message, [body]
 binary data not important
 extensions: PEP, JEPI, PICS, . . .
 easy to parse & generate for Tcl, Perl, Python, . . .
 overhead (space, time)? unidirectional?
 but 6= HTTP: not object retrieval, state (RTSP), . . .

January 18, 2000

SIP 33

RPC: RMI, Corba, DCOM

RMI, Corba, DCOM: ➠ potentially replace all upper-layer Internet
protocols

 cost of entry?

 maturity (security, extensions, multicast, . . . )

 performance?

 tools (binary)?

 scalable to global name/object space?

January 18, 2000

SIP 34

SIP Details

January 18, 2000

SIP 35

SIP methods
INVITE initiate call
ACK confirm final response
BYE terminate (and transfer) call
CANCEL cancel searches and “ringing”
OPTIONS features support by other side
REGISTER register with location service

January 18, 2000

SIP 36

SIP response codes

1xx provisional
100 continue
180 ringing
2xx success
200 OK
3xx redirect
300 multiple choices
301 moved permanently
302 moved temporarily

January 18, 2000

SIP 37

SIP response codes

4xx client error
400 bad request
401 unauthorized
403 forbidden
408 request timeout
480 unavailable
481 invalid Call-ID
482 loop detected

January 18, 2000

SIP 38

SIP response codes

January 18, 2000

SIP 39

5xx server error

500 server internal error
501 not implemented
502 bad gateway
503 service unavailable
504 gateway time-out
505 version not supported
6xx global failure
600 busy
601 decline
604 does not exist
606 not acceptable

January 18, 2000

SIP 40

REGISTER

 on startup, send registration to [Link] via multicast

 registrations expire – determined by server

 returns list of current registrations

 registrations may be proxied ➠ mobility

Send this registration to [Link], forwarded to [Link]:

January 18, 2000

SIP 41

REGISTER examples
REGISTER sip:[Link] SIP/2.0
Contact: sip:room234@[Link]
;q=0.9;expires=3600
Contact: sip:me@[Link] ;q=0.5
;expires="Th, Aug 13 1998 10:15:65 GMT"
Contact: [Link]
;q=0.3;expires="Mo, Jan 1 2000"

January 18, 2000

SIP 42

Extended Contact header

for REGISTER:
q location preference
expires expiration time/date
class business, residence
description show to caller
duplex full or half-duplex
feature call handling features
language languages spoken
media audio, video, text/numeric, . . .
mobility fixed or mobile
priority “only in case of emergency”
service IP, PSTN, ISDN, pager, . . .

January 18, 2000

SIP 43

Contact example
q=quality gives preference.
SIP/2.0 302 Moved temporarily
Contact: sip:hgs@[Link]
;action=redirect ;service=IP,voice-mail
;media=audio ;duplex=full ;q=0.7;
Contact: [Link] ; service=ISDN
;mobility=fixed ;language=en,es,iw ;q=0.5
Contact: [Link] ; service=pager
;mobility=mobile
;duplex=send-only;media=text; q=0.1; priority=urgent;
;description="For emergencies only"
Contact: [Link]

January 18, 2000

SIP 44

Headers: call and request identification

To, From: logical call destination, source (“call leg”)

Call-ID: globally (time, space) unique call identifier

CSeq: request within call leg

January 18, 2000

SIP 45

SIP request routing

 send requests to local proxy or host in Request-URI

 each proxy checks for loop, prepends a Via header with own address

 UAS copies Via headers to response

 on receipt, make sure it’s own address

 received set by receiver ➠ NATs

 maddr if received via multicast

January 18, 2000

SIP 46

SIP response routing

 response traces back request route without proxy server state

 forward to host, port in next Via

 TCP: re-use connection if possible, create new one if needed

 UDP: may send responses to same port as requests

Via: SIP/2.0/UDP [Link]

;received=[Link]

January 18, 2000

SIP 47

Loop and misdirection prevention

 Via header before forwarding

 Via list of locations

 Max-Forwards limits number of hops

 Expires limits search time

January 18, 2000

SIP 48

Call and caller identification

Subject topic of call, short message
Organization caller and callee, possibly filled in by proxy
Date date of call (for dumb devices)
Server make and model of server
User-Agent make and model of client
Accept-Language human languages preferred
Priority call priority

January 18, 2000

SIP 49

SIP extensions: new methods

 methods can be added at any time without changing the protocol

 server complains with 405 if not implemented, returns list of

methods in Allow header

 client can ask via OPTIONS header ➠ Allow list

January 18, 2000

SIP 50

SIP extensions and feature negotiation

 receiver ignores headers, parameters it doesn’t understand
 if crucial, mark with “Require: feature”

C->S: INVITE sip:watson@[Link] SIP/2.0

Require: [Link]
Payment: sheep_skins, conch_shells

S->C: SIP/2.0 420 Bad Extension

Unsupported: [Link]

 methods: on failure (506), indicate via Allow

 inquire about capabilities: OPTIONS ! Allow, possibly
supported media types

January 18, 2000

SIP 51

SIP reliability: all but INVITE

 SIP: UDP and TCP, same messages, same behavior

 requests contain

Call-ID: globally unique in time and space

CSeq: command sequence number ➠ duplicate detection
Timestamp: timestamp at origin ➠ RTT estimation

 retransmit  11 times at 0.5, 1, 2, 4, 4, . . . seconds

 . . . until provisional (1xx) response

 then with interval 4 seconds

January 18, 2000

SIP 52

SIP reliability: INVITE

 retransmit request after 0.5, 1, 2, 4, 4, 4, 4 seconds

 until provisional or final response

 client confirms final response via ACK ➠

1. C ! S : INVITE
2. S ! C : 100, user location, ringing, . . .
3. S ! C : 200
4. C ! S : ACK

 server repeats final response (as above) if no ACK

January 18, 2000

SIP 53

SIP state transition – server

Initial

INVITE
1xx
status change
CANCEL INVITE
200 1xx 1xx
Call proceeding

failure callee picks up

>= 300 200
n
max(T1*2 , T2) INVITE
status status
INVITE
status Failure Success CANCEL
200

32s ACK
-
-
ACK CANCEL
event -
Confirmed 200
message sent

January 18, 2000

SIP 54

SIP state transition – client

Initial
7 INVITE sent -
-
INVITE
event
n
request sent T1*2 Calling
INVITE give up
BYE
1xx

status 1xx
ACK
Call proceeding
status
give up
ACK
BYE
status
ACK
Completed

32 s (for proxy)

January 18, 2000

SIP 55

SIP Session (Media) Description

January 18, 2000

SIP 56

SIP message body

 requests and response can contain any (binary/text) object
 typically:
– requests ➠ session (media) description
– response ➠ session description on success, HTML or plain text
on failure
 described by:

Accept media type

Accept-Language language of response
Content-Type type of media (text/html, application/sdp, . . . )
Content-Length length of message body

January 18, 2000

SIP 57

 future: MIME, e.g., multipart/mixed

January 18, 2000

SIP 58

Session Description: SDP

 application-specific: media vs. events

 caller and callee indicate receive capabilities and receive

address/port

 media address may not be same as signaling address ➠ PINT with

PSTN addresses

January 18, 2000

SIP 59

Session Description Protocol (SDP)

 originally for Mbone session advertisements

 used for Mbone tools (sdr), RTSP, H.332

 parameter=value, no continuation lines

 global and per-media objects

 others (SMIL) in progress ➠ nesting (and/or)

January 18, 2000

SIP 60

SDP example for Internet telephony

v=0
o=[Link] 877283459 877283519 IN IP4 [Link]
c=IN IP4 [Link]
b=CT:64
t=3086272736 0
m=audio 3456 RTP/AVP 96
a=rtpmap:96 VDVI/8000/1
m=video 3458 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait

January 18, 2000

SIP 61

SIP Security, Authentication and

Privacy

January 18, 2000

SIP 62

Security

hop-by-hop encryption & authentication: IPsec, SSL

proxy authentication: Proxy-Authentication

end-to-end HTTP authentication: basic (password) and digest

(challenge-response)

end-to-end cryptographic: PGP, S/MIME – as filter

also: anonymous calls

January 18, 2000

SIP 63

SIP authentication

Basic: include plain-text password in request, immediately or after 401

(Unauthorized) response

Digest: challenge-response with shared secret

Certificate: sign non-Via parts of request headers, body with PGP,

PKCS #7

SSL, SSH: but only for TCP

 but: need more elaborate cryptographic capability indication in SDP

January 18, 2000

SIP 64

Anonymous calls

 near-end proxy that scrambles identifying information (“anonymous

remailer”) ➠ no call-state needed

 far-end proxy hides exact callee location

 Via hiding

 source and media IP addresses valuable ➠ NAPT

 can have third-parties vouch for calls (“caller-id”) ➠ proxy signs

request with (phone) company id

January 18, 2000

SIP 65

Anonymous calls

traceable: encrypt salted version

recognizable: “payphone” ! same caller, same identification ➠

non-salted encryption

confirmable: hash without key

non-returnable: (teachers) ➠ encrypt only URL, not name

January 18, 2000

SIP 66

SIP firewalls

 act as standard SIP proxy

 much easier than H.323:

– single protocol vs. H.225.0 + H.245

– SDP  H.245.0
– single-stage negotiation
– no need to maintain TCP connections during call

 need to understand INVITE, ACK and BYE

 if final SDP in success ACK: ACK only

January 18, 2000

SIP 67

SIP billing/charging
What for?
 transport ➠ resource reservation protocol
 SIP services (call processing) ➠ authentication
 PSTN gateway services
 media server services (translation, storage)
How?
 resource reservation protocols
 SIP-in-DIAMETER approach
 server log files

January 18, 2000

SIP 68

SIP Services

January 18, 2000

SIP 69

SIP services

 buddy lists and notifications

 proxy and fanout

 IN services

 MCUs and “multi-unicast”

January 18, 2000

SIP 70

Signaling event notification

 call queueing . . . buddy lists . . . event notification

 SUBSCRIBE to events

 server NOTIFY

 can use forking

 handle subscriptions using CPL

 transition to multicast if large group of subscribers

January 18, 2000

SIP 71

SIP “fan-out”

 proxy server may issue several request

 e.g., all known login locations

 waits for definitive response ( 200)

 3xx (redirect) code: possibly recurse

 returns “best” (lowest-class) definitive response

 200 (OK) and 6xx (Busy, . . . ) terminate search

 CANCEL: terminate other search branches

January 18, 2000

SIP 72

Branching requests
Search for callee in several places:
3 BYE U@H1

INV U@P2 INV U@H1

P2 H1
200 (H1) 200 (H1) 2

1
INV U@P1
C P1
200 (H1)
200 (H2)
INV U@H2

482
2
200 (H2) 200 (H2)
P3 H2
INV U@P3 INV U@H2

request 3 ACK U@H2

response (Location)

January 18, 2000

SIP 73

IN call forwarding features

SIP can implement intelligent network features:
name feature SIP note
SCF selective call forwarding 302, Contact
SCR selective call reject 302, Contact
CFU call-forwarding unconditional 302, Contact
CFB call-forwarding busy 302, Contact
CFNR, CFDA call forwarding, no response 302, Contact
DND call forwarding to voice mail 302, Contact

➠ differences as server program or in end system

January 18, 2000

SIP 74

IN call handling features

name description SIP notes
CW call waiting not: > 1 call pres.
(A)CB call back email, log file
ICS incoming call screening end system
OCS outgoing call screening firewall?
CID, CND calling # delivery From
CLIR, CIDR, CNDB calling # delivery blocking leave out, anonymizer
TWC three-way calling Also:

January 18, 2000

SIP 75

SIP advanced services

 Also for third-party control: A asks B to send request to C

 generic establishment of call legs

 Call-Disposition for enumerated features

 Contact headers for feature description

January 18, 2000

SIP 76

Building advanced services

Construct from element behavior, not feature descriptions:

request URL: next resolution stage

From: logical call source

To: logical call destination

SDP “c=”: address media is to be sent to – Internet or PSTN!

Also: indication of additional requests to send

Contact: indication of alternate participants

January 18, 2000

SIP 77

Building advanced services: rules

 SIP responses go to requestor

 INVITE establishes single data association

 don’t ring for new additional participant in existing call ➠ call

transfer

 BYE terminates From leg only

 OPTIONS may use Also

 call ends when last party leaves

January 18, 2000

SIP 78

Multipoint Control Units (MCUs)

URL = conference-id@mcu-host

call in: new participant invites MCU

call out: MCU invites participants

January 18, 2000

SIP 79

Mesh
 multicast not always available
 easier for adding third party to call
 full mesh of all participants
 if x wants to add party y , invite y with list of other participants in
Also:
 any member of call can invite
A B A B A B

1
Also: B 2 3
2

D C D C D 1 C
Also: A,B

BYE INVITE session

January 18, 2000

SIP 80

MCUs: transition from mesh to MCU

 transition from mesh to MCU
 Replaces = “inverse” Also
 ask recipient to delete calls with named parties
 recipient sends BYE

MCU MCU
1 2
Also: B Replace: A
3
A B A B

6 5

D C D C 4
Replace: A,B
BYE INVITE session

January 18, 2000

SIP 81

SIP user location

 SIP is independent of mechanism to locate user
 examples:
– local multicast of invitation
– login-based via NFS
– recursive “finger”-traversal
– name translation: [Link] ➠ agb
– active badges
– SIP:
 REGISTER announces location, with time limit
 REGISTER + Contact sets new location
 forwarding within host (6= standard port)
January 18, 2000
SIP 82

Interaction with directory services

 LDAP (with dynamic extensions)

 rwhois

 whois++ (RFC 1913)

 possibly implement SIP interface ➠ simpler clients

January 18, 2000

SIP 83

Automatic call distribution (ACD)

 caller connects to server for company, indicates language, subject,

organization, urgency, . . .

 alternatives:

– proxy server maintains queue state, forwards

– (local) multicast signaling, Call-Disposition: First ➠ first
suitable agent answers
proxy suppresses multiple responses
avoids centralized state maintenance

January 18, 2000

SIP 84

Hold
➠ temporarily disable media delivery

 multicast: use RTCP “interest indication”

 thus, unicast only

 send INVITE with SDP port number = 0 for media

music-on-hold ➠

 ask RTSP server to stream to callee address

 send INVITE with SDP address of music server (multicast!)

January 18, 2000

SIP 85

Camp-on service
Choices:

1. callee indicates time to call back

2. “polling”: caller issues repeated INVITE

3. caller indicates desire to wait:

C->S: INVITE sip:watson@[Link] SIP/2.0

Call-Disposition: queue

S->C: 181 Queued: 2 pending

181 Queued: 1 pending
200 OK

January 18, 2000

SIP 86

Outgoing call handling

Three-party setups:

 secretary dials for boss

 auto-dialer hands call to telemarketer

 attended call transfer

 operator services

➠ treat as three-party calls

January 18, 2000

SIP 87

Outgoing call handling: telemarketing

telemarketer
T INVITE(Also:)
BYE(Also:)
3
2(C) 4

5
A C
auto-dialer 1 customer

January 18, 2000

SIP 88

Mobility Support Using SIP

Elin Wedlund and Henning Schulzrinne, “Mobility Support Using SIP”,
WoWMoM, Seattle, August 1999.

January 18, 2000

SIP 89

Overview
pure-IP mobility $ IP over GSM, 3G, . . .

 SIP

 mobile applications

 mobile IP issues for Internet telephony

 mobility support using SIP

 performance

 future work

January 18, 2000

SIP 90

Aside: Where is Mobile IP Needed?

Not needed if short-lived, restartable client-server connections:
http short, stateless
smtp short, restartable
pop, imap short, restartable
telnet yes, but rarely used by mobiles (?)
ftp restartable, rare
chat, irc yes, but fixable (proxy, protocol)

January 18, 2000

SIP 91

Requirements for VoIP Mobility

 fast hand-off, preferably without network support:

– voice packet every 20–50 ms

– FEC can recover 2–3 packets

 low packetization overhead:

headers IP+UDP+RTP 40 bytes
G.729 payload 8 kb/s, 10 ms n
10 bytes

 simple end systems

January 18, 2000

SIP 92

Mobile IP Issues
 encapsulation

 dog-legged routing

 binding updates still home network

CN
MH
MH mobile host
correspondent host
through HA
CH
HA
HA router with home agent
functionality


CH

data HA router with foreign agent

may fail with IP address FA
functionality

filters data
tunnelled
data

 stack/infrastructure MH
data
foreign
changes network

January 18, 2000

SIP 93

SIP Mobility Overview

 pre-call mobility ➠ SIP proxy, redirect

 mid-call mobility ➠ SIP re-INVITE, RTP

 recovery from disconnection

January 18, 2000

SIP 94

SIP mobility: pre-call

 MH acquires IP address
via DHCP

 optional: MH finds SIP

server via multicast IN- redir
MH
MH mobile host
home correspondent host
VITE
CH

network redir
SIP redirect server
1


CH 2 1 SIP INVITE

MH updates home SIP 2 SIP 302 moved temporarily

3 SIP INVITE
server 5
3

4 4 SIP OK


5 data

optimization: hierarchi- MH
foreign
network

cal LR (later)

January 18, 2000

SIP 95

SIP Mobility: Mid-call

MH!CH: new INVITE, with Contact and updated SDP

redir
MH MH mobile host
home CH correspondent host
network
redir
SIP redirect server

CH 1 SIP INVITE

2 SIP OK

2 3 data
1
3

MH
foreign
MH
network

January 18, 2000

SIP 96

SIP Mobility: Multi-stage Registration

Don’t want to bother home registrar with each move

From: alice@NY
Contact: [Link]
From: alice@NY
Contact: alice@CA

San Francisco CA NY

From: alice@NY
Contact: [Link]

REGISTER
INVITE
Los Angeles

January 18, 2000

SIP 97

802.11 Movement Detection: Ad-Hoc Mode

no “access point” ➠ regular station as BS

 BS serves as default router

 periodic multicast beacon

 pick best: driver provides SNR, strength

 could use regular multicast packets for quick BS discovery

January 18, 2000

SIP 98

802.11 Movement Detection: Infrastructure Mode

access point (AP) for BSS

 attachment handled by MAC layer, invisible to application

 BSSID is contained in 802.11 packet, but

– BSSID not visible to application

– driver doesn’t get notified if MH attaches to new AP

 modified driver that polls hardware?

January 18, 2000

SIP 99

Handoff Performance
MH BS DHCP CH

beacon interval

handoff interval
beacon

Discover

Offer

INVITE
Request
Ack
200

January 18, 2000

SIP 100

Open Issues

 handoff performance in a loaded network

 soft hand-off: IP-level vs. application proxies

 soft hand-off for 802.11 infrastructure mode possible?

 RTP issues: collision detection

January 18, 2000

SIP 101

Conclusion

 mobile telephony = most common mobile application

 all-IP network: can’t punt hand-off

 terminal mobility as special case of personal mobility

 SIP-based mobility ➠ immediate deployment

January 18, 2000

SIP 102

Internet phone “appliance”

 phone = $49.99; PC > $600 (GPF included)
 Ethernet phone ➠ no PBX for switching
 examples: 3Com NBX, Columbia University, e-tel, Nortel, Pingtel,
Symbol Technologies (wireless), . . .
 Columbia e*phone:
– DSP for voice coding ➠ limited memory (256 kB SRAM!)
– implemented minimal IP stack (IP/UDP/RTP, DHCP, SIP, tftp,
DNS)
– no TCP
– MP3 radio

January 18, 2000

SIP 103

– sensor interfaces to the world: chair, IR, temperature, . . .

January 18, 2000

SIP 104

January 18, 2000

SIP 105

SIP Scripting

January 18, 2000

SIP 106

cgi-bin for SIP Servers

 extend SIP user/proxy/redirect server functionality without

changing server software

 server manages retransmission, loop detection, authentication, . . .

 Perl, Tcl, VB scripts

January 18, 2000

SIP 107

Examples
 Call forward on busy/no answer
 Administrative screening (firewall)
 Central phone server
 Intelligent user location
 Third-party registration control
 Calendarbook access
 Client billing allocation (lawyer’s office)
 End system busy
 Phone bank (call distribution/queueing)

January 18, 2000

SIP 108

cgi Script Functionality

called for any method except ACK or CANCEL

 proxying of requests

 returning responses

 generate new requests

once for each request or response or timeout

January 18, 2000

SIP 109

cgi Script Mechanism

environment variables: headers, methods, authenticated user, . . .

stdin: body of request

stdout: new request, meta-requests:

 CGI- requests for proxying, response, default action

 script cookie for state across messages
 reexecute on all, final response, never

January 18, 2000

SIP 110

Cgi Example: Call Forwarding

use DB_File;

sub fail {
my($status, $reason) = @_;
print "SIP/2.0 $status $reason\n\n";
exit 0;
}

tie %addresses, ’DB_File’, ’[Link]’

or fail("500", "Address database failure");

$to = $ENV{’HTTP_TO’};

if (! defined( $to )) {
fail("400", "Missing Recipient");
}

January 18, 2000

SIP 111

$destination = $addresses{$to};

if (! defined( $destination )) {
fail("404", "No such user");
}

print "CGI-PROXY-REQUEST-TO $destination SIP/2.0\n";

print "CGI-Reexecute-On: never\n\n";
untie %addresses; # Close db file

January 18, 2000

SIP 112

Caller Preferences

January 18, 2000

SIP 113

Preferences

callee: scripts, CPL, REGISTER advice in Contact, . . .

caller: help guide routing (“no home number”) and order of attempts
when forking (“try videophone first, then phone, then answering
service”)

“caller proposes, callee disposes”

January 18, 2000

SIP 114

Accept-Contact and Reject-Contact

 determine order of contacting users:

Accept-Contact: sip:sales@[Link] ;q=0,

;media="!video" ;q=0.1,
;mobility="fixed" ;q=0.6,
;mobility="!fixed" ;q=0.4

➠ “avoid connecting me to sales; I prefer a landline phone; try

 Reject-Contact: rule out destinations

Reject-Contact: ;class=personal

January 18, 2000

SIP 115

Request-Disposition

 proxy or redirect

 cancel ringing second phone after first picked up?

 allow forking?

 search recursively?

 search sequentially or in parallel?

 queue the call?

January 18, 2000

SIP 116

The Call Processing Language

Jonathan Lennox
Columbia University
lennox@[Link]

IRT Group talk

March 3, 1999

January 18, 2000

SIP 117

Purpose
Allow users to create simple Internet telephony services

Features

 Creatable and editable by simple graphical tools

 Independent of signalling protocol

 Safe to run in servers

January 18, 2000

SIP 118

Abstract Structure
busy
location proxy timeout
url: sip:jones@ timeout: 10s failure
Call String-switch [Link]
field: from
match:
*@[Link]
otherwise
location
url: sip:jones@
voicemail. redirect
[Link]
merge: clear

January 18, 2000

SIP 119

Abstract Structure (cont)

 Nodes and outputs — “boxes” and “arrows”

 Nodes have parameters

 Start from single root “call” node

 Progress down acyclic graph

 Follow one output of each node, based on outcome

 Continue until we get to a node with no outputs

January 18, 2000

SIP 120

Textual representation
<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "[Link]">

<call>
<string-switch field="from">
<string matches="*@[Link]">
<location url="sip:jones@[Link]">
<proxy>
<busy> <link ref="voicemail" /> </busy>
<noanswer> <link ref="voicemail" /> </noanswer>
<failure> <link ref="voicemail" /> </failure>
</proxy>
</location>
</string>
<otherwise>
<location url="sip:jones@[Link]"
merge="clear" id="voicemail">
<redirect />
</location>
</otherwise>
</string-switch>
</call>

January 18, 2000

SIP 121

Textual Representation (cont)

 Represent scripts as XML documents

 Nodes and outputs are both tags

 Parameters are tag attributes

 Multiple outputs to one input represented by link tags

January 18, 2000

SIP 122

Switch nodes
Switch nodes make decisions.
Structure:
<type-switch field=var>
<type condition1="value1">
-action1-
</type>
<type condition2="value2">
-action2-
</type>
<otherwise>
-action3-
</otherwise>
</type-switch>

January 18, 2000

SIP 123

String Switches
Switch based on textual strings.

 type: “string”
 conditions: one of
– “is” (exact string match)
– “contains” (substring match)
– “matches” (glob match)
 Possible fields:
– “to,” “from” — all servers
– “request-uri,” “subject,” “organization,” “priority,”
“display-from,”, “display-to” — SIP servers

January 18, 2000

SIP 124

– ??? — H.323 servers

January 18, 2000

SIP 125

Time switches
Switch based on the current time at the server.

 type: “time”

 conditions:

– year, month, date, day, timeofday

– each condition is a list of ranges: a1 b1 ; a2 b2 ; : : :

– must fall within a range of all specified conditions

January 18, 2000

SIP 126

Time switches: Examples

Examples:

<time month="12" date="25" year="1999">

December 25th, 1999, all day

<time month="5" date="4">

May 4th, every year, all day

<time day="1-5" timeofday="0900-1700">

9 AM – 5 PM, Monday through Friday, every week

<time timeofday="1310-1425,1440-1555,1610-1725"
day="2,4">
1:10 – 2:25 PM, 2:40 – 3:55 PM, and 4:10 – 5:25 PM, Tuesdays and
Thursdays, every week

January 18, 2000

SIP 127

<time date="1-7" day="1">

The first Monday of every month, all day

January 18, 2000

SIP 128

Location nodes

 A number of CPL actions (proxy, redirect) take locations

 Location nodes let you specify them

 These are full-featured nodes because we might want to make

decisions based on outcomes of location lookups, or cascade
locations

 A CPL script has an implicit global list of locations

 Location nodes can add to this list, or clear the list

January 18, 2000

SIP 129

Simple location nodes

Specify a location explicitly.

 Name: “location”

 Parameter: “url”: explicitly specified location

 Parameter: “merge”

 Only one output; cannot fail. Don’t use an explicit output node in
the URL.

January 18, 2000

SIP 130

Location lookup nodes

Specify a location abstractly, by where it should be looked up.

 Name: “lookup”

 Parameter: one of
– “url”: Gives URL of where to search for locations — ldap, http
(CGI), etc.
– “source”: Non-URL source of locations — currently only
“registration”
 Parameter: timeout
Gives time to wait for locations to be found

 Parameter: “merge”

January 18, 2000

SIP 131

 Outputs: “success,” “notfound,” “failure”.

January 18, 2000

SIP 132

Signalling Actions: Proxy

Proxy the call to the currently-specified set of locations, and
automatically select one “best” final response.

 Name: “proxy”

 Parameter: timeout
Gives time to wait before giving up on the proxy attempt.

 Outputs: “busy,” “noanswer,” “failure”

 If the proxy attempt was successful, the script terminates.

January 18, 2000

SIP 133

Signalling Actions: Redirect

Redirect the call to the currently-specified set of locations. This has no
specific parameters, and causes the script to terminate.

 Name: “redirect”

January 18, 2000

SIP 134

Signalling Actions: Response

Reject the call attempt. This causes the script to terminate.

 Name: “response”

 Parameter: “status”: value is one of “busy,” “notfound,” “reject,” or

“error”, or optionally a 4xx, 5xx, or 6xx numeric code (if the server
is a SIP server).

 Parameter: “reason”: A string explaining the failure in more detail.

January 18, 2000

SIP 135

Non-signalling action: Notify

Notify a user of something through some non-telephony means (e.g.,
e-mail).

 Name: “notify”

 Parameter: “url”: the address to contact (mailto, impp, etc)

 Parameter: “comment”: a string explaining the notification

 Outputs: “success,” “failure”

January 18, 2000

SIP 136

Non-signalling action: Log

Store a record of the current call in a log.

 Name: “log”.

 Parameter: “name”: the name of the log where this should be stored

 Parameter: “comment”: a string explaining the log entry

 Outputs: “success,” “failure”

January 18, 2000

SIP 137

Links

 XML syntax defines a tree; we want CPLs to be represented as

directed acyclic graphs.

 To do this, we need to have links in the tree

 Every node can take an additional parameter, “id,” which takes an

arbitrary token.

 Anywhere a node is expected, you can instead have a “link” tag,

with a “ref” parameter which refers to some node’s id.

 Server must verify that the resulting graph is acyclic.

January 18, 2000

SIP 138

Example: Call Redirect Unconditional

<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "[Link]">

<call>
<location url="sip:smith@[Link]">
<redirect />
</location>
</call>

January 18, 2000

SIP 139

Example: Call Forward Busy/No Answer

<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "[Link]">

<call>
<location url="sip:jones@[Link]">
<proxy timeout="8s">
<busy>
<location url="sip:jones@[Link]" merge="clear"
id="voicemail" >
<proxy />
</location>
</busy>
<noanswer>
<link ref="voicemail" />
</noanswer>
</proxy>
</location>
</call>

January 18, 2000

SIP 140

Example: Call Screening

<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "[Link]">

<call>
<string-switch field="from">
<string matches="anonymous@*">
<response status="reject"
reason="I don’t accept anonymous calls" />
</string>
</string-switch>
</call>

January 18, 2000

SIP 141

Example: Time-of-day Routing

<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "[Link]">

<call>
<time-switch>
<time day="1-5" timeofday="0900-1700">
<lookup source="registration">
<success>
<proxy />
</success>
</lookup>
</time>
<otherwise>
<location url="sip:jones@[Link]">
<proxy />
</location>
</otherwise>
</time-switch>
</call>

January 18, 2000

SIP 142

Example: Non-call Actions

<?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "[Link]">

<call>
<lookup url="[Link]
timeout="8s">
<success>
<proxy />
</success>
<failure>
<notify url="[Link]
comment="The lookup server failed">
<success>
<response status="error" />
</success>
</notify>
</failure>
</lookup>
</call>

January 18, 2000

SIP 143

Open issues
In no particular order. . .
 How do we make decisions based on media types? Media types,
source address, bandwidth?
 The user should be able to specify time zones for time-switch —
how?
 H.323 attributes?
 What additional Proxy results are needed?
 What additional Rejection reasons are needed?
 Is “notify” too general? Should we just have “mailto” instead?
 Other issues?

January 18, 2000