The document provides an overview of the Session Initiation Protocol (SIP), including its history, functionality, message structure, elements, and call flow. SIP is an application layer protocol for establishing multimedia sessions over the internet, similar to HTTP but for multimedia communications like voice, video and messaging. It uses SIP requests and responses to initiate, modify and terminate calls between SIP user agents.

1. Introduction to SIP Alan B. Johnston and Henry Sinnreich San Jose, March 17 2008 SIP and P2P Tutorial part 1

2. Session Initiation Protocol Overview Application Layer Signaling Protocol “ Rendezvous” Protocol Used to establish, modify, and terminate multimedia sessions Part of Internet Multimedia Architecture Can use a variety of transports UDP, TCP, TLS, SCTP, etc. Based on HTTP (Web) Similar text-based structure Uses URIs (Uniform Resource Indicators) Applications include (but not limited to): Voice, video, gaming, instant messaging, presence, call control, etc.

3. The Internet Hourglass Protocol Architecture Putting on weight: QoS, MPLS Midlife crisis: Too many interfaces (SONET, ATM, frame relay) http://www.cs.columbia.edu/~coms6181/slides/1/internet.ppt L5: Application L4: Transport L3: Network L2: Data Link L1: Physical Copper Fiber Wireless Ethernet PPP IP UDP SMTP RTP SIP TCP HTTP Applications are not dependent on the network and transport layers

4. Internet End-to-End Control User has little control Walled gardens and central network control: POTS, X.25, ISDN, BISDN, FR, ATM, GSM, H.323, H.248, 3GPP, TISPAN, NG… Central Control USER USER Central Control Central Control UNI NNI NNI UNI Services supported by interfaces and central controllers Central Control in Telecom Networks USER USER Elective Server Elective Server Internet “ Dumb Network” R R R User has control of all applications and choice of servers All services enabled by protocols: From ftp to web No single point of failure R

5. A Short History of SIP Internet Engineering Task Force (IETF) protocol Inventors: M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg Became “Proposed Standard” and RFC 2543 in March 1999 in MMUSIC WG. Separate SIP WG established in September 1999. Now new SIPPING (applications) and SIMPLE (presence and instant messaging) WGs using SIP. RFC2543bis-09 I-D became RFC 3261 in June 2002 Added four new authors: G. Camarillo, A. Johnston, J. Peterson, and R. Sparks. Entire spec rewritten for clarity, but some new features Mostly backwards compatible with RFC 2543 Many other SIP extensions published as RFCs.

6. SIP “Rendezvous” Functionality Locate another SIP device Locate a SIP server to facilitate the finding of another SIP device Establish a media session using an offer/answer exchange Modify an existing session using an offer/answer exchange Express a SIP device’s capabilities and features Request 3rd party (remote) call control operations Find out the status, capabilities, and availability of another SIP device Request future updates on the status and availability of another SIP device Exchange mid call signaling information Exchange short instant messages

7. SIP Requests SIP Requests are called “methods” Examples:

8. SIP Responses SIP Responses have a numerical part and a reason phrase First digit of code indicates class of response Examples

9. SIP Uniform Resource Indicators (URIs) Same form as email addresses: user@domain Two URI schemes: s ip:henry@pulver.com is a SIP URI Most common form introduced in RFC 2543 sips:henry@pulver.com is a Secure SIP URI New scheme introduced in RFC 3261 Requires TLS over TCP as transport for security Two types of SIP URIs: Address of Record (AOR) (identifies a user) sip:henry@pulver.com (Needs DNS SRV records to locate SIP Servers for mci.com domain) Contact (identifies a device and is usually a Fully Qualified Domain Name, FQDN ) sip:henry@127.24.45.4 or sip:henry@wisip.pulver.com (Which needs no resolution for routing) Other URI Schemes used with SIP

10. Related Protocols SDP – Session Description Protocol Used to describe media session. Carried as a message body in SIP messages. Text-based protocol Uses RTP/AVP Profiles for common media types Defined by RFC 2327 Minor updates in draft-ietf-mmusic-sdp-new-xx.txt SIP use of SDP based on Offer/Answer model RFC 3264 RTP – Real-time Transport Protocol Used to transport media packets over IP RTP adds a bit-oriented header containing: name of media source timestamp codec type sequence number Defined by H. Schulzrinne et al, RFC 3550. Profiles defined by RFC 3551. RTCP for exchange of participant and quality reports. RTCP-XR provides additional VoIP statistics defined in RFC 3611

