1. Anna Sfairopoulou Page 1 SIP

2. Anna Sfairopoulou Page 2 What we will see... Signalling vs Media SIP standarization and design principles Message syntax SIP addressing SIP methods –Request messages –Response messages SIP entities (servers) Examples

3. Anna Sfairopoulou Page 3 Why SIP SIP  VoIP + WLAN  competition to cellular telephony? IMS component P2PSIP Application layer mobility using SIP

4. Anna Sfairopoulou Page 4 The simplest voice call 10.0.0.1 192.168.20.2 Listening on port 5060 Expecting UDP Expecting CODEC PCM A-law Knows port 5060 Knows UDP Knows CODEC PCM A-law Knows address 192.168.20.2 Internet Alice Bob Self-written C code: Open socket Take voice samples from microphone Send voice samples in UDP packets Self-written Java code: Open socket Wait for UDP packets Playback voice samples

5. Anna Sfairopoulou Page 5 What if... Alice doesn't know Bob's IP address? Alice uses a different codec? Bob is busy in a previous call? Bob is absent? Other media desired (e.g. Video)? Cesar would like to join in?  Some form of call control (a.k.a. SIGNALING) is needed!

6. Anna Sfairopoulou Page 6 Think about the road system...

7. Anna Sfairopoulou Page 7 Media vs Signaling To interchange user data, transport protocols are used –UDP –TCP To control that interchange, signaling protocols are used –RSVP –SIP –RTSP (+ RTP on top)

8. Anna Sfairopoulou Page 8 Signaling serves to... Set up and tear down VoIP calls/sessions Reserve bandwidth among routers Establish secure connections over the Internet Interchange routing information Inform of network malfunctions Configure network equipment remotely Etc.

9. Anna Sfairopoulou Page 9 The ATM cube revisited

10. Anna Sfairopoulou Page 10 Layers vs Planes Layering: Structures how data transport is done in a network Planes: Define what purpose a data transfer serves: –User plane: Transfer of user info –Control plane: Control the transfer of user info –Management plane: Check and update status of network elements (routers, servers, etc.)

11. Anna Sfairopoulou Page 11 The purpose of signaling Interchange of control information for the management of traffic aggregates and of the network as a whole Signaling protocols represent a parallel network for the purpose of network and traffic control  The complexity and the intelligence of the network lies mainly here!

12. Anna Sfairopoulou Page 12 The real “simplest” voice call

13. Anna Sfairopoulou Page 13 The real “simplest” voice call SIP Express Server (SER) Database (MySQL) DNS (Named) Twinkle

14. Anna Sfairopoulou Page 14 Signalling Signalling serves to control user data transfer across the network –Data transfer is easy, signaling is hard! SIP is a session-layer signaling protocol RTP is a session-layer data transfer protocol UDP is the transport protocol mostly used to transport both

15. Anna Sfairopoulou Page 15 SIP standardization First designed by Henning Schulzrinne and Mark Handley starting in 1996 Standardized in IETF RFC 3261 –See also RFC 3551, 2327, 3219, 3761, 3525, 3398... Decentralized design –The intelligence lies on the nodes Ongoing process –Extensions –Services

16. Anna Sfairopoulou Page 16 SIP design principles (I) Modelled after HTTP –Text-based Based on transactions –Request / response Simple –Less than 10 methods / packet types Only for call control –No QoS, no media transfer, no application-specific functions

17. Anna Sfairopoulou Page 17 SIP design principles (II) Session-oriented –Can manage any session-based service Online gaming Videoconferencing Virtual reality Chat Etc

18. Anna Sfairopoulou Page 18 The SIP-related protocol “Zoo” Loosely coupled to other Internet protocols –SDP, DNS, SMTP, HTTP, RSVP,... Defines complementary protocols to enable special services –TRIP, ENUM, SPIRITS, PINT,... Any VoIP network needs a combination of protocols to work

19. Anna Sfairopoulou Page 19 VoIP protocol stack SIP TCP / UDP / SCTP? MPEG, H.261, etc. RTP UDP IP RTCP, TRIP, etc. TCP / UDP? Fast/GigEth, ATM, 802.11 MAC/LLC, etc. DSL, Phy GigEth,802.11 PHY etc. SignalingMedia Transport Support Physical Network Transport Session Presentation Layer Datalink

20. Anna Sfairopoulou Page 20 SIP fundamentals Which messages do we need to control a VoIP call? –Let's try to find out...

21. Anna Sfairopoulou Page 21 A basic SIP call Alice Bob | | | INVITE | |----------------------->| | 180 Ringing | |<-----------------------| | | | 200 OK | |<-----------------------| | ACK | |----------------------->| | Both Way RTP Media | | | | BYE | |<-----------------------| | 200 OK | |----------------------->| | | INVITE sip:bob@biloxi.com SIP/2.0 From: Alice To: Bob m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 SIP/2.0 200 OK m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000

