Delta Electronics DNS SIP Series Manual do Utilizador

1The Session Initiation Protocol(SIP)Henning SchulzrinneColumbia University, New [email protected]://www.cs.columbia.edu/˜hgsc1998-2

10SIP architecture: VoIP to PSTN100IPH.248SIPlocation serveroutbound proxysip:1−212−555−1234@domaintel:+1−212−555−1234SLP?, TRIP−GW?sip:12125551234@gw

100Columbia University SIP implementationssipd proxy/redirect server, registrarsipc user agentSIP C++ librarySIP-H.323 gatewaySIP multiparty conferenc

101sipd = SIP registration + redirect serverregistration via unicast and multicastlocation server functionality:1. lists (ug-students@cs), ambiguous n

102SIP server implementationHTTP, SIP, RTSP (+ email) share common format ➠functionality C lines ()generic RFC822-style parser 500HTTP generic headers

103“Active Phone Networks”language:don’t want Turing-complete languagefail safe: make phone calls even if crashespredictable resource consumptionhide

104CPL exampleString-switchfield: frommatch:*@example.comotherwiseproxytimeout: 10slocationurl: sip:[email protected]: clearlocationurl

105Internet phone “appliance”phone = $49.95; PC $600 (GPF included)Ethernet phone ➠ no PBX for switchingexamples (not all SIP yet): 3Com/S4, Columbia

