SIP: Session Initiation Protocol

SIP: Session Initiation Protocol Comes from IETF (RFC 3261) SIP long-term vision All telephone calls and video conference calls take place over the Internet People are identified by names or e-mail addresses, rather than by phone numbers. You can reach the callee, no matter where the callee roams, no matter what IP device the callee is currently using. SIP services Setting up a call Provides mechanisms for caller to let callee know she wants to establish a call Provides mechanisms so that caller and callee can agree on media type and encoding. Provides mechanisms to end call. Determine current IP address of callee. Maps mnemonic identifier to current IP address Call management Add new media streams during call Change encoding during call Invite others Transfer and hold calls Transport Layer 3-1 Transport Layer 3-2 Alice SIP: Setting up a call to a known IP address 167.180.112.24 time INVITE bob@193.64.210.89 c=in IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 port 5060 port 5060 port 38060 200 OK c=in IP4 193.64.210.89 m=audio 48753 RTP/AVP 3 GSM ACK port 5060 µ Law audio 193.64.210.89 port 48753 time Bob Bob's terminal rings Alice s SIP invite message indicates her port number & IP address. Indicates encoding that Alice prefers to receive (PCM ulaw) Bob s 200 OK message indicates his port number, IP address & preferred encoding (GSM) SIP messages can be sent over TCP or UDP; here sent over RTP/UDP. Default SIP port number is 5060. Transport Layer 3-3 Example of SIP message INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip:alice@hereway.com To: sip:bob@domain.com Call-ID: a2e3a@pigeon.hereway.com Content-Type: /sdp Content-Length: 885 c=in IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 Notes: HTTP message syntax sdp = session description protocol Call-ID is unique for every call. Here we don t know Bob s IP address. Intermediate SIP servers will be necessary. Alice sends and receives SIP messages using the SIP default port number 5060. Alice specifies in Via: header that SIP sends and receives SIP messages over UDP Transport Layer 3-4 SIP: Name translation and user location Caller wants to call callee, but only has callee s name or e-mail 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 be based on: time of day (work, home) caller (don t want boss to call you at home) status of callee (calls sent to voicemail when callee is already talking to someone) Service provided by SIP servers: SIP registrar server SIP proxy server SIP registrar When Bob starts SIP, sends SIP REGISTER message to Bob s registrar server (similar function needed by Instant Messaging) Register Message: REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: sip:bob@domain.com To: sip:bob@domain.com Expires: 3600 Transport Layer 3-5 Transport Layer 3-6 1

SIP proxy Alice sends invite message to her proxy server contains address sip:bob@domain.com Proxy responsible for routing SIP messages to callee possibly through multiple proxies. Callee sends response back through the same set of proxies. Proxy returns SIP response message to Alice contains Bob s IP address Note: proxy is analogous to local DNS server Transport Layer 3-7 SIP proxy example Caller jim@umass.edu with places a call to keith@upenn.edu SIP proxy SIP registrar upenn.edu SIP registrar eurecom.fr (1) Jim sends INVITE umass.edu 3 4 message to umass SIP proxy. (2) Proxy forwards 1 7 5 request to upenn 8 6 registrar server. (3) upenn server returns 9 redirect response, SIP SIP 197.87.54.21 indicating that it should 217.123.56.89 try keith@eurecom.fr (4) umass proxy sends INVITE to eurecom registrar. (5) eurecom registrar forwards INVITE to 197.87.54.21, which is running Keith s SIP. (6-8) SIP response sent back (9) media sent directly between s. Note: also a SIP ACK message, which is not shown. Transport Layer 3-8 2 Lecture 3: Transport layer I TDTS41 Computer s Lecture 3: Transport layer I 1 Transport-layer services 2 Multiplexing and demultiplexing 3 Connectionless : UDP 4 Principles of reliable data transfer Juha Takkinen, juhta@ida.liu.se IDA/ADIT/IISLAB, Linköpings universitet 2005-08-29 Slides are modified from J.F Kurose and K.W. Ross Transport Layer 3-9 Transport Layer 3-10 Transport services and protocols Transport vs. layer provide logical communication between app processes running on different hosts protocols run in end-systems sender-side: breaks app messages into segments, passes to layer -side: reassembles segments into messages, passes to app layer more than one protocol available to apps Internet: TCP and UDP logical end-end layer: logical communication between hosts layer: logical communication between processes relies on, enhances, layer services Household analogy: 12 kids sending letters to 12 kids processes = kids app messages = letters in envelopes hosts = houses protocol = Ann and Bill -layer protocol = postal service Transport Layer 3-11 Transport Layer 3-12 2

