SIP Tutoiral A Tutorial on SIP Jonathan

SIP Tutoiral A Tutorial on SIP Jonathan

SIP Tutoiral A Tutorial on SIP Jonathan Rosenberg Chief Scientist SIP Tutoiral Introducing - Session Initiation Protocol (SIP) Developed in mmusic group in IETF Proposed standard RFC2543, Feb. 1999 Work began 1995 Part of Internet Multimedia Conferencing Suite Main functions SIP Tutoiral

Invitation of users to sessions Find the users current location to deliver invitation Carry opaque session descriptions Modification of sessions Termination of sessions Main Features Personal mobility services Wide area operation Session independence voice, video, games, chat, virtual reality, etc. Leverages other Internet protocols Basic Design SIP is a Client Server Protocol Clients send requests, receive responses Servers receive requests, send responses Modelled after HTTP Each request invokes method on server Main purpose of request request Client Server response Messages contain bodies

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

200 Second Transaction C SIP Tutoiral S Session Independence SIP Body Bodies of SIPare message MIME objects used to establish call describes the session MIME = Multipurpose Internet Mail Extensions Session could be for describing and carrying opaque content Mechanisms Audio Used Video with HTTP and email SIP Game bodies can carry other information too! JPEG for caller ID

SIP operation is independent of type of session HTML page for Web IVR SIP Tutoiral Protocol Components User Agent Client (UAC) End systems Send SIP requests Redirect Server Network server; redirects users to try other server User Agent Server (UAS) Proxy Server Listens for call requests Network Server Proxies request to another Prompts user or executes program to server Can fork request to multiple determine response servers, creating a search tree User Agent UAC + UAS SIP Tutoiral Registrar receives registrations regarding current user

locations SIP Addressing SIP addresses are URLs URL contains several components Scheme (sip) Username Optional password Hostname Optional port Parameters Headers and Body sip:[email protected]:5061; SIP allows any URI type user=host?Subject=foo tel URIs http URLs for redirects mailto URLs leverage vast URI infrastructure SIP Tutoiral Network Servers Main Function is routing LS Where should request go next? Can redirect or proxy there

SIP does not dictate how routing is done Location Service provides data Abstract concept LDAP, whois, whois++ result of program execution (IN) Proxy End result is a mapping from one SIP URI to another sip:[email protected] to sip:[email protected] SIP Tutoiral Proxies Requests can traverse multiple proxies from caller to callee LS Each proxy: receives request checks if domain in request sip:[email protected]

URI is its own Domain matches invokes location service obtains new request URI 200 OK Proxy sip:[email protected] Proxy 200 OK 200 OK looks up host portion in DNS forwards to next hop server receives response sip:[email protected] forwards response SIP Tutoiral DNS Usage DNS

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

A records A records are standard hostname to IP address records SIP Tutoiral A Local Outbound Proxies Can send a request to a proxy without performing DNS procedure INVITE [email protected] Result is that proxy receives a request whose domain is not its own Proxy then performs DNS process just described to forward request INVITE [email protected] May also provide additional services Outbound screening Authorization Logging Firewall control SIP Tutoiral SIP Methods INVITE Invites a participant to a session idempotent - reINVITEs for session modification OPTIONS Queries a participant about their media capabilities, and finds them, but doesnt invite BYE Ends a clients participation in a session ACK For reliability and call acceptance CANCEL Terminates a search REGISTER Informs a SIP server about the location of a user SIP Tutoiral 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 SIP Message Syntax Many header fields from http Payload contains a media description SDP - Session Description Protocol INVITE sip:[email protected] SIP/2.0 From: J. Rosenberg Subject: SIP will be discussed, too To: A. Netravali Via: SIP/2.0/UDP Call-ID: [email protected] Content-type: application/sdp CSeq: 4711 INVITE

Content-Length: 187 v=0 o=user1 53655765 2353687637 IN IP4 s=Mbone Audio i=Discussion of Mbone Engineering Issues [email protected] c=IN IP4 t=0 0 m=audio 3456 RTP/AVP 0 SIP Tutoiral SIP Address Fields Request-URI Contains address of next hop server Rewritten by proxies based on result of Location Service To Address of original called party Contains optional display name From Address of calling party Optional display name SIP Tutoiral INVITE sip:[email protected] SIP/2.0 From: J. Rosenberg

