Signaling & Network Control 7th Semester SIP Tutorial Signaling & Network Control 7th Semester

Why packet switching? Why SIP? Technology evolution of PSTN

Session Initiation Protocol Overview Application Layer Signaling Protocol Used to establish, modify, and terminate multimedia sessions Part of Internet Multimedia Architecture Can use 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. SIP sessions involve one or more participants and can use unicast or multicast communication. SIP is a key component of the Internet Multimedia Architecture. Other protocols including SDP, RTP, DNS, etc are needed to implement a complete service. SIP was designed based on one of the most scalable and deployed Internet protocols Hyper Text Transport Protocol (HTTP) the underlying protocol of the World Wide Web (WWW). SIP is about much more than just voice – supports all media.

SIP entities User Agent User Agent Client Proxy Server Redirect server User Agent Server Proxy Server Redirect server Registrar

SIP Elements – User Agents Capable of sending and receiving SIP requests. UAC – User Agent Client UAS – User Agent Server End Devices SIP phone PC/laptop with SIP Client PDA mobile phone PSTN Gateways are a type of User Agent DNS Server Location Server DNS SIP Inbound Proxy Server Outbound Proxy Server SIP SIP User Agents (UAs) are the endpoints in a SIP network – they originate and terminate SIP requests and responses. They can be implemented as SIP phones, PC/laptop clients, PDAs, cell phones, or even as a PSTN gateway. SIP Media (RTP) User Agent A User Agent B

SIP Elements – Proxy Servers DNS Server Location Server Forward or “proxy” requests on behalf of User Agents Consult databases: DNS Location Server Types: Stateless Transaction Stateful Call Stateful No media capabilities Ignore SDP. Normally bypassed once dialog established, but can Record-Route to stay in path. DNS SIP Inbound Proxy Server Outbound Proxy Server SIP SIP SIP proxy servers are the intermediary servers that help UAs establish sessions using SIP. They typically consult databases and perform SIP routing (proxying) on behalf of UAs. They are catagorized based on they type of state information they keep – a stateless proxy keeps no state, a transaction stateful proxy only keeps state on pending transactions, while a call stateful proxy keeps state for the entire duration of a SIP session. SIP Media (RTP) User Agent A User Agent B

SIP Elements – Other Servers Location Server Database of locations of SIP User Agents Queried by Proxies in routing Updated by User Agents by Registration DNS Server SRV (Service) Records used to locate Inbound Proxy Servers DNS Server Location Server DNS SIP Inbound Proxy Server Outbound Proxy Server SIP SIP Location Servers and DNS servers are two examples of databases often queried by SIP proxies (although DNS is often also queried by UAs). Location Servers are SIP registration databases, built by registrar servers. SIP can utilize DNS queries to resolve URIs using A (Address), SRV (Service), or NAPTR (Naming Authority Pointer Records) resource records. SIP Media (RTP) User Agent A User Agent B

SIP Client and Server SIP Elements are either A User Agent acts as a User Agents (end devices that initiate and terminate media sessions) Servers (that assist in session setup) Proxies: Decides next hop and forwards request Registrars: Accepts REGISTER requests from clients Redirect servers : Sends address of next hop back to client SIP Gateways: To PSTN for telephony interworking To H.323 for IP Telephony interworking A User Agent acts as a Client when it initiates a request (UAC) Server when it responds to a request (UAS)

SIP Addressing Uses Internet URLs Uniform Resource Locators Supports both Internet and PSTN addresses General form is name@domain To complete a call, needs to be resolved down to User@Host Examples: sip:alan@wcom.com sip:J.T. Kirk <kirk@starfleet.gov> sip:+1-613-555-1212@wcom.com;user=phone sip:guest@10.64.1.1 sip:790-7360@wcom.com;phone-context=VNET

SIP Requests and Responses SIP Responses use a numerical code and a “reason phrase” Classes: 1xx Informational 2xx Success 3xx Redirection 4xx Client Error 5xx Server Error 6xx Global Failure SIP Request types are called “methods” Methods in base spec: INVITE ACK OPTIONS CANCEL BYE REGISTER SIP is a client/server protocol that uses a request/response structure. Requests are called “methods”. Responses have a numerical code and a reason phrase – many are borrowed from HTTP including the common “404 Not Found” response. (Not all HTTP response codes are valid in SIP – only those defined in RFC 3261.) Example: 404 Not Found

