2003-10-i2-kuthan

advertisement
SIP and SER: More Than You
Ever Wanted To Know About
(If you do insist on more, send me an E-mail or grab me in
bar.)
Jiri Kuthan, iptel.org/FhG
sip:jiri@iptel.org
September 2003
iptel.org Credit History
• iptel.org, a Fraunhofer organization, focuses
on VoIP consultancy and manufacturing of SIP
servers.
• iptel.org has been providing public SIP
services since 2001 – got to
www.iptel.org/user/ to get a free SIP account.
• Services powered by SIP Express Router, SER,
extremely scalable and flexible SIP server
developed at iptel – partially, subject of this
tutorial. See more at www.iptel.org/ser/.
Jiri Kuthan, iptel.org, October 2003
Acknowledgements
• The work presented here was to a large extent been
funded by the IST project Evolute, (seamlEss
multimedia serVices Over alL IP-based
infrastructures) under contract IST-2001-32449
• EVOLUTE is addressing issues of providing SIPbased multimedia services including messaging and
streaming in a seamless manner to roaming users in
NGN.
• For more information see
evolute.intranet.gr
Jiri Kuthan, iptel.org, October 2003
Outline
• Introduction (10:30—11:00)
– Motivation
• About Internet Telephony
Application Space
• Usage Scenarios for SIP
• Feasibility Check: How
Much Does It Cost?
– Technology:
• SIP Refresher
• Concern Stack
• SER (11:00-12:00)
– Routing language
– Programming
1:30-3:00 pm – on demand
program … prepare tough
questions!!!
• (Demonstration?)
• SIP Tutorial
–
–
–
–
IETF/History
Services
IM/Presence
Programming
• BCP
– PSTN gatways, security,
reliability, firewalls/NATs,
QoS
Jiri Kuthan, iptel.org, October 2003
Motivation: Applications
Convenience Applications
• What does make existing deployments use SIP?
Applications and Cost effectiveness.
• The application driver is convenience.
• Applications demanded and deployed are mostly about
service integration:
– E-mail: replacement of IVR annoyance with voicemail-2-email
– Web: read list of missed calls from your webpage (both off-line
and on-line) with click-to-dial.
– Web: online phonebook.
– Instant Messaging and Presence, Notification services (T-sturm
alarm), SMS delivery
– Telephony: conferencing
Jiri Kuthan, iptel.org, October 2003
Example: Web Integration,
Missed Calls/Click-to-Dial
Click To Dial
Jiri Kuthan, iptel.org, October 2003
Motivation: Applications
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
Provider’s 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
Jiri Kuthan, iptel.org, October 2003
Motivation: Scenarios
Scenario: Use In Enterprises
PSTN
E1
DSL
• Services available to all
company’s 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.
Jiri Kuthan, iptel.org, October 2003
Motivation: Affordability
How Much in 2003?
• Very little! With IP infrastructure, a host and a
skilled administrator already in place, PC-to-PC
telephony is free:
• $0
– Softphones Free (Windows Messenger, X-Lite)
– Servers available freely (SIP Express Router)
• Your grandma does not want to talk through a PC? • N x $65
Buy her a hardphone. A freebie SIP site
(sipphone.com) ships a pair for $129.99.
• Gateway for PSTN connectivity? Commercial
T1/E1 gateways begin at $2500, software for
experimental PC-based gateways available on the
Internet for free.
• $2500
Motivation: Affordability
How Much Effort?
• Becoming an IP-Telephony operator takes complexity
comparable to setting up E-mail server:
• Configuration Checklist:
– Configure DNS
– Download and configure a SIP proxy server
– Configure supporting services: web provisioning, database
back-end typically.
– Configure PSTN gateway for use with your proxy server.
Jiri Kuthan, iptel.org, October 2003
Technology: SIP
Does SIP Do All of It Today?
 Session Initiation Protocol (SIP) is an IETF signaling protocol
(RFC 3261) that helps to:
 Keep track of users.
 Set up and maintain voice, video and other sessions between them
 Industry acceptance: SIP devices shipped by both established
vendors (Cisco, Microsoft, Lucent, Lucent, …) as well as startups (Pingtel, Grandstream, Intertex, …)
 See www.iptel.org/info/products/
 Interoperability: Good!
 In August 2003 even advanced features such as IPv6 and TLS worked
together in SIPit!
 Future: Use of SIP for mobile networks standardized in 3GPP
Technology: SIP
Basic SIP Call-Flow
•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@195.37.78.173
From: sip:Caller@sip.com;tag=12
To: sip: jiri@iptel.org
#2
Call-ID: 345678@sip.com
INVITE sip:jiri@iptel.org
From: sip:Caller@sip.com;tag=12
To: sip: jiri@iptel.org
#1
Call-ID: 345678@sip.com
#4
OK 200
From: sip:Caller@sip.com;tag=12
To: sip: jiri@iptel.org;tag=34
Call-ID: 345678@sip.com
Proxy
#3
OK 200
From: sip:Caller@sip.com;tag=12
To: sip: jiri@iptel.org;tag=34
Call-ID: 345678@sip.com
sip:jiri@195.37.78.173
Caller@sip.com
Media streams #5
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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).
Jiri Kuthan, iptel.org, October 2003
Technology: Concern Stack
 Concern: Performance
• Performance – are you really able to process all the crap
messages you receive over the public Internet?
• iptel.org’s 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.
Jiri Kuthan, iptel.org, October 2003
Technology: Concern Stack
 Concern: SIP Routing
• Flexible signaling among • Iptel’s
answer:
routing
a variety of components language that allows precise
by proxy is good for definition of server behaviour.
service creation, but how
Begin
do you define proper
no
no
routing?
User Online?
INVITE request?
yes
yes
Report
Missed Call
Applications
SIP: forward
request
SIP: 404
Not Found
Done
 Application Programming