106Columbia e*phoneDSP for voice coding and signaling ➠ limited memory (e*phone: 512 kBSRAM)only need minimal IP stack (IP/UDP/RTP, DHCP, SIP, tftp, D

107Columbia e*phone

108SIP Services

109SIP servicesbuddy lists and notificationsproxy and fanoutIN servicesMCUs and “multi-unicast”

11SIP architecture: PSTN to VoIP100IPINVITE sip:[email protected]:[email protected] database

110Signaling event notificationcallqueueing...buddy lists ...eventnotificationalso: message waiting, pickup group, ACDSUBSCRIBE to events (e.g., message

111SIP “fan-out”proxy server may issue several requeste.g., all known login locationswaits for definitive response ( )3xx (redirect) code: possibly rec

112Branching requestsSearch for callee in several places:21332200 (H1)200 (H2)ACK U@H2response (Location)200 (H1)200 (H2) 200 (H2)482200 (H1)BYE U@H1r

113Parallel search with CANCELUASproxy server100 TryingUACUASINVITE bob@portalbob@portal180 Ringing200 OKalicebob@home bob@workCANCEL bob@workACK bob@

114Sequential searchINVITE [email protected] serverUACACKieee.orgINVITE alice100 Trying100 Trying486 Busy HereACKINVITE bob180 Ringing200 OKUAS UASa

115IN call forwarding featuresSIP can implement intelligent network features:name feature SIP noteSCF selective call forwarding 302, ContactSCR select

116IN call handling featuresname description SIP notesCW call waiting not: call pres.(A)CB call back email, log fileICS incoming call screening end sys

117SIP advanced servicesAlso for third-party control: A asks B to send request to Calternative: TRANSFER request (in progress)generic establishment of

118Building advanced servicesConstruct from element behavior, not feature descriptions:request URL: next resolution stageFrom: logical call sourceTo:

119Building advanced services: rulesSIP responses go to requestorINVITE establishes single data associationdon’t ring for new additional participant i

12SIP: basic operation1. use directory service (e.g., LDAP) to map name to user@domain2. locate SIP servers using DNS SRV, CNAME or A RR3. called serv

120Multipoint Control Units (MCUs)URL = conference-id@mcu-hostcall in: new participant invites MCUcall out: MCU invites participants

121Meshmulticast not always availableeasier for adding third party to callfull mesh of all participantsif wants to add party , invite with list of oth

122MeshINVITEAlso: A,B321session2BYEAlso: B1ABCDABBACDCD

123MCUs: transition from mesh to MCUtransition from mesh to MCUReplaces =“inverse”Alsoask recipient to delete calls with named partiesrecipient sends

124SIP user locationlocal multicast of invitationlogin-based via NFSrecursive “finger”-traversalname translation: Alexan-der.G.Bell ➠ agblist aliasesac

125Interaction with directory servicesLDAP (with dynamic extensions)rwhoiswhois++ (RFC 1913)possibly implement SIP interface ➠ simpler clients

126Automatic call distribution (ACD)caller connects to server for company, indicates language, subject,organization, urgency, . . .alternatives:– prox

127Hold➠ temporarily disable media deliverymulticast: use RTCP “interest indication”thus, unicast onlysend INVITE with SDP port number = 0 for mediamu

128Camp-on serviceChoices:1. callee indicates time to call back2. “polling”: caller issues repeated INVITE3. caller indicates desire to wait:C->S:

129Outgoing call handlingThree-party setups:secretary dials for bossauto-dialer hands call to telemarketerattended call transferoperator services➠ tre

13SIP–DNS interactionextended email-like domain resolution ➠ try until success:1. try SRV DNS record for “sip. udp” and “ sip. tcp” in domain, withpri

130Outgoing call handling: telemarketing51customerauto-dialertelemarketerACT342(C)INVITE(Also:)BYE(Also:)

131SIP and H.323

132SIP – H.323 ComparisonH.323 SIPArchitecture stack elementOrigin ITU IETFConference control yes noProtocol mostly TCP mostly UDPEncoding ASN.1, Q.93

133SIP and H.323 elementsH.323 SIP + SDPH.225.0 + RAS SIPH.245 SDP, SMIL, . . .gatekeeper proxy

134H.323 Resource Reservationlocal admission decisionprior to call setup no information about bandwidth availableworks only for “yellow cable Ethernet

135SIP vs. H.323: Call SetupH.323v1: several TCP connections (H.245, Q.931) very long latency(6.5-8 RTTs), particularly with packet loss; currently in

136H.323v3 call setupcaller calleeport 1720, 13002 dynamic portsRASgatekeeperaudioSETUPCALL PROCEEDINGCONNECTALERTING

137ServicesService H.323 SIPCall transfer H.450.2 “30x”Call diversion H.450.3 “30x”Call hold H.450.4 SDP-basedCall park H.450.5 REGISTERCall waiting H

138H.323 vs. SIP: Basic Call Control(modified from Dalgic and Fang, Comparison of H.323 and SIP)Service H.323v1 v2 v3 SIPCall holding no yes yes yesCal

139H.323 vs. SIP: Advanced FeaturesService H.323v1 v2 v3 SIPThird party control no no no yesConference yes yes yes yesClick-to-dial ? ? ? PINTCapabili

14SIP operation in proxy mode10media [email protected]@[email protected] OKlocat

140H.323 vs. SIP: Quality of ServiceH.323v1 v2 v3 SIPCall setup delay 6-7 RTT 3-4 1.5-2.5 1.5Loss recovery TCP TCP better betterFault detection yes ye

141H.323 vs. SIP: ManageabilityH.323v1 v2 v3 SIPAdmission control yes yes yes no (RSVP)Policy control yes yes yes ob proxyResource reservation local l

142H.323 vs. SIP: ScalabilityH.323v1 v2 v3 SIPComplexity more more more+ lessServer processing SF SF SF/SL, TSF SL, TSF/TSLInter-server no no yes yesT

143H.323 vs. SIP: FlexibilityH.323v1 v2 v3 SIPTransport protocols TCP TCP TCP/UDP anyExtensibility unlabeled vendor extensions IANA, labeledCustomizat

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

145Overviewpure-IP mobility IP over GSM, 3G, . . .SIPmobile applicationsmobile IP issues for Internet telephonymobility support using SIPperformancefu

146Mobility in an IP environmentTerminal mobility: terminal moves between subnetsPersonal mobility: different terminals, same addressService mobility:

147Terminal mobilitydomain of IEEE 802.11, 3GPP, mobile IP, . . .main problems in some versions:– handover performance– handover failure due to lack o

148Personal mobilitytel:[email protected]:[email protected]@[email protected]@columbia.ed

149Personal mobilityswitch between PDA, cell phone, PC, Ethernet phone, Internet appliance,...several “generic” addresses, one person/function, many t

15SIP operation in redirect mode14326785?henningACK [email protected] [email protected] Moved temporarilycolumbia.edulocationservercolumbia.edu

150– need dialing plan to recognize [email protected] andtel:2129397042 as same

151Visiting a remote networkregister locally (multicast, DHCP) andregister at home

152Hotel CaliforniaContact: sip:128.59.16.1From: [email protected]: [email protected]: [email protected]: [email protected] sip:home.comREGIST

153Getting home servicesmay want to use home services – e.g., lawyer per-client billing, third-partyauthenticationUA can add Route header to force out

154Service mobilityExamples:speed dial & address bookmedia preferencesspecial feature buttons (voice mail, do-not-disturb)incoming call handling i

155Service mobilityREGISTER can retrieve configuration information (e.g., speed dialsettings, distinctive ringing or voice mail settings)but needs to b

156speech recognition, . . .One device, but changing set of owners!

157Service mobility – call handlingneed uniform basic service description model Call ProcessingLanguage (CPL)CPL = XML-based flow graph for inbound &am

158Terminal mobility – detailsmove to new network ➠ IPaddress changes (DHCP)mobile IP hides addresschangesbut: little deploymentencapsulation overhead

159Aside: Where is Mobile IP Needed?Not needed if short-lived, restartable client-server connections:http short, statelesssmtp short, restartablepop,

16Basic SIP call(h.a.com, port 49170)AliceBob(g.b.org, port 3456)INVITE sip:[email protected] SIP/2.0From: Alice <sip:[email protected]>To: Bob <sip:bob@b.

160Requirements for VoIP Mobilityfast hand-off, preferably without network support:– voice packet every 20–50 ms– FEC can recover 2–3 packetslow packe

161Mobile IP Issuesencapsulationdog-legged routingbinding updates stillthrough HAmay fail with IP address fil-tersstack/infrastructurechangesCNCHHAFAtu

162SIP Mobility Overviewdesigned for personal mobility, but boundary to terminal mobility fluidpre-call mobility ➠ SIP proxy, redirectmid-call mobility

163SIP mobility: pre-callMH acquires IP address viaDHCPoptional: MH finds SIPserver via multicast REG-ISTERMH updates home SIPserveroptimization: hiera

164SIP Mobility: Mid-callMH CH: new INVITE, with Contact and updated SDPCH132foreignnetworkhomemobile hostcorrespondent hostSIP redirect serverMHCHred

165SIP Mobility: Multi-stage RegistrationDon’t want to bother home registrar with each moveContact: alice@CAFrom: alice@NYContact: 193.1.1.1REGISTERIN

166802.11 Movement Detection: Ad-Hoc Modeno “access point” ➠ regular station as BSBS serves as default routerperiodic multicast beaconpick best: drive

167802.11 Movement Detection: Infrastructure Modeaccess point (AP) for BSSattachment handled by MAC layer, invisible to applicationBSSID is contained

168Handoff Performancehandoff interval200INVITEDiscoverOfferbeacon intervalbeaconRequestAckMH DHCPBS CH

169Open Issueshandoff performance in a loaded networksoft hand-off: IP-level vs. application proxiessoft hand-off for 802.11 infrastructure mode possi

17SIP operation in redirect modeUAC redirect [email protected] TryingINVITE [email protected] Moved temporarilyACKINVITE a12@columb

170Conclusionmobile telephony = most common mobile applicationall-IP network: can’t punt hand-offterminal mobility as special case of personal mobilit

171Programming SIP Services

172Programming SIP servicessafety language? party?SIP-cgi same as scripting any calleeservlets same as Java Java calleeCPL very XML bothapplets same a

173Programming services“caller proposes, callee disposes, administrator decides”web = static pages cgi-bin Java“if somebody is trying to call for the

174cgi-bin for SIP Serversextend SIP user/proxy/redirect server functionality without changingserver softwareserver manages retransmission, loop detec

175ExamplesCall forward on busy/no an-swerAdministrative screening (fire-wall)Central phone serverIntelligent user locationThird-party registration con

176cgi Script Functionalitycalled for any method except ACK or CANCELproxying of requestsreturning responsesgenerate new requestsonce for each request

177cgi Script Mechanismenvironment variables: headers, methods, authenticated user, . ..stdin: body of requeststdout: new request, meta-requests:CGI-

178Cgi Example: Call Forwardinguse DB_File;sub fail {my($status, $reason) = @_;print "SIP/2.0 $status $reason\n\n";exit 0;}tie %addresses, ’

179$destination = $addresses{$to};if (! defined( $destination )) {fail("404", "No such user");}print "CGI-PROXY-REQUEST-TO $d

18SIP – more detailINVITE sip:[email protected]: sip:[email protected]/2.0 180 RingingContact: sip:[email protected]/2.0 302 Move

180The Call Processing LanguageJonathan LennoxColumbia [email protected] 5, 2000

181PurposeAllow users to create simple Internet telephony servicesFeatures:Creatable and editable by simple graphical toolsIndependent of signalling p

182Abstract structureAddress-switchfield: fromsubfield: hostsubaddress-of:example.comotherwiselocationexample.comurl: sip:[email protected]

183Abstract structure (cont)Nodes and outputs — “boxes” and “arrows”Nodes have parametersStart from single root “call” nodeProgress down tree of contr

184Textual representation<cpl><subaction id="voicemail"><location url="sip:[email protected]"><redi

185Textual representation<incoming><address-switch field="origin" subfield="host"><address subdomain-of="examp

186Textual representationRepresent scripts as XML documentsIncoming, outgoing scripts are separate top-level tagsNodes and outputs are both tagsParame

187Switch nodesSwitch nodes make decisions.Structure:<type-switch field=var><type condition1="value1">action1</type><ty

188Address Switches: addressSwitch based on textual strings:is: (exact string match)contains: substring match: only for “display”subdomain-of: domain

189String Switches: stringSwitch based on textual strings, with conditions:is: exact string matchcontain: substring matchFields: subject, organization

19Invitation modessignaling mediaunicast multicastunicast telephony multicast sessionmulticast reach first dept. conference➠ SIP for all modes, SAP als

190Time switches: timeSwitch based on the current time at the server.timezone: which timezone the matching should apply inConditions:year, month, date

191Time switches: examples<time month="12" date="25" year="1999">December 25th, 1999, all day<time month="

192Time switches: examples<time timeofday="1310-1425,1440-1555,1610-1725"day="2,4">1:10–2:25PM,2:40–3:55PM,and4:10–5:25PM,Tu

193Location nodesA number of CPL actions (proxy, redirect) take locationsLocation nodes let you specify themThese are full-featured nodes because we m

194Simple location nodes: locationSpecify a location explicitly.url: explicitly specified locationclear: clear earlier location valuesOnly one output;

195Location lookup nodes: lookupSpecify a location abstractly, by where it should be looked up.Parameters:source: URL (ldap, http (CGI), etc) or non-U

196Location removal nodes: remove-locationRemove locations from the location set, based on caller preferences/calleecapabilities. Has the same effect

197Signalling Actions: proxyProxy the call to the currently-specified set of locations, and automaticallyselect one “best” final response.timeout: time

198Signalling Actions: redirectRedirect the call to the currently-specified set of locations. This has no specificparameters, and causes the script to t

199Signalling Actions: rejectReject the call attempt. This causes the script to terminate.status: “busy,” “notfound,” “reject,” or “error”, or a 4xx,

2Overviewbasic protocol operationdesign alternativesdetails: reliability, forking, . . .services: mute, transfer, . ..authentication and anonymitymobi

20Proxy and redirect serversproxy: may fork requests ➠ parallel or sequential searchstateless: forward request or responsetransaction stateful: rememb

200Non-signalling action: mailNotify a user of something through e-mail.url: the address to contact, including any header parameters.

201Non-signalling action: logStore a record of the current call in a log.name: the name of the log this should be storedomment: a string explaining th

202SubactionsXML syntax defines a tree; we want CPLs to be represented as directedacyclic graphs.Subactions are defined at the top level of the script,

203Example: Call Redirect Unconditional<cpl><incoming><location url="sip:[email protected]"><redirect /></l

204Example: Call Forward Busy/No Answer<cpl><subaction id="voicemail"><location url="sip:[email protected]&quo

205Example: Call Screening<cpl><incoming><address-switch field="origin" subfield="user"><address is="ano

206Example: Time-of-day Routing<?xml version="1.0" ?><!DOCTYPE call SYSTEM "cpl.dtd"><cpl><incoming><ti

207Example: Non-call Actions<?xml version="1.0" ?><!DOCTYPE call SYSTEM "cpl.dtd"><cpl><incoming><looku

208SIP Future

209What is SIP good at?session setup = “out of band”resource location via location-independent identifier (“user@domain”, tel)particularly if location

21SIP requests and responsesHTTP look-alikeprovisional and final responses:– 1xx = searching, ringing, queueing, . . .– 2xx = success– 3xx = forwarding

210What is SIP not meant for?bulk transport: media streams, files, pictures, . . .asynchronous messaging (“email”)resource reservationhigh-efficiency ge

211SIP and CorbaSIP Corbadata optional fields versioning hardtwo-level hierarchy general, C-likehiding dynamic directory-basedmultiple forking proxy no

212Current SIP effortsSIP to Draft StandardQoS and security preconditionsinter-domain AAA and billingsession timer (liveness)early media (announcement

213Other SIP UsesMGC MGC: SIP BCPPINT: establishing “legacy” phone callsInternet call waitinginstant messaging and event notification

214Internet telephony signaling: some open issuestouch-tone transmissioninteroperation of SIP with SS7, ISDN and POTSlarge-scale IPtel gatewayslocatin

215Summary and ConclusionSIP as flexible, extensible signaling protocolbasic functionality + proxying: doneextension to call controlextension to event

22SIP protocol requestINVITE sip:[email protected] SIP/2.0From: Christian Zahl <sip:[email protected]>To: Henning Schulzrinne <sip

23SIP requestscall leg: From, To, Call-IDrequests from callee to caller reverse To and Fromcaller and callee keep their own CSeq spaceeither side can

24SIP URLssip:[user:pw@]host:[port];transport=UDP;maddr=224.2.0.1used in Request-URI, Contact headers (redirect, registration), web pagestransport and

25SIP Protocol Design

26SIP protocol designSIP and RTSP are not HTTP ➠support UDP: no data stream, low latency desiredmulticast: group signaling, user locationavoid HTTP mi

27SIP protocol design: robustnessSIP is designed to be robust against server failures:no state in proxy servers during call (cf. H.323 GK)responses ar

28SIP and RTSP protocol design: encoding“Internet binary”ASN.1textualJini/RMI, Corba, DCOM

29Protocol design: internet binaryIP, TCP, RTP, RSVP, Q.931, . . . ➠fixed fields and/or type-length-value (TLV)efficient if alignedfewer ambiguitiesnesti

3SIP Basics

30Protocol design: ASN.1SNMP (BER), H.323/H.245 (PER) ➠not self-describing ➠ need external descriptionBER: inefficient, lots of optionsPER: external de

31Protocol design: textualSMTP (RFC 822), HTTP, SIP, RTSP:random textual: ftp, POP, IMAP, gopher, . . .➠ new parser for eachprotocolSMTP, HTTP, SIP, R

32RPC: RMI, Corba, DCOMRMI, Corba, DCOM: ➠ potentially replace all upper-layer Internet protocolscost of entry?maturity(security,extensions,multicast,

33Summary: SIP and CorbaSIP Corbadata optional fields versioning hardtwo-level hierarchy general, C-likehiding dynamic directory-basedmultiple forking

34SIP Details

35SIP syntaxmessage headermessage bodyresponserequestmessaget=0 0m= media type port RTP/AVPhostc=IN IP4 media destination addressV=0method URL SIP

36SIP syntaxfield names and some tokens (e.g., media type) are case-insensitiveeverything else is case-sensitivewhite space doesn’t matter except in fir

37SIP methodsINVITE initiate callACK confirm final responseBYE terminate (and transfer) callCANCEL cancel searches and “ringing”OPTIONS features support

38SIP response codes1xx provisional100 continue180 ringing2xx success200 OK3xx redirect300 multiple choices301 moved permanently302 moved temporarily

39SIP response codes4xx client error 480 temporarily unavailable400 bad request481 call leg doesn’t exist401 unauthorized482 loop detected403 forbidde

4SIP: Session Initiation ProtocolIETF-standardized peer-to-peer signaling protocol (RFC 2543):locate user given email-style addressset up session(re)-

40SIP response codes5xx server error500 server internal error501 not implemented502 bad gateway503 service unavailable504 gateway time-out505 version

41Headers: call and request identificationCall-ID: globally (time, space) unique call identifierTo: logical call destinationFrom: call sourceCSeq: reque

42Tagging Toafter forking and merging, hard to tell who respondedUAS responds with random tag added to disambiguateTo: "A. G. Bell" <sip:

43SIP request routingsend requests to local proxy or host in Request-URIeach proxy checks for loop, prepends a Via header with own addressVia: SIP/2.0

44SIP response routingresponse traces back request route without proxy server stateforward to host, port in next ViaTCP: re-use connection if possible

45Loop and misdirection preventionVia header before forwarding“spirals”: revisit same server, with different request URIMax-Forwards limits number of

46Spirals: revisiting proxy serversh(info,alice,17,1,bob@sales)h(info,alice,17,1,bob@sales)[email protected](To,From,Call−ID,C

47Forcing request pathsusually, bypass proxies on subsequent requestssome proxies want to stay in the path call-stateful:– firewalls– anonymizer proxie

48Record-Route and RouteRoute: A;maddr=PBRoute: A;maddr=PARoute: A;maddr=AINVITE PB INVITE PB INVITE BContact: ARecord−Route: PB, PAContact: A200 OKCo

49Forcing request pathsproxies that want to be in path add themselves as first Record-RouteRecord-Route:Alice <sip:[email protected];maddr=216.11

5SIP featuresprovidescallcontrol(hold,forward,transfer,mediachanges,...)leverages web infrastructure: security, “cgi-bin”, electronic payments,PICS, c

50Forcing request paths – reverse directionrequest from called party also traverse same proxiesbut can’t just use Record-Route valuesuse From in Route

51Call and caller identificationSubject topic of call, short messageOrganization caller and callee, possibly filled in by proxyDate date of call (replay

52Content descriptionDescribes message body:Content-Disposition display? session? script?Content-Encoding compression (gzip)Content-Language English,G

53SIP message sizestandard headers have one-letter compact formsminimal request/response, with email address, host 20 bytes:component full compacthead

54SIP message sizeINVITE, 100, 200, ACK, BYE, 200 1500 bytes1.5 s of 8 kb/s voicegzip compression improves by about 25%

55SIP extensions: new methodsmethods can be added at any time without changing the protocolserver complains with 405 if not implemented, returns list

56SIP headersreceiver ignores headers, parameters it doesn’t understandheaders are not negotiated, but features arefeatures: behavior, maybe headers,

57SIP extensions and feature negotiationif crucial, mark with “Require: feature”IANA-registered features are simple names, private features use revers

58Inquiring about capabilitiesOPTIONS request returns:Allow methodsAccept media typesAccept-Encoding compression methodsAccept-Language human language

59SIP reliability: all but INVITESIP: UDP and TCP, same messages, same behaviorrequests containCall-ID: globally unique in time and spaceCSeq: command

6SIP servers and clientsUAC: user-agent client (caller application)UAS: user-agent server ➠ accept, redirect, refuse callredirect server: redirect req

60SIP reliability: INVITEretransmit request after 0.5, 1, 2, 4, 4, 4, 4 secondsuntil provisional or final responseclient confirms final response via ACK

61SIP state transition – serverCompleted1xxACK−−INVITEfailurenmin(T1*2 , T2)1xx487ACK>= 300INVITEstatusstatus changestatus2xx−32s−INVITEterminated

62SIP state transition – clientACKstatusINVITE−ACKACKstatusstatusrequest senteventCallingInitial1xx1xxCall proceedingINVITET1*2n7 INVITE sentCompleted

63Reliability for provisional responsesINVITESupported: 100rel183 ProceedingRequire: 100relRSeq: 776655CSeq: 1 INVITE183 ProceedingRequire: 100relRSeq

64Interaction with resource reservationavoid “fast busy” after ringing ➠ interleaveUACPRACKPRACK180 RingingreservationINVITE [email protected] OK (PRA

65SIP Registration and UserLocation

66REGISTERregistration one (common) way of letting local proxy know where you areon startup, send REGISTER to sip.mcast.net via multicastor pre-configu

67REGISTER exampleSend this registration to sip.mcast.net,forwardedtohome.edu:REGISTER sip:registrar.home.edu SIP/2.0Contact: sip:[email protected]

68User requests contact listREGISTER sip:ss2.wcom.com SIP/2.0Via: SIP/2.0/UDP there.com:5060From: LittleGuy <sip:[email protected]>To: LittleGuy &

69User requests contact list, cont’d.SIP/2.0 200 OKVia: SIP/2.0/UDP there.com:5060From: LittleGuy <sip:[email protected]>To: LittleGuy <sip:Use

7SIP architecture: peer-to-peerRTP audioCATVEthernet128.119.40.186SIPredirect serverInternet128.59.19.141user agent (UA) user agent (UA)user agent (UA

70SIP Session (Media) Description

71SIP message bodyrequests and response can contain any (binary/text) objecttypically:– requests ➠ session (media) description– response ➠ session des

72SIP message bodydescribed by:Accept media typeAccept-Language language of responseContent-Type typeofmedia(text/html,application/sdp,...)Content-Len

73Session description: SDPapplication-specific: media vs. eventscaller and callee indicate receive capabilities and receive address/portmedia address m

74Session Description Protocol (SDP)originally for Mbone session advertisementsused for Mbone tools (sdr), RTSP, H.332parameter=value, no continuation

75SDP example for Internet telephonyversion session idRTP payload typedestination addressglobalaudiovideov=0o=the subject of the callc=IN IP4 t=m=audi

76SIP Security, Authentication andPrivacy

77Securityhop-by-hop encryption & authentication: IPsec, SSLproxy authentication: Proxy-Authenticate, for firewalls and PSTN gatewaysURL-based auth

78SIP authenticationBasic: include plain-text password in request, immediately or after 401(Unauthorized) or 407 (Proxy Authorization) responseDigest:

79Basic authenticationChallenge by UAS:SIP/2.0 401 UnauthorizedWWW-Authenticate: Basic realm="business"client responds withINVITE sip:alice@

8SIP architecture: outbound [email protected]@ph7.wonderland.comTo: sip:[email protected] sip:[email protected] SIP/

80Digest authenticationcalls and fails:SIP/2.0 401 UnauthorizedAuthenticate: Digest realm="GW service",domain="wcom.com", nonce=&q

81Digest authenticationusername: user authenticating herselfrealm: several per user, used also for displaynonce: copied into Authorizationopaque: copi

82PGP authenticationRequest authorization – not necessary:SIP/2.0 401 UnauthorizedWWW-Authenticate: pgp version="5.0"realm="Your Startr

83PGP authenticationcomputed across nonce, realm, method, header fields followingAuthorization, bodymay also be signed by third party (e.g., outbound p

84PGP encryptionencrypt part of SIP messageINVITE sip:[email protected] SIP/2.0...Encryption: PGP version=2.6.2,encoding=asciihQEMAxkp5

85Anonymous callsnear-end proxy that scrambles identifying information (“anonymousremailer”) ➠ no call-state neededfar-end proxy hides exact callee lo

86Anonymous callstraceable: encrypt salted versionrecognizable: “payphone”same caller, same identification ➠ non-saltedencryptionconfirmable: hash witho

87Hiding signaling paths: Via hidingP1 P2 callee200 OKP1e1(caller)Via: Via: ;hidden200 OKP2Via: Via: e2(P1) ;hidden;hiddene1(caller)Via: INVITEINVITEV

88Getting SIP through firewalls and NATsSIP proxy as firewall controller or NAT ALGmuch easier than H.323:– single protocol vs. H.225.0 + H.245– SDPH.24

89SIP billing/chargingWhat for?transport ➠ resource reserva-tion protocolSIP services (call processing)➠ authenticationPSTN gateway servicesmedia serv

9SIP architecture: carrierNAT(10.0.0.3)bob.example.com(10.0.0.2)(216.32.74.51)www.yahoo.com5678 10.0.0.1/2345port addr/port10.0.0.2/2345 −> 216.32.

90SIP Caller Preferences

91Preferencescallee: scripts, CPL, REGISTER advice in Contact,...caller: help guide routing (“no home number”) and order of attempts whenforking (“try

92Extended SIP Contact headerq location preferenceclass business, residencedescription show to callerduplex full or half-duplexfeature call handling f

93Contact exampleq=quality gives preference.SIP/2.0 302 Moved temporarilyContact: sip:[email protected];action=redirect ;service=IP,voice-mai

94Accept-Contact and Reject-Contactdetermine order of contacting users:Accept-Contact: sip:[email protected] ;q=0,;media="!video" ;q=0.1,;mobil

95Request-Dispositionproxy or redirectcancel ringing second phone after first picked up?allow forking?search recursively?search sequentially or in para

96SIP Protocol Status andImplementations

97StatusProposed Standard, Feb. 1999 – RFC2543bakeoffs every 4 months cross-vendor interoperability testshost when companies1 Columbia University Apri

98SIP implementationsRoughly in order of maturity:proxies and redirect servers for service creationPC-based user agents – Windows and other OSEthernet

99On-going SIP Implementations3ComAudioTalk NetworksBroadsoftCatapultCiscoCarnegie-Mellon UniversityColumbia UniversityDelta Information Systemsdynami