Related Protocol: RTP 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 1889. Profiles defined by RFC 1890. RTCP for exchange of participant and quality reports.

SIP Call Setup Attempt Scenario DNS Server Location Server 1. A “dials” SIP AOR URI sip:B@mci.com. User Agent A sends INVITE to outbound Proxy Server. 2. Outbound Proxy sends 100 Trying response. Inbound Proxy Server Outbound Proxy Server 1. INVITE Contact: A SDP A 2. 100 Trying In this SIP call setup attempt scenario, A wishes to call B and “dials” the AOR URI of B. User Agent A generates an INVITE and sends it to its default outbound proxy. This proxy address can be manually configured or looked up using DNS. The proxy server immediately returns a 100 Trying provisional response to indicate that it has received the INVITE but that the request is still pending. User Agent A User Agent B (Not Signed In)

SIP Call Setup Attempt Scenario DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 1.2.3.4 3. Outbound Proxy does DNS query to find proxy server for mci.com domain 4. DNS responds with IP address of mci.com Proxy Server Inbound Proxy Server Outbound Proxy Server 1. INVITE Contact: A SDP A 2. 100 Trying The proxy server performs a DNS query and utilizes SRV records to locate the SIP proxy server for the destination domain. User Agent A User Agent B (Not Signed In)

SIP Call Setup Attempt Scenario DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 1.2.3.4 5. Outbound Proxy sends INVITE to Inbound Proxy Server. 6. Inbound Proxy sends 100 Trying response. 5. INVITE Contact: A SDP A Inbound Proxy Server Outbound Proxy Server 6. 100 Trying 1. INVITE Contact: A SDP A 2. 100 Trying The proxy server the forwards (proxies) the INVITE to that proxy server for the destination domain which also immediately responds with a 100 Trying. The 100 Trying response is not forwarded by the proxy server back to User Agent A – multiple 100 Trying responses do not convey an new information. As a result, the 100 Trying response is defined to only be a “hop-by-hop” response that is never proxied. User Agent A User Agent B (Not Signed In)

SIP Call Setup Attempt Scenario DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 1.2.3.4 7. LS Query: B? 8. Response: Not Signed In 7. Inbound Proxy consults Location Server. 8. Location Server responds with “Not Signed In.” 5. INVITE Contact: A SDP A Inbound Proxy Server Outbound Proxy Server 6. 100 Trying 1. INVITE Contact: A SDP A 2. 100 Trying The inbound proxy server consults a location server for B’s current registration information. B is not currently signed in, so the location server returns this information. User Agent A User Agent B (Not Signed In)

SIP Call Setup Attempt Scenario DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 1.2.3.4 7. LS Query: B? 8. Response: Not Signed In 9. Inbound Proxy sends 480 Temporarily Unavailable response. 10. Outbound Proxy sends ACK response. 5. INVITE Contact: A SDP A Inbound Proxy Server Outbound Proxy Server 6. 100 Trying 1. INVITE Contact: A SDP A 9. 480 Temporarily Unavailable 10. ACK 2. 100 Trying The proxy server uses this information to generate a 480 Temporarily Unavailable response. This response receives an immediate ACK (Acknowledgement request) from the other proxy server. This INVITE/failure-response/ACK exchange completes the SIP transaction between the proxy servers. User Agent A User Agent B (Not Signed In)

SIP Call Setup Attempt Scenario DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 1.2.3.4 7. LS Query: B? 8. Response: Not Signed In 11. Outbound Proxy forwards 480 response to A. 12. A sends ACK response. 5. INVITE Contact: A SDP A Inbound Proxy Server Outbound Proxy Server 6. 100 Trying 1. INVITE Contact: A SDP A 9. 480 Temporarily Unavailable 10. ACK 2. 100 Trying 11. 480 Temporarily Unavailable The proxy then forwards the 480 back to User Agent A and receives an ACK, completing the transaction between them. The ACK is not forwarded by the proxy as it has already sent an ACK in the previous exchange. 12. ACK User Agent A User Agent B (Not Signed In)

