A Tutorial on SIP Jonathan Rosenberg Chief Scientist

A Tutorial on SIP Jonathan Rosenberg Chief Scientist SIP Tutoiral www. dynamicsoft. com

Introducing - Session Initiation Protocol (SIP) l l Developed in mmusic group in IETF n Proposed standard RFC 2543, Feb. 1999 n Work began 1995 n Part of Internet Multimedia Conferencing Suite Main functions n l Main Features n Personal mobility services n Wide area operation n Session independence l Invitation of users to sessions l Find the users current location to deliver invitation l Carry opaque session descriptions n Modification of sessions n Termination of sessions SIP Tutoiral n voice, video, games, chat, virtual reality, etc. Leverages other Internet protocols www. dynamicsoft. com

Basic Design l SIP is a Client Server Protocol n Clients send requests, receive request responses n Servers receive requests, send responses Client Server response l Modelled after HTTP l Each request invokes method on server n Main purpose of request l Messages contain bodies SIP Tutoiral www. dynamicsoft. com

Transactions INVITE 100 l Fundamental unit of messaging 200 Cseq: 1 exchange ACK n Request n Zero or more provisional First Transaction responses n Usually one final response n Maybe ACK BYE l All signaling composed of independent transactions Cseq: 2 200 l Identified by Cseq Second Transaction n Sequence number n Method tag C SIP Tutoiral S www. dynamicsoft. com

Session Independence l Body of SIP message used to establish call describes the session l Session could be n Audio n Video n Game l SIP operation is independent of type of session SIP Tutoiral l SIP Bodies are MIME objects n MIME = Multipurpose Internet Mail Extensions n Mechanisms for describing and carrying opaque content n Used with HTTP and email l SIP bodies can carry other information too! n JPEG for caller ID n HTML page for Web IVR www. dynamicsoft. com

Protocol Components l l User Agent Client (UAC) n End systems n Send SIP requests l Redirect Server n User Agent Server (UAS) n Listens for call requests n Prompts user or executes program to determine response l User Agent n UAC + UAS SIP Tutoiral l Proxy Server n l “Network” server; redirects users to try other server “Network Server” Proxies request to another server Can “fork” request to multiple servers, creating a search tree Registrar n receives registrations regarding current user locations www. dynamicsoft. com

SIP Addressing l SIP addresses are URL’s l URL contains several components l n Scheme (sip) n Username n Optional password n Hostname n Optional port n Parameters n Headers and Body SIP allows any URI type n tel URIs n http URLs for redirects n mailto URLs n leverage vast URI infrastructure SIP Tutoiral sip: jdrosen@dynamicsoft. com: 5061; user=host? Subject=foo www. dynamicsoft. com

Network Servers l Main Function is routing LS n Where should request go next? n Can redirect or proxy there l SIP does not dictate how routing is done l Location Service provides data Proxy n Abstract concept n LDAP, whois++ n result of program execution (IN) l End result is a mapping from one SIP URI to another n sip: jdrosen@dynamicsoft. com to sip: jdrosen@eagle. dynamicsoft. com SIP Tutoiral www. dynamicsoft. com

Proxies l Requests can traverse multiple proxies from caller to callee LS l Each proxy: n receives request n checks if domain in request sip: joe@a. com Proxy URI is its own l Domain matches n invokes location service 200 OK sip: j_user@eng. a. com Proxy 200 OK n obtains new request URI n looks up host portion in DNS n forwards to next hop server n receives response sip: j_user@host. eng. a. com n forwards response SIP Tutoiral www. dynamicsoft. com

DNS Usage DNS l Take domain name of request URI l Look for SRV records n SRV records specify a list of IP DNS SRV Query addresses for servers for a particular service A 100 B 200 C 300 D 400 A B n List includes priority values and preferences for each address l Try IP addresses in order of preference, go to next if no response C Proxy D l If no SRV records present, use A records n A records are standard hostname to IP address records SIP Tutoiral www. dynamicsoft. com

