1 / 54

Understanding SIP (I)

Understanding SIP (I). Outlines. Something About IETF It’s IP Telephony IP Telephony Basics Protocol Zoo SIP Signaling Reference. Something about IETF. Internet Engineering Task Force ( www.ietf.org ) IETF’s bussiness Standardization Procedure ( RFC 2026 )

jaclyn
Télécharger la présentation

Understanding SIP (I)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Understanding SIP (I)

  2. Outlines • Something About IETF • It’s IP Telephony • IP Telephony Basics • Protocol Zoo • SIP Signaling • Reference

  3. Something about IETF • Internet Engineering Task Force (www.ietf.org) • IETF’s bussiness • Standardization Procedure ( RFC 2026 ) • Advantages of the IETF Standardization Process • Related IETF Working Groups • SIP • IPTEL

  4. Appeals of IP Telephony • Saving • Lower QoS • Internet Service Integration • Distribution Games • Instant Messaging • In IP, you are your own master. • Open service market • Programmability

  5. What Protocols Are Needed？ • Signaling protocol • SIP / SDP • Media protocol • RTP • Transport protocol • TCP / UDP • Supporting Protocol • DNS • Diameter

  6. Protocol ZOO http://www.cs.columbia.edu/~hgs/internet/

  7. SIP Signaling

  8. Session Initiation Protocol • SIP is end-to-end, client-server session signaling protocol • Arbitrary services built on top of SIP • Features： • Text-based Encoding • Programmability • History

  9. SIP-General Purpose Presence Protocol • SIP is not limited to Internet telephony • Suitable for applications having a notion of session • Network games • Video conferencing, etc.

  10. SIP Workhorses • SIP Proxy Server • Relays call signaling • Operates in a transactional manner • SIP Redirect Server • Redirects callers to other servers • SIP Registrar • Accept registration requests from users • Maintain user’s whereabouts at a Location Server

  11. SIP Addresses • SIP gives you a globally reachable address • URLs used as address data format; examples： • sip:jiri@iptel.org • sip:voicemail@iptel.org?subject=callme • Sip:sales@hotel.xy; geo.position=48.54_-123.84_120 • Must include host, may include user name, port number, parameters, etc. • Address space unlimited • Non-SIP URLs can be used as well (mailto:...)

  12. REGISTER sip:iptel.org SIP/2.0 From:sip:jiri@iptel.org To:sip:jiri@iptel.org Contact:<sip:195.37.78.173> Expires:3600 jiri@195.37.78.173 SIP/2.0 200 OK SIP Registration Location Server SIP Registrar (domain: iptel.org)

  13. jiri ? INVITE sip:jiri@195.37.78.173 From:sip:Caller@sip.com To:sip:jiri@iptel.org Call-ID:345678@sip.com INVITE sip:jiri@iptel.org From:sip:Caller@sip.com To:sip:jiri@iptel.org Call-ID:345678@sip.com jiri@195.37.78.173 SIP/2.0 200 OK SIP/2.0 200 OK ACK sip :jiri@195.37.78.173 SIP Operation in Proxy Mode Location Server SIP Proxy Server Caller@sip.com jiri@195.37.78.173

  14. Proxy Server Functionality • Serve as rendezvous point at which callees are globally reachable. • Perform routing function • Allow the routing function to be programmable. Arbitrary logic may be built on top of the protocol. • Forking

  15. Proxy Chaining • There may be also cases when a local outbound proxy may be involved • In general, Server may be arbitrarily chained. • Servers have to avoid loops and recognize spirals.

  16. Proxy Chaining － Example

  17. “Stateful” Proxy Refers to Transactions SIP state forgotten as soon as transactio over Unless route recording is used, Bye may take a completely different Path to destination in Contact: header field BYE

  18. Callee ? Callee@home.com INVITE sip:Callee@example.com 302 Moved Temporarily Contact: Callee@home.com ACK sip:Callee@example.com INVITE sip:Callee@home.com SIP/2.0 200 OK ACK sip:Callee@home.com SIP Operation in Redirect Mode Location Server Caller@sip.com Callee@home.com SIP Redirect Server

  19. SIP Server － Proxy v.s Redirection • A SIP Server may either proxy or redirect a request. • Redirection useful if a user moves or changes her provider. • Proxy useful if forking AAA, firewall control needed.

  20. SIP RFC2543 Methods

  21. Response Status Line • SIP-Version SP Status-Code SP Reason-Phrase CRLF • Status-Code = SIP/2.0 SP 180 SP Ringing CRLF

  22. SIP Message Structure

  23. Reference • Understanding SIP, GMD Fokus • Introduction to SIP in Chunghwa Telecom Co. Ltd, Wen-Ping Lai, III • RFC 3261 (SIP: Session Initiation Protocol )

  24. Understanding SIP (II)

  25. Outlines • Session Description Protocol (SDP) • SIP Protocol Design • Real Time Transport Protocol (RTP) • Real-Time Transport Control Protocol (RTCP) • Media Path != Signaling Path • Programming SIP • SIP && QoS Control • To Be Continuing…….

  26. Session Description Protocol (SDP) • A well defined format for conveying sufficient information to discover and participate in a multimedia session – RFC 2327 • Session Announcement Protocol (SAP) • Periodically multicasting an announcement packet to a well known multicast address and port – RFC 2974

  27. Session Description Protocol (SDP) • SDP is a data format rather than a protocol • SDP include： • Session name and purpose • Times the session is active • The media comprising the session • Information to receive those media (addresses, ports, formats and so on) • Information about the bandwidth to be used by the conference • Contact information for the person responsible for the session

  28. Session Description Protocol (SDP) • Session description • v= (protocol version) • o= (owner/creator and session identifier). • s= (session name) • i=* (session information) • u=* (URI of description) • e=* (email address) • p=* (phone number) • c=* (connection information - not required if included in all media) • b=* (bandwidth information) • z=* (time zone adjustments) • k=* (encryption key) • a=* (zero or more session attribute lines)

  29. Session Description Protocol (SDP) • Time description • t= (time the session is active) • r=* (zero or more repeat times) • Media description • m= (media name and transport address) • i=* (media title) • c=* (connection information - optional if included at session-level) • b=* (bandwidth information) • k=* (encryption key) • a=* (zero or more media attribute lines)

  30. Session Description Protocol (SDP)Example • v=0 • o=sisalem 28908044538 289080890 IN IP4 193.175.132.118 • s=SIP Tutorial • e=sisalem@fokus.gmd.de • c=IN IP4 126.16.69.4 • t=28908044900 28908045000 • m=audio 49170 RTP/AVP 0 98 • a=rtpmap:98 L16/11025/2

  31. SIP Protocol Design • Infrastructure follows IP state model • Most intelligence and state in the end-devices • Network core maintains at most transactional state • Network edge may maintain session state • Benefits： • memory and CPU consumption low in servers, reliability and scalability high (no single point of failure) • UDP Support • faster set-up, less state • Idempotent INVITEs • SIP requests are said to be idempotent , i.e., receiving more than one copy of a request does not change the server state

  32. SIP Protocol Design Extensibility • SIP designers took lesson from HTTP • Self-identifying Attribute-Value-Pairs (AVPs) followed by separators (EoL) • best-effort: receivers ignore unknown AVPs and skip to next separator • SDP support compulsory, arbitrary MIME payloads may be included (JPEG, ISUP, charging info, Multipart, ...) • transparent proxying

  33. SIP Protocol Design Extensibility (Cont.) • SIP designers took lesson from HTTP (cont.) • classes of status codes (1xx in-progress, 2xx success, 3xx forwarding, ...) • guidance on designing new extensions provided (draft-ietf-sipguidelines) • Capability inquiry with OPTION -- returns supported methods (Allow), media types (Accept), compression methods (Accepted-Encoding), Supported (supported features)

  34. SIP Protocol Design IP Based Multimedia Communication • SIP mainly establishes the IP addresses and port numbers at which the end systems can send and receive data • SIP does not transport data and does not depend on a certain compression • Data packets most probably do not follow the same path as the SIP packets

  35. SIP Protocol Design IP Based Multimedia Communication • Audio/Video samples are digitized, compressed and sent in UDP packets • Compression schemes use limitations of human ears/eyes to reduce bandwidth • Reduce audio bandwidth using silence suppression • Reduce video bandwidth using motion detection

  36. Compression Codecs more http://www.cs.columbia.edu/~hgs/(audio/video)

  37. Real Time Transport Protocol (RTP) • Standardized by the IETF and used by ITU-T as well • Designed to be scalable, flexible and separate data and control mechanisms Payload

  38. Real Time Transport Protocol (RTP) • Provides information for: • Media content type • Talk spurts • Sender identification • Synchronization • Loss detection • Segmentation and Reassembly • Security (encryption)

  39. RTP Header V：Version P：Padding for encryption X：Extension bit Payload type：Audio/Video encoding method Sequence number：Number of packet increased by one for each new packet Timestamp：Different fixed value for each compression type SSRC：A random number identifying the source (unique per source)

  40. Real-Time Transport Control Protocol (RTCP) • Exchange information about losses and delays between the end systems • Measure QoS • Packets sent in intervals determined based on number of end systems and available bandwidth

  41. Real-Time Transport Control Protocol (RTCP) • Sender Reports: Information about sent data, synchronization timestamp • Receiver Reports: Information about received data, losses, jitter and delay • Source Description: Name, Email, Phone, Identification • Bye: Explicit leave indication • Application defined parts: Parts for experimental functions

  42. Media Path != Signaling Path Location server Signing IP hop Proxy server Media

  43. Media Path != Signaling Path • SIP proxies can not usually control media path as there is split between signaling and media. • IP, DiffServ, and RSVP are the protocols for communication between end-devices and the network. • Attempts to manipulate media flows in the middle of path will difficult and may tend to fail: • A proxy does not know all IP hops along an end-to-end media path • Hops may belong to foreign administrative domains. • Signaling and media transport (possibly w/QoS) are two different businesses. • A SIP proxy may be located far apart from media path.

  44. Media Path != Signaling Path • For generality, extensibility and performance purposes, proxies do not parse SDP. • Even if they did, their operation might result in failure as new extensions (e.g., new codecs) • Even with SDP knowledge, proxies do not know entire media flow selectors -- SDP indicates only destination address of media streams. • SDP may be encrypted. • Unless route recording used, subsequent SIP requests (including ACK w/SDP) may take completely different path. • Exception to the rule: firewall control • Better than embedded ALGs • Firewalls located in the same administrative domain as a call party and its SIP proxy • The construct still suffers from shortcomings listed previously

  45. Programming SIP • Users and third parties may program • SIP follows HTTP programming model • Mechanisms suggested in IETF: CGI, Call Processing Language (CPL), Servlets • CPL – RFC 2824 • SIP CGI – RFC 3050

  46. Programming SIP (Cont.)Where may signaling services live ? • Some services have to live in the network: • Call distribution • Services for dial-up users without always-on IP connectivity • Some services can be implemented in both places: • Forward on busy • Some services work best in end-devices: • Distinctive ringing

  47. Programming SIP CGI • Follows Web-CGI. Unlike Web-CGI, SIP-CGI supports proxying and processes responses as well. • Language-indpendent (Perl, C, ...) • Communicates through input/output and environment variables. • CGI programs unlimited in their power. Drawback: Buggy scripts may affect server easily.

  48. Programming SIP Call Processing Language (CPL) • Special-purpose call processing language. • May be used by both SIP and H.323 servers. • Target scenario: users determine call processing logic executed at a server. • Limited languages scope makes sure server’s security will not get compromised. • Portability allows users to move CPL scripts across servers. • Scripts may be manually written, generated using convenient GUI tools, supplied by 3rd parties, ...

  49. Call Processing Language (CPL)Example

  50. Programming SIP Java Servlets • Compromise between security and power: still a powerful generic language but security provided by Java “sand-box”. • JAIN thought to be a generic API applicable to almost any signaling (SIP, H.323, PSTN, etc.)

More Related