Internet -layer protocols reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of best-effort IP services not available: delay guarantees bandwidth guarantees logical end-end Lecture 3: Transport layer I 1 Transport-layer services 2 Multiplexing and demultiplexing 3 Connectionless : UDP 4 Principles of reliable data transfer Transport Layer 3-13 Transport Layer 3-14 Multiplexing/demultiplexing Demultiplexing at rcv host: delivering received segments to correct socket link = socket P3 = process P1 P1 link host 1 host 2 Multiplexing at send host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) P2 P4 host 3 link Transport Layer 3-15 How demultiplexing works host receives IP datagrams each datagram has source IP address & destination IP address each datagram carries one -layer segment each segment has source & destination port number (recall: well-known port numbers for specific s) host uses IP addresses & port numbers used to direct segment to appropriate socket 32 bits source port # dest. port # other header fields data (message) -level (TCP/UDP) segment format Transport Layer 3-16 Connectionless demultiplexing Connectionless demultiplexing, cont'd Create sockets with port numbers: DatagramSocket mysocket1 = new DatagramSocket(99111); DatagramSocket mysocket2 = new DatagramSocket(99222); UDP socket identified by two-tuple: (dest. IP address, dest. port number) When host receives UDP segment: checks destination port number in segment directs UDP segment to socket with that port number IP datagrams with different source IP addresses and/or source port numbers directed to same socket DatagramSocket serversocket = new DatagramSocket(6428); P2 IP: A 9157 DP: 6428 6428 DP: 9157 SP provides return address P3 server IP: C 6428 DP: 5775 5775 DP: 6428 P1P1 IP:B Transport Layer 3-17 Transport Layer 3-18 3

Connection-oriented demultiplexing Connection-oriented demultiplexing, cont'd TCP socket identified by 4-tuple: source IP address source port number destination IP address destination port number host uses all four values to direct segment to appropriate socket Server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple Web servers have different sockets for each connecting non-persistent HTTP will have different socket for each request P1 IP: A 9157 S-IP: A P 4 P 5 server IP: C P 6 5775 S-IP: B 9157 S-IP: B P2 P1P3 IP:B Transport Layer 3-19 Transport Layer 3-20 Connection-oriented demux: Threaded Web Server Lecture 3: Transport layer I P1 P4 5775 S-IP: B P2 P1P3 1 Transport-layer services 2 Multiplexing and demultiplexing 3 Connectionless : UDP 4 Principles of reliable data transfer IP: A 9157 S-IP: A server IP: C 9157 S-IP: B IP:B Transport Layer 3-21 Transport Layer 3-22 UDP: User Datagram Protocol [RFC 768] UDP checksum (Internet checksum) bare bones Internet protocol best-effort service, UDP segments may be: lost delivered out of order to connectionless: no handshaking between UDP sender, each UDP segment handled independently of others Length, in bytes of UDP segment, including header 32 bits source port # dest port # length Application data (message) checksum UDP segment format Transport Layer 3-23 Goal: detect errors (e.g., flipped bits) in transmitted segment Sender: treat segment contents as sequence of 16-bit integers checksum: addition (using one s complement) of segment contents sender puts checksum value into UDP checksum field Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But there maybe errors nonetheless? Transport Layer 3-24 4

Internet Checksum Example One's complement addition When adding numbers, a carryout from the most significant bit needs to be added to the result Example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 Lecture 3: Transport layer I 1 Transport-layer services 2 Multiplexing and demultiplexing 3 Connectionless : UDP 4 Principles of reliable data transfer wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum checksum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 Transport Layer 3-25 Transport Layer 3-26 Principles of Reliable data transfer Reliable data transfer: Getting started important in,, and link layers top-10 list of important ing topics! rdt_send(): called from, (e.g., by app.). Passes data to deliver to upper layer deliver_data(): called by rdt to deliver data to upper send side receive side characteristics of unreliable channel will determine complexity of reliable data transfer (rdt) protocol Transport Layer 3-27 udt_send(): called by rdt, to transfer packet over unreliable channel to rdt_rcv(): called when packet arrives on rcv-side of channel Transport Layer 3-28 Reliable data transfer: Getting started, cont'd Rdt1.0: Reliable transfer over a reliable channel We will: incrementally develop sender & sides of a reliable data transfer protocol (rdt) consider only unidirectional data transfer but control info will flow in both directions! use finite state machines (FSM) to specify sender & : state: when in this state, next state is uniquely determined by next event state 1 event causing state transition actions taken on state transition event actions state 2 Assumptions: underlying channel is perfectly reliable no bit errors no loss of packets Show separate FSMs for sender &, respectively: sender sends data into underlying channel reads data from underlying channel packet = make_pkt(data) udt_send(packet) sender rdt_rcv(packet) extract (packet,data) Transport Layer 3-29 Transport Layer 3-30 5