Local Outbound Proxies l Can send a request to a proxy without performing DNS procedure INVITE joe@b. edu l Result is that proxy receives a request whose domain is not its own l Proxy then performs DNS process just described to forward request INVITE joe@b. edu l May also provide additional services n Outbound screening a. com n Authorization n Logging n Firewall control SIP Tutoiral www. dynamicsoft. com

SIP Methods l l INVITE n Invites a participant to a session n idempotent - re. INVITEs for session modification BYE n l SIP Tutoiral Terminates a search OPTIONS n l l Queries a participant about their media capabilities, and finds them, but doesn’t invite ACK n Ends a client’s participation in a session CANCEL n l For reliability and call acceptance REGISTER n Informs a SIP server about the location of a user www. dynamicsoft. com

SIP Architecture Request Response Media SIP Redirect Server Location Service 2 3 5 4 1 7 11 12 13 SIP UA 6 SIP Proxy 10 SIP Proxy 8 14 9 SIP UA (User Agent Server) SIP Tutoiral www. dynamicsoft. com

SIP Message Syntax l Many header fields from http l Payload contains a media description n SDP - Session Description Protocol INVITE sip: ann@lucent. com SIP/2. 0 From: J. Rosenberg <sip: jdrosen@dynamicsoft. com> Subject: SIP will be discussed, too To: A. Netravali <sip: ann@lucent. com> Via: SIP/2. 0/UDP pc 13. dynamicsoft. com Call-ID: 1997234505. 56. 78@122. 3. 44. 12 Content-type: application/sdp CSeq: 4711 INVITE Content-Length: 187 v=0 o=user 1 53655765 2353687637 IN IP 4 128. 3. 4. 5 s=Mbone Audio i=Discussion of Mbone Engineering Issues e=mbone@somewhere. com c=IN IP 4 224. 2. 0. 1/127 t=0 0 m=audio 3456 RTP/AVP 0 SIP Tutoiral www. dynamicsoft. com

SIP Address Fields l Request-URI n Contains address of next hop server n Rewritten by proxies based on result of Location Service l To n Address of original called party n Contains optional display name l From n Address of calling party n Optional display name SIP Tutoiral INVITE sip: ann@lucent. com SIP/2. 0 From: J. Rosenberg <sip: jdrosen@dynamicsoft. com>; tag=76 ah Subject: SIP will be discussed, too To: A. Netravali <sip: ann@lucent. com> Via: SIP/2. 0/UDP pc 13. dynamicsoft. com Call-ID: 1997234505. 56. 78@122. 3. 44. 12 Content-type: application/sdp Contact: sip: jdrosen@pc 13. dynamicsoft. com CSeq: 4711 INVITE Content-Length: 187 v=0 o=user 1 53655765 2353687637 IN IP 4 128. 3. 4. 5 s=Mbone Audio i=Discussion of Mbone Engineering Issues e=mbone@somewhere. com c=IN IP 4 224. 2. 0. 1/127 t=0 0 m=audio 3456 RTP/AVP 0 www. dynamicsoft. com

SIP Responses l Look much like requests n l l Headers, bodies Differ in top line n Status Code SIP Tutoiral n 100 - 199 (1 XX): Informational n 200 - 299 (2 XX): Success n 300 - 399 (3 XX): Redirection l Numeric, 100 - 699 n 400 - 499 (4 XX): Client Error l Meant for computer processing n 500 - 599 (5 XX): Server Error l Protocol behavior based on 100 s digit n 600 - 699 (6 XX): Global Failure l n Status Code Classes l Other digits give extra info Two groups n Reason Phrase l Text phrase for humans l Can be anything 100 - 199: Provisional l n l Not reliable 200 - 699: Final, Definitive Example n 200 OK n 180 Ringing www. dynamicsoft. com