Technical Status
• Site administrator service request examples:
– “Implement a welcome announcement for new subscribers”.
– “Show My on-line status on my web-page!”
• Problem: Do you really want to put your hands on 100k LOC
server code with timers, locks, shared memory usages, etc.?
• Fortunately easy to handle: SIP’s textual nature allows easy
combination with UN*X and web applications known to be
effective for programming.
• Example: FWD’s online status; few lines of HTML/PHP
<a href="http://fwd.pulver.com/callme.php">
<img
src=http://fwd.pulver.com/myicon.php?userid=nnnnn
border=1 alt="FWD
Status">
</a>
Jiri Kuthan, iptel.org, October 2003
Technical Status
 NAT Traversal
• NATs popular because they conserve IP address space
and help residential users to save money charged for
IP addresses.
• Problem: VoIP does not work over NATs without
extra work.
• Straight-forward solution: replace NATs with IPv6 –
unclear when deployed if ever.
• There are many scenarios for which no single
solution exists. Solutions include: STUN, ALGs,
symmetric communication, media relay, UPnP, …
• See the BCP section later…
Jiri Kuthan, iptel.org, October 2003
 Troublemakers
• Phone makers: Some phone features still either in
infancy or in chaos:
– Few phone vendors support NAT traversal (STUN,
symmetric signaling).
– Very few SIP phone vendor support fail-over using
DNS/SRV.
– No standardized means of phone provisioning.
• Politicians and legacy operators.
– recently, state of Minnesota put unrealistic requirements on
Vonage in response to telcos’ attempt to rule out VoIP
competition.
– Bans on VoIP in several countries. (Pakistan, Panama).
– US ILECs attacking VoIP industry (“numbering issues”).
Jiri Kuthan, iptel.org, October 2003
First Conclusion Series
• Basic VoIP & complementary services up and running.
Many problems of past years are gone: QoS,
performance, SIP routing, application integration, NAT
traversal, etc. See BCP section later for more details.
• Infrastructure can be set up in an inexpensive way: Just
download the software from the Internet and call “make
install”.
• Many phone features which I would love to have in
general availability or still on vendors’ to-do lists.
Jiri Kuthan, iptel.org, October 2003
SIP Tutorial
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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.
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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.
Jiri Kuthan, iptel.org, October 2003
Protocol Zoo (Hourglass Model)
ENUM
WWW
iLBC, G.711, ...
signaling interdomain
HTTP
SIP
DNS
AAA
RADIUS
media
RTP
NAT
STUN
TLS
TCP
SCTP
UDP
IPv4/IPv6
PPP
Ethernet
GPRS
SONET
AALx
V.x
Jiri Kuthan, iptel.org, October 2003
ATM
Packetized Communication
Signaling Protocol
Media Transport
Call Server
End Users
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
Jiri Kuthan, iptel.org, October 2003
Given All Supporting Protocols are In
Place, What Do I need on SIP Part?
• SIP Registrar
– accept registration requests from users
– maintains user’s 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!
Jiri Kuthan, iptel.org, October 2003
SIP Registrar
#2
Jiri @ 195.37.78.173
Location Database
REGISTER sip:iptel.org SIP/2.0
From: sip:jiri@iptel.org
To: sip:jiri@iptel.org
Contact: <sip:195.37.78.173> #1
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 user’s current
location 195.37.78.173.
Expires: 3600
#3
SIP/2.0 200 OK
SIP Registrar
(domain iptel.org)
Jiri Kuthan, iptel.org, October 2003
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.
Location Database
#0
INVITE sip:jiri@iptel.org
From: sip:Caller@sip.com;tag=12
To: sip: jiri@iptel.org
#1
Call-ID: 345678@sip.com
#6
jiri
#2
OK 200
From: sip:Caller@sip.com;tag=12
To: sip: jiri@iptel.org;tag=34
Call-ID: 345678@sip.com
#7
jiri@195.37.78.173
DNS SRV Query ? iptel.org
Reply: IP Address of iptel.org SIP Server
#3
Proxy
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
#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
sip:jiri@195.37.78.173
Caller@sip.com
Media streams #8
Jiri Kuthan, iptel.org, October 2003
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.
Jiri Kuthan, iptel.org, October 2003
Service composition: Added-value
Server Chains
Caller’s administrative domain
Administrative domain of a PSTN gateway operator
pstn.com
#2
asia.pstn.com
#3
gw01.asia.pstn.com
#4
#1
Caller’s outbound
proxy accomplishes
firewall traversal.
Destination’s
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).
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
“Stateful” Proxy Refers to
Transactions
SIP state
forgotten
as soon as
transaction over
INVITE
a@a.com
OK
Frequently
Misunderstood
Issue
• 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!
Legend
SIP signaling
SIP state
media
Jiri Kuthan, iptel.org, October 2003
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:
• Today’s 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.
Jiri Kuthan, iptel.org, October 2003
SIP Message Structure
Request
Response
INVITE sip:UserB@there.com SIP/2.0
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>
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
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
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
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
Payload
SDP (RFC2327): “receive RTP G.711-encoded
audio at 100.101.102.103:49172”
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:, ...)
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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)
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
SIP Service Space
Jiri Kuthan, iptel.org, October 2003
What’s the Killer App?
• Q: Added-value services expected to be major source of
revenues. So what is the killer app?
• A: If I saw raw gold on the street I would not tell you either.
• It is believed that the convenience of integrated services will
be the killer.
• IN-like services reproducible, though with different mimics
sometimes.
• Couple of examples follow...
• (No, I really do not know which of them will be the best-seller.)
Jiri Kuthan, iptel.org, October 2003
Example Convenience Services
• Applications demanded and deployed are mostly
about service integration:
– E-mail: replacement of IVR annoyance with voicemail-2-email
– Web: read list of missed calls from your webpage (both offline and on-line)
– Web: online phonebook, click-to-dial
– Instant Messaging and Presence, Notification services (Tstorm alarm), SMS delivery
– Telephony: conferencing
• Technical challenge: make service programming easy
Jiri Kuthan, iptel.org, October 2003
IN-like Services with SIP
• Most of IN services may be
easily implemented with SIP
in proxies/redirect servers or
UAs:
– (Un)conditional call
forwarding
– abbreviated dialing
– Screening
– distinctive ringing
– call distribution
– call transfer
– etc.
•
Sometimes, implementation
logic may completely differ.
– Televoting and IVRs likely to be
replaced by Web in the long run.
– Call-waiting is end-device
implementation issue with no
protocol support.
– Music-on-hold may be played
localy.
The real benefit is those services beyond IN: straight-forward
integration with web, email, instant messaging, etc.
Jiri Kuthan, iptel.org, October 2003
Example:
Call Transfer Call Flow
#1
A
REFER B
To: B
Refer-To: C
Referred-By: A
#2 202 Accept
A is having a call with B. A decides to
transfer B to C. It sends a “REFER” to
B with C’s address. Eventually, A is
notified on successful transfer using
NOTIFY (#6).
B
#3
#4
#6
NOTIFY (OK)
#7
#5
INVITE C
Referred-By: A
200 OK
200 ACK
200 OK
media
timeline
Jiri Kuthan,
iptel.org, October 2003
C
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
Jiri Kuthan, iptel.org, October 2003
Answering Machine
• Old-times behavior: set-up number of rings, plug-in, if you do
not answer the machine will
• Easy to mimic with SIP: AM acts as a SIP UA; you need to
set-up an answer timer, let the answering machine register
using your credentials; when an invitation arrives it is forked
both to your phone and your answering machine
• Added value examples:
– Unified messaging: SIP answering machine can turn voice messages
into email messages that follow you or comprehensive web-pages (cf.
voice navigation)
– Programmability allows to play variety of customized prompt
messages:
• If (caller  friends) then play (“You can reach me at Venice beach or leave
a message”) else play (“leave a message please”);
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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.
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
draft-ietf-simplepresence
Subscribe-Notify
For Presence Services
Step I: subscription to a condition
#1 SUBSCRIBE joe
Event: presence
Presence server
Step III: event occurs
#5 REGISTER joe
Contact: alice
#6 OK
#2 202 Accepted
#4 OK
#3 NOTIFY alice
Event: presence
subscriber
#7 NOTIFY alice
Event: presence
#8 OK
Step II: subscriber is immediately notified
on current condition
Jiri Kuthan, iptel.org, October 2003
Step IV:
subscriber
is notified
whenever
condition
changes
Service Programming
Jiri Kuthan, iptel.org, October 2003
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. Don’t be
worried about buzzword compliance too much.
Jiri Kuthan, iptel.org, October 2003
Service Execution Layering
User Code
Interpreters
CGI Scripts
(Perl, Python,
C, …)
SIP-CGI
CPL
scripts
Servlets
Java
Servlets
SIP Messages
CPL
SIP Actions
Protocol stack
SIP
Call Processing Logic Example
The call processing
logic may be designed
using various
mechanisms: CPL, SIPCGI, servlet,
proprietary ones.
Jku’s call processing logic:
If ($caller is in {Jane, Bob})
proxy to jku@cell.com
else proxy to voicemail@trash.com
Jku’s call processing
logic:
If ($caller ==Jane)
play Mozart
else
play Smetana
#2 pass invitation
to call processing
#3 return an
#5
action
logic
#4a INVITE jku@cell
#1 INVITE jku
#4b INVITE voicemail@trash
Jiri Kuthan, iptel.org, October 2003
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
operator’s 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
Jiri Kuthan, iptel.org, October 2003
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”
Jiri Kuthan, iptel.org, October 2003
Scripting Languages Key To Efficiency
• Web lesson: variety of languages; PHP, Perl, Python, shell scripts….
• No dependency on a particular programming language – developers can use what
they best understand, including scripting languages
• Use of scripting languages makes code shorter and takes less time (graphs from [*]
demonstrate complexity for a specific problem)
(*) Source of both graphs: Lutz Prechelt: “An Empirical Comparison of C, C++, Java,
Perl, Python,RXX, and Tcl”,Jiri
March
2000.
Kuthan,
iptel.org, October 2003
RFC 3050
SIP Common Gateway Interface
(CGI)
• 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.
Jiri Kuthan, iptel.org, October 2003
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>
Jiri Kuthan, iptel.org, October 2003
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 server’s 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, ...
Jiri Kuthan, iptel.org, October 2003
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>
Jiri Kuthan, iptel.org, October 2003
Example: Creating CPL Scripts
iptel.org: CPL Composer
Jiri Kuthan, iptel.org, October 2003
SIP Express Router (SER)
Jiri Kuthan, iptel.org, October 2003
SER Primer
• SER is an open-source, GPL-ed SIP server with
– High scalability (up to thousands of calls per second of
transactional throughput on a PC)
– Effective application building (modules and
FIFO/application interface)
– High flexibility (routing language)
• Web address (download, documentation, etc.):
www.iptel.org/ser/
• Some non-GPL features available too (LDAP, TLS,
redundancy, …)
Jiri Kuthan, iptel.org, October 2003
Linking Applications to SIP/SER
• To create rich services, one needs to link existing
applications to SIP communication.
• Design requiement: apply division principle and split
SIP infrastructure from applications cleanly.
• I know, we are not the first to come up with the
priniciple…
– Divide and Conquer (“Divide et impera”, Caesar, 100BCE44BCE)
– Labor Division (Adam Smith: The Wealth of Nations, 1776)
• “The greatest improvement in the productive powers of labour, and the
greater part of the skill, dexterity, and judgement with which it is any
where directed, or applied, seem to have been the effects of the division
of labour.”
Jiri Kuthan, iptel.org, October 2003
Application Examples
• Web-applications
– User manipulation of their contacts in user location
database
• Could not be done easily via a back-end database if cached by SIP
server
– “Send Instant Message” – initiate a SIP transaction
– Monitoring of server health|
• Management Applications (command-line or web)
– User administration (e.g., revoking user’s privileges)
– Run-time reconfiguration (e.g., introducing a new domain)
• Presence Applications:
– Drive presence status displayed in SIP messengers.
Jiri Kuthan, iptel.org, October 2003
On Windsurfing
• Jiri’s hobby: windsurfing; cool but loading a van with
gear, traveling to a lake, setting up a sale and learning
that the wind is gone is frustrating.
• The application is out there: there are tons of software
for weather forecasts. The software can generate
information that is precisely needed.
• Missing piece: link the applications to the SIP-based
real-time communication infrastructure.
• How to engineer that? Build in a door in SIP server
that allows SIP-unaware applications to talk SIP.
Jiri Kuthan, iptel.org, October 2003
Our Proposal: Use ASCII Interface
Connected via a FIFO Pipe
Weather
notification
• Design idea:
Web
provisioning
– Export SIP logic to
applications through a textual
request-response FIFO
interface (named pipes)
• FIFO server properties
– Server looks like a file to
application – any file-based
application can use it
– Excellent portability
– Simple and extensible
– Application isolation
Server health
watching
FIFO interface
In addition to its normal
SIP operation, SIP Server acts
as “application rendez-vous
point”
Plug-in modules with exported features
digest
authentication
Jiri Kuthan, iptel.org, October 2003
user
location
SMS
gateway
Example: Contact Maintenance
Web application can show, add and delete user contacts stored in server’s memory.
Jiri Kuthan, iptel.org, October 2003
FIFO Use Example: Adding a New
Contact
• Adding contacts useful for
linking address of record
with static contacts, such as
PSTN destinations
• User location module
exports FIFO action for
adding new contacts
:ul_add:reply
location # (table name)
jiri # (username in address of record)
sip:7271@gw.iptel.org # (new contact)
3600 # (expiration time)
0.5 # (priority)
Request pipe
SIP
Server
Response pipe
200 OK # (status code)
Jiri Kuthan, iptel.org, October 2003
Example: Use of FIFO from Web/PHP
• Appending a contact from a PHP script
/* construct FIFO command */
$fifo_cmd=":ul_add:".$config->reply_fifo_filename."\n".
$config->ul_table."\n".
//table
$user_id."\n".
//username
$sip_address."\n".
//contact
$expires."\n".
//expires
$config->ul_priority."\n\n";
//priority
$reply=write2fifo($fifo_cmd, $errors, $status);
• Note:
– Few lines of code … it is SIMPLE
– The stub function long only less than 40 lines of commented PHP code
Jiri Kuthan, iptel.org, October 2003
Legacy Recycling: Weather Example
• Textual stdin/stdout
interface well established in
the world of UN*X
applications.
• Examples:
– cron daemon for scheduled
calls
– awk for database processing
– PHP for web applications
– shell scripts for commandline tools
– wx2000 for weather forecasts

• Note:
– Applications SIP-unaware
– Application code simple
measure=`./wx200d-1.2/wx200
--gust --C`
speed=`echo $measure | cut -d\ -f1
| sed -e 's/\.//' `
if [ "$speed" -gt "$max_speed" ]
then
cat > $SER_FIFO << EOF
:t_uac_from:null
MESSAGE
sip:weather@iptel.org
sip:receiver@iptel.org
Content-Type: text/plain
Contact: sip:weather@iptel.org
weather alert: Very strong winds in
the area: $speed
.
EOF
fi
Jiri Kuthan, iptel.org, October 2003
Simplicity & Language Independence
• Programming as easy as printing a request
• Textual stdin/stdout FIFO interface easily linkable to any
programming environment: No binary linking difficulties
• No dependency on a particular programming language – developers
can use what they best understand, including scripting languages
• Use of scripting languages makes code shorter and takes less time
(graphs from [*] demonstrate complexity for a specific problem)
(*) Source of both graphs: Lutz Prechelt: “An Empirical Comparison of C, C++, Java,
Perl, Python,RXX, and Tcl”,Jiri
March
2000.
Kuthan,
iptel.org, October 2003
SIP Routing
• One of primary benefits of
SIP: Ability to link various
service components speaking
SIP together.
• The “glue” are signaling
servers.
Their
primary
capability is routing requests
to appropriate services.
• Issues:
SMS Gateway
PSTN Gateway
IP Phone Pool
– Routing flexibility – how to
determine right destination for a
request
– Troubleshooting when routing
failures occur
Jiri Kuthan, iptel.org, October 2003
SIP proxy
Applications
Other domains
Routing Policy
• SIP request-routing decision can depend on a variety of
factors. Iptel.org example:
– address-based routing – requests to numeric destination are forwarded
to PSTN gateway, whereas others to IP phones
– Policy-based processing – calls to international PSTN requests require
authentication and privileges
– Method-based routing – requests to numerical destinations are split by
method between SMS and PSTN gateway
– Further factors include request’s transport origin, address claimed in
From header field, content of Contact, etc.
• Operational observation: mighty tools for specification of
routing policy are needed.
Jiri Kuthan, iptel.org, October 2003
Routing Language
• Request routing flexibility needed to link SIP components
(voicemail, PSTN gateway, logging facility, etc.) together
• Answer: request routing language (features conditions, URIrewriting, request modification, replying, etc.)
• Example: reporting missed calls
Begin
SER Routing Language
no
User Online?
yes
no
INVITE request?
yes
Report
Missed Call
SIP: forward
request
SIP: 404
Not Found
/* user online ? */
if (lookup(“location”)) {
t_relay();
break;
};
if (method==“INVITE”) {
/* report to syslog */
log(“ACC: missed call\n”);
};
sl_send_reply(“404”,”Not Found”);
Done
Jiri Kuthan, iptel.org, October 2003
Leveraging Applications from SER
• Requests for new features come in continuously: how
to make them happy so that server code-base stays
stable and untouched?
• Alternative 1: Build your own new modules (like in
Apache): Introduce new commands to SER routing
languages. The modules are typically written in C and
they are very powerful in that they can access raw
server internals.
• Alternative 2: reuse existing UN*X applications:
affect SER’s routing decision through exec-ed
commands.
Jiri Kuthan, iptel.org, October 2003
Extensibility: Modules
• Existing modules: RADIUS
accounting, SMS support,
digest authentication,
regular expressions, jabber
gateway, presence agent, nat
traversal helper,
multidomain support, etc.
(about 40 today).
#
#
#
#
#
SER script: challenge any user
claiming our domain in From header
field; good anti-spam practise; it
uses module actions for RegExp and
digest authentication
# apply a regular expression
if (!search(“From:.*iptel\.org”)
{
# verify credentials
if (!proxy_authorize(
“iptel.org”,
“subscriber”)) {
# challenge if credentials poor
proxy_challenge(“iptel.org”);
break;
}
}
Jiri Kuthan, iptel.org, October 2003
Exec Module – Link to More Apps
• Exec module: starting external
applications on request receipt;
(similar to but simpler than SIP
CGI-BIN)
• Features:
– ability to use existing UN*X
tools (mail, sed & awk,
wget, …)
– Language-independency
• Interface:
– Request URI and header fields
passed as environment variables to
the applications
– Whole request passed on standard
input
– Optionally, application’s output
evaluated as new request’s URI
(e.g., unconditional forwarding)
2
INVITE
404
# SER script: execute an external
# command for off-line users
if (!lookup(“location”)) {
/* log(“missed call”); */
exec_msg(“/tmp/notify.sh”);
}
# shell script: send email
# notification
2
MAILTO=`user2email $SIP_USER`
printf “User %s called” \
“$SIP_HF_FROM” |
mail –s “Missed Call” $MAILTO
Jiri Kuthan, iptel.org, October 2003
BCP
Jiri Kuthan, iptel.org, October 2003
Interworking with PSTN
Jiri Kuthan, iptel.org, October 2003
About SIP-to-PSTN Connectivity
• SIP Telephony really nice. There are however still
200 million PSTN users hanging around and you
would like to talk at least to some of them.
Jiri Kuthan, iptel.org, October 2003
PSTN Gateways
• Problem #1: your device speaks a different language
than your grandmother’s.
• Solution: use a gateway, i.e., adapter which converts
signaling and speech from Internet to PSTN and vice
versa.
PSTN Internet
• Gateway market established: Cisco, Ericsson, Lucent.
Sonus, Vegastream, etc. Open-source as well.
Jiri Kuthan, iptel.org, October 2003
Call Flow SIP to PSTN
ISDN/ISUP: RFC 3398
QSIG: draft-ietf-sipping-qsig2sip
• Request-URI in the INVITE
contains a Telephone Number
which is sent to PSTN Gateway.
• The Gateway maps the INVITE
to a SS7 ISUP IAM (Initial
Address Message)
• 183 Session Progress
establishes early media session so
caller hears Ring Tone.
• Two way Speech path is
established after ANM (Answer
Message) and 200 OK
Slide courtesy of Alan Johnston,
WorldCom. (See reference to Alan’s
SIP book.)
Jiri Kuthan, iptel.org, October 2003
A Possible Gateway Shopping
Option…
• Size does matter: How to enlarge size of your
network? Take MGCP/Megaco/H.248 and double the
number of boxes today.
• Some vendors decompose gateways in two parts:
signaling gateway and media gateway. These two
parts are reconnected together through some of
Megaco/MGCP/H.248 protocols.
• Don’t ask me what decomposition is here good for
and why there are multiple protocols to choose from.
Jiri Kuthan, iptel.org, October 2003
PSTN GW != SIP proxy
• PSTN gateways are adapters between two
different technologies.
• From SIP perspective, PSTN gateways are
SIP termination devices, i.e., SIP User
Agents just like IP phones.
• PSTN gateway functionality separate SIP
from call processing logic residing at a
proxy.
• Gateway operator != proxy operator.
jku@sipforfree.com.au
media
PSTN Gateway
na.pstn.com
call processing logic:
If ($destination in PSTN) then
route_to_least_cost_gateway();
elseif local(“sipforfree.com.au”) then
lookup_registry;
else proxy_to_foreign_domain();
SIP Proxy & Registrar
sipforfree.com.au
Jiri Kuthan, iptel.org, October 2003
Frequently
Misunderstood
Issue
Gateways Ship Today, What Is the
Problem Then? Integration!
• Identity: jiri@iptel.org calls out through PSTN
gateway. What Caller-ID will display down in PSTN?
• Interdomain settlement: your SIP service operator
does not have the capability to terminate anywhere in
world cheaply. How can he establish a secure channel
to PSTN termination operators?
• How do you locate a proper PSTN termination
gateway?
• And some other ugly legacy problems like DTMF,
overlap dialing.
Jiri Kuthan, iptel.org, October 2003
draft-ietf-sip-privacy
CLID
• Typical deployment problem: jiri@iptel.org (in possession of a
valid PSTN number) would like to call to PSTN through his
gateway operator – how does the gateway know which
telephone number to display?
• Architecturally, proxy servers are highly programmable
devices that can easily link SIP identity to PSTN numbers.
Thus, that’s the place for mapping of SIP identity to an
“owned” PSTN number.
• Missing piece: communicating the PSTN number a server
determined to gateway.
• Current standardization status: several competing documents.
“Remote-Party-ID” deployed.
Jiri Kuthan, iptel.org, October 2003
Remote Party ID
+49-179-123123
INVITE sip:1234@gw.com
From: sip:a@bc.de;tag=12
To: sip:1234@gw.com
a
User ID/phone number database
INVITE sip:1234@gw.com
From: sip:a@bc.de;tag=12
To: sip:1234@gw.com
Remote-Party-ID:
<sip:+49179123123@gw.com>
PSTN
Proxy Server with CLID support
Jiri Kuthan, iptel.org, October 2003
PSTN gateway
Problem of Trust
• Displaying proper caller ID is a legal requirement for
operators. What happens if someone fakes the RPID and
operator displays a wrong number?
– Ask your lawyer or regulator, I better tell you how to ensure
displaying correct number.
• It is about a reasonable trust model: a gateway may only
display caller ID issued by a trustworthy source.
• Trust needed to solve other problems too: Does the call
come from a source to whom my gateway can credit
international calls?
• Establishing trust to individual users within a single
domain almost easy…but what if multiple domains comes
in?
Jiri Kuthan, iptel.org, October 2003
Trust: Interdomain versus Intradomain
• Within single administrative domain, trust can be
implemented using physical security and knowledge
of identity of local users – proxy servers verify
identity of local users using digest and gateways trust
local proxies.
• Interdomain scenario example: iptel.org users
terminate calls to US PSTN with National Gateways
Inc. How do you export the trust then?
– The terminating provider can’t verify identity of remote
users and can’t trust information passed over the public
Internet. RPID alone can’t be trusted as it can be changed
anywhere on the transit. Stronger security protocols come
in for interdomain operation: TLS.
Jiri Kuthan, iptel.org, October 2003
TLS Use for Interdomain Security
Internet
#1
PSTN
#2
TLS
Originating domain
Public
Internet
Terminating Domain
With Local Trust
• Assumption: target domain trusts source domain to display
proper CallerID and settle incurred costs.
• Step 1: originating domain verifies identity of local user
(digest). If ok, it appends RPID and uses TLS for secure
inter-domain communication.
• Step 2: terminating proxy verifies incoming TLS
connection against list of trustworthy domains. If ok, SIP
request is forwardedJiritoKuthan,
PSTN
gateway.
iptel.org, October 2003
More on TLS Use
• TLS use for SIP solves other trust problems too:
– With trust mechanisms, interdomain accounting can be also
implemented securely
– Signaling can be no longer sniffed during transport.
• Security Disclaimers:
– Trust established hop-by-hop – it implies transitive trust
along arbitrarily long proxy chains. Remember a chains is
as strong as the weakest element in it. You have to trust
next-hop not to pass your requests to questionable servers.
– Privacy is not end-to-end: proxy servers along the signaling
path do see SIP in plain-text,
Jiri Kuthan, iptel.org, October 2003
RFC2833
DTMF Support
• Actually, I would wish this slide wasn’t here: IVRs are
horribly inconvenient devices. I like voicemail message
delivery by e-mail and flight-ticket shopping with web much
better. But …
• … Large deployed base for telephony applications.
• Solution 1: include tones in audio. It works fairly well with
G.711 codecs. More compressive codec may degrade quality
so that tones are no longer recognized by receiver.
• Solution 2: special DTMF payload for RTP: RFC 2833.
Reliability achieved through redundant encoding (RFC2198).
Jiri Kuthan, iptel.org, October 2003
RFC3578
Overlapped Dialing
• Problem: ingress PSTN2IP gateway operates in
overlapped dialing mode whereas SIP operates enblock;
• Solution #1: initiate en-block SIP dialing using
knowledge of numbering plans or after a period of
overlapped dialing inactivity; drawback: delay
• Solution #2: send a new INVITE for each new digit
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
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 TSB’s decision.
• Deployment problem: number validation. How does
an ENUM provider know you can claim a number?
Jiri Kuthan, iptel.org, October 2003
More PSTN-Related Reads
• Mapping of of Integrated Services Digital Network (ISUP)
Overlap Signalling to the Session Initiation Protocol
[RFC3578]
• Session Initiation Protocol PSTN Call Flows [draft-ietfsipping-pstn-call-flows]
• Integrated Services Digital Network (ISDN) User Part (ISUP)
to Session Initiation Protocol (SIP) Mapping [RFC 3398]
• Session Initiation Protocol for Telephones (SIP-T): (SIP-T):
Context and Architectures [RFC3372]
• Interworking between SIP and QSIG [draft-ietf-sippingqsig2sip]
Jiri Kuthan, iptel.org, October 2003
Security
Security, Reliability, Performance,
Accounting
Jiri Kuthan, iptel.org, October 2003
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)
Jiri Kuthan, iptel.org, October 2003
Disclaimer: Security Protocols Don’t 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...
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
1. Request w/o
credentials
2. Challenge:
authenticate
yourself
3. Request
resubmitted
w/credentials
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 gh’s credentials but uses a’s address
of record in To header field
• Registrar must enforce a policy that links digest identity to permissible
addresses of records
Jiri Kuthan, iptel.org, October 2003
Reliability
Jiri Kuthan, iptel.org, October 2003
RFC 3263
SIP Reliability
• Murphy’s Law holds: Everything Can Go Wrong
• Most common failure reasons include but are not limited to:
human errors in maintenance procedures, security
vulnerabilities, hardware failures, digging accidents, loss of IP
connectivity
• Loss of SIP server availability does not affect existing calls
but new SIP transactions cannot take place
• Solution: run redundant servers, all of them linked to a single
DNS/SRV name. Clients receive a prioritized list of servers
for a name and can try a backup server if primary is
unavailable.
Jiri Kuthan, iptel.org, October 2003
Caution: DNS
• Too few implementations have implemented
DNS SRV properly (2003)
• DNS servers responsible for a domain must be
redundant too, otherwise they become a single
point of failure in the system
• DNS may be a pain and take very long ...
Jiri Kuthan, iptel.org, October 2003
AAA
Jiri Kuthan, iptel.org, October 2003
Accounting
• Standardization status in IETF:
– No standard for accounting on SIP transactions.
– Use of RADIUS for accounting discouraged since
RADIUS provides no reliability.
– Diameter on roadmap, no deployments now though.
• Current practice: use RADIUS with AVPs as
specified in an expired Internet Draft; other deployed
mechanisms for transmitting CDRs include syslog
and database protocol
• Accounting mostly used for PSTN termination.
Jiri Kuthan, iptel.org, October 2003
Accounting Practices
• Who originates CDRs? PSTN gateway or a front-end
proxy server?
– Gateway is a better place: it is the place where service is
provided and it knows all details including media status,
PSTN status, and local timezone
• How to originate a cut-off when caller’s credit
expires?
– Back-to-back User Agent (B2BUA) – it is a call stateful
element which behaves as a UA to each call participant and
can initiate a BYE to them on demand
Jiri Kuthan, iptel.org, October 2003
Firewall/NAT Traversal
Jiri Kuthan, iptel.org, October 2003
Firewall Traversal
Ultimately Secure Firewall
Installation Instructions: For best effect install the firewall between the CPU
unit and the wall outlet. For Internet use install the firewall between the demarc of
the T1 to the Internet. Place the jaws of the firewall across the T1 line lead, and
bear down firmly. When your Internet service provider's network operations
center calls to inform you that they have lost connectivity to your site, the firewall
is correctly installed.
(© Marcus Ranum)
Jiri Kuthan, iptel.org, October 2003
Problems with Firewalls and NATs
• Firewalls
– Interest to keep policy restrictive conflicts with dynamic
nature of VoIP
– Solutions space: ALGs, external ALGs (MidCom), static
communication
• NATs
– Address translations conserves IP space but causes
inconsistency between address in IP/transport headers and
application payload
– Solutions space: ALGs, external ALGs (MidCom), STUN
• Problem size: HUGE
Jiri Kuthan, iptel.org, October 2003
Where FWs/NATs affect SIP
INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP 192.168.99.1:5060
From: BigGuy <sip:UserA@here.com>
To: LittleGuy <sip:UserB@there.com>
Call-ID: 12345600@here.com
CSeq: 1 INVITE
Subject: Happy Christmas
Contact: BigGuy <sip:UserA@192.168.99.1>
Content-Type: application/sdp
Content-Length: 147
• Contact, Route, RecordRoute header fields
• Via header fields
(received tag)
• SDP payload
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
Jiri Kuthan, iptel.org, October 2003
NAT Traversal
• NATs popular because they conserve IP address space and help
residential users to save money charged for IP addresses.
• Problem: SIP does not work over NATs without extra effort.
Peer-to-peer applications’ signaling gets broken by NATs:
Receiver addresses announced in signaling are invalid out of
NATted networks.
• Straight-forward solution: IPv6 – unclear when deployed if
ever.
• There are many scenarios for which no single solution exists
(they primarily differ in design properties of NATs –
symmetric, app-aware, etc.)
Jiri Kuthan, iptel.org, October 2003
Current NAT Traversal Practices …
• Application Layer Gateways (ALGs) – built-in application
awareness in NATs.
– Requires ownership of specialized software/hardware and takes
app-expertise from router vendors (Intertex, PIX).
• Geeks’ choice: Manual configuration of NAT translations
– Requires ability of NATs, phones, and humans to configure
static NAT translation. (Some have it.) If a phone has no
SIP/NAT configuration support, an address-translator can be
used.
• UPnP: Automated NAT control
– Requires ownership of UPnP-enabled NATs and phones. NATs
available today, phones rarely (Snom).
Jiri Kuthan, iptel.org, October 2003
… Current NAT Traversal Practices
• STUN (RFC 3489): Alignment of phones to NATs
– Requires NAT-probing ability (STUN support) in end-devices and
a simple STUN server. Implementations exist (snom, kphone).
– Does not work over NATs implemented as “symmetric”.
– Troubles if other party in other routing realm than STUN server.
+ Works even if NAT device not under user’s control.
• Relay: Each party maintains client-server communication
– Introduces a single point of failure; media relay subject to serious
scalability and reliability issues
+ Works over most NATs
+ Symmetric clients (RFC3581 for signaling, symmetric
media), comedia support
Jiri Kuthan, iptel.org, October 2003
NAT Practices: Overview
ALG
STUN UPnP Manual Relay
Works over ISP’s N/A
NATs?
Symmetric NATs? N/A
Ltd. (*) N/A
N/A
Maybe
No
N/A
ok
Ltd.
Phone support
needed?
NAT support
needed?
Scalability
No
Yes
Yes
Yes
Yes
Yes
Ltd. (*) Yes
Ltd. (+) No
? (o)
Ok
Ok
Ok
User Effort
Small
Small
Small Big 
*… does not work for symmetric NATs
+ … port translation must be configurable
poor 
Small
o … application-awareness affects scalability
Jiri Kuthan, iptel.org, October 2003
NAT Traversal Scenarios
• There is no “one size fits it all” solution. All current
practices suffer from many limitations.
• iptel.org observations for residential users behind
NATs: Affordability wins: SIP-aware users relying on
public SIP server use ALGs or STUN. First UPnP
uses sighted.
• Our plan for operation on the public Internet:
– Let as many phones as possible handle NAT traversal
autonomously using STUN or UPnP
– Detect cases which cannot be handled autonomously.
– If “hard NATs” detected, ignore SIP and help out with RTP
relay
Jiri Kuthan, iptel.org, October 2003
QoS
Jiri Kuthan, iptel.org, October 2003
RFC3312
QoS: SIP and QoS Control
• In many cases, you don’t need complex QoS protocols: use
Ethernet switches (as opposed to hubs), sufficient bandwidth, and
DiffServ if needed.
• SIP DOES NOT provide QoS support: QoS protocols are kept
separate from signaling.
• Deadlock:
– QoS signaling cannot begin until I learn through signaling who is the other
party.
– SIP signaling cannot complete and alert callee until QoS is established
• Proposal: “QoS Preconditions”: if QoS signaling is enabled, find
the called party, ask it not to ring, carry out QoS reservation, and
start ringing when QoS is ready (UPDATE)
Jiri Kuthan, iptel.org, October 2003
SIP and QoS Control
Caller@sip.com
INVITE sip:Callee@example.com
#1
m=audio 49170 RTP/AVP 0
a=curr: qos e2e none
a=des:qos mandatory e2e sendrecv
Proxy
Callee@example.com
INVITE sip:Callee@10.0.0.1
#2
#3
PRACK/OK
#4
#5
183 Progress
m=audio 49170 RTP/AVP 0
a=curr: qos e2e none
a=des: qos mandatory e2e sendrecv
Reserve
UPDATE/OK
UPDATE sip:Callee@10.0.0.1
a=curr: qos e2e send
#6
180 Ringing
At step #6, path is reserved and callee’s phone can begin ringing.
Then, SIP completes as usual (180 confirmed by PRACK, 200 sent
Jiri Kuthan,
iptel.org, October
2003
when callee answers, media
exchange
begins.)
Record-Routing
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
Record-Routing Example
INVITE sip:jiri@iptel.org
From: joe@abc.com;tag=12
Contact: <sip:joe@1.2.3.4>
BYE sip:joe@abc.com
From: joe@abc.com;tag=12
Route: <sip:rr@1.2.3.4;lr>
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>
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
-The End –
Jiri Kuthan, iptel.org, October 2003
Information Resources
Jiri Kuthan, iptel.org, October 2003
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/
Jiri Kuthan, iptel.org, October 2003
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
Jiri Kuthan, iptel.org, October 2003
There Are SIP Books!
• Alan B. Johnston: “SIP:
Understanding the Session Initiation
Protocol”
• Artech House 2001
• Henry Sinnreich, Alan Johnston:
Internet Communications Using
SIP: Delivering VoIP and
Multimedia Services with Session
Initiation Protocol
• John Wiley & Sons, 2001
Jiri Kuthan, iptel.org, October 2003
Backup
Jiri Kuthan, iptel.org, October 2003
3GPP: Architecture
Alternative
Access
Network
Legacy mobile
signaling
Network
Applications &
Services *)
SCP
Mh
SGSN
GGSN
Mw
CAP
Gn
Other PLMN
Gp
CSCF
R
Um
Iu-ps'
Gi
MGCF
Gi
Gc
GGSN
SGSN
Iu
Mg
MRF
Gf
ERAN
MT
Mr
Gi
EIR
TE
Mm
Cx
HSS *)
Gr
Multimedia
IP Networks
CSCF
R-SGW
Ms
T-SGW *)
Mc
Gi
Gn
Iu1
TE
UTRAN
MT
R
MGW
MGW
Uu
Iu 2
PSTN/
Legacy/External
Nb
Mc
Mc
1
Iu = Iucs (RTP, AAL2)
Nc
MSC server
2
Iu = Iu(RANAP)
GMSC server
MAP
MAP
Applications
& Services
Mh
HSS
Signalling Interface
Signalling and Data Transfer Interface
Jiri Kuthan, iptel.org, October 2003
R-SGW
T-SGW
Technology: Complementary Protocols
ENUM….
• That’s all just fine but how do the 200 million PSTN callers find
SIP callees? They really can’t type in a SIP address like
sip:jiri@iptel.org!
iptel.org
+49-30-3463-8271
?
FWD
sipphone
• Idea: provide a number-2-SIP-address mapping using DNS:
“ENUM”. E.g.: +49-30-3463-8271=> 8271@iptel.org.
Jiri Kuthan, iptel.org, October 2003
Performance Concerns
• New applications, like presence, are very talkative
– Presence status updates are a frequent fan: all members of buddy list
are sent an update when keyboard idle
• Broken or misconfigured devices account for a fair part of
load; few of many real-world observations:
– Broken digest clients resend wrong credentials in an infinite loop 
heavy flood
– Mis-configured password: a phone attempted to re-register every ten
minutes (factor 6) 2400 messages a day
– Mis-configured Expires=30 (factor 120)
– Keeping NAT bindings up – SIP request each 20 seconds
• Replication, Boot avalanches
Jiri Kuthan, iptel.org, October 2003
Download