11. SIP Element Types User Agent (UA) PSTN Gateway Minimal capabilities Advanced User Agent Multimedia Call control and conferencing Proxy Server Receives requests from UAs and acts upon them Performs database queries (DNS, etc.) Signaling only – ignores message bodies (SDP) and never sees media flow (RTP) Can implement services (forwarding, find me, voice mail, etc.) Can be stateless, transaction stateful, or call stateful Drops out of signaling after initial exchange unless Record-Routes Redirect Server Server queries database or implements service then returns response in 3xx Simple query/response mechanism Registrar Server Receives REGISTER requests and populates Location Server database Location Server Database of AOR/Contact URI binding Consulted by proxy and redirect servers No standard IETF protocol defined Back to Back User Agent (B2BUA) Terminates SIP session and re-originates May also proxy RTP media Breaks end-to-end security and service transparency

12. SIP Call Flow Example Proxy proxy.aol.com 200 OK 200 OK Proxy server.munich.de BYE Media Session ACK UA sip:schroed5422@aol.com UA sip:w.heisenberg@munich.de INVITE INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK “ SIP Trapezoid”

13. SIP Message Details INVITE sip:wh@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5061;branch=z9hG4bK8542.1 Via: SIP/2.0/TLS proxy.aol.com:5060;branch=z9hG4bK9213 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 First line of a SIP message is Start Line which contains: the method or Request type: INVITE ( session setup request). the Request-URI which indicates who the request is for sip:wh@200.201.202.203 Note: Request-URI can be either an AOR or Contact (FQDN) This Request-URI is a FQDN, but the initial Request-URI was an AOR (same as To URI) the SIP version number SIP/2.0

14. SIP Message Details INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5061;branch=z9hG4bK8542.1 Via: SIP/2.0/TLS proxy.aol.com:5060;branch=z9hG4bK9213 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 Via headers show the path the request has taken The bottom Via header is inserted by the User Agent which initiated the request Additional Via headers are inserted by each proxy in the path Shows transport used (TLS between proxies in this case) The Via headers are used to route responses back the same way Required branch parameter contains a “cookie” ( z9hG4bK ) then a transaction-ID.

15. SIP Message Details INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5061;branch=z9hG4bK8542.1 Via: SIP/2.0/TLS proxy.aol.com:5060;branch=z9hG4bK9213 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 Max-Forwards is a count decremented by each proxy that forwards the request. When count goes to zero, request is discarded and 483 Too Many Hops response is sent. Used for stateless loop detection.

16. SIP Message Details INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5061;branch=z9hG4bK8542.1 Via: SIP/2.0/TLS proxy.aol.com:5060;branch=z9hG4bK9213 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 Dialog (formerly called call leg) information is in headers: To tag, From tag, and Call-ID (Note: Not URIs) To and From URIs usually contain AOR URIs. All requests and responses in this call will use this same Dialog information. Call-ID is unique identifier usually composed of pseudo-random string or string “@” hostname or IP Address

17. SIP Message Details CSeq Command Sequence Number Initialized at start of call ( 1 in this example) Incremented for each subsequent request Used to distinguish a retransmission from a new request Also contains the request type (method) - INVITE INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5061;branch=z9hG4bK8542.1 Via: SIP/2.0/TLS proxy.aol.com:5060;branch=z9hG4bK9213 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159

18. SIP Message Details INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5061;branch=z9hG4bK8542.1 Via: SIP/2.0/TLS proxy.aol.com:5060;branch=z9hG4bK9213 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159 Contact header contains a SIP FQDN URI for direct communication between User Agents If Proxies do not Record-Route , they can be bypassed If Record-Route is present in 200 OK, then a Route header is present in all future requests in this dialog. Contact header is also present in 200 OK response

19. SIP Message Details Content-Type indicates the type of message body attachment (others could be text/plain , application/cpl+xml , etc.) Content-Length indicates the octet (byte) count of the message body. Message body is separated from SIP header fields by a blank line (CRLF). INVITE sip:w.h@200.201.202.203 SIP/2.0 Via: SIP/2.0/UDP proxy.munich.de:5061;branch=z9hG4bK8542.1 Via: SIP/2.0/TLS proxy.aol.com:5060;branch=z9hG4bK9213 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 Max-Forwards: 69 To: Heisenberg <sip:w.heisenberg@munich.de> From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:schroed5244@100.101.102.103 Content-Type: application/sdp Content-Length: 159