;tag=76ah Subject: SIP will be discussed, too To: A. Netravali Via: SIP/2.0/UDP Call-ID: [email protected] Content-type: application/sdp Contact: sip:[email protected] CSeq: 4711 INVITE Content-Length: 187 v=0 o=user1 53655765 2353687637 IN IP4 s=Mbone Audio i=Discussion of Mbone Engineering Issues [email protected] c=IN IP4 t=0 0 m=audio 3456 RTP/AVP 0 SIP Responses Look Statusmuch Codelike Classes requests 100 Headers, - 199 bodies (1XX): Informational 200 - 299 (2XX): Success Differ in top line 300 - 399 (3XX): Redirection

Status Code 400 499 (4XX): Client -Numeric, 100 - 699Error 500 599 (5XX): Server Error -Meant for computer processing 600 699 (6XX): Global Failure Protocol behavior based on 100s digit Two groups Other digits give extra info 100 Reason - 199: Phrase Provisional Not Textreliable phrase for humans -Can 200 699:be Final, anything

Definitive Example 200 OK 180 Ringing SIP Tutoiral Example SIP Response Note how only difference is top line Rules for generating responses Call-ID, To, From, Cseq are mirrored in response to support matching Tag added to To field SIP Tutoiral SIP/2.0 200 OK From: J. Rosenberg ;tag=76ah To: A. Netravali ;tag=112 Via: SIP/2.0/UDP Call-ID: [email protected] CSeq: 4711 INVITE Contact: sip:[email protected]

SIP Transport Reliability SIP Messages mechanisms over UDPdepend or TCP on SIP request method INVITE Reliability mechanisms defined for UDP anything except INVITE UDP Preferred Reason: Fasteroptimized for phone calls No connection state needed in kernel Multicast possible (later) SIP Tutoiral INVITE reliability INV INV Client retransmits INVITE with exponential backoff INV 500ms, 1s, 2s, 4s, 8s.. Retransmissions cease when provisional response arrives Next hop should send 100 Trying to stop retransmissions INV Response retransmitted when request retransmissions arrive

Ring... Final response retransmitted with exponential backoff up to 4s 100 Trying May take a long time to answer phone!! INV ACK sent on receipt of final response 100 Trying 200 OK 200 OK ACK C SIP Tutoiral S Non-INVITE Reliability BYE BYE Responses should come quickly No need to ring phone BYE Request retransmitted w/ exponential backoff, up to 4s 100 Trying BYE If provisional response received, request retransmitted at 4s intervals After 4s, request retransmitted every 4s

Response retransmitted on receipt of request Thats why request must be retransmitted after provisional BYE - protect against response loss no ACK 200 OK BYE 200 OK C SIP Tutoiral S TCP Transport Reliability rules for TCP same as UDP with one change Requests not retransmitted However, 2xx final responses still retransmitted ACK is still sent Reason? Handles case of a mix of UDP and TCP connections SIP Tutoiral Hop by Hop vs. End to End INVITE INVITE

100 Trying Reliability can be HBH or E2E 100 Trying INVITE HBH implies message transmitted reliably between each entity (UAC to proxy, proxy to UAS) 100 Tryingbetween UAC and UAS only E2E implies proxies simply forward requests, reliability assured SIP uses HBH reliability almost Stateless proxies simply forward requests 200 OK response to INVITE is E2E reliable!!! UAC must see all 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK ACK 200 OK 200 OK ACK UAC SIP Tutoiral ACK Proxy

UAS Registrations Proxy needs to know where users are sitting SIP REGISTER message allows clients to tell proxy servers REGISTER properties Contains list of current locations in Contact headers Registrar identified in Request URI Identifies registered user in To field Identifies person performing registration in From field (usually = To) Expires header indicates desired lifetime Can be different for each Contact May be body SIP Tutoiral REGISTER SIP/2.0 To: Rosenberg From: Claribel Call-ID: [email protected] CSeq: 123 REGISTER

Contact: sip:[email protected] Contact: Expires: 3600 Registration Responses Registrar behavior on receiving REGISTER check if domain is its own authorize user in From field Add address bindings of (To field) -> (Contact list) Lower expiration time if too long Return, in response, list of all current registrations Return, in response, expiration time for all registrations SIP Tutoiral SIP/2.0 200 OK To: Rosenberg From: Claribel Call-ID: [email protected] CSeq: 123 REGISTER Contact: sip:[email protected] Contact: Contact: mailto:[email protected] ;expires=Thu, 01 Dec 2002 16:00:00 GMT