User Agent B (Not Signed In) SIP Presence Example DNS Server Presence Server 1. A wants to be informed when B signs on, so sends a SUBSCRIBE 2. Outbound Proxy forwards to Inbound Proxy 3. Inbound Proxy forwards to B’s Presence Server 3. SUBSCRIBE 2. SUBSCRIBE Inbound Proxy Server Outbound Proxy Server 1. SUBSCRIBE A wishes to receive a notification when B signs in and is available for communication. User Agent A sends a SUBSCRIBE request requesting to be notified when B is available. The previous DNS query has been cached, so no new DNS query is needed for the request to be forwarded to the proxy in B’s domain. The inbound proxy then forwards the request to B’s presence server. User Agent A User Agent B (Not Signed In)

User Agent B (Not Signed In) SIP Presence Example DNS Server Presence Server 3. SUBSCRIBE 4. 200 OK 4. Presence Server authorizes subscription by sending a 200 OK. 5. & 6. 200 OK proxied back to A. 2. SUBSCRIBE Inbound Proxy Server Outbound Proxy Server 5. 200 OK 1. SUBSCRIBE 6. 200 OK The presence server authenticates the subscription and confirms it by sending a 200 OK response which is forwarded back to User Agent A. No ACK is sent, as ACK is only used to confirm receipt of final responses to INVITE requests – only INVITE transactions use the 3 way handshake. The SUSBSCIBE/200 OK exchange completes the transaction. User Agent A User Agent B (Not Signed In)

User Agent B (Not Signed In) SIP Presence Example DNS Server Presence Server 7. Presence Server sends NOTIFY containing current presence status of B (Not Signed In). 8. and 9. NOTIFY is proxied back to A. 10. A acknowledges receipt of notification with 200 OK. 11. & 12. 200 OK is proxied back to B’s Presence Server. 7. NOTIFY <Not Signed In> 12. 200 OK 8. NOTIFY <Not Signed In> Inbound Proxy Server Outbound Proxy Server 11. 200 OK 9. NOTIFY <Not Signed In> 10. 200 OK The presence server immediately sends a NOTIFY containing the current state of B, that is, not signed in. User Agent A responds with a 200 OK which is proxied back to the presence server. This NOTIFY/200 OK exchange completes this transaction. User Agent A User Agent B (Not Signed In)

SIP Registration Example DNS Server Location Server 2. Update database: B = B@2.3.4.5 1. B signs on to his SIP Phone which sends a REGISTER message containing the FQDN URI of B’s User Agent. 2. Database update is sent to the Location Server Outbound Proxy Server Outbound Proxy Server REGISTER Contact: B@2.3.4.5 Time passes, then B signs in by send a REGISTER request to through his proxy which forwards it to the registrar server for B’s domain. The REGISTER contains B’s AOR and a Contact URI which identifies the device that B is currently using. User Agent A User Agent B

SIP Registration Example DNS Server Location Server 3. Location Server database update is confirmed. 4. Registration is confirmed with a 200 OK response. 2. Update database: B = B@2.3.4.5 3. OK Outbound Proxy Server Outbound Proxy Server 1. REGISTER Contact: B@2.3.4.5 4. 200 OK Contact: B@2.3.4.5 The location server updates its database with the information and returns a 200 OK to confirm. The Contact URI is also returned in the 200 OK along with an expiration time. To ensure continuous service, B will need to refresh the registration (by sending another REGISTER request) within the time interval. The REGISTER/200 OK exchange completes the transaction. User Agent A User Agent B

SIP Presence Example DNS Server Presence Server 13. Presence Server learns of B’s new status from the Location Server and sends a NOTIFY containing new status of B (Signed In). 14. & 15. NOTIFY is proxied back to A. 16. A acknowledges receipt of notification with 200 OK. 17. & 18. 200 OK is proxied back to Presence Server. 13. NOTIFY <Signed In> 18. 200 OK 14. NOTIFY <Signed In> Inbound Proxy Server Outbound Proxy Server 17. 200 OK 15. NOTIFY <Signed In> 16. 200 OK The presence server is informed of the change in B’s availability and sends a NOTIFY to User Agent A containing this new information. The 200 OK response of User Agent A is proxies back to the presence server. User Agent A User Agent B

