IP Telecom Signaling: Softswitch, H.323, and SIP with SDP

Chiang, Wei-Kuo (江為國)

Associate Professor Department of CSIE National Chung Cheng University Office : EA 311 Phone : 05-2720411~33126 Email : [email protected]

URL : http://www.cs.ccu.edu.tw/~wkchiang/

IP Telecom Signaling:

Softswitch, H.323, and SIP with SDP

Outline

Introduction What is SIP? Why SIP?

When SIP? Where SIP?

SIP Protocol SIP Basics

SIP Message

SIP Communication

SIP Extensions

SIP in NGN 3GPP IP Multimedia Subsystem (IMS)

IMS Call Session Control Function (CSCF)SIP Protocol原理 2

The Telephone Network (1/2)

SIP Protocol原理 3

Class 5

End Office Switch

Circuit Switched Network

Intelligent

Peripheral

Signal

Transfer

Point

Service

Control

Point

Class 4

Tandem Switch

Service

Data

Point

+

Transport Layer

Control Layer

SS7 Signaling

ISUP Messages

INAP/TCAP Messages

備忘稿

傳統電信網路中電話建立的過程為：語音(Voice)部份是經由局用交換機(CO Switches)之間的Trunk介面傳輸；信令(Signaling)部份則是透過SS7網路傳遞。

如果只是一般的通話，負責通話控制(Call Control)的SS7 ISUP信令，僅會透過SS7網路的信號轉運點(Signal Transfer Point；STP)，在發話端交換機(Originating Switch)與受話端交換機(Terminating Switch)之間傳送；

然而，當通話需要智慧型網路服務(IN Services)時，則要發送SS7 TCAP信令，經由SS7網路轉送至提供該服務的服務控制點(Service Control Point；SCP)，要求提供該項服務；

若是該項服務包括語音播放(Announcement) 、互動語音回應(Interactive Voice Response；IVR)，此時SCP就會要求智慧型設備(Intelligent Peripheral；IP)播放語音給發話端，同時偵測發話端的按鍵，並將按鍵結果之DTMF回傳給SCP，用來決定該項服務的進行。


The Telephone Network (2/2)

5 Basic Components in Intelligent Networks SSP/Service Switching Point

switching, signaling, routing, service invocation

STP/Service Transfer Point

signaling, routing

SCP/Service Control Point

service logic execution

SDP/Service Data Point

subscriber data storage, access

IP/Intelligent Peripheral

resources such as customized voice announcement, voice recognition, DTMF digit collection


SSP

SCP SDP

STPIP

SSP

STP

TCAP messages

ISUP messages

Voice

Telephony Switches

Hierarchy of telephony exchanges (switches)

Class 1 – Regional

Class 2 – Sectional

Class 3 – Primary

Class 4 – Toll

Class 5 – Central OfficeAll telephony lines terminated in a central office

The central office (CO) offered only local services

Classes 1~4 switch connections only, have no subscribers attached to them

The lower the class number and the bigger the exchange


ISUP Signaling

Used as the protocol for setting up and tearing down phone calls between switches

Initial Address Message (IAM) To initiate a call between two switches

Address Complete Message (ACM) To indicate that the call party’status

Answer Message (ANM) To indicate that a call has been accepted by the called party

Release Message (REL) To initiate call disconnection

Release Complete Message (RLC)


ISUP Call Establishment


Calling

IAMSetup

Originating

SSP

ACMAlerting

ANMConnect

Tandem

SwitchCalled

IAM SetupIAM

Terminating

SSP

AlertingACMACM

ConnectANMANM

Tandem

Switch

Conversation

ISUP Call Release


Calling

REL

Disconnect

Originating

SSP

RLC

Release

Tandem

SwitchCalled

REL

Disconnect

REL

Terminating

SSP

RLC

RLC

Release

Tandem

Switch

備忘稿建立通話，發話端的交換機會送出 IAM。IAM 帶有發話人電話號碼、收話人電話號碼、傳輸的輸求、發話人種類（一般通話、系統商通話、付費電費）等資訊。

經由 STP 傳輸到收話端的交換機後，會回傳一個 ACM 來告知發話端：「通話已經連接到了目的地。」而 ACM 會開啟一個由收話端到發話端的單向音訊路徑，如果收話端可以接聽的話，發話端即可聽到撥話時的振鈴聲(ring-back tone)。如果不可以接聽的話，發話端即可聽到撥話時的嘟嘟聲(busy tone)。

嚴格來說，ACM是一個 optional 的訊息，如果不回傳 ACM 就不會開啟單向音訊路徑，並不會影響到通話建立的成功率，而發話端必須等到完整的通話建立之後才會知道通話已經建立。但是當撥話之後，如果發話端能先聽到 ring-back tone 就好像收話端可以即時的 response （雖然尚未完全建立通話），因此大多數仍然會回傳 ACM。

收話端接起電話時，收話端的交換機會回傳一個 ANM，而這個訊息有兩個功能：開啟雙向的音訊路徑以及開始對通話計費。

通話結束之後，當兩端有使用者掛下電話時，該方交換機會送出 REL 訊息，另一方的交換機收到後則會送出 RLC 的訊息。在 RLC 回傳到對方的交換機之後，通話便結束了。


What is SIP?

SIP (Session Initiation Protocol)

Application-Layer Control Signaling Protocol

SIP is Text-based, HTTP-like, “Request-Response”

establish, modify and terminate multimedia sessions

SIP (+ SDP) to describe the session characteristics


SIP Signaling

IP Network

RTP Media Stream

SIP User SIP User

Related Specifications

SIP: Session Initiation Protocol

J. Rosenberg , H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler

RFC 2543(-> 3261prop), March 1999 (-> June 2002).

SDP: Session Description Protocol

M. Handley, V. Jacobson, C. Perkins

RFC 2327(-> 4566prop), April 1998 (-> July 2006).

RTP: A Transport Protocol for Real-Time Applications

H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson

RFC 1889(-> 3550std64), January 1996 (-> July 2003).


SIP History

Developed in SIP Working Group in IETF

Work began 1995

Proposed standard RFC 2543, February 1999

Sep. 1999 split from MMUSIC Multiparty Multimedia Session Control

New Version of SIP - RFC 3261, June 2002

Applied to NGN signaling

SIP for Signaling Transparency inter-softswitch communications

SIP for Softswitch Service Interface

Call control protocol in 3GPP IP Multimedia Subsystem SIP Protocol原理 13

Softswitch Overview

Softswitch: Emulating Circuit Switching in Software


IN/SCP

PSTN

Local Switch

PSTN

Local SwitchSTP SS7 Network

IP Network

RTP Streams

MGC MGC

Trunk

GatewayTrunk

Gateway

SIP-T

SGSG

SIGTRAN

MEGACO

IP Phone

9000 Personalized VoIP

Service System

Application Server

Introduction to Telecom. Networks Voice over IP (Internet Telephony)15

Softswitch Overview (2/2)

Softswitch Provides Open Layered Architecture

• Solutions in a proprietary box

• Expensive

• Little room for innovation

Circuit-Switched

Transport

Hardware

Call Control &

Switching

Services &

Applications

P

R

O

P

R

I

E

T

A

R

Y

• Solutions are open standards-based