Example SIP Response l Note how only difference l SIP/2. 0 200 OK is top line From: J. Rosenberg <sip: jdrosen@dynamicsoft. com>; tag=76 ah Rules for generating To: A. Netravali <sip: ann@lucent. com>; tag=112 Via: SIP/2. 0/UDP pc 13. dynamicsoft. com responses Call-ID: 1997234505. 56. 78@122. 3. 44. 12 n Call-ID, To, From, Cseq are CSeq: 4711 INVITE mirrored in response to Contact: sip: ann@lucent 3. lucent. com support matching n Tag added to To field SIP Tutoiral www. dynamicsoft. com

SIP Transport l SIP Messages over UDP or TCP l Reliability mechanisms defined for UDP l UDP Preferred n Faster n No connection state needed in l Reliability mechanisms depend on SIP request method n INVITE n anything except INVITE l Reason: optimized for phone calls kernel n Multicast possible (later) SIP Tutoiral www. dynamicsoft. com

INVITE reliability l Client retransmits INVITE with exponential backoff n l n 500 ms, 1 s, 2 s, 4 s, 8 s…. . INV Ring. . . Next hop should send 100 Trying to stop retransmissions 100 Trying INV Response retransmitted when request retransmissions arrive Final response retransmitted with exponential backoff up to 4 s n l INV Retransmissions cease when provisional response arrives n l INV 100 Trying 200 OK May take a long time to answer phone!! 200 OK ACK sent on receipt of final response ACK C SIP Tutoiral S www. dynamicsoft. com

Non-INVITE Reliability l Responses should come quickly n l BYE BYE No need to ring phone Request retransmitted w/ exponential backoff, up to 4 s n BYE If provisional response received, request retransmitted at 4 s intervals l After 4 s, request retransmitted every 4 s l Response retransmitted on receipt of request n That’s why request must be retransmitted after provisional - protect against response loss n no ACK BYE 200 OK C SIP Tutoiral 100 Trying S www. dynamicsoft. com

TCP Transport l Reliability rules for TCP same as UDP with one change n Requests not retransmitted l However, 2 xx final responses still retransmitted l ACK is still sent l Reason? n Handles case of a mix of UDP and TCP connections SIP Tutoiral www. dynamicsoft. com

Hop by Hop vs. End to End INVITE l n n l 100 Trying INVITE Reliability can be HBH or E 2 E HBH implies message transmitted reliably between each entity (UAC to proxy, proxy to UAS) 100 Trying E 2 E implies proxies simply forward requests, reliability assured between UAC and UAS only 200 OK SIP uses HBH reliability… almost n n Stateless proxies simply forward requests 200 OK response to INVITE is E 2 E reliable!!! l ACK 200 OK UAC must see all 200 OK ACK UAC SIP Tutoiral 200 OK ACK Proxy UAS www. dynamicsoft. com

Registrations l Proxy needs to know where users are sitting l SIP REGISTER message allows clients to tell proxy servers l REGISTER properties n Contains list of current locations in Contact headers n Registrar identified in Request URI n Identifies registered user in To field n Identifies person performing registration in From field (usually = To) n Expires header indicates desired lifetime l n SIP Tutoiral REGISTER sip: dynamicsoft. com SIP/2. 0 To: Rosenberg <sip: jdrosen@dynamicsoft. com> From: Claribel <sip: cpena@dynamicsoft. com> Call-ID: 1997234505. 56. 78@122. 3. 44. 12 CSeq: 123 REGISTER Contact: sip: jdrosen@pc 33. dynamicsoft. com Contact: http: //www. cs. columbia. edu/~jdrosen Expires: 3600 Can be different for each Contact May be body www. dynamicsoft. com