22. Anna Sfairopoulou Page 22 Message syntax (I) SIP is request / response Every request carries a method indicating the request type INVITE sip:bob@biloxi.com SIP/2.0 Every response carries a status code explaining the answer SIP/2.0 200 OK Request Line or Status Line Message Headers Payload

23. Anna Sfairopoulou Page 23 Message syntax (II) Both carry message headers with the parameters –Variable depending on method / context –Additional information about the message –Ex: From: Alice Payload transports additional info (normally using SDP) –No user data! –description of audio / video capabilities –Ex: m=audio 3456 RTP/AVP 0

24. Anna Sfairopoulou Page 24 SIP addressing SIP URL (Uniform Resource Locator) –Specify the location of a resource (user) –Email-like addresses –sip:User@Domain –But it is not an e-mail address! sip:alice@atlanta.com sip:33445566@google.com Non sip URLs can be also found in SIP messages –mailto, tel. im …

25. Anna Sfairopoulou Page 25 Original SIP methods (I) Six methods defined initially in the standard –INVITE –ACK –BYE –CANCEL –OPTIONS –REGISTER

26. Anna Sfairopoulou Page 26 Original SIP methods (II) INVITE initiates sessions –session description included in message body – re-INVITEs used to change session state ACK confirms session establishment – can only be used with INVITE BYE terminates sessions

27. Anna Sfairopoulou Page 27 Original SIP methods (III) CANCEL cancels a pending INVITE OPTIONS capability inquiry REGISTER binds a permanent address to current location –may convey user data (CPL scripts)

28. Anna Sfairopoulou Page 28 SIP methods extensions INFO mid-call signaling COMET preconditions met PRACK provisional reliable responses ACK SUBSCRIBE/NOTIFY/MESSAGE instant messaging REFER call re-direction UPDATE update call state PUBLISH user info

29. Anna Sfairopoulou Page 29 SIP responses (I) Borrowed from HTTP:  xyz code + explanatory text Receivers need to understand x 1yz Informational –100 Trying –180 Ringing –183 Session in progress 2yz Success –200 ok

30. Anna Sfairopoulou Page 30 SIP responses (II) 3yz Redirection –300 Multiple choices –302 Moved temporarily –305 Use proxy 4yz Request failure – 400 Bad Request – 401 Unauthorized – 407 Proxy authentication required – 486 Busy Here 

31. Anna Sfairopoulou Page 31 SIP responses (III) 5yz Server failure –500 Server internal error –501 Not implemented –503 Service unavailable 6yz Global failure –600 Busy everywhere –606 Not acceptable

32. Anna Sfairopoulou Page 32 A basic SIP call (again) Alice Bob | | | INVITE | |----------------------->| | 180 Ringing | |<-----------------------| | | | 200 OK | |<-----------------------| | ACK | |----------------------->| | Both Way RTP Media | | | | BYE | |<-----------------------| | 200 OK | |----------------------->| | | INVITE sip:bob@biloxi.com SIP/2.0 From: Alice To: Bob m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 SIP/2.0 200 OK m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000

33. Anna Sfairopoulou Page 33 SIP message headers Huge number of different headers –See RFC 3261 –Nomenclature: SIP header = Other protocol's header field Headers parameterize the request or response A SIP entity ignores headers it does not understand –Simplifies interworking

34. Anna Sfairopoulou Page 34 Header types General headers –Basic info to process the transaction –E.g. “To”, “From” and “Call-ID” headers Request headers –Additional info about request or sender –E.g. The “Subject” header Response headers –Additional info about response or receiver –E.g. “Unsupported” and “Retry-After” header Entity headers

35. Anna Sfairopoulou Page 35 A complete SIP message

36. Anna Sfairopoulou Page 36 Example: Invite message Starting Line Headers Separator Message Body

37. Anna Sfairopoulou Page 37 SIP entities: UAC & UAS User Agent Client (UAC) –Places calls –Sends requests User Agent Server (UAS) –Waits for incoming calls –Sends responses A SIP terminal is a UAC + UAS –Beware of this special client/server terminology!

38. Anna Sfairopoulou Page 38 SIP network entities Servers (UAS) –Proxy server –redirect server –registrar Can be combined in a single device  p.e. SER!!! They deal only with signaling Media is transported end-to-end –There are exceptions...  Signaling controls media interchange: It is not necessary to touch the media streams directly!

39. Anna Sfairopoulou Page 39 SIP entities: Registrar Users register their contact info –Keeps the info at a Location Server (Which is simply a database) –SIP address, but also other addresses, with a type indication: sip:anna.sfairopoulou@upf.edu sip:935422942@upf.edu, user = phone –Enables personal and terminal mobility and user behaviour patterns