• Customers choose best-in-class products

• Open standards enable lower cost for innovation

Soft-Switched

Transport Hardware

Softswitch Call Control

Services, Applications & Features

(Management, Provisioning and

Back Office)

Open Protocols APIs

Open Protocols APIs

Open APIs for 3rd Party App develop.

Best-in-class Access Devices.

Scalable, Open Interfaces for Comm.

Softswitch Architecture


CO

Switch

STP

SCP

CO

Switch

STP

SCP

Signaling Layer

Transport Layer

IP

SIP-T

Media

Server

RTP

SIP-?/

MGCP

SIP-TSI

Media

Gateway

Controller

MGCP/

MEGACO

Phones

App.

Server

Media

Gateway

Controller

SIGTRAN

SSA/SCTP

MGCP/MEGACOTrunking

Gateway

Signaling

(SS7)

Gateway

SS7 TCAP

ISUP/TCAP

17

Softswitch Architecture (2/2)

Media Gateway Controller (MGC) provides basic call control, signaling, manages resources, generates CDR

Application Server (AS) hosts enhanced services:

calling card, 800 translation, voice mail, follow-me

provides service/AP interfaces access to underlying service & switching functions

Media Server (MS) provides specialized resources:

IVR, conferencing, facsimile functions

AS can access MS to utilize resources on MS

SIP Protocol原理

Softswitch Operations

Inter-Softswitch Communications


Local

Switch

STP

Trunking

Gateway

Signaling

(SS7)

Gateway

Media

Gateway

Controller

STP

Trunking

Gateway

STP

Media

Gateway

Controller

Signaling

(SS7)

Gateway

STP STP

Domain A Domain B

Local

Switch

Routing

Directory

3

1

5

2

ISUP IAM

4

SIGTRAN

MGCP/MEGACO

6 SIP-T

7

9

16

Voice

RTP

8

ISUP IAM

12

13

Voice

10

11

14 ISUP ACM

15 ISUP ANM

ISUP ACM

ISUP ANM

19

MGCP/

MEGACO

Phones

Trunking

Gateway

Signaling

Gateway

MGC

SIGTRAN

SSA/SCTP

RTP

MGCP/MEGACO

SS7 TCAP

ISUP/TCAP

Softswitch Protocols (1/3)

Concept of MGCP/MEGACO

CO

Switch

STP

SCP

PSTN

Phones

Media

Gateway

MGC

Connection

Create

Delete

Modify

Event Notification

Request

Status

Query

Response

Success

Failure

Event

Notify

Status

Report

Dumb Client

Stateless

Intelligent

Server

SIP Protocol原理

20


IETF SIGTRAN - for SS7 over IP

ISUPTCAP

SCCP

MAP

MTP

OSI Layers

Application

Presentation

Session

Transport

Network

Data Link

Physical

INAP

SS7 Protocol Stack

ISUPTCAP

SCCP

MAP

SCN Signaling Adaptation

(SSA)

Common Signaling Transport

(CST)

IP

INAP

SIGTRAN Protocol Stack

SIP Protocol原理

21

CO

Switch

PSTN

Phones

Trunking

Gateway

MGCP/MEGACOCO

SwitchTGW


SIP-T (SIP for Telephones) : RFC 3372 (Sept.2002)

interface between softswitches

MGCMGC

STP

SCP

Signaling

Gateway

SIGTRAN

SSA/SCTP

SS7 TCAP

ISUP/TCAP

STP

SCP

SG

SIP-T

SIP Message +

Mid-call control

Header

ISUP

SDP

. . .

ISUP/SS7

Messages

MTP

ISUP

ISUP/IP

Messages

ISUP

IP

SIP

UA

SS Adapt.

SCTP

SIP Protocol原理

IP-PSTN Converged Network


CO

Switch

STP

SCP

CO

Switch

STP

SCP

Trunking

Gateway

Signaling

(SS7)

GatewayMedia

Gateway

Controller

Residential

Gateway

RTP

SS7 TCAP

ISUP/TCAPMGC

SG

TGW

SIP-T

SIP

Phones

SIP

Server

SIP

Server

SIPAS

MS

SIP

Call Flow (1/2)

SIP bridging


PSTN Proxy Softswitch 2Softswitch 1 PSTN

IAM

ACM

ANM

REL

RLC

IAM

ACM

ANM

REL

RLC

INVITE

18x

200 OK

BYE

200 OK

100 TRYING

ACK

Conversation

Call Flow (2/2)

PSTN Origination – IP Termination


PSTN Proxy SIP PhoneSoftswitch

IAM

ACM

ANM

REL

RLC

INVITE

18x

200 OK

BYE

200 OK

100 TRYING

ACK

Conversation

INVITE

18x

200 OK

ACK

BYE

200 OK

H.323 Architecture


Has Been Adopted by Vendors for Years

H.323Terminal

H.323Terminal

H.323MCU

H.323Terminal

H.323Gateway

H.323Gatekeeper

Packet Based Network

Scope of H.323

GSTN/PSTN

H.323 Terminal


H.323 Call Setup Flow


Logical Channel

3. Setup

Q.931 Call Signaling Channel

RAS Channel

1. ARQ (alias address/bandwidth)

2. ACF (call signaling channel address/bandwidth)

5. ARQ 6. ACF

8. Connect (H.245 Address)

4. Call Proceeding

7. Alerting

H.245 Control Channel (Logical Channel 0)

Master/Slave Determination

RTCP StreamRTCP Stream

RTP Stream

Gatekeeper

Terminal

Terminal

Capability Exchange

OpenLogicChannel (RTCP address)

OpenLogicChannelACK (RTP & RTCP address)

H.323 Gateway


H.323 Gateway

System

H.323 Terminal

(NetMeeting)

package

switch

network

H.323 Protocol

PBX

Phone Phone Phone

Internet/

Intranet

H.323 Gateway

System

PBX

Phone Phone Phone

PSTN

(2)

(4)

(5)(1)

Call Route

Table(3)

Why SIP? (1/2)

Evolution Traditional Telecom (SS7) -> IP Telecom (H.323/SIP)

Voice call (H.323/SIP)

Multimedia Session (SIP)

Converged Service (SIP)

A powerful alternative to H.323

More flexible, simpler

Easier to implement advanced features

Better to support of intelligent user devices

Transport independence (UDP, TCP, or SCTP)


Why SIP? (2/2)

It is easier to support than H.323

Lots more products than H.323

Cheaper than H.323

Does more than H.323

Has digest authentication (encrypted shared key for users)

In practice SIP has more features than H.323.

All the Video/PABX Manufacturers are moving to SIP!

Find a H.323 client for Mac or Unix – no, you can not!

But there are SIP clients for Mac, Unix, PDAs, Microsoft messenger is a Video capable SIP client (support G.722.1 and H.263), GPRS, G3, ….!


By Stephen Kingham, 2005

H.323 vs. SIP


IETF ProtocolITU-T Protocol

SIPH.323

RFC 2543 (March 1999)V.1 ( May 1996)

Working Groups: SIP,SIPPING, and SIMPLE

Study Group 16

Now RFC 3261 (2002)Now V.7 (2009)

H.323 vs. SIP


User AgentUser Node

SIPH.323

Registrar, Proxy, Redirect Server