Expires: 3600 Registration Details Querying User Agent list must of current refreshregistrations registrations by resending before expiration Send REGISTER with no Contact headers Each contact must be refreshed independently contains listsame of current registrations Response Can place them all in REGISTER Distributed Can use separate registrations REGISTER for each Registrations for the same user (I.e., same To field) can come from different Deleting Registrations hosts, each registering different contacts Send a refresh with Expires: 0

Example: my cell phone registers itself, my PC registers itself SIP Tutoiral Forking A proxy may have more than one address for a user Happens when more than one SIP URL is registered for a user Can happen based on static routing configuration INVITE [email protected] In this case, proxy may fork Forking is when proxy sends request to more than one proxy at once INVITE First 200 OK that is received is forwarded upstream [email protected] All other unanswered requests cancelled INVITE [email protected] SIP Tutoiral More on Forking Many Main benefits proxies can fork, resulting in tree of proxies Allows rapid search for user at many locations Best response to forked request is chosen and forwarded upstream

rings than one place at a time Phone First 200 OKmore received Two First variations 600 received if no 200 OK Lowest Sequential numbered Search:response Try first address, after all responses only if that are failsreceived, try second given address none was or 600 200 Parallel Search: Try all addresses at once (as in previous slide) Note usually only one response is forwarded upstream Hybrid approaches possible SIP Tutoiral CANCEL INV CANCEL used to take back 100 a request INV 100 INV Main application: stop 100 phones from ringing which have not yet answered 200 Semantics Always refers to another request If you get a CANCEL, and havent answered request, answer request with 487. Answer CANCEL with 200. Can be generated by proxies or UA - usually proxies

OK 487 ACK ACK UAC SIP Tutoiral CANCEL 200 Proxy UAS UAS Response Routing: Via Via Responses header reflected take same in path response as requests from UAS When How does proxy server

receives know response where to send response? check Remember if topmost whereVia request is itselfcame from If Place yes, information remove andincheck request, nextget header it back in response!! Send response to address in next Via Via Header no next Via, If Traces path ofresponse request is for me Stack header Each proxy pushes its address in requests Pops its address in responses SIP Tutoiral Via Operation Via: B Via: A 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 Received Tags Many cases where address in NAT Multihomed hosts INVITE sip:[email protected] SIP/2.0 sip:[email protected];tag=76ah viaFrom: is wrong! To: sip:[email protected] Via: SIP/2.0/UDP;received= Rather, source address of packet is more correct Solution: receive tag If source address of packet doesnt equal viaresult address top End Proxy inserts received parameter into via header Responses sent to source IP Indicates source IP address address of request, but to port in via header That address is used to send responses Strange combination, but it works

well for multihomed hosts SIP Tutoiral Stateful vs. Stateless Proxies A proxy must be stateful when Stateless Proxy Definition forks (thisrequest, requires special processing responses to remember best one) It Receives acccess location of services, forwards request It sends a request using multicast Forgets it even saw request after forwarding it It uses TCP When response comes, uses Via header to figure out where to send it

Stateful vs. Stateless Stateful Proxy Definition Stateless scales very well Remembers it saw the request after forwarding it No memory requirements Can Tiny apply additional logic after response arrives socket requirements Stateful is better for services Each proxy can independently decide which to be Call Stateful Remembers multiple transactions being associated with a call SIP Tutoiral Loop Detection With all this forking and forwarding, request may hit the same proxy twice! Need mechanisms to prevent this from looping forever SIP provides two

Max-Forwards Counter decremented by 1 on each hop Discard request when zero Via based loop prevention and detection Every proxy inserts address Check for my address when request comes SIP Tutoiral Loop Detection: Details Branch Spirals ID Component 1 When a request proxy forks, hits server each twice, fork has butawith different different component request 1, URI so response with forked requestforwards to [email protected]! associated Example: [email protected] Not an Branch IDerror

Component 2 Hash of To, From, Call-ID, Cseq and incoming request URI Must detect difference between loop and spiral When you receive a request, check for Via headers with your own address Solution For those with that address, recompute hash, see if it matches value in branch ID Via header contains branch ID parameter If match, loop, if not, spiral Branch ID has two components SIP Tutoiral Routing of Subsequent Requests Initial SIP request sent through many proxies No need per se for subsequent requests to go through proxies Proxy Each proxy can decide whether it wants to receive subsequent INVITE requests Inserts Record-Route header containing its address Proxy For subsequent requests, users insert Route header Contains sequence of proxies (and final user) that should receive request BYE Proxy

UA1 UA2 SIP Tutoiral Construction of Route Header UAC Each Constructs proxy may insert Route a RR Flips Stackorder property of Route headers Places Any URL Contact meeting from two200 requirements OK at bottom Routes Result is Route backset to that server Identifies the target recipient in some way UAS Constructs Route

