SIP. SIP Services. Setting up a call to a known IP address. Setting up a call (more) Example of SIP message. Name translation and user locataion

Transcription

1 SIP Session Initiation Protocol Comes from IETF SIP long-term vision All telephone calls and video conference calls take place over the Internet People are identified y names or addresses, rather than y phone numers. You can reach the callee, no matter where the callee roams, no matter what IP device the callee is currently usg. SIP Services Settg up a call Provides mechanisms for caller to let callee know she wants to estalish a call Provides mechanisms so that caller and callee can agree on media type and encodg. Provides mechanisms to end call. Determe current IP address of callee. Maps mnemonic identifier to current IP address Call management Add new media streams durg call Change encodg durg call Invite others Transfer and hold calls 7: Multimedia Networkg 7-1 7: Multimedia Networkg 7-2 Alice Settg up a call to a known IP address INVITE o@ c=in IP m=audio RTP/AVP 0 port 5060 port 5060 port OK c=in IP m=audio RTP/AVP 3 GSM ACK port 5060 µ Law audio port Bo Bo's termal rgs Alice s SIP vite message dicates her port numer & IP address. Indicates encodg that Alice prefers to receive (PCM ulaw) Bo s 200 OK message dicates his port numer, IP address & preferred encodg (GSM) SIP messages can e sent over TCP or UDP; here sent over RTP/UDP. Settg up a call (more) Codec negotiation: Suppose Bo doesn t have PCM ulaw encoder. Bo will stead reply with 606 Not Acceptale Reply and list encoders he can use. Alice can then send a new INVITE message, advertisg an appropriate encoder. Rejectg the call Bo can reject with replies usy, gone, payment required, foridden. Media can e sent over RTP or some other protocol. time time Default SIP port numer is : Multimedia Networkg 7-3 7: Multimedia Networkg 7-4 Example of SIP message Name translation and user locataion INVITE sip:o@doma.com SIP/2.0 Via: SIP/2.0/UDP From: sip:alice@hereway.com To: sip:o@doma.com Call-ID: a2e3a@pigeon.hereway.com Content-Type: application/sdp Content-Length: 885 c=in IP m=audio RTP/AVP 0 Notes: HTTP message syntax sdp = session description protocol Call-ID is unique for every call. Here we don t know Bo s IP address. Intermediate SIP servers will e necessary. Alice sends and receives SIP messages usg the SIP default port numer 506. Alice specifies Via: header that SIP client sends and receives SIP messages over UDP 7: Multimedia Networkg 7-5 Caller wants to call callee, ut only has callee s name or address. Need to get IP address of callee s current host: user moves around DHCP protocol user has different IP devices (PC, PDA, car device) Result can e ased on: time of day (work, home) caller (don t want oss to call you at home) status of callee (calls sent to voic when callee is already talkg to someone) Service provided y SIP servers: SIP registrar server SIP proxy server 7: Multimedia Networkg 7-6

2 SIP Registrar When Bo starts SIP client, client sends SIP REGISTER message to Bo s registrar server (similar function needed y Instant Messagg) Register Message: REGISTER sip:doma.com SIP/2.0 Via: SIP/2.0/UDP From: sip:o@doma.com To: sip:o@doma.com Expires: 3600 SIP Proxy Alice sends vite message to her proxy server contas address sip:o@doma.com Proxy responsile for rg SIP messages to callee possily through multiple proxies. Callee sends response ack through the same set of proxies. Proxy returns SIP response message to Alice contas Bo s IP address Note: proxy is analogous to local DNS server 7: Multimedia Networkg 7-7 7: Multimedia Networkg 7-8 Example Caller jim@umass.edu places a call to keith@upenn.edu (1) Jim sends INVITE message to umass SIP proxy. (2) Proxy forwards request to upenn registrar server. (3) upenn server returns redirect response, dicatg that it should try keith@eurecom.fr SIP proxy umass.edu 1 8 SIP client SIP registrar upenn.edu SIP registrar eurecom.fr SIP client (4) umass proxy sends INVITE to eurecom registrar. (5) eurecom registrar forwards INVITE to , which is runng keith s SIP client. (6-8) SIP response sent ack (9) media sent directly etween clients. Note: also a SIP ack message, which is not shown. 7: Multimedia Networkg Comparison with H.323 H.323 is another signalg protocol for real-time, teractive H.323 is a complete, vertically tegrated suite of protocols for multimedia conferencg: signalg, registration, admission control, transport and codecs. SIP is a sgle component. Works with RTP, ut does not mandate it. Can e comed with other protocols and services. H.323 comes from the ITU (telephony). SIP comes from IETF: Borrows much of its concepts from HTTP. SIP has a We flavor, whereas H.323 has a telephony flavor. SIP uses the KISS prciple: Keep it simple stupid. 7: Multimedia Networkg 7-10 Chapter 7 le 7.1 Multimedia Networkg Applications 7.2 Streamg stored audio and video 7.3 Real-time Multimedia: Internet Phone study 7.4 Protocols for Real- Time Interactive Applications RTP,RTCP,SIP 7.5 Distriutg Multimedia: content distriution networks 7.6 Beyond Best Effort 7.7 Schedulg and 7.8 Integrated Services and Differentiated Services 7.9 RSVP 7: Multimedia Networkg 7-11 Content distriution networks (CDNs) Content replication Challengg to stream large files (e.g., video) from sgle orig server real time Solution: replicate content at hundreds of servers through Internet content downloaded to CDN servers ahead of time placg content close to user avoids impairments (loss, delay) of sendg content over long paths CDN server typically edge/access network orig server North America CDN distriution node CDN server S. America CDN server Europe CDN server Asia 7: Multimedia Networkg 7-12