Network Node

None*

IP-PSTN Gateway

Terminal

Gatekeeper

Multipoint Control Unit (MCU)

IP-PSTN Gateway

*What SIP cannot provide?

H.323 vs. SIP


SIPSignaling

SIPH.323

SDPCapacity

Negotiation

AnyCodecs

RTP/RTCPReal-time

Communication

RSA/Q.931

H.245

Any

RTP/RTCP

H.323 vs. SIP


ASCIIMessage Encoding

SIPH.323

UDP and TCPMostly TCP

Transport

NoneData

Conference

DNS, TRIP, ENUMInter-domain

Routing

Binary

UDP and TCPMostly TCP

T.120

Annex G/H.225.0, TRIP, ENUM

What SIP cannot provide?

SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services.

SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol.

SIP cannot, and does not, provide any kind of network resource reservation capabilities.


SIP in IP Multimedia


Applications

SDP/SDPng

HTTP SMTP SAPSIP RTSP

TCP/SCTP TCP/UDP UDP

RTP/RTCP

RSVP

IPv4/IPv6 with Mobility, DiffServ and Multicast

• Common Addressing, user@domain(URI & URL)• Text-based and Encoding Format• Same Request-Response Model,

and Response Codes• MIME for Flexible Payload• DNS for Address Mapping

Easy to Do Integrated Servicesby Combining more than OneProtocols

When SIP? Where SIP?

IP Network Communication Understand SIP Protocol

Develop SIP Elements

Deploy SIP Network

Create SIP Services

Mobile Network Communication 3G/All IP Network Session Control

IP Multimedia Subsystem Components

Call Session Control Function (CSCF)

NGN Service Technology

IMS Call Model, OMA service enablers


Next Generation Network

Internet Telecom & Wireless Communication


IP

MGCF

CSCF

T-SGW MGWMGW

PDG

GPRS

CSCFSIP

Server

PSTN

InternetWireless App.Server

3rd Parties App.

WLAN

3G/LTE

SIP Protocol

SIP Basics SIP Network Entities

SIP Network Architecture

SIP Message Message Header

Message Body (SDP)

SIP Communication SIP Message Flows

SIP Entities Behavior

SIP Extensions


SIP Network Entities (1/4)

User Agent (UA) User Agent Client - Initiate SIP Request

User Agent Server - Accepts or rejects call

Network Servers Registrar (as UAS), Proxy, Redirect Server (as UAS)


User

Agent

ServerClient Client Server

RegistrarLocation

Server

Redirect

Server

Proxy

Servers

INVITEREGISTER INVITE INVITEResponse

3XX

INVITE


Proxy server Handle requests or forward requests to other servers

Can be used for call forwarding, time-of-day routing, or follow-me services



Proxy Server + Location Server


[email protected]

cs.ccu.edu.tw

itri.org.tw

location server

BENS

Honda@AUDI

AUDI(1) INVITE

[email protected]

BMW(2

) h

on

da

(3)

ho

nd

a@

AU

DI

(4) INVITEhonda@AUDI

(5) 200 OK(6) 200 OK

(7) ACK [email protected] (8) ACK honda@AUDI


Redirect servers Map the destination address to zero or more new

addresses




User Agent Server (Callee)

Proxy ServerProxy Server

Proxy Server

Redirect Server

Location Server

SIP Request

SIP Response

RTP Media Stream

User Agent Client (Caller)

SIP Requests

Methods (Commands)

REGISTER: Log in and register the address with a SIP

server

INVITE: Initiate a session

ACK: ACK only when receiving the final response

BYE: Terminate a session

CANCEL: Terminate a pending request

OPTIONS : Allow a UA to query another UA or a proxy

server as to its capabilities


SIP Responses

Status code (A three-digit number) 1xx: Provisional -- request received, continuing to process the

request;

2xx: Success -- the action was successfully received, understood, and accepted;

3xx: Redirection -- further action needs to be taken in order to complete the request;

4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;

5xx: Server Error -- the server failed to fulfill an apparently valid request;

6xx: Global Failure -- the request cannot be fulfilled at any server.


SIP Session Setup Example


SIP Protocol




Message Body (SDP)



SIP Extensions


SIP Message

SIP is a text-based protocol and uses the UTF-8 charset (RFC 3629std63) .

A SIP message is either a request from a client to a server,

or a response from a server to a client.

Both types of messages consist of a start-line,

one or more header fields,

an empty line indicating the end of the header fields, and

an optional message-body.


SIP Message Format (1/2)


INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP science.fiction.com

From: Fingal <sip:[email protected]>

To: Patric <sip:[email protected]>

Call-ID: [email protected]

Cseq: 1 INVITE

Subject: lunch at La Empenada?

Content-Type: application/sdp (mime)

Content-Length: …

SIP

Header

Payload:

SDP

(MIME type)

SIP/2.0 200 OK

Via: SIP/2.0/UDP science.fiction.com

From: Fingal <sip:[email protected]>

To: Patric <sip:[email protected]>


Cseq: 1 INVITE

Content-Type: application/sdp

Content-Length: …

SIP Response ExampleSIP Request Example

v=0

o=ffl 53655765 2353687637 IN IP4 123.4.5.6

s=Chorizo

c=IN IP4 science.fiction.com

m=audio 5004 RTP/AVP 0 3 5

a=rtpmap:0 PCMU/8000

SIP Message Format (2/2)

Message headers Additional information of the request or response E.g.,

The originator and recipient (From and To headers )Subject headerContent-Length header

Message body Describe the type of session The most common structure for the message body is SDP

(Session Description Protocol). Could include an ISDN User Part message Examined only at the two ends


SIP Messaging Syntax

Text-based Disadvantage – more bandwidth consumption Similar to HTTP

However, in SIP, the two endpoints are symmetric

SIP messages message = start-line

*message-header CRLF[message-body]

start-line = request-line | status-line The request-line specifies the type of request The response status-line indicates the success or failure

of a given request


SIP Request Start-Line (1/2)

Method SP Request-URI SP SIP-version CRLF

Methods REGISTER

Log in and register the address with a SIP server“all SIP servers” – multicast address (224.0.1.175)Can register with multiple serversCan have several registrations with one server

INVITE, ACKInitiate a session～IAM (initial address message) of ISUPACK only when receiving the final response


SIP Request Start-Line (2/2)

BYETerminate a sessionCan be issued by either the calling or called party

CANCELTerminate a pending requestE.g., an INVITE did not receive a final response

OPTIONSQuery servers about their capabilities

Request-URI The address of the destination

SIP-Version: SIP/2.0


SIP Addressing & Naming

The entities addressed by SIP are users at hosts (SIP

URLs: Uniform Resource Locators)

Augmented Backus-Naur Form described

email-like identifier of the form user@host

user: user name or telephones number

host: domain name or a numeric network address

Examples of SIP URLs user@host

sip:[email protected]





SIP Response Status-Line

SIP Version SP Status Code SP Reason-Phrase CRLF

Status code (A three-digit number) 1XX Informational

2XX Success

3XX Redirection

4XX Request Failure

5XX Server Failure

6XX Global Failure

All responses, except for 1XX, are considered final

Reason-Phrase A textual description of the outcome, presented to the user