SIP Instant Message Scenario 1. A sends an Instant Message to B saying “Can you talk now?” in a MESSAGE request. 2., 3. & 4. MESSAGE request is proxied, Location Server queried. 5. Inbound Proxy forwards MESSAGE to B. 6. User Agent B responds with 200 OK. 7. & 8. 200 OK is proxied back to A. DNS Server Location Server 3. LS Query: B? 4. Response: sip:B@2.3.4.5 2. MESSAGE <Can you talk now?> Inbound Proxy Server Outbound Proxy Server 7. 200 OK 1. MESSAGE <Can you talk now?> 8. 200 OK 5. MESSAGE <Can you talk now?> 6. 200 OK Knowing that B is now available, A types in an Instant Message (IM) to B. User Agent A generates a MESSAGE request containing the typed text in a message body. The location server query by the inbound proxy server now returns B’s Contact URI and the MESSAGE is routed to B. User Agent B confirms receipt with a 200 OK. (Note that any typed response by B would not be returned in the 200 OK – it will be sent using a separate MESSAGE request sent from B to A as shown in the next slide.) User Agent A User Agent B

SIP Instant Message Scenario 1. B sends an Instant Message to A saying “Sure.” in a MESSAGE sent to A’s AOR URI. 2. & 3. DNS Server is queried. 4. Outbound Proxy forwards MESSAGE to Inbound Server. 5. & 6. Location Server is queried. 7. Inbound Proxy forwards to A. 8. User Agent A responds with 200 OK. 9. & 10. 200 OK is proxied back to B. Location Server DNS Server 5. LS Query: A? 6. Response: sip:A@4.5.3.2 2. DNS Query: globalipcom.com? 3. Response: 5.6.7.8 4. MESSAGE <Sure.> Outbound Proxy Server Inbound Proxy Server 9. 200 OK 7. MESSAGE <Sure.> 8. 200 OK 1. MESSAGE <Sure.> 10. 200 OK B types a reply to A. User Agent B generates a MESSAGE request and sends it to its local proxy. The proxy consults DNS to locate the proxy server for the globalipcom.com domain of A. The MESSAGE request is then forwarded to this proxy server which then forwards it to User Agent A. A 200 OK reply is sent which is proxied back to User Agent B. User Agent A User Agent B

SIP Call Setup Attempt Scenario DNS Server Location Server 1. to 5. A retries INVITE to B which routes through two Proxy Servers. 6. Location Server responds with the FQDN SIP URI of B’s SIP Phone. 7. Inbound Proxy Server forwards INVITE to B’s SIP Phone. 5. LS Query: B 6. Response: sip:B@2.3.4.5 3. INVITE Contact: A SDP A Inbound Proxy Server Outbound Proxy Server 4. 100 Trying 1. INVITE Contact: A SDP A 2. 100 Trying 7. INVITE Contact: A SDP A A again attempts to establish a session with B by sending an INVITE. This time, the INVITE is forwarded to User Agent B by the inbound proxy server. User Agent A User Agent B

SIP Call Setup Scenario DNS Server Location Server 8. User Agent B alerts B and sends 180 Ringing response. 9. & 10. 180 Ringing is proxied back to A. 9. 180 Ringing Inbound Proxy Server Outbound Proxy Server 10. 180 Ringing 8. 180 Ringing User Agent A being alerting user B and sends a 180 Ringing provisional response which is proxied back to User Agent A. User Agent A informs A that alerting is taking place, possibly by generating local ringtone. User Agent A User Agent B

SIP Call Setup Scenario DNS Server Location Server 11. B accepts call and User Agent B sends 200 OK response. 12. & 13. 200 OK is proxied back to A. 9. 180 Ringing Inbound Proxy Server Outbound Proxy Server 12. 200 OK Contact: B SDP B 10. 180 Ringing 13. 200 OK Contact: B SDP B 11. 200 OK Contact: B SDP B 8. 180 Ringing A accepts the call, so User Agent A sends a 200 OK success response which is proxied back to A. Since the media is sent directly between A and B, it is possible that B’s “Hello” may reach A before the 200 OK. To avoid this clipping, User Agent A must be prepared to receive and play any RTP media packets as soon as the INVITE is sent. Likewise, User Agent B must be prepared to receive and play media packets before the ACK from User Agent A is received. The INVITE/200 OK completes the transaction (the ACK is not part of the same transaction for a success class response). User Agent A User Agent B