20. SDP Message Body Details v=0 o=schroed5244 289084526 28904529 IN IP4 100.101.102.103 s=- c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 97 98 a=rtpmap:0 PCMU/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:98 telephone-event/8000 Version number (ignored by SIP) Origin (only version used by SIP - 28904529 ) Subject (ignored by SIP) Connection Data (IP Address for media - 100.101.102.103 ) Time (ignored by SIP) Media (type - audio , port - 49170 , RTP/AVP Profile – 0, 97, 98 ) Attributes RTP/AVP 0 is PCM  Law (64kb/s) RTP/AVP 97 (dynamic payload) is Internet Low Bit Rate Codec (iLBC) RFC 3952 RTP/AVP 98 (dynamic payload) is for telephone events (DTMF) RFC 2833

21. SIP Response Details Via , To , From , Call-ID , & CSeq are all copied from request. To now has a tag inserted by UAS Contact and Message Body contain UAS information. SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.munich.de:5061;branch=z9hG4bK8542.1 Via: SIP/2.0/TLS proxy.aol.com:5060;branch=z9hG4bK9213 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK45a35h76 To: Heisenberg <sip:w.heisenberg@munich.de>; tag=24019385 From: E. Schroedinger <sip:schroed5244@aol.com>;tag=312345 Call-ID: 105637921@100.101.102.103 CSeq: 1 INVITE Contact: sip:wh@200.201.202.203 Content-Type: application/sdp Content-Length: 173 v=0 o=Heisenberg 2452772446 2452772446 IN IP4 200.201.202.203 s=SIP Call c=IN IP4 200.201.202.203 t=0 0 m=audio 56321 RTP/AVP 0 a=rtpmap:0 PCMU/8000

22. Example SIP Header Fields

23. SIP Capability Discovery SIP has strong capability discovery. Using OPTIONS inside or outside a session Declared in INVITE and other requests and responses Indicates The types of SIP requests (methods) the UAC will accept ( Accept header field) Any SIP extensions and capabilities ( Supported header field) The characteristics of the UAC such as whether it is mobile or fixed, a conference server, etc. (feature tags in the Contact header field) Any SIP event packages supported ( Allow-Events header field) Any SIP extensions and capabilities required to complete the request ( Require header field) The type of message bodies accepted ( Accept-Content header field) Call control capabilities Capabilities and characteristics of a UA (feature tags) Codecs supported (SDP message body response to OPTIONS )

24. SIP Extensions and Features Method Extensions Unknown methods rejected by UA using 405 or 501 response Listed in Allow header field Proxies treat unknown methods as a non- INVITE Header Field Extensions Unknown header fields are ignored by UAs and Proxies Some have feature tags registered, can be declared in a Supported or Require header field. Message Body Extensions Unknown message body types are rejected with a 406 response. Supported types can be declared with a Accept header field. Content-Disposition indicates what to do with it. Extensions must define fallback to base specification. Result – No Profiling is Needed!

25. SIP Message Body Types

26. Successful Session Establishment Through One Proxy INVITE F1 INVITE F2 100 (Trying) F3 180 (Alerting) F4 180 (Alerting) F5 200 (OK) F6 200 (OK) F7 ACK F8 ACK F9 Both way RTP media BYE F10 BYE F11 ACK F12 ACK F13 Progress tone Ring back Call is accepted Dialog state tear-down IM/Voice/video conversation Hang up call Call state tear-down Start the call Alice SIP Proxy Bob Dialog state Call state The italic/underlined events require human audio and visual interaction

27. Successful Session Establishment Through P2P SIP Both way RTP media Progress tone Ring back Call is accepted Dialog state tear-down IM/Voice/video conversation Hang up call Call state tear-down Start the call INVITE F1 100 (Trying) F2 180 (Alerting) F3 200 (OK) F4 ACK F5 ACK F7 BYE F6 Alice Bob Dialog state Call state The italic/underlined events require human audio and visual interaction DHT P2P

28. SIP and PSTN Interworking Gateways interwork SIP with PSTN Signaling: SIP to ISUP (or ISDN D-channel) Media: RTP to PCM trunk (or B-channel) Details in “ISUP to SIP Mapping” RFC 3398 by G. Camarillo et al. SIP/PSTN Call flows in RFC 3666 by A. Johnston et al. The 183 Session Progress response is used along with “early media” RTP packets to provide “inband” call progress indicators. 2 407 Proxy Auth Req. SIP Phone Proxy Server SIP/PSTN Gateway PSTN Switch 1 INVITE 3 ACK 5 100 Trying 4 INVITE WWW-Auth 14 ACK 9 183 Session Progress 6 INVITE 8 Alerting 7 Setup 15 ACK 12 200 OK 13 200 OK 11 Answer 10 183 Session Progress Early Media RTP Media RTP PSTN Phone