Terms: Call & Session

Call Some communication between peers. Identified by a globally unique Call-ID

Session SDP specification: “ A multimedia session is a set of

multimedia senders and receivers and the data streams flowing from senders to receivers.”

SIP Transaction The first SIP request message to a final response. 1 INVITE request + a non-2xx response + ACK 1 INVITE request + a 2xx response 1 Non-INVITE request + 1 final response


Terms: SIP Transaction

SIP Transaction: A SIP transaction occurs between a client and a server, and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.


Message Headers

Provide further information about the message

Example of headers To: The called party

From: The calling party

Call-ID Header: uniquely identifies a specific invitation to a session

Four main categories General headers

Request headers

Response headers

Entity headers


General Headers (1/6)

Used in both requests and responses

Call-ID Header uniquely identifies a specific invitation to a session

Call-ID = (“Call-ID” | “i”) “:” local-id“@”host

local-id = 1 *uric

“host” SHOULD be a fully qualified domain name or a globally routable IP address.

Call-IDs are case-sensitive

All REGISTER requests issued by a single client SHOULD use the same Call-ID, at least within the same boot cycle.



To Header To = (“To” | “t”) “:” (name-addr | addr-spec) * (“;”addr-

params)

To: The Operator <sip:[email protected]>;tag=28722

To: sip:[email protected]

Requests and responses MUST contain To field.

If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. Otherwise, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response. (to be combined in the Dialog ID)



Contact Header Provides a URL for use in future communication

regarding a particular session

INVITE request and response

MUST be present for the establishment of a dialog

INVITE 2xx response (from UAS)reachable most directly for future SIP requests

INVITE 3xx response (from redirect server)

the list of alternative locations

An "expires" parameter to indicate the lifetime



REGISTER requestwhich locations the user is reachable

REGISTER 2xx responsesreturn all current locations

In a SIP INVITE, the Contact header might be different from the From header

An third-party server initiates a multiparty session



Via Header Prevent request looping.

Ensure replies take the same path.

Requests:

Original request MUST insert Via field(host name, network address, port number).

Subsequent proxy: add its own Via field before

Proxy send a request to a multicast addressadd the “maddr” and “ttl”

Proxy server receive a request containing it’s address.Response with a 482(loop detected)



Receiver-tagged Via headerVia: SIP/2.0/UDP erlang.bell-telephone.com:5060

Via: SIP/2.0/UDP 10.0.0.1:5060; received=199.172.136.3

Response

First Via header indicate the proxy or client processing the response ?Yes: remove this Via field

No: discard the message

No second Via headerYes: this response is destined for this client

No: processing depends on “maddr” or “receiver-tag”

UAS or redirect server copies the Via into response.


Request/Response Header

Request Headers Apply only to SIP requests

Addition info. about the request or the client

Subject:

Priority: urgency of the request emergency, urgent, normal, or non-urgent

Response Headers Further info about the response that cannot be included

in the status line

Unsupported

Retry-After


Entity Headers

Indicate the type and format of information included in the message body

Content-Length: the length of message body

Content-Type: the media type of message body E.g., application/sdp

Content-Encoding: for message compression

Content Disposition: how a message part should be interpreted session, icon (image), alert (audio), render (text) …


SIP Message Examples


Session Description Protocol

The Most Common Message Body Be session information describing the media to be

exchanged between the parties

SDP, RFC 2327(-> 4566prop), April 1998 (-> July 2006 )

SIP uses SDP in an offer/answer mode. An agreement between the two parties as to the types

of media they are willing to share

RFC 3264 (An Offer/Answer Model with SDP)

To describe how SDP and SIP should be used together


Usage of SDP with SIP

SIP and SDP make a wonderful partnership for the transmission of session information

SIP provides the messaging mechanism for the establishment of multimedia sessions

SDP provides a structured language for describing the sessions The entity headers identifies the message body


The Structure of SDP

Text-based Protocol

The Structure of SDP Session Level Info

Name of the sessionOriginator of the sessionTime that the session is

to be active Media Level Info

Media typePort numberTransport protocolMedia format


Originator and Session IDProtocol Version

Session NameSession Time

Media Name and TransportConnection Information

Media Name and TransportConnection Information

Session Description

Session Level Information

Media Description 1

Media Description 2

SDP Syntax

A number of lines of text

In each line field=value

field is exactly one character

case-significant

Session-level fields

Media-level fields Begin with media description field (m=)


Mandatory Fields

v=(protocol version)

o=(session origin or creator)

s=(session name), a text string For multicast conference

t=(time of the session), start time & stop time For pre-arranged multicast conference

m=(media) Media type

The transport port

The transport protocol

The media format, an RTP payload formatSIP Protocol原理 73

Optional Fields (1/3)

Some optional fields can be applied at both session and media levels. The value applied at the media level overrides that at

the session level

i=(session information) A text description At both session and media levels It would be somewhat superfluous, since SIP already

supports the Subject header.

u=(URI of description) Where further session information can be obtained Only at session level



e=(e-mail address) Who is responsible for the session Only at the session level

p=(phone number) Only at the session level

c=(connection information) Network type, address type & connection address At session or media level

b=(bandwidth information) In kilobits per second At session or media level



r=(repeat times) A regularly scheduled session to be repeated How often and how many times

z=(timezone adjustments) For regularly scheduled session Standard time and daylight savings time

k=(encryption key) An encryption key or a mechanism to obtain it for the

purposes of encrypting and decrypting the media At session or media level

a=(attributes) Describe additional attributes


Ordering of Fields

Session Level Protocol version (v)

Origin (o)

Session name (s)

Session information (i)

URI (u)

E-mail address (e)

Phone number (p)

Connection info (c)

Bandwidth info (b)

Time description (t)

Repeat info (r)

Time zone adjustments (z)

Encryption key (k)

Attributes (a)

Media level

Media description (m)

Media info (i)

Connection info (c)

Optional if specified at the session level

Bandwidth info (b)

Encryption key (k)

Attributes (a)


Subfields (1/3)

Field = <subfield1> <subfield2> <subfield3>

Origin

Username, the originator’s login id or “-”

session ID, a unique ID: Make use of NTP timestamp

version, a number for this particular session

network type, a text string: IN refers to Internet

address type: IP4, IP6

address, a fully-qualified domain name or the IP address


Subfields (2/3)

Connection Data The network & address at which media will be received

Network type, Address type, Connection address

Media Information Media type - Audio, video, data, or control

Port

Format

List the types of media format to be supported

According to the RTP audio/video profile

m= audio 45678 RTP/AVP 15 3 0

G.728, GSM, G.711


Subfields (3/3)

Attributes To enable additional information to be included Property attribute

a=sendonlya=recvonly

value attributea=orient:landscape used in a shared whiteboard session

rtpmap attributeThe use of dynamic payload typea=rtpmap:<payload type> <encoding name>/<clock rate>

[/<encoding parameters>].m=video 54678 RTP/AVP 98a=rtpmap 98 L16/16000/2

16-bit linear encoded stereo (2 channels) audio sampled at 16kHz


SDP Example


SDP in SIP Messages

INVITE with multiple media streams Unsupported should also be returned with a port

number of zero

An alternative INVITE request

m=audio 4444 RTP/AVP 2 4 15