SIP Call Setup Scenario DNS Server Location Server 14. ACK is sent by A to confirm setup call bypassing proxies. Media session begins between A and B! 9. 180 Ringing Inbound Proxy Server Outbound Proxy Server 12. 200 OK Contact: B SDP B 10. 180 Ringing 13. 200 OK Contact: B SDP B 11. 200 OK Contact: B SDP B 8. 180 Ringing In this example, neither proxy server inserts a Record-Route header field, so the ACK sent by User Agent B is sent to the Contact URI contained in the 200 OK sent by User Agent B, which bypasses the two proxies. This ACK is a separate transaction, not related to the INVITE/200 OK transaction of the previous slide. 14. ACK Media (RTP) User Agent A User Agent B

SIP Call Hold (re-INVITE) DNS Server Location Server 15. B places A on hold by sending a re-INVITE. 16. A accepts with a 200 OK. 17. B sends ACK to A. No media between A and B. Inbound Proxy Server Outbound Proxy Server 15. INVITE SDP a=sendonly B decides to attempt to transfer A to another party, C. In preparation, B places A on “hold” by sending a re-INVITE (an INVITE sent within an existing dialog) in which the media stream is set to sendonly. (B also applies local mute, so no RTP packets are exchanged between A and B.) 16. 200 OK SDP A 17. ACK User Agent A User Agent B

SIP Call Transfer Scenario DNS Server Location Server 18. B transfers A to C using REFER. 19. Transfer is accepted by A with 202 Accepted response. 20. Notification of trying transfer is sent to B in NOTIFY. 21. B sends 200 OK response to NOTIFY Inbound Proxy Server Outbound Proxy Server B initiates the transfer by sending a REFER to A which receives a 202 Accepted response. This success-class response indicates that User Agent A has received the REFER and will attempt the transfer. However, the final outcome of the refer (success or failure) is not yet known. User Agent B sends an initial NOTIFY indicating that it will be trying to send an INVITE to User Agent C, which receives a 200 OK response. 18 REFER Refer-To: sip:C@mci.com 19. 202 Accepted 20. NOTIFY <100 Trying> User Agent A 21. 200 OK User Agent B

SIP Call Transfer Scenario DNS Server Location Server 1. to 5. A sends new INVITE to C which routes through two Proxy Servers. 6. Location Server responds with the FQDN SIP URI of C’s SIP Phone. 7. Inbound Proxy Server forwards INVITE to C’s SIP Phone. 5. LS Query: C? 6. Response: sip:C@6.7.8.9 3. INVITE Contact: A Ref-By: B SDP A Inbound Proxy Server Outbound Proxy Server 4. 100 Trying 7. INVITE Contact: A Ref-By: B SDP A 1. INVITE Contact: A Ref-By: B SDP A 2. 100 Trying Acting upon the REFER, User Agent A generates an INVITE and sends it to the URI in the Refer-To header field in the REFER. A Referred-By header field contains B URI, telling C that A has been transferred by B. User Agent C User Agent A User Agent B

SIP Call Transfer Scenario DNS Server Location Server 8. User Agent C alerts C and sends 180 Ringing response. 9. & 10. 180 Ringing is proxied back to A. 11. C accepts call and sends 200 OK response. 12. & 13. 200 OK is proxied back to A. 14. ACK is sent by A to confirm setup call. Media session between A and C begins. 9. 180 Ringing Inbound Proxy Server Outbound Proxy Server 12. 200 OK Contact: C SDP C 11. 200 OK Contact: C SDP C 10. 180 Ringing 13. 200 OK Contact: C SDP C 8. 180 Ringing User Agent C begins alerting, sending 180 Ringing. C accepts the call and User Agent C sends a 200 OK. Again, no proxy Record-Routes, so the ACK is sent directly to C’s Contact URI. 14. ACK User Agent C Media (RTP) User Agent A User Agent B

SIP Call Transfer Scenario DNS Server Location Server 20. Notification of successful transfer is sent to B in NOTIFY. 21. B sends 200 OK response to NOTIFY 22. B hangs up by sending a BYE. 23. 200 OK response to BYE is sent. Inbound Proxy Server Outbound Proxy Server User Agent A sends a NOTIFY to User Agent B informing him that the transfer was completed successfully. As a result, User Agent B disconnects with A by sending a BYE. If the transfer had failed, User Agent B could have attempted another transfer by sending another REFER or could have taken A off hold and continued the media session. 20. NOTIFY <200 OK> 21. 200 OK 22. BYE User Agent A User Agent B 23. 200 OK

SIP Session Establishment and Call Termination Media Stream From the RADVISION whitepaper on SIP