40. Anna Sfairopoulou Page 40 Registration example

41. Anna Sfairopoulou Page 41 Registration example Contact could also be a specific location e.x. pc1.grup2.labtel2.upf.edu Un-Register –Send the same message but with EXPIRE = 0

42. Anna Sfairopoulou Page 42 SIP entities: Proxy server Proxy Server –Acts on behalf of UAC Processing the request Responding to requests Forwarding requests –Can impersonate the client –Acts both as client and server –Forking proxies Forwards an INVITE to several destinations in parallel

43. Anna Sfairopoulou Page 43 Proxy example

44. Anna Sfairopoulou Page 44 Stateless vs Stateful proxy In general –Stateless: get a request, forward it, forget about it –Stateful: remembers previous responses/requests of a particular transaction act more intelligently on subsequent requests! Record-Route: force future messages to pass from this proxy

45. Anna Sfairopoulou Page 45 SIP entites: Redirect server Maps destination SIP addresses to “reachable” addresses –SIP address, e-mail, telephone number, etc. –Depending on user preferences Informs the client about them –No message forwarding!

46. Anna Sfairopoulou Page 46 Redirection example

47. Anna Sfairopoulou Page 47 Additional examples (taken from RFC 3665 and Collins)

48. Anna Sfairopoulou Page 48 Session establishment through two proxies In this scenario, Alice completes a call to Bob using two proxies Proxy 1 and Proxy 2. The initial INVITE (F1) contains a pre-loaded Route header with the address of Proxy 1 (Proxy 1 is configured as a default outbound proxy for Alice). The request does not contain the Authorization credentials Proxy 1 requires, so a 407 Proxy Authorization response is sent containing the challenge information. A new INVITE (F4) is then sent containing the correct credentials and the call proceeds. The call terminates when Bob disconnects by initiating a BYE message. Proxy 1 inserts a Record-Route header into the INVITE message to ensure that it is present in all subsequent message exchanges. Proxy 2 also inserts itself into the Record-Route header. The ACK (F15) and BYE (F18) both have a Route header.

49. Anna Sfairopoulou Page 49

50. Anna Sfairopoulou Page 50 Unsuccessful temporarily unavailable In this scenario, Bob initially sends a 180 Ringing response to Alice, indicating that alerting is taking place. However, then a 480 Unavailable is then sent to Alice. This response is acknowledged and then proxied back to Alice.

51. Anna Sfairopoulou Page 51

52. Anna Sfairopoulou Page 52 Forking proxy Used if a particular user is registered at several locations Stateful! –Proxy remembers that it has two sessions pending and it cancels the one the moment the other responds The “branch” parameter in the “via” header allows to distinguish among forked requests (and responses)

53. Anna Sfairopoulou Page 53

54. Anna Sfairopoulou Page 54 SDP Session Description Protocol –Which is not a protocol... –...but a description language for media flows Convey sufficient information to participate in a multimedia session Independent of SIP –But they work nicely together

55. Anna Sfairopoulou Page 55 SDP message info SDP includes description of: –Media to use Codec Sampling rate –Media destination IP address and port number –Session name and purpose –Times the session is active –Contact information

56. Anna Sfairopoulou Page 56 SDP message example v=0 o=alice 28908044538 289080890 IN IP4 193.175.132.118 s=Wedding Proposal e=alice@atlanta.com c=IN IP4 126.16.69.4 t=28908044900 28908045000 m=audio 49170 RTP/AVP 15 98 a=rtpmap:15 G728/8000 a=rtpmap:98 L16/11025/2 m=audio 4666 RTP/AVP 4 a=rtpmap:4 G723/8000

57. Anna Sfairopoulou Page 57 SDP capability negotiation Caller offers set of possible media Callee accepts or rejects every one of them –If several chosen, re-invite If none acceptable, warning sent back and re-invite Alternative: Use the OPTIONS method –Query the callee's capabilities prior to INVITE

58. Anna Sfairopoulou Page 58 SDP examples 1.Successful capability selection with SDP 2.Re-invite after capability exchange with SDP 3.Capability query with OPTIONS (Taken from Collins)

59. Anna Sfairopoulou Page 59 Example 1: Successful capability selection

60. Anna Sfairopoulou Page 60 Example 2: Re-Invite after capability exchange

61. Anna Sfairopoulou Page 61 Example 3: capability query with OPTIONS

62. Anna Sfairopoulou Page 62 For next class Find an article on any of the following topics: - SIP + WLANs - Mobile P2PSIP - Application layer mobility using SIP Small presentation (5-10 slides) each during seminar Short report (max. 2 pages) on paper send by Friday, 29 January