Registration Responses l Registrar behavior on receiving REGISTER n check if domain is its own n authorize user in From field n Add address bindings of (To field) -> (Contact list) n Lower expiration time if too long n Return, in response, list of all current registrations n Return, in response, SIP/2. 0 200 OK To: Rosenberg <sip: jdrosen@dynamicsoft. com> From: Claribel <sip: cpena@dynamicsoft. com> Call-ID: 1997234505. 56. 78@122. 3. 44. 12 CSeq: 123 REGISTER Contact: sip: jdrosen@pc 33. dynamicsoft. com Contact: http: //www. cs. columbia. edu/~jdrosen Contact: mailto: jdrosen@dynamicsoft. com ; expires=“Thu, 01 Dec 2002 16: 00 GMT” Expires: 3600 expiration time for all registrations SIP Tutoiral www. dynamicsoft. com

Registration Details l User Agent must refresh registrations by resending before expiration l Each contact must be refreshed independently n Can place them all in same REGISTER n Can use separate REGISTER for each l Deleting Registrations n Send a refresh with Expires: 0 l Querying list of current registrations n Send REGISTER with no Contact headers n Response contains list of current registrations l Distributed registrations n Registrations for the same user (I. e. , same To field) can come from different hosts, each registering different contacts n Example: my cell phone registers itself, my PC registers itself SIP Tutoiral www. dynamicsoft. com

Forking l A proxy may have more than one address for a user n Happens when more than one SIP INVITE user 2@domain 2 URL is registered for a user n Can happen based on static routing configuration l In this case, proxy may fork INVITE user@domain l Forking is when proxy sends request to more than one proxy at once INVITE user 3@domain 3 l First 200 OK that is received is forwarded upstream l All other unanswered requests cancelled SIP Tutoiral www. dynamicsoft. com

More on Forking l Main benefits n Allows rapid “search” for user at many locations n Phone rings more than one place at a time l Two variations n Sequential Search: Try first address, only if that fails try second address n Parallel Search: Try all addresses at once (as in previous slide) l Hybrid approaches possible SIP Tutoiral l Many proxies can fork, resulting in tree of proxies l “Best” response to forked request is chosen and forwarded upstream n First 200 OK received n First 600 received if no 200 OK n Lowest numbered response after all responses are received, given none was 200 or 600 n Note usually one response is forwarded upstream www. dynamicsoft. com

CANCEL INV l CANCEL used to “take back” 100 a request INV 100 INV l Main application: stop phones 100 from ringing which have not yet answered 200 l Semantics CANCEL 200 n Always refers to another OK request n If you get a CANCEL, and 487 haven’t answered request, answer request with 487. Answer CANCEL with 200. ACK n Can be generated by proxies or UA - usually proxies SIP Tutoiral UAC Proxy UAS www. dynamicsoft. com UAS

Response Routing: Via l Responses take same path as requests l How does server know where to send response? n Remember where request came from n Place information in request, get it back in response!! l Via Header l Via header reflected in response from UAS l When proxy receives response n check if topmost Via is itself n If yes, remove and check next header n Send response to address in next Via n If no next Via, response is for me n Traces path of request n “Stack” header SIP Tutoiral l Each proxy pushes its address in requests l Pops its address in responses www. dynamicsoft. com

Via Operation Via: B Via: A UAC Address: A Proxy Via: A Via: C Via: B Via: A Address: B Proxy Via: B Via: A Address: C UAS Via: C Via: B Via: A Address: D Request Response SIP Tutoiral www. dynamicsoft. com

Received Tags l Many cases where address in via is wrong! n NAT INVITE sip: ann@lucent. com SIP/2. 0 From: sip: jdrosen@dynamicsoft. com; tag=76 ah To: sip: ann@lucent. com Via: SIP/2. 0/UDP pc 13. dynamicsoft. com; received=12. 3. 2. 1 n Multihomed hosts l Rather, source address of packet is more correct l Solution: receive tag n If source address of packet doesn’t equal top via address n Proxy inserts received parameter into via header l End result n Responses sent to source IP address of request, but to port in via header n Strange combination, but it works well for multihomed hosts n Indicates source IP address n That address is used to send responses SIP Tutoiral www. dynamicsoft. com