3 Content distriution networks (CDNs) CDN example HTTP request for Content replication CDN (e.g., Akamai) customer is the content provider (e.g., CNN) CDN replicates customers content CDN servers. When provider updates content, CDN updates servers orig server North America CDN distriution node CDN server S. America CDN server Europe CDN server Asia orig server ( distriutes HTML replaces: with Orig server CDNs authoritative DNS server Neary CDN server DNS query for HTTP request for CDN company (cdn.com) distriutes gif files uses its authoritative DNS server to re redirect requests 7: Multimedia Networkg : Multimedia Networkg 7-14 More a CDNs Chapter 7 le rg requests CDN creates a map, dicatg distances from leaf ISPs and CDN nodes when query arrives at authoritative DNS server: server determes ISP from which query origates uses map to determe est CDN server CDN nodes create application-layer overlay network 7: Multimedia Networkg Multimedia Networkg Applications 7.2 Streamg stored audio and video 7.3 Real-time Multimedia: Internet Phone study 7.4 Protocols for Real- Time Interactive Applications RTP,RTCP,SIP 7.5 Distriutg Multimedia: content distriution networks 7.6 Beyond Best Effort 7.7 Schedulg and 7.8 Integrated Services and Differentiated Services 7.9 RSVP 7: Multimedia Networkg 7-16 Improvg QOS IP Networks Thus far: makg the est of est effort Future: next generation Internet with QoS guarantees RSVP: signalg for resource reservations Differentiated Services: differential guarantees Integrated Services: firm guarantees simple model for sharg and congestion studies: 7: Multimedia Networkg 7-17 Prciples for QOS Guarantees Example: 1MpsI P phone, FTP share 1.5 Mps lk. ursts of FTP can congest rer, cause audio loss want to give priority to audio over FTP Prciple 1 packet markg needed for rer to distguish etween different classes; and new rer policy to treat packets accordgly 7: Multimedia Networkg 7-18

4 Prciples for QOS Guarantees (more) what if applications misehave (audio sends higher than declared rate) policg: force source adherence to andwidth allocations markg and policg at network edge: similar to ATM UNI (User Network Interface) Prciples for QOS Guarantees (more) Allocatg fixed (non-sharale) andwidth to flow: efficient use of andwidth if flows doesn t use its allocation Prciple 2 provide protection (isolation) for one class from others 7: Multimedia Networkg 7-19 Prciple 3 While providg isolation, it is desirale to use resources as efficiently as possile 7: Multimedia Networkg 7-20 Prciples for QOS Guarantees (more) Summary of QoS Prciples Basic fact of life: can not support traffic demands eyond lk capacity Prciple 4 Call Admission: flow declares its needs, network may lock call (e.g., usy signal) if it cannot meet needs 7: Multimedia Networkg 7-21 Let s next look at mechanisms for achievg this. 7: Multimedia Networkg 7-22 Chapter 7 le Schedulg And 7.1 Multimedia Networkg Applications 7.2 Streamg stored audio and video 7.3 Real-time Multimedia: Internet Phone study 7.4 Protocols for Real- Time Interactive Applications RTP,RTCP,SIP 7.5 Distriutg Multimedia: content distriution networks 7.6 Beyond Best Effort 7.7 Schedulg and 7.8 Integrated Services and Differentiated Services 7.9 RSVP 7: Multimedia Networkg 7-23 schedulg: choose next packet to send on lk FIFO (first first ) schedulg: send order of arrival to queue real-world example? discard policy: if packet arrives to full queue: who to discard? Tail drop: drop arrivg packet priority: drop/remove on priority asis random: drop/remove randomly 7: Multimedia Networkg 7-24

5 Schedulg Policies: more Priority schedulg: transmit highest priority queued packet multiple classes, with different priorities class may depend on markg or other header fo, e.g. IP source/dest, port numers, etc.. Real world example? Schedulg Policies: still more round ro schedulg: multiple classes cyclically scan class queues, servg one from each class (if availale) real world example? 7: Multimedia Networkg : Multimedia Networkg 7-26 Schedulg Policies: still more Weighted Fair Queug: generalized Round Ro each class gets weighted amount of service each cycle real-world example? Goal: limit traffic to not exceed declared parameters Three common-used criteria: (Long term) Average Rate: how many pkts can e sent per unit time ( the long run) crucial question: what is the terval length: 100 packets per sec or 6000 packets per m have same average! Peak Rate: e.g., 6000 pkts per m. (ppm) avg.; 1500 ppm peak rate (Max.) Burst Size: max. numer of pkts sent consecutively (with no terveng idle) 7: Multimedia Networkg : Multimedia Networkg 7-28 Token Bucket: limit put to specified Burst Size and Average Rate. (more) token ucket, WFQ come to provide guaranteed upper ound on delay, i.e., QoS guarantee! arrivg traffic token rate, r ucket can hold tokens tokens generated at rate r token/sec unless ucket full over terval of length t: numer of packets admitted less than or equal to (r t + ). 7: Multimedia Networkg 7-29 ucket size, per-flow rate, R WFQ D = /R max 7: Multimedia Networkg 7-30

6 Chapter 7 le 7.1 Multimedia Networkg Applications 7.2 Streamg stored audio and video 7.3 Real-time Multimedia: Internet Phone study 7.4 Protocols for Real- Time Interactive Applications RTP,RTCP,SIP 7.5 Distriutg Multimedia: content distriution networks 7.6 Beyond Best Effort 7.7 Schedulg and 7.8 Integrated Services and Differentiated Services 7.9 RSVP 7: Multimedia Networkg 7-31 IETF Integrated Services architecture for providg QOS guarantees IP networks for dividual application sessions resource reservation: rers mata state fo (a la VC) of allocated resources, QoS req s admit/deny new call setup requests: Question: can newly arrivg flow e admitted with performance guarantees while not violated QoS guarantees made to already admitted flows? 7: Multimedia Networkg 7-32 Intserv: QoS guarantee scenario Resource reservation call setup, signalg (RSVP) traffic, QoS declaration per-element admission control QoS-sensitive schedulg (e.g., WFQ) request/ reply Call Admission Arrivg session must : declare its QOS requirement R-spec: defes the QOS eg requested characterize traffic it will send to network T-spec: defes traffic characteristics signalg protocol: needed to carry R-spec and T- spec to rers (where reservation is required) RSVP 7: Multimedia Networkg : Multimedia Networkg 7-34 Intserv QoS: Service models [rfc2211, rfc 2212] Guaranteed service: worst case traffic arrival: leaky-ucket-policed source simple (mathematically provale) ound on delay [Parekh 1992, Cruz 1988] arrivg traffic token rate, r ucket size, per-flow rate, R WFQ D = /R max Controlled load service: "a quality of service closely approximatg the QoS that same flow would receive from an unloaded network element." 7: Multimedia Networkg 7-35 IETF Differentiated Services Concerns with Intserv: Scalaility: signalg, matag per-flow rer state difficult with large numer of flows Flexile Service Models: Intserv has only two classes. Also want qualitative service classes ehaves like a wire relative service distction: Platum, Gold, Silver Diffserv approach: simple functions network core, relatively complex functions at edge rers (or hosts) Don t defe defe service classes, provide functional components to uild service classes 7: Multimedia Networkg 7-36

7 Diffserv Architecture Edge-rer Packet Markg Edge rer: per-flow traffic management marks packets as -profile and -profile markg r schedulg. profile: pre-negotiated rate A, ucket size B packet markg at edge ased on per-flow profile Rate A B Core rer: per class traffic management ufferg and schedulg ased on markg at edge preference given to -profile packets Assured Forwardg 7: Multimedia Networkg 7-37 Possile usage of markg: User packets class-ased markg: packets of different classes marked differently tra-class markg: conformg portion of flow marked differently than non-conformg one 7: Multimedia Networkg 7-38 Classification and Conditiong Packet is marked the Type of Service (TOS) IPv4, and Traffic Class IPv6 6 its used for Differentiated Service Code Pot (DSCP) and determe PHB that the packet will receive 2 its are currently unused Classification and Conditiong may e desirale to limit traffic jection rate of some class: user declares traffic profile (e.g., rate, urst size) traffic metered, shaped if non-conformg 7: Multimedia Networkg : Multimedia Networkg 7-40 Forwardg (PHB) PHB result a different oservale (measurale) forwardg performance ehavior PHB does not specify what mechanisms to use to ensure required PHB performance ehavior Examples: Class A gets x% of gog lk andwidth over time tervals of a specified length Class A packets leave first efore packets from class B Forwardg (PHB) PHBs eg developed: Expedited Forwardg: pkt departure rate of a class equals or exceeds specified rate logical lk with a mimum guaranteed rate Assured Forwardg: 4 classes of traffic each guaranteed mimum amount of andwidth each with three drop preference partitions 7: Multimedia Networkg : Multimedia Networkg 7-42

8 Chapter 7 le 7.1 Multimedia Networkg Applications 7.2 Streamg stored audio and video 7.3 Real-time Multimedia: Internet Phone study 7.4 Protocols for Real- Time Interactive Applications RTP,RTCP,SIP 7.5 Distriutg Multimedia: content distriution networks 7.6 Beyond Best Effort 7.7 Schedulg and 7.8 Integrated Services and Differentiated Services 7.9 RSVP 7: Multimedia Networkg 7-43 Signalg the Internet connectionless (stateless) forwardg y IP rers est effort service + = no network signalg protocols itial IP design New requirement: reserve resources along end-to-end path (end system, rers) for QoS for multimedia applications RSVP: Resource Reservation Protocol [RFC 2205] allow users to communicate requirements to network roust and efficient way. i.e., signalg! earlier Internet Signalg protocol: ST-II [RFC 1819] 7: Multimedia Networkg 7-44 RSVP Design Goals RSVP: does not 1. accommodate heterogeneous receivers (different andwidth along paths) 2. accommodate different applications with different resource requirements 3. make multicast a first class service, with adaptation to multicast group memership 4. leverage existg multicast/unicast rg, with adaptation to changes underlyg unicast, multicast res 5. control protocol overhead to grow (at worst) lear # receivers 6. modular design for heterogeneous underlyg technologies specify how resources are to e reserved rather: a mechanism for communicatg needs determe res packets will take that s the jo of rg protocols signalg decoupled from rg teract with forwardg of packets separation of control (signalg) and data (forwardg) planes 7: Multimedia Networkg : Multimedia Networkg 7-46 RSVP: overview of operation senders, receiver jo a multicast group done side of RSVP senders need not jo group sender-to-network signalg path message: make sender presence known to rers path teardown: delete sender s path state from rers receiver-to-network signalg reservation message: reserve resources from sender(s) to receiver reservation teardown: remove receiver reservations network-to-end-system signalg path error reservation error 7: Multimedia Networkg 7-47 Path msgs: RSVP sender-to-network signalg path message contents: address: unicast destation, or multicast group flowspec: andwidth requirements spec. filter flag: if yes, record identities of upstream senders (to allow packets filterg y source) previous hop: upstream rer/host ID refresh time: time until this fo times path message: communicates sender fo, and reversepath-to-sender rg fo later upstream forwardg of receiver reservations 7: Multimedia Networkg 7-48

9 RSVP: simple audio conference,,,, oth senders and receivers multicast group m1 no filterg: packets from any sender forwarded audio rate: only one multicast rg tree possile R1 RSVP: uildg up path state,, all send path messages on (address=m1, Tspec=, filter-spec=no-filter,refresh=100) Suppose sends first path message R1 7: Multimedia Networkg : Multimedia Networkg 7-50 RSVP: uildg up path state next, sends path message, creatg more state rers RSVP: uildg up path state,, send path msgs, completg path state tales R1 R2 R3 R1 R2 R3 7: Multimedia Networkg : Multimedia Networkg 7-52 reservation msgs: receiver-to-network signalg reservation message contents: desired andwidth: filter type: no filter: any packets address to multicast group can use reservation fixed filter: only packets from specific set of senders can use reservation dynamic filter: senders who s packets can e forwarded across lk will change (y receiver choice) over time. filter spec reservations flow upstream from receiver-to-senders, reservg resources, creatg additional, receiverrelated state at rers 7: Multimedia Networkg 7-53 RSVP: receiver reservation example 1 wants to receive audio from all other senders reservation msg flows uptree to sources only reserves enough andwidth for 1 audio stream reservation is of type no filter any sender can use reserved andwidth R1 7: Multimedia Networkg 7-54

10 RSVP: receiver reservation example 1 reservation msgs flows uptree to sources rers, hosts reserve andwidth needed on downstream lks towards RSVP: receiver reservation example 1 (more) next, makes no-filter reservation for andwidth forwards to R1, R1 forwards to and R2 (?) R2 takes no action, sce already reserved on () () () () () () () R1 R1 7: Multimedia Networkg : Multimedia Networkg 7-56 RSVP: receiver reservation: issues What if multiple senders (e.g.,,, ) over lk (e.g., )? aritrary terleavg of packets flow policed y leaky ucket: if ++ sendg rate exceeds, packet loss will occur () () () R1 () RSVP: example 2, are only senders send path messages as efore, dicatg filtered reservation Rers store upstream senders for each upstream lk will want to receive from (only) R1 7: Multimedia Networkg : Multimedia Networkg 7-58 RSVP: example 2, are only senders send path messages as efore, dicatg filtered reservation RSVP: example 2 receiver sends reservation message for source at andwidth propagated upstream towards, reservg, (-via- ; -via-r2 ) (-via- ) (-via-r2 ), (-via- ; -via-r3 ) (-via-r2 ) (-via- ), (-via- ;-via-r2()) (-via- ) (-via-r2 ), (-via- ; -via-r2 ) (-via-62 ) (-via- ()) R1 R2 R3, (-via-r3 ) (-via-r1 ) R1 R2 R3, (-via-r3 ()) (-via-r1 ) 7: Multimedia Networkg : Multimedia Networkg 7-60

11 RSVP: soft-state RSVP: soft-state senders periodically resend path msgs to refresh (mata) state receivers periodically resend resv msgs to refresh (mata) state path and resv msgs have TTL field, specifyg refresh terval suppose (sender) leaves with performg teardown eventually state rers will time and disappear!, (-via- ;-via-r2()) (-via- ) (-via-r2 ), (-via- ; -via-r3 ) (-via-62 ) (-via- ()), (-via- ;-via-r2()) (-via- ) (-via-r2 ), (-via- ; -via-r3 ) (-via-62 ) (-via- ()) R1 R2 R3, (-via-r3 ()) (-via-r1 ) 7: Multimedia Networkg 7-61 R1 R2 R3 gone fishg!, (-via-r3 ()) (-via-r1 ) 7: Multimedia Networkg 7-62 The many uses of reservation/path refresh recover from an earlier lost refresh message expected time until refresh received must e longer than time terval! (short timer terval desired) Handle receiver/sender that goes away with teardown Sender/receiver state will time and disappear Reservation refreshes will cause new reservations to e made to a receiver from a sender who has joed sce receivers last reservation refresh E.g., previous example, is only receiver, only sender. Path/reservation messages complete, data flows jos as sender, nothg happens until refreshes reservation, causg R3 to forward reservation to, which allocates andwidth RSVP: reflections multicast as a first class service receiver-oriented reservations use of soft-state 7: Multimedia Networkg : Multimedia Networkg 7-64 Multimedia Networkg: Summary multimedia applications and requirements makg the est of today s est effort service schedulg and policg mechanisms next generation Internet: Intserv, RSVP, Diffserv What else is eg done? Many, many research projects! Adaptive encodgs, e.g. Multiple description codg (MDC) Application to moile networks... Multicast tree construction usg overlays, techniques for handlg flash crowds. One of my M.Sc. students is workg on improved algorithms for application layer multicast for streamg live video. 7: Multimedia Networkg : Multimedia Networkg 7-66