29. SIP dialogs and routes Dialog: P2P SIP relationship between 2 UAs Sequencing and routing between UAs Dialog ID = Call-ID, local/remote tag (To/From) Dialog uses sequence numbers for state Dialog states: Early, provisional and final responses Route through a select list of proxies Via header indicates the path taken so far Branch parameter starting with <z9hG4bK> Loose routing: Separates the destination and the path Forking: Parallel search using several INVITE’s

30. Tags and branches in SIP routing with two proxies Alice Proxy 1 Proxy 2 Bob F1 INVITE F2 INVITE F3 INVITE F6 100 F4 100 F5 180 F6 180 F7 180 F8 200 F9 200 F10 200 F11 ACK F12 ACK F13 ACK F14 BYE F15 BYE F16 BYE F17 200 F18 200 F15 200 VIA: branch z9hG4bK74bf9 From: tag=9fxced76sl Via: branch=z9hG4bK2d4790.1 Via: branch=z9hG4bK721e4.1 To: tag=314159 RTP Media From: tag=314159 RFC 3665 Section 3.2. response and request tag processing

31. SIP-T ISUP Messages are carried as multipart MIME message bodies in the SIP messages between the SIP-T Gateways. (RFC 3204) Advantage: Possible ISUP transparency Disadvantages: SIP-T does not interwork with SIP Perpetuates ISUP PSTN Switch 2 INVITE (IAM) SIP-T Gateway 6 183 Session Progress (ACM) 9 200 OK (ANM) 11 ACK 13 BYE (REL) 16 200 OK (RLC) RTP Media Session No Media Session PSTN Switch 5 ACM 8 ANM 14 REL 15 RLC 3 IAM 4 100 Trying One way RTP Media One way speech Two way speech No Speech Path SIP-T Gateway 7 ACM 10 ANM 12 REL 17 RLC 1 IAM One way speech Two way speech No Speech Path

32. Digest Challenge/Response SIP User Agent 1 INVITE Proxy Server 3 ACK 4 INVITE Proxy-Auth:1 5 100 Trying 17 200 OK Authenticated Media Session SIP User Agent 7 401 Unauthorized 9 ACK 16 200 OK 19 ACK 6 INVITE 2 407 Proxy Authentication Required 8 401 Unauthorized 10 ACK 11 INVITE Proxy-Auth:1, WWW-Auth:2 13 100 Trying 14 180 Ringing 12 INVITE WWW-Auth:2 15 180 Ringing 18 ACK Caller is challenged by Proxy Server and Called User Agent. Relies on “shared secret” (username and password) exchange. Based on HTTP Digest RFC 2716 Does not provide integrity protection unless qop=auth-int

33. SIP Digest Example INVITE sip:913145551212@siptest.mci.com SIP/2.0 From: sip:alan.johnston@siptest.mci.com;tag=1c31657 To: sip:913145551212@siptest.mci.com Call-Id: call-1087694972-1@192.168.0.32 Cseq: 2 INVITE Contact: <sip:alan.johnston@192.168.0.32> Content-Type: application/sdp Content-Length: 306 Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE Supported: replaces, join User-Agent: Pingtel/2.1.11 (VxWorks) Date: Sun, 20 Jun 2004 01:29:40 GMT Proxy-Authorization: DIGEST USERNAME=&quot;alanjohnston&quot;, REALM=&quot;MCI&quot;, NONCE=&quot;f9d26bd9c4766eacd3101d8d2dc5f38d.1087694984&quot;, URI=&quot;sip:913145551212@siptest.mci.com&quot;, RESPONSE=&quot;fe1545a816d698b993b83bade8428c0f&quot; Via: SIP/2.0/UDP 192.168.0.32 (SDP Message body not shown)

34. SIP Media Negotiation – The Offer Answer Model Media Session negotiation is handled using Offer Answer model RFC 3264 – a two pass mechanism Usage of SDP Offer and Answer carried in: INVITE/200 OK (most common) 200 OK/ACK (used in 3pcc) Combinations of INVITE , reliable 18x , PRACK , UPDATE , etc. (used in preconditions) Order and number of media lines must be the same in an offer answer exchange Media streams can be added by appending media line in an offer. Media streams can be refused or deleted by setting port to 0 in offer or answer. Offer lists all codecs supported in preference order Answerer answers with a subset If none in common, media stream is declined in answer. Streams can be marked sendrecv, sendonly, recvonly Offer Answer Examples I-D has many examples draft-ietf-mmusic-offer-answer-examples-05.txt

35. The Ecologic System of SIP SIP XCAP (config) RTSP SIMPLE Presence+IM policy RPID … . SDP XCON (conferencing) STUN/TURN/ICE (NAT traversal) RTP (media) configures initiates carries carries controls provide addresses Ref: H. Schulzrinne