a=rtpmap 2 G726-32/8000

a=rtpmap 4 G723/8000

a=rtpmap 15 G728/8000

INVITE responsem=audio 6666 RTP/AVP 15

a=rtpmap 15 G728/8000


SDP in SIP Flow (1/2)


Daniel<sip:[email protected]> Boss<sip:[email protected]>

INVITE sip:[email protected] SIP/2.0From: Daniel<sip:[email protected]>; tag = abcd1234To: Boss<sip:[email protected]>CSeq: 1 INVITEContent-Length: 213Content-Type: application/sdpContent-Disposition: session

v=0o=collins 123456 001 IN IP4 station1.work.coms=c=IN IP4 station1.work.comt=0 0m=audio 4444 RTP/AVP 2a=rtpmap 2 G726-32/8000m=audio 4666 RTP/AVP 4a=rtpmap 4 G723/8000m=audio 4888 RTP/AVP 15a=rtpmap 15 G728/8000

a

bSIP/2.0 200 OK…

SDP in SIP Flow (2/2)



SIP/2.0 200 OKFrom: Daniel<sip:[email protected]>; tag = abcd1234To: Boss<sip:[email protected]>; tag = xyz789CSeq: 1 INVITEContent-Length: 163Content-Type: application/sdpContent-Disposition: session

v=0o=collins 45678 001 IN IP4 station2.work.coms=c=IN IP4 station2.work.comt=0 0m=audio 0 RTP/AVP 2m=audio 0 RTP/AVP 4m=audio 6666 RTP/AVP 15a=rtpmap 15 G728/8000

ACK sip:[email protected] SIP/2.0From: Daniel<sip:[email protected]>; tag = abcd1234To: Boss<sip:[email protected]>; tag = xyz789CSeq: 1 ACKContent-Length: 0

b

c

dConversation

SIP&SDP Offer/Answer Model

Re-INVITE is issued when the server replies with more than one codec. With the same dialog identifier (To and From headers,

including tag values), Call-ID and Request-URI

The session version is increased by 1 in o= line of message body.

A mismatch 488 or 606 - Not Acceptable

A Warning header with warning code 304 (media type not available) or 305 (incompatible media type)

Then the caller issues a new INVITE request.


Offer/Answer Flow (1/2)


INVITE sip:[email protected] SIP/2.0CSeq: 1 INVITEContent-Length: 183Content-Type: application/sdpContent-Disposition: session

v=0o=collins 123456 001 IN IP4 station1.work.coms=c=IN IP4 station1.work.comt=0 0m=audio 4444 RTP/AVP 2 4 15a=rtpmap 2 G726-32/8000a=rtpmap 4 G723/8000a=rtpmap 15 G728/8000a=inactive


b

a

SIP/2.0 200 OKCSeq: 1 INVITEContent-Length: 157Content-Type: application/sdpContent-Disposition: session

v=0o=collins 45678 001 IN IP4 station2.work.coms=c=IN IP4 station2.work.comt=0 0m=audio 6666 RTP/AVP 4 15a=rtpmap 4 G723/8000 a=rtpmap 15 G728/8000a=inactive

Offer/Answer Flow (2/2)



d

c

INVITE sip:[email protected] SIP/2.0CSeq: 2 INVITEContent-Length: 126Content-Type: application/sdpContent-Disposition: session

v=0o=collins 123456 002 IN IP4 station1.work.coms=c=IN IP4 station1.work.comt=0 0m=audio 4444 RTP/AVP 15a=rtpmap 15 G728/8000

ACK sip:[email protected] SIP/2.0From: Daniel<sip:[email protected]>; tag = abcd1234To: Boss<sip:[email protected]>; tag = xyz789CSeq: 1 ACKContent-Length: 0

SIP Protocol




Message Body (SDP)



SIP Extensions


SIP Session Setup Example


i) Register(Bob)


ii) 200 OK


1) INVITE(A->Pa)


2) INVITE(Pa->Pb)


3) INVITE(Pb->B)


4) 180 Ringing(B->Pb)


5) 180 Ringing(Pb->Pa)


6) 180 Ringing(Pa->A)


7) 200 OK(B->Pb)


8) 200 OK(Pb->Pa)


9) 200 OK(Pa->A)


10) ACK(A->B)


11) Media


12) BYE(B->A)


13) 200 OK (A->B)


SIP Registration Example

Registration Via:

From: and To:

Call-ID: host-specific

Contact:

* (to remove all registrations, valid only if expires=0)

Content-Length:

Zero, no msg body

CSeq:

A response must use the same CSeq as used in the request.

Expires:

0, unreg


Initial Registration (1/2)


SIP Registrar (as UAS)Register F1

401 Unauthorized F2

REGISTER sip:register.com SIP/2.0

Via: SIP/2.0/UDP user.com:5060

From: John <sip:client@ register.com>

To: John <sip:client@ register.com>


CSeq: 1 REGISTER

Contact: John <sip:[email protected]>

Contact: <sip:[email protected];user=phone>

Contact: tel:+886-3-1234567

Content-Length: 0

F1SIP/2.0 401 Unauthorized





CSeq: 1 REGISTER

WWW-Authenticate: Digest realm="MCI WorldCom SIP",

domain="wcom.com",

nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",

stale=FALSE,

algorithm=MD5

Content-Length: 0

F2

[email protected]

register.comuser.com

John

Initial Registration (2/2)


REGISTER sip:register.com SIP/2.0


From: John <sip:client@ register.com >

To: John <sip:client@ register.com >


CSeq: 2 REGISTER



Contact: tel:+886-3-1234567

Authorization:Digest username=“John", realm="MCI WorldCom SIP",

nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",

uri="sip:ss2.wcom.com",

response="dfe56131d1958046689cd83306477ecc"

Content-Length: 0

F3SIP/2.0 200 OK





CSeq: 2 REGISTER



Contact: tel:+886-3-1234567

Content-Length:0

F4

Register F1

401 Unauthorized F2

REGISTER F3

200 OK F4

SIP Registrar (as UAS)[email protected]

register.com

user.com

John

Updated Registration (1/2)


[email protected] Registrar (as UAS)

REGISTER sip:bell-tel.com SIP/2.0

Via: SIP/2.0/UDP saturn.bell-tel.com

From: sip:[email protected]



CSeq: 1 REGISTER

Contact: <sip:[email protected]

tel.com:3890;transport=udp>

Expires: 7200

F1






CSeq: 2 REGISTER

Contact: *

Expires: 0

F2

Register F1 (2hours)

REGISTER F2 (clear all)

saturn.bell-tel.combell-tel.com

200 OK

200 OK

Updated Registration (2/2)


[email protected] SIP Registrar (as UAS)


Via: SIP/2.0/UDP pluto.bell-tel.com




CSeq: 1 REGISTER

Contact: sip:[email protected]

F4

Register F1 (2hours)

REGISTER F2 (clear all)

200 OK saturn.bell-tel.com

bell-tel.com

Updated REGISTER F3 (register again,moved)

200 OK






CSeq: 3 REGISTER

Contact: sip:[email protected]

F3

[email protected]

200 OK

pluto.bell-tel.com

[email protected]

UAC Behavior (1/2)


Generating the Request mandatory request line