Stateful vs. Stateless Proxies l Stateless Proxy Definition l A proxy must be stateful when n Receives request, acccess n location services, forwards request It forks (this requires special processing of responses to “remember” best one) n It sends a request using multicast n It uses TCP n Forgets it even saw request after forwarding it l n When response comes, uses Via Stateful vs. Stateless n header to figure out where to send it l Stateful Proxy Definition n Remembers it saw the request after forwarding it n Can apply additional logic after response arrives SIP Tutoiral l Stateless scales very well l No memory requirements l Tiny socket requirements n Stateful is better for services n Each proxy can independently decide which to be Call Stateful n Remembers multiple transactions being associated with a call www. dynamicsoft. com

Loop Detection l With all this forking and forwarding, request may hit the same proxy twice! l Need mechanisms to prevent this from looping forever l SIP provides two n n SIP Tutoiral Max-Forwards l Counter decremented by 1 on each hop l Discard request when zero Via based loop prevention and detection l Every proxy inserts address l Check for my address when request comes www. dynamicsoft. com

Loop Detection: Details l Spirals l Branch ID Component 1 n When request hits server twice, n When a proxy forks, each fork has but with different request URI a different component 1, so response associated with forked request n Example: joe@example. com forwards to bob@example. com! n Not an error l Must detect difference between loop and spiral l Solution n Via header contains branch ID parameter n Branch ID has two components l Branch ID Component 2 n Hash of To, From, Call-ID, Cseq and incoming request URI n When you receive a request, check for Via headers with your own address n For those with that address, recompute hash, see if it matches value in branch ID n If match, loop, if not, spiral SIP Tutoiral www. dynamicsoft. com

Routing of Subsequent Requests l Initial SIP request sent through many proxies Proxy l No need per se for subsequent INVITE requests to go through proxies l Each proxy can decide whether Proxy it wants to receive subsequent requests n Inserts Record-Route header BYE containing its address l For subsequent requests, users insert Route header n Contains sequence of proxies Proxy UA 1 UA 2 (and final user) that should receive request SIP Tutoiral www. dynamicsoft. com

Construction of Route Header l Each proxy may insert a RR l UAC Constructs Route n Stack property n Flips order of Route headers n Any URL meeting two n Places Contact from 200 OK at requirements l Routes back to that server l Identifies the target recipient in some way l UAS reflects all RR in 200 OK Response bottom n Result is Route set l UAS Constructs Route n Takes RR from INVITE n Adds Contact from INVITE at the end n Proxies can modify RR they inserted n Allows Route for UAC/UAS to be different, which it should be! SIP Tutoiral www. dynamicsoft. com

Example Route Construction INV sip: b@t m: sip: a@o UAC Sip: a@o SIP Tutoiral INV sip: b@t 2 m: sip: a@o RR: sip: a@o; maddr=B Proxy Addr: B Domain: t SIP/2. 0 200 OK m: sip: b@t 3 RR: sip: b@t 2; maddr=C RR: sip: b@t; maddr=B UAC Route: Sip: b@t; maddr=B, Sip: b@t 2; maddr=C Sip: b@t 3 INV sip: b@t 3 m: sip: a@o RR: sip: a@o; maddr=C RR: sip: a@o; maddr=B Proxy SIP/2. 0 200 OK m: sip: b@t 3 RR: sip: b@t 2; maddr=C RR: sip: a@o; maddr=B Addr: C Domain: t 2 UAS SIP/2. 0 200 OK m: sip: b@t 3 Sip: b@t 3 RR: sip: a@o; maddr=C RR: sip: a@o; maddr=B UAS Route: Sip: a@o; maddr=C, Sip: a@o; maddr=B Sip: a@o www. dynamicsoft. com