UAS Takes reflects all RR in 200 OK Response RR from INVITE Adds Proxies Contact can modify from INVITE RR theyatinserted the end Allows Route for UAC/UAS to be different, which it should be! SIP Tutoiral Example Route Construction INV sip:[email protected] m: sip:[email protected] INV sip:[email protected] m:sip:[email protected] RR:sip:[email protected];maddr=B Proxy Addr: B UAC Domain: t

SIP/2.0 200 OK Sip:[email protected] m:sip:[email protected] RR:sip:[email protected];maddr=C RR:sip:[email protected];maddr=B UAC Route: Sip:[email protected];maddr=B, Sip:[email protected];maddr=C Sip:[email protected] SIP Tutoiral INV sip:[email protected] m:sip:[email protected] RR:sip:[email protected];maddr=C RR:sip:[email protected];maddr=B Proxy Addr: C SIP/2.0 200 OK Domain: t2 m:sip:[email protected] RR:sip:[email protected];maddr=C RR:sip:[email protected];maddr=B UAS SIP/2.0 200 OK m:sip:[email protected] Sip:[email protected] RR:sip:[email protected];maddr=C RR:sip:[email protected];maddr=B UAS Route: Sip:[email protected];maddr=C, Sip:[email protected];maddr=B

Sip:[email protected] Setting up the Session SDP INVITE also contains conveys the other Session information Description about Protocol session(SDP) in the body Time it will take place SDP conveys the desired session from the callers perspective originated Who Session consiststhe of session a number of media streams of thecan session subject Each stream be audio, video, text, application, etc. URL for more information

Also contains information needed about the session SDP origins are multicast sessions on the mbone codecs INVITE Originator addresses of and ports is not originator of session SIP Tutoiral Anatomy of SDP SDP contains informational headers version (v) origin(o) - unique ID information (I) Time of the session Followed by a sequence of media streams Each media stream contains an m line defining port transport codecs

v=0 o=user1 53655765 2353687637 IN IP4 s=Mbone Audio i=Discussion of Mbone Engineering Issues [email protected] t=0 0 m=audio 3456 RTP/AVP 0 78 c=IN IP4 a=rtpmap:78 G723 m=video 4444 RTP/AVP 86 c=IN IP4 a=rtpmap:86 H263 Media Stream also contains c line SIP Tutoiral Address information Negotiating the Session Called party receives SDP offered by caller Each stream can be accepted rejected v=0 o=user2 16255765 8267374637 IN IP4

t=0listing 0 Accepting involves generating an SDP same stream m=audio 3456 RTP/AVP 0 port number and address of called party c=IN IP4 subset of codecs from SDP in request m=video 0 RTP/AVP 86 c=IN Rejecting indicated by setting port to zeroIP4 Resulting SDP returned in 200 OK Media can now be exchanged SIP Tutoiral Audio stream accepted, PCMU only. Video stream rejected Changing Session Parameters Once call is started, session can be modified INVITE 200 ACK Possible changes

Add a stream Remove a stream Change codecs Change address information INVITE Call hold is basically a session change 200 Accomplished through a re-INVITE reINVITE ACK Same session negotiation as INVITE, except in middle of call Rejected re-INVITE - call still active! C SIP Tutoiral S Hanging Up INVITE How to hang up depends on when and who100 After call is set up either party sends BYE request

Hangup CANCEL 200 OK Accept From caller, before call is accepted send CANCEL 200 OK BYE is bad since it may not reach the same set of users that got INVITE If call is accepted after CANCEL, then send BYE BYE From callee, before accepted Reject with 486 Busy Here 200 OK C SIP Tutoiral ACK S Calls, Call Legs and Transactions Call is a set of point to point SIP relationships Call-ID

Call-ID local participant Call Leg (aka Dialog) is a point to point SIP relationship Call-ID + To + from Transaction is a request/response Call-ID + To + From + CSeq Remote participant CSeq SIP Tutoiral CSeq Remote participant CSeq CSeq Call Flow for basic call: UA to proxy to UA Call setup 100 trying hop by hop 180 ringing 200 OK acceptance

Call parameter modification INVITE 100 Trying 180 Ringing re-INVITE 200 OK Same as initial INVITE, updated session description Termination INVITE 100 Trying 180 Ringing 200 OK ACK RTP BYE method BYE 200 OK SIP Tutoiral Addressing Scalability Edge

