2003-10-i2-kuthan-sipser.ppt
Upcoming SlideShare
Loading in...5
×
 

2003-10-i2-kuthan-sipser.ppt

on

  • 2,252 views

 

Statistics

Views

Total Views
2,252
Views on SlideShare
2,251
Embed Views
1

Actions

Likes
0
Downloads
35
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Who sends COMET here?

2003-10-i2-kuthan-sipser.ppt 2003-10-i2-kuthan-sipser.ppt Presentation Transcript

  • 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/.
  • Acknowledgement s
    • 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 SIP-based multimedia services including messaging and streaming in a seamless manner to roaming users in NGN.
    • For more information see
    • evolute.intranet.gr
  • 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
  • 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-e-mail
      • 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
    Motivation: Applications
  • Example: Web Integration, Missed Calls/Click-to-Dial Click To Dial Motivation: Applications
  • Scenario: Internet Telephony Providers
    • Borderless customer base: Services available anywhere on the public Internet to subscribers very much like E-mail.
    • Low CAPEX and OPEX.
    • PSTN connectivity typically offered as an extra option; (example: deltathree charges <$.1 per US2UK minute and $11 a month for a US 800 number)
    • Freebies: FWD, PCH, iptel SipPhone.
    • PSTN-termination: deltathree, packet8, Vonage
    Motivation: Scenarios IP Telephony Users With Softphones and Hardphones Provider’s SIP Server keeps track of users and Powers services Gateways Terminate And Initate Calls in PSTN
  • Scenario: Use In Enterprises
    • Services available to all company’s users, on-site, off-site and multi-site – toll bypass.
    • No telephone line required for home-workers and remote offices.
    • Single infrastructure for data and voice.
    • Effectiveness tools.
    • Service operation can be outsourced in a Centrex-like manner (MCI Advantage). Like with web/email, single server may host multiple domains.
    Motivation: Scenarios RIPE Meeting DSL T1 E1 WaveLAN PSTN
  • How Much in 2003?
    • Very little! With IP infrastructure, a host and a skilled administrator already in place, PC-to-PC telephony is free:
      • Softphones Free (Windows Messenger, X-Lite)
      • Servers available freely (SIP Express Router)
    • Your grandma does not want to talk through a PC? 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.
    • $0
    • N x $65
    • $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.
    Motivation: Affordability
  • 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 start-ups (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 [email_address] sip:jiri@ 195.37.78.173 Proxy
    • 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
    Technology: SIP INVITE sip:jiri@ 195.37.78.173 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org Call-ID: 345678@sip.com #2 DNS SRV Query ? iptel.org #0 Reply: IP Address of iptel.org SIP Server INVITE sip:jiri@iptel.org From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org Call-ID: 345678@sip.com #1 OK 200 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org;tag=34 Call-ID: 345678@sip.com #3 OK 200 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org;tag=34 Call-ID: 345678@sip.com #4 Media streams #5
  • Basic Server Element: SIP 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/
    Technology: SIP proxy IP Phone Pool PSTN Gateway SMS Gateway Applications Other domains
  • 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: SIP
  •  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).
    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.
    Technology: Concern Stack
  •  Concern: SIP Routing
    • Flexible signaling among a variety of components by proxy is good for service creation, but how do you define proper routing?
    Applications Technology: Concern Stack User Online? INVITE request? yes no Report Missed Call yes SIP: 404 Not Found SIP: forward request Done no Begin
    • Iptel’s answer: routing language that allows precise definition of server behaviour.
  •  Application Programming
    • 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
    Technical Status <a href=&quot; http:// fwd.pulver.com/callme.php &quot;> <img src= http:// fwd.pulver.com/myicon.php?userid = nnnnn border=1 alt=&quot;FWD Status&quot;> </a>
  •  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…
    Technical Status
  •  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”).
  • 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.
  • SIP Tutorial
  • 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 5 th 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
    • SIPPING: Future SIP extensions and related issues
    • ENUM: integration of E.164 numbering with Internet services
    • SIMPLE: SIP for Instant Messaging
    • IPTEL: Internet Telephony
    • AVT: Audio Video Transport
    • QoS Related: DiffServ, IntServ, RSVP
    • PSTN legacy: SigTran, Megaco
    • and Presence Leveraging
    • interaction of PSTN and IP services: PINT,SPIRITS
    • MMUSIC: Multiparty Multimedia Session Control
    • MIDCOM: Firewall/NAT Traversal
  • 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.
  • 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 real-time
      • RTP – protocol for transmitting real-time data such as audio, video and games
    • End-to-end delivery: underlying IP connects the whole world
  • Supporting Protocols: How Do I ...
    • … find domain of called party? Like with email, use DNS to resolve address of server responsible for [email_address] !
    • … authenticate users and generate Call Detail Records? De-facto 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.
    Technology: Complementary Protocols
  • Protocol Zoo (Hourglass Model) UDP SCTP TCP DNS SIP RADIUS AALx GPRS V.x SONET Ethernet ATM PPP IPv4/IPv6 HTTP RTP STUN WWW signaling interdomain AAA media NAT TLS iLBC, G.711, ... ENUM
  • Packetized Communication End Users Call Server End Users IP Router Signaling Protocol Media Transport
    • 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
  • 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!
  • SIP Registrar Location Database SIP Registrar (domain iptel.org) REGISTER sip:iptel.org SIP/2.0 From: sip:jiri@iptel.org To: sip:jiri@iptel.org Contact: <sip:195.37.78.173> Expires: 3600 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. #1 Jiri @ 195.37.78.173 #2 SIP/2.0 200 OK #3
  • Basic SIP Call-Flow (Proxy Mode) [email_address] sip:jiri@ 195.37.78.173 Location Database Proxy SIP Proxy looks up next hops for requests to served users in location database and forwards the requests there. INVITE sip:jiri@ 195.37.78.173 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org Call-ID: 345678@sip.com #4 DNS SRV Query ? iptel.org #0 Reply: IP Address of iptel.org SIP Server INVITE sip:jiri@iptel.org From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org Call-ID: 345678@sip.com #1 jiri@ 195.37.78.173 #3 jiri #2 OK 200 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org;tag=34 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 #6 ACK sip:jiri@ 195.37.78.173 #7 Media streams #8
  • 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.
  • Service composition: Added-value Server Chains #1 #4 Caller’s outbound proxy accomplishes firewall traversal. Destination’s “ first-hit proxy” identifies a proxy serving dialed area. #3 Proxy in the target area distributes load in a gateway farm. #2 Note: signaling (in red) may take a completely different path from media (in blue). Caller’s administrative domain Administrative domain of a PSTN gateway operator pstn.com asia.pstn.com gw01.asia.pstn.com
  • 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
  • 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
  • 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
  • “Stateful” Proxy Refers to Transactions
    • 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!
    INVITE [email_address] SIP state forgotten as soon as transaction over Legend SIP signaling SIP state media OK Frequently Misunderstood Issue
  • Subsequent Transactions Bypass Proxy
    • Unless route recording is used, subsequent transactions (e.g., BYE) take a direct path to destination as indicated in Contact : header field.
    • Today’s common practice is to turn record-routing ALWAYS on to deal with devices that speak different transport protocols and need a mediator in-between them.
    OK Contact: sip:jiri@195.3.4.9 Frequently Misunderstood Issue BYE takes direct path INVITE
  • SIP Message Structure
    • INVITE sip:UserB@there.com SIP/2.0
    • Via : SIP/2.0/UDP here.com:5060
    • From : BigGuy <sip:UserA@here.com>;tag=123
    • To : LittleGuy <sip:UserB@there.com>
    • Call-ID : 12345600@here.com
    • CSeq : 1 INVITE
    • Subject: Happy Christmas
    • Contact : BigGuy <sip:UserA@here.com>
    • Content-Type : application/sdp
    • Content-Length : 147
    Response SIP/2.0 200 OK Via : SIP/2.0/UDP here.com:5060 From : BigGuy <sip:UserA@here.com>;tag=123 To : LittleGuy <sip:UserB@there.com>;tag=65a35 Call-ID : 12345600@here.com CSeq : 1 INVITE Subject: Happy Christmas Contact : LittleGuy <sip:UserB@there.com> Content-Type : application/sdp Content-Length : 134 Request SDP (RFC2327): “receive RTP G.711-encoded audio at 100.101.102.103:49172” 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 Message Header Fields Payload
  • SIP Addresses
    • SIP gives you a globally reachable address.
      • Callees bind their temporary address to the global one using SIP REGISTER method.
      • Callers use this address to establish real-time communication with callees.
    • URLs used as address data format; examples:
      • sip:jiri@iptel.org
      • sip:voicemail@iptel.org?subject=callme
      • sip:sales@hotel.xy; geo.position:=48.54_-123.84_120
    • must include host, may include user name, port number, parameters (e.g., transport), etc.
    • may be embedded in Webpages, email signatures, printed on your business card, etc.
    • address space unlimited
    • non-SIP URLs can be used as well (mailto:, http:, ...)
  • SIP RFC3261 Methods
    • INVITE initiates sessions
      • session description included in message body
      • re-INVITEs used to change session state
    • ACK confirms session establishment
      • can only be used with INVITE
    • CANCEL cancels a pending INVITE
    • BYE terminates sessions
    • REGISTER binds a permanent address to current location; may convey user data (CPL scripts)
    • OPTIONS capability inquiry
  • SIP Extension Methods
    • SUBSCRIBE/ instant messaging and presence
    • NOTIFY/ (RFC3265, RFC3428, draft-ietf-simple-*)
    • MESSAGE
    • REFER call transfer (RFC3515)
    • PRACK provisional reliable responses acknowledgement (RFC3262)
    • INFO mid-call signaling (RFC 2976)
  • SIP Response Codes
    • Borrowed from HTTP: xyz explanatory text
    • Receivers need to understand response class (“x”)
    • x80 and higher codes avoid conflicts with future HTTP response codes
    • 1yz Informational
      • 100 Trying
      • 180 Ringing (ringing tone played locally)
      • 181 Call is Being Forwarded
    • 2yz Success
      • 200 ok
    • 3yz Redirection
      • 300 Multiple Choices
      • 301 Moved Permanently
      • 302 Moved Temporarily
  • SIP 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
  • Summary of SIP Properties
    • Textual (HTTP-like) client-server protocol
      • Easy to debug, extend and process with textual operating systems
    • End-2-end
      • It puts most of intelligence into end-devices (“user agents”) – good for scalability and extensibility
      • The network infrastructure designed to be leight-weighted. Network functionality (registrar, proxy) are typically logical parts of a single server.
    • Internet addressing using URIs
      • E.g., sip:jiri@iptel.org
      • Non-SIP URIs possible to (e.g., they may be used to redirect a caller to webpage)
      • Address space unlimited and may be used to create services ( sip:sales@hotel.xy; geo.position:=48.54_-123.84_120)
    • It delivers mobility: User can register from one or more locations with IP connectivity
  • SIP Service Space
  • 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.)
  • Example Convenience Services
    • Applications demanded and deployed are mostly about service integration:
      • E-mail: replacement of IVR annoyance with voicemail-2-e-mail
      • Web: read list of missed calls from your webpage (both off-line and on-line)
      • Web: online phonebook, click-to-dial
      • Instant Messaging and Presence, Notification services (T-storm alarm), SMS delivery
      • Telephony: conferencing
    • Technical challenge: make service programming easy
  • 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.
  • Example: Call Transfer Call Flow B timeline 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). A C REFER B To: B Refer-To: C Referred-By: A #1 202 Accept #2 #3 INVITE C Referred-By: A #4 200 OK NOTIFY (OK) #6 200 OK #7 200 ACK #5 media
  • 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
    draft-ietf-sip-cc-transfer, RFC3515
  • 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”);
  • 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
  • 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. RFC3428
  • 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
    RFC3265
  • Subscribe-Notify For Presence Services #3 NOTIFY alice Event: presence #4 OK Step II: subscriber is immediately notified on current condition subscriber Presence server draft-ietf-simple-presence #1 SUBSCRIBE joe Event: presence Contact: alice #2 202 Accepted Step I: subscription to a condition #5 REGISTER joe #6 OK Step III: event occurs Step IV: subscriber is notified whenever condition changes #7 NOTIFY alice Event: presence #8 OK
  • Service Programming
  • 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.
  • Service Execution Layering SIP Java Servlets SIP-CGI CPL SIP Messages SIP Actions Protocol stack Interpreters User Code Servlets CGI Scripts (Perl, Python, C, …) CPL scripts
  • Call Processing Logic Example #1 INVITE jku #2 pass invitation to call processing logic #3 return an action #4a INVITE jku@cell #4b INVITE voicemail@trash #5 The call processing logic may be designed using various mechanisms: CPL, SIP-CGI, 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
  • 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
  • Service Location Examples Source: H. Schulzrinne: “Industrial Strength IP Telephony”
  • 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”, March 2000.
  • 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.
    RFC 3050
  • 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> <sip-version>
      • Set cookie for subsequent messages: CGI-SET-COOKIE <token> <sip-version>
      • Determine if the script should be called for the next message belonging to the same transaction: CGI-AGAIN (&quot;yes&quot; | &quot;no&quot;) <sip-version>
  • 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, ...
    draft-ietf-iptel-cpl
  • CPL Example
    • <incoming>
    • <address-switch field=&quot;origin&quot; subfield=&quot;host&quot;>
    • <address subdomain-of=&quot;example.com&quot;>
    • <location url=&quot;sip:jones@example.com&quot;>
    • <proxy timeout=&quot;10&quot;>
    • <busy> <sub ref=&quot;voicemail&quot; /> </busy>
    • <noanswer> <sub ref=&quot;voicemail&quot; /> </noanswer>
    • <failure> <sub ref=&quot;voicemail&quot; /> </failure>
    • </proxy>
    • </location>
    • </address>
    • <otherwise>
    • <sub ref=&quot;voicemail&quot; />
    • </otherwise>
    • </address-switch>
    • </incoming>
  • Example: Creating CPL Scripts iptel.org: CPL Composer
  • SIP Express Router (SER)
  • 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, …)
  • 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, 100BCE-44BCE)
      • 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.”
  • 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.
  • 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.
  • Our Proposal: Use ASCII Interface Connected via a FIFO Pipe
    • Design idea:
      • 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
    SMS gateway user location digest authentication Plug-in modules with exported features In addition to its normal SIP operation, SIP Server acts as “application rendez-vous point” Weather notification Web provisioning Server health watching FIFO interface
  • Example: Contact Maintenance Web application can show, add and delete user contacts stored in server’s memory.
  • 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
    Request pipe Response pipe :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) 200 OK # (status code) SIP Server
  • Example: Use of FIFO from Web/PHP
    • Appending a contact from a PHP script
    • /* construct FIFO command */
    • $fifo_cmd=&quot;:ul_add:&quot;.$config->reply_fifo_filename.&quot; &quot;.
    • $config->ul_table.&quot; &quot;. //table
    • $user_id.&quot; &quot;. //username
    • $sip_address.&quot; &quot;. //contact
    • $expires.&quot; &quot;. //expires
    • $config->ul_priority.&quot; &quot;; //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
  • 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 command-line 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 [ &quot;$ speed &quot; -gt &quot;$ max_speed &quot; ]
    • 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
  • 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”, March 2000.
  • 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:
      • Routing flexibility – how to determine right destination for a request
      • Troubleshooting when routing failures occur
    SIP proxy IP Phone Pool PSTN Gateway SMS Gateway 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.
  • Routing Language
    • SER Routing Language
    • /* user online ? */
    • if (lookup(“location”)) {
    • t_relay();
    • break;
    • };
    • if (method==“INVITE”) {
    • /* report to syslog */
    • log(“ACC: missed call ”);
    • };
    • sl_send_reply(“404”,”Not Found”);
    • Request routing flexibility needed to link SIP components (voicemail, PSTN gateway, logging facility, etc.) together
    • Answer: request routing language (features conditions, URI-rewriting, request modification, replying, etc.)
    • Example: reporting missed calls
    User Online? INVITE request? yes no Report Missed Call yes SIP: 404 Not Found SIP: forward request Done no Begin
  • 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.
  • 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;
    • }
    • }
  • 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)
    • # 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 MAILTO=`user2email $SIP_USER ` printf “User %s called” “ $SIP_HF_FROM ” | mail –s “Missed Call” $MAILTO INVITE 2 2 404
  • BCP
  • Interworking with PSTN
  • 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.
  • 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.
    Internet PSTN
    • Gateway market established: Cisco, Ericsson, Lucent. Sonus, Vegastream, etc. Open-source as well.
  • Call Flow SIP to PSTN
    • 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.) ISDN/ISUP: RFC 3398 QSIG: draft-ietf-sipping-qsig2sip
  • 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.
  • 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 from call processing logic residing at a proxy.
    • Gateway operator != proxy operator.
    SIP Proxy & Registrar sipforfree.com.au [email_address] PSTN Gateway na.pstn.com SIP media 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(); Frequently Misunderstood Issue
  • Gateways Ship Today, What Is the Problem Then? Integration!
    • Identity: [email_address] 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.
  • CLID
    • Typical deployment problem: [email_address] (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.
    draft-ietf-sip-privacy
  • Remote Party ID User ID/phone number database +49-179-123123 a INVITE sip:1234@gw.com From: sip:a@bc.de;tag=12 To: sip:1234@gw.com INVITE sip:1234@gw.com From: sip:a@bc.de;tag=12 To: sip:1234@gw.com Remote-Party-ID: <sip:+49179123123@gw.com> Proxy Server with CLID support PSTN gateway PSTN
  • 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?
  • 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.
  • TLS Use for Interdomain Security Internet PSTN Originating domain Public Internet Terminating Domain With Local Trust #1 #2
    • 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 forwarded to PSTN gateway.
    TLS
  • 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,
  • 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).
    RFC2833
  • Overlapped Dialing
    • Problem: ingress PSTN2IP gateway operates in overlapped dialing mode whereas SIP operates en-block;
    • 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
    RFC3578
  • 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 e-mail, 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
    RFC2916
  • ENUM Call Flow DNS/ ENUM INVITE sip:jiri@iptel.org Gateway with ENUM resolution PSTN: +4917… ?...7.1.9.4.e164.arpa ! sip:jiri@iptel.org
    • 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
  • 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?
  • 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-ietf-sipping-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-sipping-qsig2sip]
  • Security Security, Reliability, Performance, Accounting
  • 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)
  • Disclaimer: Security Protocols Don’t Implement Social Engineering SIP INVITE w/JPEG 200 OK 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 ... SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:UserA@here.com> To: LittleGuy <sip:UserB@there.com> Call-ID: 12345601@here.com...
  • SIP 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
    Proxy 1. REGISTER RFC 2617 3. REGISTER w/credentials
    • Request w/o credentials
    • Challenge: authenticate yourself
    • Request resubmitted w/credentials
    2. 407 Challenge (nonce,realm) 4. OK
  • 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=&quot; gh &quot;, realm=“bc.de&quot;, algorithm=&quot;md5&quot;, uri=&quot;sip:bc.de&quot;, nonce=&quot;3edab81b7a8427be362c2a924f3171d215a8f7d3&quot;, response=&quot;4a868f9cbffd2b1f39c778abca78f75b&quot;.
    • 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
  • Reliability
  • 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.
    RFC 3263
  • 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 ...
  • AAA
  • 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.
  • 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
  • Firewall/NAT Traversal
  • 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 )
  • 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
  • Where FWs/NATs affect SIP
    • Contact, Route, Record-Route header fields
    • Via header fields (received tag)
    • SDP payload
    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 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
  • 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.)
  • 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).
  • … 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
  • NAT Practices: Overview *… does not work for symmetric NATs + … port translation must be configurable o … application-awareness affects scalability Ltd. ok N/A No N/A Symmetric NATs? Big  Ok Ltd. (+) Yes N/A Manual poor  Ok Ok ? (o) Scalability Small Small Small Small User Effort No Yes Ltd. (*) Yes NAT support needed? Yes Yes Yes No Phone support needed? Maybe N/A Ltd. (*) N/A Works over ISP’s NATs? Relay UPnP STUN ALG
  • 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
  • QoS
  • 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)
    RFC3312
  • SIP and QoS Control [email_address] [email_address] Proxy INVITE sip:Callee@10.0.0.1 PRACK/OK INVITE sip:Callee@example.com m=audio 49170 RTP/AVP 0 a=curr: qos e2e none a=des:qos mandatory e2e sendrecv UPDATE/OK UPDATE sip:Callee@10.0.0.1 a=curr: qos e2e send At step #6, path is reserved and callee’s phone can begin ringing. Then, SIP completes as usual (180 confirmed by PRACK, 200 sent when callee answers, media exchange begins.) 183 Progress m=audio 49170 RTP/AVP 0 a=curr: qos e2e none a=des: qos mandatory e2e sendrecv #2 #3 #1 #4 Reserve #5 #6 180 Ringing
  • Record-Routing
  • 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
  • Record-Routing Example INVITE sip:jiri@iptel.org From: joe@abc.com;tag=12 Contact: <sip:joe@1.2.3.4> INVITE sip:jiri@iptel.org From: joe@abc.com;tag=12 Record-route: <sip:rr@1.2.3.4;lr> BYE sip:joe@abc.com From: joe@abc.com;tag=12 Route: <sip:rr@1.2.3.4;lr> BYE sip:joe@abc.com From: joe@abc.com;tag =12 Route: <sip:rr@1.2.3.4;lr>
  • Record-Routing Apps
    • Record-Routing can be also use to piggy-back session-state in SIP messages to leave server state-less
    • 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
    • The End –
  • Information Resources
  • Information Resources
    • Author: [email_address]
    • 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/
  • 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
  • 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
  • Backup
  • 3GPP: Architecture
  • ENUM….
    • That’s all just fine but how do the 200 million PSTN caller s find SIP callees ? They really can’t type in a SIP address like sip:jiri@iptel.org!
    Technology: Complementary Protocols +49-30-3463-8271 iptel.org FWD sipphone ?
    • Idea: provide a number-2-SIP-address mapping using DNS: “ENUM”. E.g.: +49-30-3463-8271=> 8271@iptel.org.
  • 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