Setting up the Session l INVITE contains the Session Description Protocol (SDP) in the body l SDP conveys the desired session from the callers perspective n Session consists of a number of media streams n Each stream can be audio, video, text, application, etc. l Also contains information l SDP also conveys other information about session n Time it will take place n Who originated the session n subject of the session n URL for more information l SDP origins are multicast sessions on the mbone n Originator of INVITE is not originator of session needed about the session n codecs n addresses and ports SIP Tutoiral www. dynamicsoft. com

Anatomy of SDP l SDP contains informational headers n version (v) n origin(o) - unique ID n information (I) l Time of the session l Followed by a sequence of media streams l Each media stream contains an m line defining l n port n transport n codecs v=0 o=user 1 53655765 2353687637 IN IP 4 128. 3. 4. 5 s=Mbone Audio i=Discussion of Mbone Engineering Issues e=mbone@somewhere. com t=0 0 m=audio 3456 RTP/AVP 0 78 c=IN IP 4 1. 2. 3. 4 a=rtpmap: 78 G 723 m=video 4444 RTP/AVP 86 c=IN IP 4 1. 2. 3. 4 a=rtpmap: 86 H 263 Media Stream also contains c line n SIP Tutoiral Address information www. dynamicsoft. com

Negotiating the Session l Called party receives SDP offered by caller l Each stream can be l n accepted n rejected Accepting involves generating an SDP listing same stream n port number and address of called party n subset of codecs from SDP in request l Rejecting indicated by setting port to zero l Resulting SDP returned in 200 OK l Media can now be exchanged SIP Tutoiral v=0 o=user 2 16255765 8267374637 IN IP 4 4. 3. 2. 1 t=0 0 m=audio 3456 RTP/AVP 0 c=IN IP 4 4. 3. 2. 1 m=video 0 RTP/AVP 86 c=IN IP 4 4. 3. 2. 1 Audio stream accepted, PCMU only. Video stream rejected www. dynamicsoft. com

Changing Session Parameters INVITE l Once call is started, session can be modified l Possible changes n Add a stream n Remove a stream n Change codecs n Change address information l Call hold is basically a session change l Accomplished through a re-INVITE l Same session negotiation as INVITE, except in middle of call l Rejected re-INVITE - call still active! 200 ACK INVITE 200 C SIP Tutoiral re. INVITE ACK S www. dynamicsoft. com

Hanging Up INVITE 100 l How to hang up depends on when and who l After call is set up n either party sends BYE request Hangup CANCEL l From caller, before call is 200 OK Accept 200 OK accepted ACK n send CANCEL BYE n BYE is bad since it may not reach the same set of users that got INVITE 200 OK n If call is accepted after CANCEL, then send BYE l From callee, before accepted n Reject with 486 Busy Here SIP Tutoiral C S www. dynamicsoft. com

Calls, Call Legs and Transactions l Call is a set of point to point SIP Call-ID relationships local participant n Call-ID l Call Leg (aka Dialog) is a point to point SIP relationship n Call-ID + To + from Remote participant l Transaction is a request/response Remote participant n Call-ID + To + From + CSeq SIP Tutoiral CSeq www. dynamicsoft. com CSeq

Call Flow for basic call: UA to proxy to UA l Call setup n 100 trying hop by hop n 180 ringing n 200 OK acceptance INVITE 100 Trying 180 Ringing l Call parameter modification n re-INVITE 200 OK n Same as initial INVITE, updated session description INVITE 100 Trying 180 Ringing 200 OK ACK RTP l Termination BYE method 200 OK SIP Tutoiral www. dynamicsoft. com

Addressing Scalability l Internet model for scalability CSF Proxy n Fast and simple in core n Smarter towards periphery n Stateless proxies in the core are CSF Proxy SL Proxy fast n Stateful proxies at periphery n Call-stateful proxies at edge SF Proxy n Example: RSVP vs. Diffserv l SIP uses Internet Model CSF Proxy SF Proxy CSF SF SL SIP Tutoiral Call Stateful Stateless www. dynamicsoft. com