method

Request-URI: initial Request-URI set as the To field

SIP version = SIP/2.0

mandatory six header fields in any request To: the desired recipient of the request

From: the initiator of the request

Cseq: a sequence number and a requested method

Call-ID: a unique identifier to group together a series of messages

Max-Forwards: to limit the number of hops

Via: identifies the location where the response is to be sent

UAC Behavior (2/2)


Sending the Request If the first element in the route set indicated a strict

router, the procedures MUST be applied to the Request-URI of the request.

Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present.

the destination MUST be determined by applying the DNS procedures

UAS Behavior

Generating the Response

mandatory request line SIP version = SIP/2.0

Status code

mandatory five header fields in the response

From, Call-ID, Cseq, Via: Copy them from request

To: the same as that in the request if a request contained a To

tag in the request.

Otherwise, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response. (to be combined in the Dialog ID)


Invitation

A two-party call Content-Type:

application/sdp A dialog

To identify a peer-to-peer relationship between two user agents

A dialog IDTag in FromTag in ToCall-ID

CSeq:# unchanged in the same

transaction ACK: no response for it


Boss<sip:[email protected]>Daniel<sip:[email protected]>

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:[email protected]>; tag=44551Contact: sip:[email protected]: Boss<sip:[email protected]>Call-ID: [email protected]: 1 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)

a

b

SIP/2.0 180 RingingVia:SIP/2.0/UDP station1.work.com;branch=z9hG4bK123From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>; tag=11222Contact: sip:[email protected]: [email protected]: 1 INVITEContent-Length: 0

c

SIP/2.0 200 OKVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>; tag=11222Contact: sip:[email protected]: [email protected]: 1 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)

d

ACK sip:[email protected] SIP/2.0Via:SIP/2.0/UDP station1.work.com;branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>; tag=11222Call-ID: [email protected]: 1 ACKContent-Length: 0

Conversation

Termination of a Call

Cseq: # Has changed


CSeq Header (1/2)

A general-header field to each request.

CSeq = “CSeq” “:” 1*DIGIT SP Method 1*DIGIT : 32-bit unsigned integer

Consecutive requests: same Call-ID, diff. Header Monotonically increasing and contiguous sequence number

Retransmissions of the same request carry the same sequence number, but an INVITE with a different message body or different header fields (a “re-invitation”) acquires a new, higher sequence number.


CSeq Header (2/2)

A server MUST echo the CSeq value from the request.

User agent server Remember the highest CSeq with the same Call-ID. Discard a lower CSeq value.

ACK and CANCEL contain the same CSeq value as the INVITE request.

BYE request with higher CSeq value.

Parallel search: same CSeq value


UA to UA Call Flow (1/3)


[email protected] INVITE F1

100 Trying F2

180 Ringing F3

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP today.com:5060From: John <sip:[email protected]>To: Mary <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContact: John <sip:[email protected]>Content-Type: application/sdpContent-Length: 147

v=0o=John 2890844526 2890844526 IN IP4 today.coms=Session SDPc=IN IP4 100.101.102.103t=0 0m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000

F1SIP/2.0 100 Trying

Via: SIP/2.0/UDP today.com:5060

From: John <sip:[email protected]>

To: Mary <sip:[email protected]>


CSeq: 1 INVITE

Content-Length: 0

F2

SIP/2.0 180 Ringing





CSeq: 1 INVITE

Content-Length: 0

F3

John

Mary

today.com

tomorrow.com

[email protected]



[email protected] F1

100 Trying F2

180 Ringing F3

[email protected]

200 OK F4

ACK F5

ACK sip:[email protected] SIP/2.0





CSeq: 1 ACK

Content-Length: 0

F5

SIP/2.0 200 OK





CSeq: 1 INVITE

Contact: Mary <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 147

v=0

o=Mary 2890844527 2890844527 IN IP4 tomorrow.com

s=Session SDP

c=IN IP4 110.111.112.113

t=0 0

m=audio 3456 RTP/AVP 0

a=rtpmap:0 PCMU/8000

F4

John

Mary

RTP Mediatoday.com

tomorrow.com



[email protected] F1

100 Trying F2

180 Ringing F3

[email protected]

200 OK F4

ACK F5

RTP Media

BYE F6

200 OK F7

SIP/2.0 200 OKVia: SIP/2.0/UDP tomorrow.com:5060From: Mary <sip:[email protected]>To: John <sip:[email protected]>Call-ID: [email protected]: 1 BYEContent-Length: 0

F7 BYE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP tomorrow.com:5060From: Mary <sip:[email protected]>To: John <sip:[email protected]>Call-ID: [email protected]: 1 BYEContent-Length: 0

F6

John

Mary

today.com

tomorrow.com

SIP OPTIONS Method

OPTIONS Request Determine the capabilities of a potential called party

Accept header field SHOULD be included

to indicate the type of message body the sender wishes to receive in the response

OPTIONS Response Allow Header

Indicate the SIP methods that the receiver can handle

Supported Header

Indicate the SIP extensions that can be supported


OPTIONS Flow



b

aOPTIONS sip:[email protected] SIP/2.0Via: SIP/2.0/UDP Station1.work.com; branch=z9hG4bK7890123From: Daniel<sip:[email protected]>; tag=lmnop123To: Boss<sip:[email protected]>Call-ID: [email protected]: Daniel<sip:[email protected]>CSeq: 1 OPTIONSAccept: application/sdpContent-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP Station1.work.com; branch=z9hG4bK7890123From: Daniel<sip:[email protected]>; tag=lmnop123To: Boss<sip:[email protected]>; tag=xyz5678Call-ID: [email protected]: 1 OPTIONSAllow: INVITE, ACK, CANCEL, OPTIONS, BYEContent-Length: 146Content-Type: application/sdp

v=0o=manager 45678 001 IN IP4 station2.work.coms=c=IN IP4 station2.work.comt=0 0m=audio 0 RTP/AVP 4 15a=rtpmap 4 G723/8000 a=rtpmap 15 G728/8000

Require Header

Client uses it to tell Server about options.

If Server not understand the option, MUST return 420(Bad Extension) and list those options in the Unsupported header.

Example:

C S INVITE sip:[email protected] SIP/2.0

Require: com.example.billing

Payment: sheep_skins, conch_shells

S CSIP/2.0 420 Bad Extension

Unsupported: com.example.billing


Redirect Servers

An alternative address 302, Moved temporarily

Contact header

Another INVITE Same Call-ID,

Same To

CSeq ++



c

d

ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>Call-ID: [email protected]: 1 ACK

Boss<sip:[email protected]>Daniel<sip:[email protected]>


a

bSIP/2.0 302 Moved TemporarilyVia:SIP/2.0/UDP station1.work.com;branch=z9hG4bK123From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>; tag=11222Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]

Redirect Server

Proxy Servers

Numerous proxies can reside in a chain between caller & callee.

Via: Record the path taken by a request Loop detected, 482 (status code) For a response

The 1st Via: header, Checked, and Removed Branch: used to distinguish between multiple responses

to the same requestForking Proxy: Issue a single request to multiple

destinations


Proxy Call Flow (1/2)


Boss<sip:[email protected]> Daniel<sip:[email protected]>

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 70From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE

a

b

