Presentation is loading. Please wait.

Presentation is loading. Please wait.

Signaling & Network Control 7th Semester

Similar presentations


Presentation on theme: "Signaling & Network Control 7th Semester"— Presentation transcript:

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

2 Why packet switching? Why SIP?
Technology evolution of PSTN

3 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.

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

5 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

6 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

7 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

8 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)

9 SIP Addressing Uses Internet URLs Uniform Resource Locators
Supports both Internet and PSTN addresses General form is To complete a call, needs to be resolved down to Examples: sip:J.T. Kirk

10 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

11 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.

12 SIP Call Setup Attempt Scenario
DNS Server Location Server 1. A “dials” SIP AOR URI 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 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)

13 SIP Call Setup Attempt Scenario
DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 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 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)

14 SIP Call Setup Attempt Scenario
DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 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 Trying 1. INVITE Contact: A SDP A 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)

15 SIP Call Setup Attempt Scenario
DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 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 Trying 1. INVITE Contact: A SDP A 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)

16 SIP Call Setup Attempt Scenario
DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 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 Trying 1. INVITE Contact: A SDP A Temporarily Unavailable 10. ACK 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)

17 SIP Call Setup Attempt Scenario
DNS Server Location Server 3. DNS Query: mci.com? 4. Response: 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 Trying 1. INVITE Contact: A SDP A Temporarily Unavailable 10. ACK Trying 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)

18 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)

19 User Agent B (Not Signed In)
SIP Presence Example DNS Server Presence Server 3. SUBSCRIBE OK 4. Presence Server authorizes subscription by sending a 200 OK. 5. & OK proxied back to A. 2. SUBSCRIBE Inbound Proxy Server Outbound Proxy Server OK 1. SUBSCRIBE 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)

20 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 OK. 11. & OK is proxied back to B’s Presence Server. 7. NOTIFY <Not Signed In> OK 8. NOTIFY <Not Signed In> Inbound Proxy Server Outbound Proxy Server OK 9. NOTIFY <Not Signed In> 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)

21 SIP Registration Example
DNS Server Location Server 2. Update database: B = 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: 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

22 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 = 3. OK Outbound Proxy Server Outbound Proxy Server 1. REGISTER Contact: OK Contact: 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

23 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. & OK is proxied back to Presence Server. 13. NOTIFY <Signed In> OK 14. NOTIFY <Signed In> Inbound Proxy Server Outbound Proxy Server OK 15. NOTIFY <Signed In> 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

24 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. & OK is proxied back to A. DNS Server Location Server 3. LS Query: B? 4. Response: 2. MESSAGE <Can you talk now?> Inbound Proxy Server Outbound Proxy Server OK 1. MESSAGE <Can you talk now?> OK 5. MESSAGE <Can you talk now?> 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

25 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. & OK is proxied back to B. Location Server DNS Server 5. LS Query: A? 6. Response: 2. DNS Query: globalipcom.com? 3. Response: 4. MESSAGE <Sure.> Outbound Proxy Server Inbound Proxy Server OK 7. MESSAGE <Sure.> OK 1. MESSAGE <Sure.> 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

26 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: 3. INVITE Contact: A SDP A Inbound Proxy Server Outbound Proxy Server Trying 1. INVITE Contact: A SDP A 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

27 SIP Call Setup Scenario
DNS Server Location Server 8. User Agent B alerts B and sends 180 Ringing response. 9. & Ringing is proxied back to A. Ringing Inbound Proxy Server Outbound Proxy Server Ringing 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

28 SIP Call Setup Scenario
DNS Server Location Server 11. B accepts call and User Agent B sends 200 OK response. 12. & OK is proxied back to A. Ringing Inbound Proxy Server Outbound Proxy Server OK Contact: B SDP B Ringing OK Contact: B SDP B OK Contact: B SDP B 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

29 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! Ringing Inbound Proxy Server Outbound Proxy Server OK Contact: B SDP B Ringing OK Contact: B SDP B OK Contact: B SDP B 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

30 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.) OK SDP A 17. ACK User Agent A User Agent B

31 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: Accepted 20. NOTIFY <100 Trying> User Agent A OK User Agent B

32 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: 3. INVITE Contact: A Ref-By: B SDP A Inbound Proxy Server Outbound Proxy Server Trying 7. INVITE Contact: A Ref-By: B SDP A 1. INVITE Contact: A Ref-By: B SDP A 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

33 SIP Call Transfer Scenario
DNS Server Location Server 8. User Agent C alerts C and sends 180 Ringing response. 9. & Ringing is proxied back to A. 11. C accepts call and sends 200 OK response. 12. & OK is proxied back to A. 14. ACK is sent by A to confirm setup call. Media session between A and C begins. Ringing Inbound Proxy Server Outbound Proxy Server OK Contact: C SDP C OK Contact: C SDP C Ringing OK Contact: C SDP C 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

34 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. 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> OK 22. BYE User Agent A User Agent B OK

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

36 Call Proxying From the RADVISION whitepaper on SIP

37 SIP Call Redirection From the RADVISION whitepaper on SIP

38 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/2.0

39 } 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/2.0 Via: SIP/2.0/UDP host.wcom.com:5060 From: Alan Johnston To: Jean Luc Picard Call-ID: CSeq: 1 INVITE } Uniquely identify this session request

40 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/ Not Found First digit gives Class of response:

41 SIP Responses: 1xx-3xx

42 SIP Responses: 4xx

43 SIP Responses: 5xx-6xx

44 SIP Responses Example Required Headers:
Via, From, To, Call-ID, and CSeq are copied exactly from Request. To and From are NOT swapped! SIP/ OK Via: SIP/2.0/UDP host.wcom.com:5060 From: Alan Johnston To: Jean Luc Picard Call-ID: CSeq: 1 INVITE

45 SIP Headers - Partial List

46 SIP Headers - Continued

47 SIP Headers - Continued

48 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

49 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

50 SIP Message Body Message body can be any protocol
Most implementations: SDP - Session Description Protocol RFC /98 by Handley and Jacobson 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

51 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

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

53 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

54 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)

55 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.

56 SIP/SS7 MSC Call Flow


Download ppt "Signaling & Network Control 7th Semester"

Similar presentations


Ads by Google