• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

SIP and SER: More Than You Ever Wanted To Know About

on

  • 6,697 views

 

Statistics

Views

Total Views
6,697
Views on SlideShare
6,697
Embed Views
0

Actions

Likes
0
Downloads
66
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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

    SIP and SER: More Than You Ever Wanted To Know About SIP and SER: More Than You Ever Wanted To Know About 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/. 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 SIP- based 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) 1:30-3:00 pm – on demand – Motivation program … prepare tough • About Internet Telephony questions!!! Application Space • Usage Scenarios for SIP • (Demonstration?) • Feasibility Check: How • SIP Tutorial Much Does It Cost? – IETF/History – Technology: – Services • SIP Refresher – IM/Presence • Concern Stack – Programming • SER (11:00-12:00) • BCP – Routing language – PSTN gatways, security, – Programming 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-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 Jiri Kuthan, iptel.org, October 2003
    • Motivation: Applications Example: Web Integration, Missed Calls/Click-to-Dial Click To Dial Jiri Kuthan, iptel.org, October 2003
    • Motivation: Scenarios Scenario: Internet Telephony Providers • Borderless customer base: Services available anywhere on the public Internet to subscribers very much like E- IP Telephony Users mail. With Softphones and • Low CAPEX and OPEX. Hardphones • PSTN connectivity typically offered as an extra option; Provider’s SIP Server (example: deltathree charges keeps track of users and <$.1 per US2UK minute 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 • Services available to all company’s users, on-site, off- RIPE Meeting site and multi-site – toll bypass. E1 • No telephone line required for home-workers and remote offices. WaveLAN • Single infrastructure for data and voice. T1 DSL • 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 • $0 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 • N x $65 PC? Buy her a hardphone. A freebie SIP site (sipphone.com) ships a pair for $129.99. • Gateway for PSTN connectivity? Commercial • $2500 T1/E1 gateways begin at $2500, software for experimental PC-based gateways available on the Internet for free.
    • 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 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 •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 INVITE sip:jiri@iptel.org From: sip:Caller@sip.com;tag=12 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org #2 To: sip: jiri@iptel.org #1 Call-ID: 345678@sip.com Call-ID: 345678@sip.com OK 200 OK 200 #3 #4 From: sip:Caller@sip.com;tag=12 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org;tag=34 Proxy To: sip: jiri@iptel.org;tag=34 Call-ID: 345678@sip.com Call-ID: 345678@sip.com Caller@sip.com sip:jiri@195.37.78.173 Media streams #5 Jiri Kuthan, iptel.org, October 2003
    • Technology: SIP Basic Server Element: SIP Proxy PSTN Gateway SMS Gateway • Proxy servers maintain central role in SIP networks: • They glue SIP components such as phones, gateways, applications and other domains • They provide place for Applications proxy service implementation IP Phone Pool (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 SIP: forward SIP: 404 Applications request Not Found Done
    • Technical Status ! 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 <a href="http://fwd.pulver.com/callme.php"> <img src=http://fwd.pulver.com/myicon.php?userid=nnnn n 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 related issues $PSTN legacy: SigTran, Megaco $ENUM: integration of E.164 $and Presence Leveraging numbering with Internet services $interaction of PSTN and IP $SIMPLE: SIP for Instant services: PINT,SPIRITS Messaging $MMUSIC: Multiparty $IPTEL: Internet Telephony Multimedia Session Control $AVT: Audio Video Transport $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 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 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? 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. Jiri Kuthan, iptel.org, October 2003
    • Protocol Zoo (Hourglass Model) ENUM iLBC, G.711, ... WWW signaling interdomain AAA media NAT HTTP SIP DNS RADIUS RTP STUN TLS TCP SCTP UDP IPv4/IPv6 PPP AALx Ethernet GPRS SONET V.x ATM Jiri Kuthan, iptel.org, October 2003
    • Packetized Communication Signaling Protocol Call Server Media Transport 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 SIP registrar keeps track of Location Database users’ whereabouts. This registration example establishes presence of Jiri @ 195.37.78.173 user with address jiri@iptel.org #2 REGISTER sip:iptel.org SIP/2.0 From: sip:jiri@iptel.org for one hour and binds this To: sip:jiri@iptel.org address to user’s current Contact: <sip:195.37.78.173> #1 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 Mode) to served users in location database and forwards the requests there. Location Database #0 jiri@195.37.78.173 DNS SRV Query ? iptel.org #2 #3 Reply: IP Address of iptel.org SIP Server INVITE sip:jiri@195.37.78.173 jiri INVITE sip:jiri@iptel.org From: sip:Caller@sip.com;tag=12 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org #4 To: sip: jiri@iptel.org #1 Call-ID: 345678@sip.com Call-ID: 345678@sip.com OK 200 OK 200 #5 #6 From: sip:Caller@sip.com;tag=12 From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org;tag=34 Proxy To: sip: jiri@iptel.org;tag=34 Call-ID: 345678@sip.com Call-ID: 345678@sip.com #7 ACK sip:jiri@195.37.78.173 Caller@sip.com sip:jiri@195.37.78.173 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 gw01.asia.pstn.com pstn.com asia.pstn.com #2 #3 #4 #1 Caller’s outbound Destination’s Proxy in the target proxy accomplishes “first-hit proxy” area distributes load firewall traversal. 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 Frequently Misunderstood Transactions Issue SIP state • SIP proxies deliver a “one-time forgotten rendezvous service” (as opposed to state as soon as storage service). transaction over • Thus a stateful proxy just keeps state during a SIP “rendezvous transaction” and completely forgets it afterwards. INVITE • A SIP proxy is not aware of existing a@a.com calls. In case of failure, existing calls are NOT affected! OK • Subsequent transactions may take a direct path! Legend SIP signaling SIP state media Jiri Kuthan, iptel.org, October 2003
    • Subsequent Transactions Bypass Frequently Misunderstood Proxy Issue • Unless route recording is used, subsequent transactions (e.g., BYE) take a direct path to destination as indicated in OK Contact: header field. Contact: • Today’s common practice is to INVITE 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. BYE takes direct path 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 Via: SIP/2.0/UDP here.com:5060 From: BigGuy <sip:UserA@here.com>;tag=123 From: BigGuy <sip:UserA@here.com>;tag=123 To: LittleGuy <sip:UserB@there.com> To: LittleGuy <sip:UserB@there.com>;tag=65a35 Call-ID: 12345600@here.com Message Call-ID: 12345600@here.com CSeq: 1 INVITE Header CSeq: 1 INVITE Subject: Happy Christmas Subject: Happy Christmas Fields Contact: BigGuy <sip:UserA@here.com> Contact: LittleGuy <sip:UserB@there.com> Content-Type: application/sdp Content-Type: application/sdp Content-Length: 147 Content-Length: 134 v=0 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com o=UserB 2890844527 2890844527 IN IP4 there.com s=Session SDP s=Session SDP c=IN IP4 100.101.102.103 c=IN IP4 110.111.112.113 t=0 0 t=0 0 m=audio 49172 RTP/AVP 0 Payload m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000 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-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 Jiri Kuthan, iptel.org, October 2003
    • IN-like Services with SIP • Most of IN services may be • Sometimes, implementation easily implemented with SIP logic may completely differ. in proxies/redirect servers or – Televoting and IVRs likely to be UAs: replaced by Web in the long run. – (Un)conditional call – Call-waiting is end-device forwarding implementation issue with no – abbreviated dialing protocol support. – Screening – Music-on-hold may be played – distinctive ringing localy. – call distribution – call transfer – etc. 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 A is having a call with B. A decides to REFER B B transfer B to C. It sends a “REFER” to To: B B with C’s address. Eventually, A is Refer-To: C #1 notified on successful transfer using Referred-By: A NOTIFY (#6). A #2 202 Accept #3 INVITE C Referred-By: A C #4 200 OK #5 #6 NOTIFY (OK) 200 ACK #7 200 OK media timeline Jiri Kuthan, iptel.org, October 2003
    • 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-simple- Subscribe-Notify presence For Presence Services Step I: subscription to a condition #1 SUBSCRIBE joe Presence server Step III: event occurs Event: presence #5 REGISTER joe Contact: alice #2 202 Accepted #6 OK Step IV: subscriber #4 OK is notified #3 NOTIFY alice whenever Event: presence #7 NOTIFY alice condition Event: presence changes #8 OK subscriber Step II: subscriber is immediately notified on current condition Jiri Kuthan, iptel.org, October 2003
    • 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 CPL scripts CGI Scripts (Perl, Python, Servlets User Code C, …) Java Interpreters SIP-CGI CPL Servlets SIP Messages SIP Actions Protocol stack SIP
    • Call Processing Logic Example The call processing logic may be designed Jku’s call processing using various Jku’s call processing logic: logic: mechanisms: CPL, SIP-CGI, servlet, proprietary ones. If ($caller is in {Jane, Bob}) If ($caller ==Jane) proxy to jku@cell.com play Mozart else proxy to voicemail@trash.com else play Smetana #2 pass invitation #3 return an to call processing action #5 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 End-device Proxy Distinctive Ringing Yes Can assist Visual call id Yes Can assist Call Waiting Yes No CF Busy Yes Yes CF No Answer Yes Yes CF No Device No Yes Location hiding No Yes Transfer Yes No Conference Bridge Yes No Gateway to PSTN Yes No Firewall Control No No Voicemail Yes 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”, March 2000. October 2003 Jiri Kuthan, iptel.org,
    • 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> <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 ("yes" | "no") <sip- version> 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, 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.” 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 Web Server health • Design idea: notification provisioning watching – Export SIP logic to applications through a textual request-response FIFO FIFO interface interface (named pipes) • FIFO server properties In addition to its normal SIP operation, SIP Server acts – Server looks like a file to as “application rendez-vous application – any file-based point” application can use it Plug-in modules with exported features – Excellent portability – Simple and extensible – Application isolation digest user SMS authentication location gateway Jiri Kuthan, iptel.org, October 2003
    • 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 :ul_add:reply PSTN destinations location # (table name) jiri # (username in address of record) • User location module sip:7271@gw.iptel.org # (new contact) exports FIFO action for 3600 # (expiration time) adding new contacts 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."nn"; //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 measure=`./wx200d-1.2/wx200 interface well established in --gust --C` speed=`echo $measure | cut -d -f1 the world of UN*X | sed -e 's/.//' ` applications. if [ "$speed" -gt "$max_speed" ] • Examples: then cat > $SER_FIFO << EOF – cron daemon for scheduled :t_uac_from:null calls MESSAGE – awk for database processing sip:weather@iptel.org – PHP for web applications sip:receiver@iptel.org – shell scripts for command- Content-Type: text/plain line tools Contact: sip:weather@iptel.org – wx2000 for weather forecasts weather alert: Very strong winds in % the area: $speed • Note: . – Applications SIP-unaware EOF – Application code simple 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”, March 2000. October 2003 Jiri Kuthan, iptel.org,
    • SIP Routing • One of primary benefits of SMS Gateway SIP: Ability to link various service components speaking SIP together. PSTN Gateway • The “glue” are signaling servers. Their primary capability is routing requests to appropriate services. Applications SIP proxy IP Phone Pool • Issues: – Routing flexibility – how to determine right destination for a request – Troubleshooting when routing failures occur Other domains Jiri Kuthan, iptel.org, October 2003
    • 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, URI- rewriting, request modification, replying, etc.) • Example: reporting missed calls Begin SER Routing Language no no /* user online ? */ User Online? INVITE request? if (lookup(“location”)) { t_relay(); yes yes break; Report }; Missed Call if (method==“INVITE”) { /* report to syslog */ SIP: forward SIP: 404 log(“ACC: missed calln”); request Not Found }; sl_send_reply(“404”,”Not Found”); Done Kuthan, iptel.org, October 2003 Jiri
    • 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 # SER script: challenge any user accounting, SMS support, # claiming our domain in From header # field; good anti-spam practise; it digest authentication, # uses module actions for RegExp and regular expressions, jabber # digest authentication gateway, presence agent, nat traversal helper, # apply a regular expression multidomain support, etc. if (!search(“From:.*iptel.org”) { (about 40 today). # 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 2 applications on request receipt; (similar to but simpler than SIP INVITE CGI-BIN) 404 • Features: – ability to use existing UN*X # SER script: execute an external tools (mail, sed & awk, # command for off-line users if (!lookup(“location”)) { wget, …) /* log(“missed call”); */ – Language-independency exec_msg(“/tmp/notify.sh”); } • Interface: – Request URI and header fields # shell script: send email 2 passed as environment variables to # notification the applications – Whole request passed on standard MAILTO=`user2email $SIP_USER` input printf “User %s called” “$SIP_HF_FROM” | – Optionally, application’s output mail –s “Missed Call” $MAILTO evaluated as new request’s URI (e.g., unconditional forwarding) 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
    • RFC 3398 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 Jiri Kuthan, iptel.org, October SIP book.) 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 jku@sipforfree.com.au • PSTN gateways are adapters between two different technologies. • From SIP perspective, PSTN gateways are media SIP termination devices, i.e., SIP User Agents just like IP phones. PSTN Gateway • PSTN gateway functionality separate SIP na.pstn.com from call processing logic residing at a proxy. • Gateway operator != proxy operator. call processing logic: If ($destination in PSTN) then route_to_least_cost_gateway(); elseif local(“sipforfree.com.au”) then lookup_registry; Frequently else proxy_to_foreign_domain(); SIP Proxy & Registrar Misunderstood sipforfree.com.au Issue Jiri Kuthan, iptel.org, October 2003
    • 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 User ID/phone number database INVITE sip:1234@gw.com INVITE sip:1234@gw.com From: sip:a@bc.de;tag=12 +49-179-123123 From: sip:a@bc.de;tag=12 To: sip:1234@gw.com To: sip:1234@gw.com a Remote-Party-ID: <sip:+49179123123@gw.com> PSTN Proxy Server with CLID support PSTN gateway Jiri Kuthan, iptel.org, October 2003
    • 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 PSTN #1 #2 TLS Originating domain Public Terminating Domain Internet 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 forwardedJiri Kuthan, iptel.org, October 2003 to PSTN gateway.
    • 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 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 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 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 Jiri Kuthan, iptel.org, October 2003
    • •DNS/ENUM helps ingress gateway to ENUM Call Flow resolve SIP address from E.164 number •Typically, owner of an ENUM entry can manipulate the address DNS/ association through a ENUM web provisioning interface ?...7.1.9.4.e164.arpa ! sip:jiri@iptel.org PSTN: +4917… INVITE sip:jiri@iptel.org Gateway with ENUM resolution Kuthan, iptel.org, October 2003 Jiri
    • More PSTN-Related Reads • Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling to the Session Initiation Protocol [draft- ietf-sipping-overlap] • 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-elwell- sipping- qsig2sip] 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. 1. REGISTER • Protocol: 1. Request w/o – challenge-response using credentials 2. 407 Challenge MD5 (nonce,realm) 2. Challenge: – Based on secret shared authenticate between client and server yourself – No message integrity 3. REGISTER 3. Request provided w/credentials resubmitted 4. OK w/credentials Jiri Kuthan, iptel.org, October 2003 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 • Contact, Route, Record- Via: SIP/2.0/UDP 192.168.99.1:5060 From: BigGuy <sip:UserA@here.com> Route header fields To: LittleGuy <sip:UserB@there.com> Call-ID: 12345600@here.com • Via header fields CSeq: 1 INVITE Subject: Happy Christmas (received tag) Contact: BigGuy <sip:UserA@192.168.99.1> Content-Type: application/sdp Content-Length: 147 • 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 Jiri Kuthan, iptel.org, October 2003
    • NAT Practices: Overview ALG STUN UPnP Manual Relay Works over ISP’s N/A Ltd. (*) N/A N/A Maybe NATs? Symmetric NATs? N/A No N/A ok Ltd. Phone support No Yes Yes Yes Yes needed? NAT support Yes Ltd. (*) Yes Ltd. (+) No needed? Scalability ? (o) Ok Ok Ok poor & User Effort Small Small Small Big & Small *… does not work for symmetric NATs o … application-awareness affects scalability + … port translation must be configurable 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 Proxy Callee@example.com m=audio 49170 RTP/AVP 0 #1 INVITE sip:Callee@10.0.0.1 a=curr: qos e2e none a=des:qos mandatory e2e sendrecv 183 Progress #2 m=audio 49170 RTP/AVP 0 a=curr: qos e2e none a=des: qos mandatory e2e sendrecv #3 PRACK/OK #4 Reserve #5 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 when callee answers, media exchangeOctober 2003 Jiri Kuthan, iptel.org, 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 INVITE sip:jiri@iptel.org From: joe@abc.com;tag=12 From: joe@abc.com;tag=12 Contact: <sip:joe@1.2.3.4> Record-route: <sip:rr@1.2.3.4;lr> BYE sip:joe@abc.com BYE sip:joe@abc.com From: joe@abc.com;tag=12 From: joe@abc.com;tag=12 Route: <sip:rr@1.2.3.4;lr> 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 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 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 • MGCP Media Gateway Control • CDR Call Detail Record Protocol • CGI Common Gateway Interface • OSP Open Settlement Protocol • CPL Call Processing Language • PSTN Public Switched Telephone • DTMF Dual Tone Multi-Frequency Network • ETSI European Telecommunications • QoS Quality of Service Standards Institute • RTCP RTP Control Protocol • IETF Internet Engineering Task Force • RTP Real-Time Transport Protocol • ITSP Internet Telephony Service Providers • RTSP Real-Time Streaming Protocol • ITU International Telecommunication • SDP Session Description Protocol Union • SIP Session Initiation Protocol • IVR Interactive Voice Reponse • SS7 Signaling System Nr. 7 • JAIN Java APIs for Integrated Network • TRIP Telephony Routing over IP Framework • VoIP Voice over IP • LEC Local Exchange Carrier • LNP Local Number Portability • NAT Network Address Translation Jiri Kuthan, iptel.org, October 2003
    • There Are SIP Books! • Alan B. Johnston: “SIP: • Henry Sinnreich, Alan Johnston: Understanding the Session Initiation Internet Communications Using Protocol” SIP: Delivering VoIP and Multimedia Services with Session • Artech House 2001 Initiation Protocol • John Wiley & Sons, 2001 Jiri Kuthan, iptel.org, October 2003
    • Backup Jiri Kuthan, iptel.org, October 2003
    • 3GPP: Architecture Alternative Le gacy mo bile A pplications & signaling A ccess Services *) N etw ork N etw ork SC P M ultim edia CSCF R -SG W IP N etw ork s Mh Mw SG SN Ms G G SN CAP Mm Gn H SS *) Cx O th er PL M N CSCF Gr Mg Gp Gi Mr Gi EIR MRF E RAN Gf TE MT Gc Gi M G CF T -SG W *) R Um Iu-ps' SG SN G G SN Mc Iu Gi Gn Iu 1 PST N / TE MT U T RAN MGW MGW Legacy/External R Uu Nb Iu 2 Mc Mc Iu 1 = Iucs (RT P, A AL2) Nc 2 M SC server G M SC serv er T -SG W Iu = Iu(RAN A P) M AP M AP Mh A pplications & Services H SS R -SG W Signallin g Interfa ce Signallin g a nd D ata T ransfer Interfa ce Jiri Kuthan, iptel.org, October 2003
    • 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