Internet Telephony Lecture Notes

19 June 2008 • The Session Initiation Protocol

Outline

• Network model.

• SIP objectives and abstractions.

• SIP architecture.

• SIP messages.

• SIP URIs.

• Controlling SIP gatekeepers.

Network Model

SIP

• The Session Initiation Protocol (SIP) defines gatekeepers in the control plane.

  • Defined, for the most part, by IETF standard rfc 3261.

• SIP gatekeepers (or servers) are responsible for session management.

  • Create, manage, and tear-down service instances.

SIP Objectives

• User definition and management.

• Session determination (requirements and protocols).

• Session set-up, management, and termination.

• SIP itself, however, rarely does performes these functions.

  • It relys on subsidiary protocols under its control.

SIP Abstractions

• SIP provides the following abstractions:

  • User location - find session end-points.

  • User availability - gathering the endpoints.

  • User capability - acceptable media.

  • Session set-up - organize the session.

  • Session management - maintenence and tear-down.

Associated Protocols

• Some of the protocols used by SIP to manage sessions:

  • RTP, RTCP, RTSP - media transport.

  • MGCP, Megaco - gateway control.

  • SDP, SAP - session management.

  • RSVP, TRIP - resource management.

• Other protocols added as needed by services.

SIP Characteristics

• SIP gatekeepers can maintain state or not.

• Interacts well with HTTP.

  • The SIP protocol is heavily influenced by HTTP.

• SIP message payloads are opaque to SIP servers.

• Associates URLs with users.

SIP and the Control Plane

• SIP makes minimal assumptions about control-plane services.

  • SIP expects datagram service.

  • Other protocols used by SIP may have more exacting requirements.

  • SIP gatekeepers may take advantage of other control-plane services.

• SIP message formats allow control over a wide variety of media.

SIP Architecture

• The SIP architecture in a network is a collection of SIP gatekeepers.

• A SIP gatekeeper is an independently executing process.

• SIP-server subsets interact to provide service sessions.

  • The subset is dynamic.

• Conceptually, the SIP gatekeepers are independent of either plane.

SIP Domains

• A SIP domain is a set of related SIP gateways and associated entites.

  • Similar to Internet domains.

• A SIP domain is largely an administrative artifact.

  

SIP Interactions

• The SIP architecture is based on a request-response model.

  

• Sometimes known as the client-server model.

  • But SIP requests may elicit multiple responses.

SIP Transactions

• A SIP transaction is a sequence of one or more request-response messages.

  Session management is a transaction sequence. “Trying” and “ringing” are provisional responses. “Ok” is a final response.

SIP Architectural Patterns

• There are four behavior patterns defined for SIP servers:

  1. Redirector - routing management.

  2. Registrar - information management.

  3. Proxy - change management.

  4. User agent - party management.

• Each SIP server in a network exhibits one (or more) of these behaviors at any time.

SIP Redirectors

• A redirector responds to requests with a reference to the server that should properly receive the request.

  A redirector is more efficient than a proxy. But requires explicit knowledge of the redirector.

SIP Registrars

• A registrar defines and tracks dynamic entities on the network.

  

  • Including users and sessions.

SIP Proxies

• A proxy represents some other SIP server.

  

• Proxy servers provide a level of indirection.

  • Important for mobility services.

SIP User Agent

• The SIP server closest to the user's phone is the phone's user agent.

  

  • It is the user's representative to the rest of the network.

SIP Messages

• Each request and response is a SIP message.

• A SIP message is a lot like an HTTP/1.1 message.

  Messages are text. Payloads are opaque to the SIP servers.

• The SIP message format makes it easy to extend for new services.

Example SIP Message

INVITE SIP:UAB@example.com SIP/2.0
Via: SIP/2.0/UDP 10.20.30.40:5060
From: UserA <SIP:UAA@example.com>;tag=589304
To: UserB <SIP:UAB@example.com>
Call-ID: 8204589102@example.com
CSeq: 1 INVITE
Contact: <SIP:UserA@10.20.30.40>
Content-Type: application/sdp
Content-Length: 141