Rdt2.0: Channel with bit errors underlying channel may flip bits in packet need checksum to detect bit errors the question: How to recover from errors: acknowledgements (ACKs): explicitly tells sender that pkt was received OK negative acknowledgements (NAKs): explicitly tells sender that received pkt had errors sender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection feedback: control msgs (ACK, NAK) from to sender rdt2.0: FSM specification snkpkt = make_pkt(data, checksum) ACK or NAK isack(rcvpkt) sender isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) notcorrupt(rcvpkt) udt_send(ack) Transport Layer 3-31 Transport Layer 3-32 rdt2.0: Operation with no errors snkpkt = make_pkt(data, checksum) ACK or NAK isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) rdt2.0: Error scenario snkpkt = make_pkt(data, checksum) ACK or NAK isnak(rcvpkt) corrupt(rcvpkt) udt_send(nak) isack(rcvpkt) isack(rcvpkt) notcorrupt(rcvpkt) udt_send(ack) notcorrupt(rcvpkt) udt_send(ack) Transport Layer 3-33 Transport Layer 3-34 rdt2.0 has a fatal flaw! rdt2.1: Sender that handles garbled ACK/NAKs What happens if ACK/NAK corrupted? sender doesn t know what happened at! can t just retransmit: possible duplicate Handling duplicates: sender adds sequence number to each pkt sender retransmits current pkt if ACK/NAK garbled discards (doesn t deliver up) duplicate pkt stop-and-wait Sender sends one packet, then waits for response && notcorrupt(rcvpkt) && isack(rcvpkt) ( corrupt(rcvpkt) isnak(rcvpkt) ) sndpkt = make_pkt(0, data, checksum) call 0 from ACK or NAK 1 ACK or NAK 0 ( corrupt(rcvpkt) isnak(rcvpkt) ) && notcorrupt(rcvpkt) && isack(rcvpkt) call 1 from sndpkt = make_pkt(1, data, checksum) Transport Layer 3-35 Transport Layer 3-36 6

rdt2.1: Receiver that handles garbled ACK/NAKs rdt2.1: Discussion (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) notcorrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) 0 from 1 from notcorrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) Transport Layer 3-37 Sender: seq. # added to pkt two seq. #s (0, 1) will suffice. Why? must check if received ACK/NAK corrupted twice as many states state must remember whether current pkt has seq. # 0 or 1 Receiver: must check if received packet is duplicate state indicates whether 0 or 1 is expected seq. # of pkt note: Receiver can not know if its last ACK/NAK was received OK at sender Transport Layer 3-38 rdt2.2: A NAK-free protocol rdt2.2: Sender and (fragments of FSM) same functionality as rdt2.1, but using ACKs only instead of NAK, sends ACK for last pkt that was received OK must explicitly include seq. # of the pkt being ACKed duplicate ACK at sender results in same action as NAK: retransmit current pkt Transport Layer 3-39 (corrupt(rcvpkt) has_seq1(rcvpkt)) sndpkt = make_pkt(0, data, checksum) call 0 from 0 from ACK 0 sender FSM fragment FSM fragment notcorrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack1, chksum) ( corrupt(rcvpkt) isack(rcvpkt,1) ) && notcorrupt(rcvpkt) && isack(rcvpkt,0) Transport Layer 3-40 rdt3.0: Channel with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions will be of help, but not enough Approach: sender waits reasonable amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but use of seq. #s already handles this must specify the seq. # of pkt being ACKed requires countdown timer rdt3.0 sender call 0from && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout ( corrupt(rcvpkt) isack(rcvpkt,0) ) sndpkt = make_pkt(0, data, checksum) Wait for ACK1 Wait for ACK0 call 1 from sndpkt = make_pkt(1, data, checksum) ( corrupt(rcvpkt) isack(rcvpkt,1) ) timeout && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer Transport Layer 3-41 Transport Layer 3-42 7