Internet model for scalability CSF Proxy Fast and simple in core CSF Proxy Smarter towards periphery Example: RSVP vs. Diffserv SIP uses Internet Model Stateless proxies in the core are fast Stateful proxies at periphery Call-stateful proxies at edge Periphery SF Proxy CSF Proxy CSF Proxy SF Proxy Core

SL Proxy CSF Proxy CSF Proxy SF Proxy SF Proxy CSF Proxy CSF Proxy CSF Call Stateful SF Stateful SL Stateless SIP Tutoiral Fault Tolerance DCS Server State crashes Header have little effect Under

No calls development terminated, even for Call Stateful proxies running TCP Much Transactions like httpincookies progress complete if a backup is available (SRV) Will allow proxies to ask for data back in subsequent requests Protocol State stored in messages fully call stateful servers Allows Responses always routed back that are highly recoverable!! TCP connections may even be re-opened to send responses! Branch parameter as a tool of the proxy SIP Tutoiral Extensibility Model Goal: Ensure baseline operation always Features works that must be Protocol can be extended by understood are given names Defining new headers and semantics Defining new parameters and semantics

Defining new methods Defining new bodies Feature naming IANA registered naming Clients can insist server New parameters and headers can be optional understand a feature Safely ignored by recipient Spec mandates that unknown headers paramscan are place ignoreda feature in a and Server Maximizes interoperability response if client understands it SIP Tutoiral Extensibility: Client requests Feature INVITE Foo: blah-blah Feature represented by new header, parameter and/or new behavior Bar: la-la Client places needed feature in special header

in request Require: foo, bar Require: want UAS to understand feature Proxy-require: want proxies to understand feature 420 Bad Extension Unsupported: foo and lists If UAS or proxy doesnt know feature, it responds with error unknown features in Unsupported header Client can resubmit request INVITE Bar: la-la Require: bar C SIP Tutoiral S Extensibility: Server wants feature Client indicates features it understands in Supported header in request INVITE Supported: foo, bar All features must be listed

Always place header in every request Server can use feature if its listed 201 OK If server applies feature in response, it includes a Require header Foo: blah-blah Require: foo indicating the feature C SIP Tutoiral S Extensibility: New Methods Methods define fundamental behavior Client can send request with new method GOAWAY To: joe UAS rejects requests with unknown methods 405 response list allowed methods in Allow header 405 Method Not Allowed Allow: INVITE, BYE, OPTIONS, ACK, CANCEL Proxies dont care about methods Proxy rules are independent of method

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

PGP S/MIME Transport Mechanisms SIP Tutoiral HTTP Basic and Digest Credentials Challenge Response can be cached Subsequent Client sends requests request to the same server can contain same credentials If Server they expire, responds server withissues 401 or401/407 407 with challenge Client ACKs Two relationships again (higher Cseq) with credentials Client Proxy sends Serverrequest challenges

UAC OK,challenges server processes, If UAS UAC else sends 401/407 again is Stateless Mechanism Multiple credentials need toofknow thatand a challenge was issued Dont Any number proxies a UAS can issue challenge just credentials Requests Credentials arecontain accumulated SIP Tutoiral HTTP Basic Authentication Cleartext Password INVITE Base64 encoded Not useful alone 401 Authorize Yourself WWW-Authenticate: Basic realm=mufasa May be useful within a TLS connection from client to server Emulates http usage of client authentication Not widely implemented Depecated from bis INVITE Authorization: Basic QWxhZGRpbjpvcGVuI== 200 OK SIP Tutoiral HTTP Digest Authentication Why Server

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

PGP Requires RFC2543 specified request tosecurity be canonicalized based on PGP Standardized format over which signature is computed Provided devices to maintain order of headers and parameters Requires Client to server authentication Deprecated! Client to server encryption No Server implementations to client authentication Canonicalization Server to client encryption a pain Other approaches more mature Uses public keys Requires PGP community General problem with PGP SIP Tutoiral

Coming soon: S/MIME S/MIME is an IETF standard for email security Provides authentication and encryption Based on X.409 Public Key Certificates The kind you get from Verisign Some infrastructure in place Can be shipped with message INVITE sip:[email protected] SIP/2.0 From: sip:[email protected] To: sip:[email protected] Content-Type: multipart SDP INVITE sip:[email protected] SIP/2.0 From: sip:[email protected] To: sip:[email protected] Content-Type: SDP Big overhead Message contains payload, signed piece, and signature, maybe certificate SDP text Requires multipart signature certificate SIP Tutoiral Transport Security Previous mechanisms allow for E2E Security Works through any number of proxies