SIP/2.0 100 TryingVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE

c

sip:Server.work.com

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE

SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]

SIP/2.0 200 OK...

e

d

Proxy Call Flow (2/2)


Boss<sip:[email protected]> Daniel<sip:[email protected]>

ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7891Max-Forwards: 70Route: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 ACK

e

f

sip:Server.work.com

ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz2Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7891Max-Forwards: 69From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 ACK

SIP/2.0 200 OKVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]

g

Terms: Loop & Spiral

Spiral: A spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error, unlike a loop.

A typical cause for this is call forwarding. A user calls [email protected]. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to [email protected]. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, a valid condition.


Loop Detect


Proxy1

Proxy4

Proxy3

Proxy2

UA1

Request message

482 Loop detect

loop detect

Spiral


Proxy1

Proxy4

Proxy3

Proxy2

UA1

spiral

UA2

Request message

Record-Route Header

Two consecutive requests may not pass through the same proxy

A Proxy might require that it remains in the signaling path. In particular, for a stateful proxy

Record-Route: Each proxy server adds its SIP-URI to the beginning of the

Record-Route list. UAS copies the Record-Route header field unchanged

into the response. The info in the Record-Route is used in subsequent

requests related to the same call.


Route Header

Route: Determine the request route.

UAC copies the Record-Route header into a Route header field of subsequent requests within the same call leg, reversing the order.

The Route = the Record-Route in reverse order

Each proxy server removes the first entry of Route

Use it as Request-URI (if strict routing)

Route the request to the UAS.


Terms: Parallel/Sequential Search

In a parallel search, a proxy issues several requests to possible user locations upon receiving an incoming request.

Rather than issuing one request and then waiting for the final response before issuing the next request as in a sequential search, a parallel search issues requests without waiting for the result of previous requests.

A 2xx or 6xx class final response always terminates a sequential search.


Forking Proxy

“fork” requests

A user is registered at several locations ;branch=xxx

In order to handle such forking, a proxy must be stateful.


Forking Proxy Flow (1/2)


Boss<sip:[email protected]>pc1

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Max-Forwards: 70From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE

a

b

SIP/2.0 100 TryingVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE

c

sip:Server.work.com

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bK123Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE

dINVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bK456Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE

pc2

Forking Proxy Flow (2/2)


Boss<sip:[email protected]>pc1

e

f

g

sip:Server.work.com

CANCEL sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bK456Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 CANCEL

SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bK456Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]

pc2

SIP/2.0 200 OKVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]

123

Terms: Dialog (1/2)

Dialog (～ call leg in RFC 2543) A dialog represents a peer-to-peer SIP relationship

between two user agents that persists for some time.

The dialog represents a context which facilitates sequencing of messages between the user agents and proper routing of requests between both of them.

A dialog identified at each UA with a dialog ID consists of

a Call-ID value: the Call-ID of the message

a local tag: the tag in the From/To field for UAC/UAS

a remote tag: the tag in the To/From for UAC/UAS.

The dialog ID at each UA in the dialog is not the same.


Terms: Dialog (2/2)

A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs. The route set is the list of servers that need to be traversed to send a request to the peer.

A dialog can also be in the "early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives.


Terms: Loose Routing

A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field).

A proxy compliant to these mechanisms is also known as a loose router.

Strict routing behavior is not used in this spec.


SIP Dialogs and Routing (1/6)


Terms: B2BUA

A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.


Terms: Location Service

A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s).

It contains a list of bindings of address-of-record keys to zero or more contact addresses.

The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings.


SIP Protocol Structure

The lowest layer is the transport layer. It defines how a client sends requests and receives responses and

how a server receives requests and sends responses over the network.

The second layer is the transaction layer. A transaction is a request sent by a client transaction (using the

transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client.

Stateless proxies do not contain a transaction layer.

The layer above the transaction layer is called the transaction user (TU). Each of the SIP entities, except the stateless proxy, is a transaction

user.


SIP Protocol Structure Example

Assumed that Proxy 1 and Proxy 3 stateful proxy servers and Proxy 2 stateless


4) INVITE (A->P1)


4) INVITE (P1->P2->P3)


4) INVITE (P3->B)


6) 180 Ringing (P1<-P2<-P3)


6) 180 Ringing (A<-P1)


2 Kinds of Proxy Servers

A logic role for SIP environment Can be either stateless or stateful

Stateless Proxy Act as a simple forwarding element.

Forward each request downstream to a single element base on the request.

Forward every response upstream.

Stateful Proxy It is a SIP transaction processing engine.

May fork a request and route it to multiple destinations.


Terms: Stateful Proxy

Stateful Proxy: A logical entity that maintains the client and server transaction state machines defined by this specification during the processing of a request, also known as a transaction statefulproxy. The behavior of a stateful proxy is further defined in Proxy behavior.

A (transaction) stateful proxy is not the same as a call stateful proxy.


INVITE Client Transaction


Calling

Proceeding

Completed

Terminated

Timer A fires

Reset A,

INVITE sent1xx

1xx to TU

INVITE from TU

INVITE sentTimer B fires

or Transport Err.

Inform TU

2xx

2xx to TU

2xx

2xx to TU

Transport Err.

Inform TU

Timer D fires

-

1xx

1xx to TU

300 – 699

ACK SENT,

resp. To TU

300 – 699

ACK SENT

300 ~ 699

ACK sent

resp. to TU

INVITE Server Transaction


Proceeding

Completed

Confirmed

Terminated

INVITE

send response

300 ~ 699 from TU

send response

INVITE

pass INV to TU

send 100 if TU won’t in 200ms

Transport Err.

Inform TU

2xx from TU

send response

Timer H fires

or Transport Err.

Inform TU

Transport Err.

Inform TUTimer I fires

-

INVITE

send response ACK

-

101 ~ 199 from TU

send response

Timer G fires

send response

Client Transaction for BYE/CANCEL/OPTIONS/REGISTER


Initial

Calling

Call

Proceeding

Completed

-

REQUEST

1xx

-

Status

-

1xx

-

Min(T1 * 2n

, T2)or n * T2

REQUEST

status

-

status

-

event

request sent

11 REQUEST sent

n * T2

Request

Server Transaction for BYE/CANCEL/OPTIONS/REGISTER


Initial

Proceeding

Completed

request

1xx

request

2xx

request

1xx

10 * T2

Status change

1xx

Failure Success

success

2xxfailure

>=300

terminated

487

request

status

32s

-

32s

-

Event

Message sent

Confirmed

32s

-

Stateful Proxy Behavior

Proxy a new request Validate the request

Reasonable syntax

URI scheme

Max-Forwards

Loop detection (optional)

Proxy-Require

Proxy-Authorization

Preprocess routing info

Determine request target(s)

Forward the request

Make a copy of the request

Update the Request-URI

Update the Max-Forwards

Optionally add a Record-route header field value

Optionally add additional header fields

Postprocess routing info

Determine the next-hop address, port, and transport

Add a Via header field value

Add a Content-Length header field if necessary

Forward the new request

Set timer C

Process all responses

Remove the topmost Via

Forward the response

Generate necessary CANCEL reqSIP Protocol原理 160

SIP Protocol




Message Body (SDP)



SIP Extensions


SIP INFO Method