rdt3.0 in action rdt3.0 in action Transport Layer 3-43 Transport Layer 3-44 Performance of rdt3.0 rdt3.0: Stop-and-wait operation rdt3.0 works, but performance stinks example: 1-Gbps link, 15 ms end-to-end prop. delay, 1-KB packet: T transmit = L (packet length in bits) 8kb/pkt = R (transmission rate, bps) 10**9 b/sec = 8 microsecs sender first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R RTT first packet bit arrives last packet bit arrives, send ACK U sender = L / R RTT + L / R =.008 30.008 = 0.00027 ACK arrives, send next packet, t = RTT + L / R U sender : utilization fraction of time sender busy sending 1KB pkt every 30 msec -> 33 KB/sec throughput over 1-Gbps link protocol limits use of resources! U sender = L / R RTT + L / R =.008 30.008 = 0.00027 Transport Layer 3-45 Transport Layer 3-46 Pipelined protocols Pipelining: sender allows multiple, in-flight, yet-tobe-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or Pipelining: Increased utilization first packet bit transmitted, t = 0 last bit transmitted, t = L / R RTT ACK arrives, send next packet, t = RTT + L / R sender first packet bit arrives last packet bit arrives, send ACK last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK Two generic forms of pipelined protocols: go-back-n and selective repeat Transport Layer 3-47 U sender = 3 * L / R RTT + L / R =.024 30.008 = 0.0008 Increase utilization by a factor of 3! Transport Layer 3-48 8

Go-back-N Sender: k-bit seq. # in pkt header window of up to N, consecutive unacked pkts allowed ACK(n): ACKs all pkts up to, including seq. # n - cumulative ACK may deceive duplicate ACKs (see ) timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq.-# pkts in window Transport Layer 3-49 GBN: Sender (extended FSM) base=1 nextseqnum=1 && corrupt(rcvpkt) if (nextseqnum < base+n) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) nextseqnum++ } else refuse_data(data) timeout Wait udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt[nextseqnum-1]) notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else Transport Layer 3-50 GBN: Receiver (extended FSM) default expectedseqnum=1 Wait sndpkt = make_pkt(expectedseqnum,ack,chksum) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) sndpkt = make_pkt(expectedseqnum,ack,chksum) expectedseqnum++ ACK-only: always send ACK for correctly-received pkt with highest in-order seq. # may generate duplicate ACKs need only remember expectedseqnum out-of-order pkt: discard (don t buffer) -> no -buffering! Re-ACK pkt with highest in-order seq. # Transport Layer 3-51 GBN in action Transport Layer 3-52 Selective repeat Selective repeat: Sender and windows individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer sender only resends pkts for which ACK not received sender timer for each unacked pkt sender window N consecutive seq. #s again limits seq. #s of sent & unacked pkts Transport Layer 3-53 Transport Layer 3-54 9

Selective repeat Selective repeat in action sender data from : if next available seq. # in window, send pkt timeout(n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+n]: mark pkt n as received if n smallest unacked pkt, advance window base to next unacked seq. # pkt n in [rcvbase, rcvbase+n-1] send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet received pkt pkt n in [rcvbase-n,rcvbase-1] ACK(n) otherwise: ignore Transport Layer 3-55 Transport Layer 3-56 Selective repeat: Dilemma Example: seq. #s: 0, 1, 2, 3 window size=3 sees no difference in two scenarios! incorrectly passes duplicate data as new in (a) Q: What relationship between seq. # size and window size? Transport Layer 3-57 Sliding window: Sequence number space SeqNum field is finite; sequence numbers wrap around Sequence number space must be larger then number of outstanding frames Sender-window size SWS <= MaxSeqNum-1 is not sufficient suppose 3-bit SeqNum field (0... 7) SWS = Receiver-window size RWS = 7 sender transmit frames 0... 6 arrive successfully, but ACKs lost sender retransmits 0... 6 expecting 7, 0... 5, but receives second incarnation of 0... 5 SWS < (MaxSeqNum+1)/2 is correct rule Intuitively, SeqNum slides between two halves of sequence number space Transport Layer 3-58 Reliable delivery in ARPAnet: Concurrent logical channels Multiplex 8 logical channels over a single link Run stop-and-wait on each logical channel Maintain three state bits per channel channel busy current sequence number out next sequence number in Header: 3-bit channel # and 1-bit sequence # 4 bits in total same as sliding window protocol Separates reliability from order no errors and no packet loss, but not in order Lecture 3: Summary principles behind layer services: multiplexing, demultiplexing reliable data transfer TCP: in-order, no packet lost, and no errors flow control Next: instantiation and implementation in the Internet (UDP) TCP congestion control timer management Transport Layer 3-59 Transport Layer 3-60 10