Fault Tolerance l Server crashes have little effect n No calls terminated, even for Call Stateful proxies running TCP n Transactions in progress complete if a backup is available (SRV) l Protocol State stored in messages l DCS State Header n Under development n Much like http cookies n Will allow proxies to ask for data back in subsequent requests n Allows fully call stateful servers that are highly recoverable!! n Responses always routed back n TCP connections may even be re- opened to send responses! n Branch parameter as a tool of the proxy SIP Tutoiral www. dynamicsoft. com

Extensibility Model l Goal: Ensure baseline operation always works l Protocol can be extended by n Defining new headers and semantics n Defining new parameters and semantics n Defining new methods n Defining new bodies l New parameters and headers can be optional l Features that must be understood are given names l Feature naming n IANA registered n com. microsoft. featurefoo naming l Clients can insist server understand a feature l Server can place a feature in a response if client understands it n Safely ignored by recipient n Spec mandates that unknown headers and params are ignored n Maximizes interoperability SIP Tutoiral www. dynamicsoft. com

Extensibility: Client requests Feature INVITE Foo: blah-blah Bar: la-la Require: foo, bar l Feature represented by new header, parameter and/or new behavior l Client places needed feature in 420 Bad Extension Unsupported: foo special header in request n Require: want UAS to understand feature n Proxy-require: want proxies to INVITE Bar: la-la Require: bar understand feature l If UAS or proxy doesn’t know feature, it responds with error and lists unknown features in Unsupported header l Client can resubmit request SIP Tutoiral C S www. dynamicsoft. com

Extensibility: Server wants feature l Client indicates features it understands in Supported header in request INVITE Supported: foo, bar n All features must be listed n Always place header in every 201 OK Foo: blah-blah Require: foo request l Server can use feature if its listed l If server applies feature in response, it includes a Require header indicating the feature C SIP Tutoiral S www. dynamicsoft. com

Extensibility: New Methods l Methods define fundamental behavior GOAWAY To: joe l Client can send request with new method l UAS rejects requests with 405 Method Not Allowed Allow: INVITE, BYE, OPTIONS, ACK, CANCEL unknown methods n 405 response n list allowed methods in Allow header l Proxies don’t care about methods n Proxy rules are independent of method C SIP Tutoiral S www. dynamicsoft. com

Extensibility: New Bodies l Bodies convey non-SIP related information about request INVITE Content-Type: text/foo Content-Length: 2 l Body types enumerated by IANA registry aa l Not all bodies known to a server l When server receives request with unknown body 415 Unsupported Media Accept: text/plain n 415 Unsupported Media response n Accept header lists valid MIME body types l Only used by UA! C SIP Tutoiral S www. dynamicsoft. com

Security l Leverage existing mechanisms l HTTP n Basic authentication n Digest authentication l PGP l S/MIME l Transport Mechanisms SIP Tutoiral www. dynamicsoft. com

HTTP Basic and Digest l Challenge Response n Client sends request n Server responds with 401 or 407 with “challenge” n Client ACKs n Client sends request again (higher Cseq) with credentials n If OK, server processes, else sends 401/407 again l Mechanism is Stateless n Don’t need to know that a challenge was issued n Requests just contain credentials SIP Tutoiral l Credentials can be cached n Subsequent requests to the same server can contain same credentials n If they expire, server issues 401/407 l Two relationships n Proxy Server challenges UAC n UAS challenges UAC l Multiple credentials n Any number of proxies and a UAS can issue challenge n Credentials are accumulated www. dynamicsoft. com

HTTP Basic Authentication INVITE l Cleartext Password n Base 64 encoded l Not useful alone n May be useful within a TLS 401 Authorize Yourself WWW-Authenticate: Basic realm=“mufasa” connection from client to server n Emulates http usage of client authentication l Not widely implemented INVITE Authorization: Basic QWxh. ZGRpbjpvc. GVu. I== l Depecated from bis 200 OK SIP Tutoiral www. dynamicsoft. com