Call Proxying From the RADVISION whitepaper on SIP

SIP Call Redirection From the RADVISION whitepaper on SIP

SIP Requests SIP Requests (Messages) defined as: Method SP Request-URI SP SIP-Version CRLF (SP=Space, CRLF=Carriage Return and Line Feed) Example: INVITE sip:picard@wcom.com SIP/2.0

} SIP Requests Example Required Headers (fields): Via: Shows route taken by request. Call-ID: unique identifier generated by client. CSeq: Command Sequence number generated by client Incremented for each successive request INVITE sip:picard@wcom.com SIP/2.0 Via: SIP/2.0/UDP host.wcom.com:5060 From: Alan Johnston <sip:alan.johnston@wcom.com> To: Jean Luc Picard <sip:picard@wcom.com> Call-ID: 314159@host.wcom.com CSeq: 1 INVITE } Uniquely identify this session request

SIP Responses SIP Responses defined as (HTTP-style): SIP-Version SP Status-Code SP Reason-Phrase CRLF (SP=Space, CRLF=Carriage Return and Line Feed) Example: SIP/2.0 404 Not Found First digit gives Class of response:

SIP Responses: 1xx-3xx

SIP Responses: 4xx

SIP Responses: 5xx-6xx

SIP Responses Example Required Headers: Via, From, To, Call-ID, and CSeq are copied exactly from Request. To and From are NOT swapped! SIP/2.0 200 OK Via: SIP/2.0/UDP host.wcom.com:5060 From: Alan Johnston <sip:alan.johnston@wcom.com> To: Jean Luc Picard <sip:picard@wcom.com> Call-ID: 314159@host.wcom.com CSeq: 1 INVITE

SIP Headers - Partial List

SIP Headers - Continued

SIP Headers - Continued

Via Headers and Routing Via headers are used for routing SIP messages Requests Request initiator puts address in Via header Servers check Via with sender’s address, then add own address, then forward. (if different, add “received” parameter) Responses Response initiator copies request Via headers. Servers check Via with own address, then forward to next Via address

SIP Firewall Considerations Firewall Problem Can block SIP packets Can change IP addresses of packets TCP can be used instead of UDP Record-Route can be used: ensures Firewall proxy stays in path A Firewall proxy adds Record-Route header Clients and Servers copy Record-Route and put in Route header for all messages

SIP Message Body Message body can be any protocol Most implementations: SDP - Session Description Protocol RFC 2327 4/98 by Handley and Jacobson http://www.ietf.org/rfc/rfc2327.txt Used to specify info about a multi-media session. SDP fields have a required order For RTP - Real Time Protocol Sessions: RTP Audio/Video Profile (RTP/AVP) payload descriptions are often used

Authentication & Encryption SIP supports a variety of approaches: end to end encryption hop by hop encryption Proxies can require authentication: Responds to INVITEs with 407 Proxy-Authentication Required Client re-INVITEs with Proxy-Authorization header. SIP Users can require authentication: Responds to INVITEs with 401 Unathorized Client re-INVITEs with Authorization header

SIP Mobility Support 4 Mobile Host SIP Redirect Server 5 SIP Proxy Foreign Network Home Network 3 1 2 6 7 1 INVITE 2 302 moved temporarily 3, 4 INVITE 5, 6 OK 7 Data Corresponding Host Global: Wire and wireless No tunneling required No change to routing

SIP Mobility Pre-call mobility Mid-call mobility Mobile host (MH) can find SIP server via multicast REGISTER MH acquires IP address via DHCP MH updates home SIP server Mid-call mobility MH->CH: New INVITE with Contact and updated SDP Re-registers with home registrar

SIP Summary SIP is: SIP is not: Relatively easy to implement Gaining vendor and carrier acceptance Very flexible in service creation Extensible and scaleable Appearing in products right now SIP is not: Going to make PSTN interworking easy Going to solve all IP Telephony issues (QoS)

Comparison with H.323 H.323 is another signaling protocol for real-time, interactive H.323 is a complete, vertically integrated suite of protocols for multimedia conferencing: signaling, registration, admission control, transport and codecs. SIP is a single component. Works with RTP, but does not mandate it. Can be combined 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 Web flavor, whereas H.323 has a telephony flavor. SIP uses the KISS principle: Keep it simple stupid.

SIP/SS7 MSC Call Flow