Understanding SIP (I)

1
Understanding SIP (I)
2
Outlines

• Something About IETF
• Its IP Telephony
• IP Telephony Basics
• Protocol Zoo
• SIP Signaling
• Reference

3
Something about IETF

• Internet Engineering Task Force (www.ietf.org)
• IETFs 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 users whereabouts at a Location Server

11
SIP Addresses

• SIP gives you a globally reachable address
• URLs used as address data format examples
• sipjiri_at_iptel.org
• sipvoicemail_at_iptel.org?subjectcallme
• Sipsales_at_hotel.xy geo.position48.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
SIP Registration
Location Server
SIP Registrar (domain iptel.org)
13
SIP Operation in Proxy Mode
Location Server
SIP Proxy Server
Caller_at_sip.com
jiri_at_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
SIP Operation in Redirect Mode
Location Server
Caller_at_sip.com
Callee_at_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
INVITE The user is begin invited to participate in a session.
ACK The client has received a final response to an INVITE.
OPTIONS The server is begin queried as to its capabilities.
BYE The user wishes to release the call.
CANCEL It cancels a pending request (not completed request).
REGISTER It conveys the users location information to a SIP server.
21
Response Status Line

• SIP-Version SP Status-Code SP Reason-Phrase CRLF
• Status-Code
• SIP/2.0 SP 180 SP Ringing CRLF

1xx Informational
2xx Success
3xx Redirection
4xx Client-Error
5xx Server-Error
6xx Global-Failure
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

SAP Header
Text payload (An SDP session description) no greater than 1 Kbyte in length
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

• v0
• osisalem 28908044538 289080890 IN IP4
  193.175.132.118
• sSIP Tutorial
• esisalem_at_fokus.gmd.de
• cIN IP4 126.16.69.4
• t28908044900 28908045000
• maudio 49170 RTP/AVP 0 98
• artpmap98 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
Codec Unidirectional Bandwidth (kb/s)
G.723 5.3/6.3
GSM 13.0
G.711 64 (telephone)
MPEG L3 56-128
Video depends on content, frame rate compression and motion
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

PHY/MAC IP UDP RTP Media content
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 Pad X Mark Payload Type Sequence number
Timestamp Timestamp Timestamp Timestamp Timestamp Timestamp
Synchronization source (SSRC) identifier Synchronization source (SSRC) identifier Synchronization source (SSRC) identifier Synchronization source (SSRC) identifier Synchronization source (SSRC) identifier Synchronization source (SSRC) identifier
Payload Payload Payload Payload Payload Payload

• VVersion
• PPadding for encryption
• XExtension bit
• Payload typeAudio/Video encoding method
• Sequence numberNumber of packet increased by one
  for each new packet
• TimestampDifferent fixed value for each
  compression type
• SSRCA 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 servers
  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.)

51
Call Processing Language (CPL)Tradeoffs

• Generality versus security
• Multipurpose programming languages provide a huge
  service space
• But also a huge vulnerability space
• Performance versus portability
• Portable languages (CPL) need to be interpreted
• higher processing delay
• Portability needed if services deployed at
  multiple servers or end-devices (e.g. if stored
  at USIMs)
• Recommendation
• Choice of appropriate service creation mechanism
  depends on deployment scenario, i.e. where the
  service is executed and by whom the service is
  maintained

52
Programming SIP Generality VS. Security

• Generality
• CGI Highest. Any binaries may be executed.
• Servlets Medium. All commands known to Java
  Virtual Machine may be executed.
• CPL Lowest. Only CPL commands may be executed.

53
SIP QoS Control

• SIP DOES NOT provide QoS support.
• QoS is coupled with SIP through the notion of
  preconditions.
• Objective is to ensure that resources are made
  available before the phone rings.
• Invitations might indicate in SDP that QoS
  assurance is mandatory.
• Call setup should only proceed after satisfying
  the preconditions
• SIP extended method (COMET) indicates the success
  or failure of the preconditions.

54
SIP QoS Control (Cont.)