Specified in RFC 2976 For transferring information during an ongoing session

DTMF digits, account-balance information, mid-call signaling information (from PSTN)

Application-layer information could be transferred in the middle of a call.

A powerful, flexible tool to support new services The transfer of DTMF digits

The transfer of account balance information

Pre-paid service

The transfer of mid-call signaling information


SIP Event Notification

Several SIP-based applications have been devised based on the concept of a user being informed of some event E.g., Instant messaging

RFC 3265 has addressed the issue of event notification SUBSCRIBE and NOTIFY

The Event header


Subscriber Notifier

SUBSCRIBE

200 OK

NOTIFY

200 OK

NOTIFY

200 OK

a

b

c

d

e

f

Current stateinformation

Updated stateinformation

SIP Presence (1/3)

A asks to be told when B registers


Registrar, Presence Server,

SIP Presence (2/3)

NOTIFY A that B has <Not Signed In>



SIP Presence (3/3)

NOTIFY A that B has <Signed In>



SIP MESSAGE Method

The IETF working group – SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)

A new SIP method – MESSAGE This request carries the actual message in a message

body.

A MESSAGE request does not establish a SIP dialog.


Instant Messaging (1/2)


Daniel<sip:[email protected]>Boss<sip:[email protected]> sip:Server.work.com

MESSAGE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 70From: Boss<sip:[email protected]> To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 MESSAGEContent-Type: text/plainContent-Length: 19Content-Disposition: render

Hello. How are you?

MESSAGE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 69From: Boss<sip:[email protected]> To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 MESSAGEContent-Type: text/plainContent-Length: 19Content-Disposition: render

Hello. How are you?

SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890From: Boss<sip:[email protected]> To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 MESSAGEContent-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890From: Boss<sip:[email protected]> To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 MESSAGEContent-Length: 0

a

b

c

d

Instant Messaging (2/2)


Daniel<sip:[email protected]>Boss<sip:[email protected]> sip:Server.work.com

MESSAGE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:[email protected]> To: Boss<sip:[email protected]> Call-ID: [email protected]: 1101 MESSAGEContent-Type: text/plainContent-Length: 22Content-Disposition: render

I’m fine. How are you?

MESSAGE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKabcdVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 69From: Daniel<sip:[email protected]> To: Boss<sip:[email protected]> Call-ID: [email protected]: 1101 MESSAGEContent-Type: text/plainContent-Length: 22Content-Disposition: render

I’m fine. How are you?

SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bKabcdVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: Daniel<sip:[email protected]> To: Boss<sip:[email protected]>Call-ID: [email protected] CSeq: 1101 MESSAGEContent-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: Daniel<sip:[email protected]> To: Boss<sip:[email protected]>Call-ID: [email protected] CSeq: 1101 MESSAGEContent-Length: 0

ef

g

h

SIP REFER Method

To enable the sender of the request to instruct the receiver to contact a third party With the contact details for the third party included

within the REFER request

For Call Transfer applications

The Refer-to: and Refer-by: Headers

The dialog between Mary and Joe remains established. Joe could return to the dialog after consultation with

Susan.


Call Transfer (1/2)


sip:[email protected] sip:[email protected] sip:[email protected]

REFER sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK789Max-Forwards: 70From: Mary<sip:[email protected]>; tag=123456 To: Joe<sip:[email protected]>; tag=67890Contact: Mary<[email protected]>Refer-To: Sussan<sip:[email protected]>Call-ID: [email protected]: 123 REFERContent-Length: 0

SIP/2.0 AcceptedVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK789From: Mary<sip:[email protected]>; tag=123456 To: Joe<sip:[email protected]>; tag=67890Contact: Joe<[email protected]>Call-ID: [email protected]: 123 REFERContent-Length: 0

Invite sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1Max-Forwards: 70From: Joe<sip:[email protected]>; tag=abcxyz To: Susan<sip:[email protected]>Contact: Joe<[email protected]>Call-ID: [email protected]: 567 INVITEContent-Type: application/sdpContent-Length: xxContent-Disposition: session{message body}

a

b

c

Call Transfer (2/2)


sip:[email protected] sip:[email protected] sip:[email protected]

e

fg

SIP/2.0 200 OKVia: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1From: Joe<sip:[email protected]>; tag=abcxyz To: Susan<sip:[email protected]>; tag=123xyzCall-ID: [email protected]: 567 INVITEContent-Type: application/sdpContent-Length: xxContent-Disposition: session{message body}

ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1Max-Forwards: 70From: Joe<sip:[email protected]>; tag=abcxyz To: Susan<sip:[email protected]>; tag=123xyzCall-ID: [email protected]: 567 ACKContent-Length: 0

NOTIFY sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bK123Max-Forwards: 70To: Joe<sip:[email protected]>; tag=67890From: Mary<sip:[email protected]>; tag=123456 Contact: Joe<[email protected]>Call-ID: [email protected]: 124 NOTIFYContent-Type: message/sipfrag;version=2.0Content-Length: 15

SIP/2.0 200 OKVia: SIP/2.0/UDP station2.work.com; branch=z9hG4bK123To: Joe<sip:[email protected]>; tag=67890From: Mary<sip:[email protected]>; tag=123456 Call-ID: [email protected]: 124 NOTIFYContent-Length: 0

h

Call Forwarding

On busy

486, busy here

With the same To, User 3 can recognize that this call is a forwarded call, originally sent to User 2.

Contact: header in 200 response

Call-forwarding-on-no-answer Timeout

CANCEL method


INVITE sip:[email protected] SIP/2.0From: sip:user1To: sip:[email protected]: User1CSeq: 1 INVITE

SIP/2.0 100 TryingFrom: sip:user1To: sip:[email protected]: 1 INVITE

INVITE sip:[email protected] SIP/2.0From: sip:user1To: sip:[email protected]: User1CSeq: 1 INVITE

SIP/2.0 486 Busy HereFrom: sip:user1To: sip:[email protected]: 1 INVITE

INVITE sip:[email protected] SIP/2.0From: sip:user1To: sip:[email protected]: 2 INVITE

SIP/2.0 200 OKFrom: sip:user1To: sip:[email protected]: sip:[email protected]: 2 INVITE

SIP/2.0 200 OKFrom: sip:user1To: sip:[email protected]: sip:[email protected]: 1 INVITE

User1 sip:Server.work.com User2 User3

Useful Web Sites

Tech-Invite: A portal for promoting standardization Knowledge

http://www.tech-invite.com/index.html

This new version of the site will have an access control, with membership management.

RFC-Ref http://www.rfc-ref.org/RFC-TEXTS/3261/contents.html

RFC-Ref is no longer maintained

FreeDownload.ishttp://freedownload.is/pdf/ietf-rfc-3261-pdf

Packetizerhttp://www.packetizer.com/ipmc/h323_vs_sip/


http://www.tech-invite.com/index.html

http://www.rfc-ref.org/RFC-TEXTS/3261/contents.html

http://freedownload.is/pdf/ietf-rfc-3261-pdf

http://www.packetizer.com/ipmc/h323_vs_sip/

Any Question?

IP Telecom Signaling: Softswitch, H.323, and SIP with SDP

Documents

Transcript of IP Telecom Signaling: Softswitch, H.323, and SIP with SDP