v=0
o=UserA 2890844526 2890844526 IN IP4 10.20.30.40
s=Session SDP
c=IN IP4 10.20.30.40
t=3034423619 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Example SIP Response

SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com
  ;branch=z9hG4bKhjhs8ass877;received=192.0.2.4
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Contact: <mailto:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Content-Length: 274

[sdp payload deleted]

SIP Request Types

• There are six SIP requests (or methods):

  1. ACK - confirm responses.
  2. BYE - leave a session.
  3. CANCEL - abandon request.
  4. INVITE - initiate a session.
  5. OPTIONS - information access.
  6. REGISTER - bind party data.

• See rfc 3261 for details.

SIP Message Fields

• Header fields in SIP messages provide SIP-specific information for the message.

• Example fields:

  Call-ID - identify a session.
  CSeq - order SIP messages within a call.
  VIA - hop-by-hop message route.
  Supported - extensions provided by SIP server.
  Require - extensions needed by session.

Extending SIP Messages

• SIP messages may be extended in two ways:

  1. Define new message types.

  2. Define new header fields for existing messages.

• Define new message types to create new session function.

• Define new header fields to change existing session function.

Example SIP Message Extensions

• SIP messages defined outside rfc 3261 include

  INFO - session information (rfc 2976).
  PRACK - provisional acknowledgment (rfc 3262).
  SUBSCRIBE - register interest in events (rfc 3265).
  NOTIFY - event-occurrence notification (rfc 3265).
  UPDATE - session set-up data (rfc 3311).
  MESSAGE - instant messaging (rfc 3428).
  REFER - forward to another server (rfc 3515).

SIP URIs

• SIP represents communication entities by uniform resource identifiers (URIs).

  • Example communication entities include

    • A cell-phone owner.

    • A conference participant.

    • A mailbox on some system.

    • Everybody at the help desk.

• SIP assumes the entity-URI mapping is given.

SIP URI Format

• SIP URIs follow HTTP format.

• Most generally, a SIP URI has the form

  sip:user:password@host:port;uri-parameters?headers

  sip - protocol
  user - user name or number, optional.
  password - optional, depricated.
  host - user home (SIP domain locaton).
  port - user agent port, optional.
  uri-parameters - optional
  headers - header fields, optional.

Example SIP URIs

sip:alice@atlanta.com

sip:alice@192.0.2.4

sip:alice:secretword@atlanta.com;transport=tcp

sips:alice@atlanta.com?subject=Help&priority=urgent

sip:+1-212-555-1212:1234@gateway.com;user=phone

sips:1212@gateway.com

sip:atlanta.com;method=REGISTER?to=bob%40atlanta.com

SIP URI Resolution

• SIP URIs represent users outside the SIP domain.

  • They don't represent entities within the domain.

• A SIP server usually has to translate a URI into an addressable domain entity.

• One or more registrars, called location servers maintain the URI-entity database.

  • This is different from DNS resolution.

    • Although DNS may be involved.

  Example SIP Interaction

  

  Controlling SIP Gatekeepers

  • Creating a service session requires a subset of SIP gatekeepers behave in some way.

  • Service-session behavior can be programmed into SIP gateways.

    • Not flexible, difficult maintenance.

  • SIP gateways can interpret service-behavior programs.

    • The programs may be CGI scripts, or servelets, or maybe even applets.

  SIP CGI

  

  SIP Mobility

  • SIP can proxy for other servers, allowing mobility.

    

  • Manipulate location servers before a call.

  • Use mobile IP or proxies during a call.

  References

  • RFC 3261, SIP: Session Initiation Protocol by Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, Alan Johnston, Jon Peterson, Robert Sparks, Mark Handley, and Eve Schooler, Network Working Group, Internet Engineering Task Force, June 2002.

  ---

  This page last modified on 17 June 2008.