Proxy Proxies dont need to be trusted Security within SIP layer Hop by Hop Security Possible as well Proxies have trust relationship with each other Proxy E2E security by transitivity Relies on all hops doing security Proxy UA1 Secure Tunnel SIP Tutoiral UA2 Transport Security Requires IPSec no SIP extensions UDP also Several

techniques widely implemented Not TLS/SSL barely supported IKE IPSec Resides in OS TLS/SSL Firewall and NAT Traversal Widely implemented Key exchange works Resides in application layer TCP only SIP Tutoiral What about QoS? QoS is handled orthogonally by other protocols Voice will be negligible compared to data anyway Signaling path isnt same as media path at all!!

Even set of ISPs is different Separation allows yahoo to be a phone company Many other apps need QOS, keep one mechanism SIP Tutoiral Models of QoS for SIP Diffserv users mark TOS byte in their RTP packets olympic service model total separation no admission control end to end signaling per call minute metering SIP Tutoiral RSVP/diffserv core w/ ringing holdback dont ring unless resources reserved

use RSVP in periphery resource reservations starts after INVITE ringing and continued signaling after RSVP done Quality of Service INV 183 Progress SIP is not a Reservation Protocol, but. . . PRACK Need Coupling Between Signaling and Reservation Do not ring phone until resources reserved Resource Reservation Uses a new extension to SIP COMET INVITE contains a header that indicates there 200 OK is a precondition to ringing the phone Preconditions include

QoS establishment Security When preconditions met, COMET request is sent Phone can then ring 200 OK Pickup ACK Media Caller SIP Tutoiral Ringing Callee Information Resource Jonathan Rosenberg [email protected] +1 973-952-5000 SIP Tutoiral

Recently Viewed Presentations

  • IAEA Standards for Packaging and Shipping of Radioactive Material

    IAEA Standards for Packaging and Shipping of Radioactive Material

    Considerations to launch a NPP 1/3. By its nature a nuclear power programme involves issues associated with nuclear material, ionizing radiation and the related national and internationalchallenges.. This is a major undertaking requiring careful planning, preparation and investment in a...
  • Principles of Art, Media & Processes, Sculpture, Architecture

    Principles of Art, Media & Processes, Sculpture, Architecture

    NON-OBJECTIVE ART. Imitationalism—the realistic presentation of subject matter or the literal qualities Formalism—design qualities or the way an art is organized (elements & principles of art) Emotionalism—ability to communicate an emotion or idea to the viewer. (mood, feelings, ideas)
  • e2 d i l S Attention-Getter/Link to Audience:

    e2 d i l S Attention-Getter/Link to Audience:

    Your attention-getter or link to audience should grab your audience's attention and draw them in to your argument. It should make them want to continue listening to your speech because they want to know what else you have to say....
  • 'An analysis of a Gulf Cooperation Council (GCC) Private ...

    'An analysis of a Gulf Cooperation Council (GCC) Private ...

    The importance and application of innovation management in the delivery of FM services by the FM providers in Malaysia is yet to be gauged. ... - Focus on quality, reliability and value. - Inception of IFM in Malaysia - FM...
  • Welcome! []

    Welcome! []

    Survival Accountability Benchmarking Improvement Focus resources "Academic libraries are facing…major threats in the global digital environment and an increasingly competitive environment, and must improve the quality of their services in order to survive" (2001, Rowena Cullen, Library Trends, 49:4) Current...
  • Which Spatial Partition Trees Are Adaptive to Intrinsic

    Which Spatial Partition Trees Are Adaptive to Intrinsic

    Empirical estimates of local covariance dimension Axis parallel splitting rules (dyadic / kd tree) don't always adapt to intrinsic dimension; the upper bounds have matching lower bounds. On the other hand, the irregular splitting rules (RP / PD / 2M...
  • Conquest and Exile - Quia

    Conquest and Exile - Quia

    Conquest and Exile Chapter 13 The fall of the south After Rehoboam The North had fallen into the hands of the Assyrians South is left with Rehoboam's descendants Hezekiah takes over the throne of David after the North was conquered...
  • Procure to Pay Project Demo Days June, 2019

    Procure to Pay Project Demo Days June, 2019

    Register for the class in MyPath. 20 minutes. UR Procurement Invoice Match Exception Class - Required for Requisitioners. This training provides an overview of the 3 way matching process between the Purchase Order (PO), Receipt, and Invoice and a demonstration...