HTTP Digest Authentication l Server challenge n Realm (keyword for password) n Nonce (random number, rotates periodically) l UAC Response n Hash of username, password, realm and nonce, and also method n Can also include body in hash n Specifically, its H(H(username: realm: password): n once: H(method: URI)) SIP Tutoiral l Why double hashing? n Server can store H(user: realm: pass); doesn’t change n Computes H(method: URI) combines with first n No password or username on disk! l Response Authorization n Responses can also contain credetials that authenticate caller www. dynamicsoft. com

PGP l RFC 2543 specified security based on PGP l Provided n Client to server authentication n Client to server encryption n Server to client authentication n Server to client encryption l Uses public keys l Requires PGP community l Requires request to be “canonicalized” n Standardized format over which signature is computed n Requires devices to maintain order of headers and parameters l Deprecated! n No implementations n Canonicalization a pain n Other approaches more mature n General problem with PGP SIP Tutoiral www. dynamicsoft. com

Coming soon: S/MIME l S/MIME is an IETF standard for email security INVITE sip: u@h SIP/2. 0 From: sip: bob@foo To: sip: a@c Content-Type: multipart l Provides authentication and encryption SDP l Based on X. 409 Public Key Certificates n The kind you get from Verisign n Some infrastructure in place n Can be shipped with message l Big overhead n Message contains payload, signed piece, and signature, maybe certificate n Requires multipart SIP Tutoiral INVITE sip: u@h SIP/2. 0 From: sip: bob@foo To: sip: a@c Content-Type: SDP text signature certificate www. dynamicsoft. com

Transport Security l Previous mechanisms allow for E 2 E Security Proxy n Works through any number of proxies n Proxies don’t need to be trusted n Security within SIP layer Proxy l Hop by Hop Security Possible as well Proxy n Proxies have trust relationship with each other UA 1 n E 2 E security by transitivity l SIP Tutoiral Relies on all hops doing security Secure Tunnel www. dynamicsoft. com UA 2

Transport Security l Requires no SIP extensions l Several techniques n TLS/SSL n IPSec l TLS/SSL l IPSec n UDP also n Not widely implemented n IKE barely supported n Resides in OS n Firewall and NAT Traversal n Widely implemented n Key exchange works n Resides in application layer n TCP only SIP Tutoiral www. dynamicsoft. com

What about Qo. S? l l Qo. S is handled orthogonally by other protocols l Voice will be negligible compared to data anyway Signaling path isn’t same as media path at all!! n Even set of ISPs is different l Separation allows yahoo to be a phone company l Many other apps need QOS, keep one mechanism SIP Tutoiral www. dynamicsoft. com

Models of Qo. S for SIP l Diffserv n users mark TOS byte in their RTP packets n olympic service model l RSVP/diffserv core w/ ringing holdback n don’t ring unless resources reserved n total separation n use RSVP in periphery n no n resource reservations starts after SIP Tutoiral l admission control l end to end signaling l per call minute metering INVITE n ringing and continued signaling after RSVP done www. dynamicsoft. com

Quality of Service INV 183 Progress l SIP is “not” a Reservation Protocol, but. . . PRACK l Need Coupling Between Signaling and Reservation n Do not ring phone until resources reserved Resource Reservation l Uses a new extension to SIP COMET n INVITE contains a header that indicates there n Preconditions include l Qo. S establishment l Security 200 OK Media sent SIP Tutoiral Pickup ACK n When preconditions met, COMET request is n Phone can then ring Ringing 200 OK is a precondition to ringing the phone Caller Callee www. dynamicsoft. com

Information Resource l Jonathan Rosenberg n jdrosen@dynamicsoft. com n +1 973 -952 -5000 SIP Tutoiral www. dynamicsoft. com