Multimedia & Protocols in the Internet

(1)

Information and Communication Networks

- Introduction to SIP

Bernard Hammer

Siemens AG, München

page 2

Presentation Outline

SIP Basics

SIP architecture

Syntax

Call flows examples

Routing

Media Negotiation

Standardization issues

(2)

6/24/2004

page 3

SIP: Basic Idea

SIP = ‘Session Description Protocol’ Proposed IETF Standard RFC 3261

Peer-to-peer application layer protocol where endpoints (User Agents) initiate, modify and terminate sessions.

SIP uses existing IETF protocols to provide media negotiation (SDP), media transport (RTP), name resolution and mobility (DHCP, DNS), and application encoding (MIME)

Users are known by SIP URIs.

Text-based encoding based on a HTTP-like request/ response transaction model.

Simple extensions by introducing new ‘Methods’ and ‘Headers`

No relation between (SIP) signaling path and data stream path.

does not provide services, rather primitives that can be used to implement different services in conjunction with other protocols

Source: User Agent A Home of B: Proxy / Registrar Target: User Agent B SIP INVITE Data Stream page 4

SIP Entities in the Network

IP Backbone SIP-T SIP _RTP Switch MGC with SIP sign. Gateway _H.323 SS7 H.248 (POTS, ISDN, VoDSL) H.248 SIP User database e.g., LDAP SIP SIP proxy/ registrar

2

SIP Redirect SIP SIP proxy

1

SIP RTP Application Servers Non-SIP

3

4

RTP SIP SIP User Agents RTP SIP SIP User Agents

1

(3)

6/24/2004

page 5

SIP Functional Entities

User Agent (UA)

Intelligent endpoint entity capable of managing its own sessions Paradigm: Intelligence to the edge!

Initiates and terminates SIP requests; Always call stateful

Is an application, containing both UA client (UAC) and UA server (UAS)

Registrar

Register current physical address of user agent Provide location information based on the registrations Essential for reachability

Proxy Server

Intermediate SIP node (“SIP router”) Routes SIP requests towards their target

Accesses location and routing information to do its job

SIP Proxies can be: stateless, transaction stateful or call stateful Additional jobs: e.g. access control, NAT / Firewall control

Redirect Server

Find location information and return it to user agent No forwarding of requests, usually “search intensive”

1

2

3

4

page 6

SIP messages

SIP is a Client-Server protocol similar to HTTP. Most SIP

components can act as client and as server.

A SIP transaction is composed of a request of a client to

a server and its response.

Message parts are:

Start Line: conveys message type & protocol version

Headers: to convey message attributes and to modify

message meaning

Body:

to describe the session to be initiated or to

transport opaque textual or binary data. Body

types: SDP, MIME, others)

(4)

6/24/2004

page 7

SIP Basic Request Methods

Method

Function

INVITE

Invites a user to a call

ACK

Used to facilitate reliable message exchange

for INVITEs

BYE

Terminates a connection between users or

decline a call

CANCEL

Terminates a request, or search for a user

OPTIONS

Solicits information about a Server’s

capabilities

REGISTER Registers a users current location

INFO

Used for mid-session signaling

page 8

SIP Responses

Similar to HTTP Response Codes (

e.g. 404 Not Found )

1xx Informational

( e.g. 100 Trying, 180 Ringing )

2xx Successful

( e.g 200 OK, 202 Accepted )

3xx Redirection

( e.g. 302 Moved Temporarily )

4xx Request Failure

( e.g 404 Not Found, 482 Loop Detected )

5xx Server Failure

( e.g 501 Not Implemented )

(5)

6/24/2004

page 9

SIP Call Flow with direct invitation

1 INVITE sip:[email protected] SIP/2.0 2 SIP/2.0 200 OK

3 ACK sip: [email protected] SIP/2.0

siemens.at delta.swh.sk

page 10

SIP Call Flow with Proxy Server

7 SIP/2.0 200 OK

8 ACK sip: [email protected] SIP/2.0 siemens.at

delta 1 INVITE sip: [email protected] SIP/2.0

4 INVITE sip:aj@delta SIP/2.0

9 ACK sip:aj@delta SIP/2.0 6 SIP/2.0 200 OK 5 ring 3 aj@de lt a 2 anto n.ja net ka location server swh.sk

(6)

6/24/2004

page 11

SIP Call Flow with Redirect Server

1 INVITE sip: [email protected] SIP/2.0 4 SIP/2.0 302 Moved temporarily 5 ACK sip: [email protected] SIP/2.0 siemens.at

delta 6 INVITE sip: [email protected] SIP/2.0

7 ring 3 aj@delta 2 anton.janetka location server swh.sk

9 ACK sip: [email protected] SIP/2.0 8 SIP/2.0 200 OK

page 12

A SIP Request in Detail

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com

;branch=z9hG4bK776asdhds Max-Forwards: 70

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 154 <CRLF> v=0 o=alice 2890844730 2890844732 IN IP4 pc33.atlanta.com s=

c=IN IP4 pc33.atlanta.com t=0 0

m=audio 54344 RTP/AVP 0 a=rtpmap:0 G711/8000 a=sendrecv

Method Type, Request URI, SIP Vers. Address of previous hop

Max. number of hops User being invited User originating the call Globally unique call Identifier Command sequence number & type URI of Alice to receive requests Body type – here SDP payload Length of body in characters SDP version

Owner/ creator & session identifier Subject of session (here empty) Connection information Media & transport information

(7)

6/24/2004

page 13

Example Request/Response

SIP/2.0 200 OK

Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.168.1.169 To: Bob <sip:[email protected]>;tag=88209988923 From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 154 v=0 o=bob 2890844815 2890844815 IN IP4 pc.bobshouse.com s=

c=IN IP4 pc.bobshouse.com t=0 0

m=audio 42993 RTP/AVP 0 a=rtpmap:0 G711/8000 a=sendrecv

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com

;branch=z9hG4bK776asdhds Max-Forwards: 70

To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 154 v=0 o=alice 2890844730 2890844732 IN IP4 pc33.atlanta.com s=

c=IN IP4 pc33.atlanta.com t=0 0 m=audio 54344 RTP/AVP 0 a=rtpmap:0 G711/8000 a=sendrecv page 14

Via Operation

Address: B Address: C Address: D

Via: A Via: B Via: A Via: C Via: B Via: A Via: C Via: B Via: A Via: B Via: A Via: A Request Response

z

Responses take same path as requests

z

The Via header field acts like a stack

zEach proxy pushes its address in requests zPops its address in responses

z

Information placed in the request comes back in the response

(8)

6/24/2004

page 15

Initial SIP request may be sent

through many proxies

It is frequently unnecessary for

subsequent requests to go

through all of them

Each proxy can decide whether it

wants to receive subsequent

requests

Inserts Record-Route header

containing its address

For subsequent requests,

endpoints insert Route header

Contains sequence of proxies that

should receive request

Route is fixed for the duration of

the dialog.

Routing of Subsequent Requests

INVITE

BYE

page 16

Forking – Search user’s location

A proxy may have more than one

address for a user

Happens when more than one SIP

URL is registered for a user

Can happen based on static

routing configuration

In this case, proxy may fork

Forking is when proxy sends

request to more than one

destination at once

First 200 OK that is received is

forwarded upstream

All other unanswered requests

cancelled

INVITE user@domain

INVITE user2@domain2

(9)

6/24/2004

page 17

Forking ctnd

Main benefits

Allows rapid “search” for user at many locations Phone rings more than one place at a time

Two variations

Sequential Search: Try first address, only if that fails try second

address

Parallel Search: Try all addresses at once (as in previous slide)

Hybrid approaches possible

Many proxies can fork, resulting in tree of proxies

“Best” response to forked request is chosen and forwarded

upstream

First 200 OK received First 600 received if no 200 OK

Lowest numbered response after all responses are received, given

none was 200 or 600

Note usually only one response is forwarded upstream

page 18

Offer/Answer – Negotiating Media

Range of options for a session are advertised in an Offer using

SDP

Multiple media streams

Multiple codecs offered for each stream

Offer can constrain media direction and codec parameters like

bandwidth and framesize

The Answer contains selections from options listed in the Offer

Individual streams are accepted or rejected

At least one codec is selected for each offered stream

An Offer is typically carried in an INVITE, and the Answer in its

200 OK

Variations: Early media, 200/ACK, UPDATE

A Session established when an Offer/Answer exchange

completes

Dialogs are established with specific SIP messages

Sessions can be modified using subsequent Offer/Answer

exchanges

(10)

6/24/2004

page 19

Example of Offer/Answer Exchange

v=0

o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s=

c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 v=0

o=bob 2890844730 2890844730 IN IP4 host.example.com s=

c=IN IP4 host.example.com t=0 0 m=audio 49920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000

ALICE’s

Offer

BOB’s

Answer

page 20

Compatibility

On the Relationship of Standards

Services & Applications

Frameworks & Interworking

Extensions

(11)

6/24/2004

page 21

Extension vs Application

Extension

Requires new protocol primitives (methods, headers)

– a toolkit for building applications

Requires more than one entity in an exchange to do

processing not specified in RFC3261

Needs to be defined based on extension guidelines in

IETF

E.g. REFER, SUBSCRIBE, replaces

Application

No new protocol primitives needed

Generally requires only one entity in an exchange to

know about the application

Informational RFC can be generated in the SIPPING

working group

E.g. SIP-T, Call Transfer,…

page 22

Who does SIP related Standardization Work?

S I P

Standard

International Fora

(12)

6/24/2004

page 23

Key Areas of Interest in SIP

SIP Forum

IMTC

TIA

Softswitch C

PacketCable

ITU-T

IETF

ETSI

()

ECMA

3GPP

Compliance/ Interop Tests Services/ Applications Frameworks/ Interworking New Features/ Extensions

Org.

Area

page 24

Who does SIP related Standardization Work?

3GPP

decided to use SIP in the CSCF of the IP Multimedia Subsystem

(IMS) of its 3G mobile network.

ECMA TC32

Usage of SIP for Enterprise Networks

ETSI TISPAN

Control Layer for Next Generation Networks NGN

IMTC

Interoperability testing of IP-based communication products

ITU-T SG13

Specification of SIP-ISUP interworking

PacketCable

Specification of cable-based communication, e.g. DCS

Softswitch Consortium

Softswitch architecture for IP-telecommunication (-> SIP-T)

SIP Forum

(13)

6/24/2004

page 25

Many IETF Working Groups have

SIP-related Activities

MMUSIC WG:

provides SDP as an supplement to SIP for session description. Currently working on new versions (SDPnew, SDPng) SIP WG

Guardian of the SIP standard incl. maintenance, extensions, changes or new features SIPPING WG

documents the usage of SIP and filters out need for extensions, new features.or changes IPTEL WG

is on IP Telephony issues, contributes e.g. CPL for ease of service creation with SIP SIMPLE WG:

provides Instant Messaging and Presence Leveraging

Extensions to SIP,

SPIRITS WG:

specifies framework for accessing IN services from SIP-networks AAA WG

addresses SIP access and billing issues

ENUM WG:

provides mapping of E.164 phone numbers to SIP URLs using DNS SPEECHSC WG,

develops protocols for distributed media processing of audio streams supporting ASR, TTS, SI and SV using SIP

XCON WG

takes care for centralized

conferences, including floor ctrl, and conference and media policy control

page 26