Scribd
Upload
82 views

RFC3372 Session Initiation Protocol For Telephones (SIP-T) : Context and Architectures

This document discusses the Session Initiation Protocol for Telephones (SIP-T) specification, which provides a framework for integrating legacy telephone signaling from the Public Switched Telephone Network (PSTN) into SIP messages. It describes how SIP-T uses encapsulation to include some SS7 ISUP messages in SIP message bodies, and translation to map SS7 messages and parameters to SIP headers. This allows SIP networks to provide feature transparency and routability comparable to the PSTN. The document outlines common SIP-T call flows and how support for the encapsulated ISUP payload can be optional, preferred, or mandatory.

Uploaded by

Vivek Jain
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
82 views

RFC3372 Session Initiation Protocol For Telephones (SIP-T) : Context and Architectures

This document discusses the Session Initiation Protocol for Telephones (SIP-T) specification, which provides a framework for integrating legacy telephone signaling from the Public Switched Telephone Network (PSTN) into SIP messages. It describes how SIP-T uses encapsulation to include some SS7 ISUP messages in SIP message bodies, and translation to map SS7 messages and parameters to SIP headers. This allows SIP networks to provide feature transparency and routability comparable to the PSTN. The document outlines common SIP-T call flows and how support for the encapsulated ISUP payload can be optional, preferred, or mandatory.

Uploaded by

Vivek Jain
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 27

RFC3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures

Presented by Zhi-Hong Guo


Instructed by Assistant Professor Quincy Wu

Introduction

It is vital for a SIP telephony network to interwork with the PSTN. An important characteristic of any SIP telephony network is feature transparency with respect to the PSTN. Another important characteristic of a SIP telephony network is routability of SIP requests.

Introduction (cont.)

The SIP-T effort provides a framework for the integration of legacy telephony signaling into SIP messages. SIP-T provides the above two characteristics through techniques known as 'encapsulation' and 'translation' respectively.

PSTN architecture

Three components:

Customer premises equipment (CPE)

Telephone set, private branch exchanges (PBX) Trunks and subscriber lines

The transmission facilities

The switching system

Central offices (CO), tandems

PSTN architecture (cont.)

Call setup and release


A call requires a communications circuit between two subscribers. The setup and release of connection is triggered by signals.

Signaling System No. 7 (SS7)


SS7 is a global standard for telecommunications defined by ITU-T. SS7 follows ISO 7 layer architecture.

SS7 Protocol Stack

ISUP:For call control,it defines the protocol and procedures used to set-up, manage and release trunk circuits.

Ex: Call setup or release

Basic call setup


IAM: Initial Address Message ACM: Address Complete Message ANM: Answer Message

Basic call release


REL: Release Message RLC: Release Complete Message

Encapsulation and translation

Encapsulation: Some of SS7 ISUP messages are encapsulated into the SIP message body in order that information necessary for services is not discarded in the SIP request. Translation: Some critical SS7 ISUP messages are translated into the corresponding SIP headers in order to determine how the SIP request will be routed.

SIP-T flows

SIP Bridging (PSTN - IP - PSTN) PSTN origination - IP termination :The terminator has no use for the encapsulated ISUP and ignores it. IP origination - PSTN termination: The terminating gateway only performs translation. IP origination - IP termination: This is a case for pure SIP.

SIP Bridging (PSTN - IP - PSTN)

PSTN
SIP Proxy

MGC SS7 ISUP


PSTN Phone

SIP
SIP Proxy

PSTN

MGC

SS7 ISUP
PSTN Phone

Call-flow

PSTN Phone
IAM

MGC#1

SIP Proxy

MGC#2 IAM ACM

PSTN Phone

ACM ANM

INVITE 100 TRYING 18X


200 OK ACK CONVERSATION BYE 200 OK

ANM

REL RLC

REL RLC

PSTN origination - IP termination

SIP Proxy

SIP Proxy SIP

SIP
SIP Proxy

SIP Phone

PSTN

MGC

SS7 ISUP
PSTN Phone

Call-flow
SIP Phone

PSTN Phone
IAM

MGC

SIP Proxy

ACM ANM

INVITE 100 TRYING 18X


200 OK ACK CONVERSATION BYE

INVITE 18X 200 OK

ACK

REL RLC

200 OK

BYE 200 OK

IP origination - PSTN termination

SIP Proxy

PSTN
MGC SS7 ISUP

SIP
SIP Proxy SIP Proxy PSTN Phone

SIP SIP Phone

Call-flow
SIP Proxy INVITE 100 TRYING 18X 200 OK ACK BYE

SIP Phone

MGC

PSTN Phone

INVITE
100 TRYING 18X 200 OK ACK CONVERSATION BYE 200 OK REL IAM ACM ANM

200 OK

RLC

Components of the SIP-T Protocol


Core SIP: defined by RFC 3261 Encapsulation: SIP-T uses multipart MIME bodies to enable SIP messages to contain multiple payloads (SDP,ISUP, etc.). Translation: ISUP SIP message mapping ISUP parameter-SIP header mapping

ISUP-SIP message mapping


IAM<->INVITE ACM<->18X REL<->BYE

ISUP parameter-SIP header mapping


Called Party Number <-> ToRequest-URI The headers of a SIP request (especially an INVITE) may be transformed by intermediaries, and that consequently, the SIP headers and encapsulated ISUP bodies come to express conflicting values effectively. The SIP headers should take precedence over the ISUP as the contents of SIP headers may be updated in routing within the IP network.

SIP content negotiation

Traditionally in SIP, if the terminating device does not support a multipart payload and/or the ISUP MIME type ,it would then reject the SIP request with a 415 Unsupported Media Type specifying the media types it supports. The originator would have to re-send the SIP request after stripping out the ISUP payload.

SIP content negotiation (cont.)

It is highly desirable to have a mechanism by which the originator could signify which bodies are required and which are optional so that the terminator can silently discard optional bodies that it does not understand. This is upon the terminator having support for a Content-type of multipart/mixed and access to the Content-Disposition header to express criticality.

Support for ISUP is optional

UA2 accepts the INVITE irrespective of whether it can process the ISUP.

UA1 UA2 INVITE--> (Content-type: multipart/mixed; Content-type: application/sdp; Content-disposition: session; handling=required; Content-type: application/isup; Content-disposition: signal; handling=optional;)
<--18x

Support for ISUP is preferred

UA2 does not support the ISUP and rejects the INVITE with a 415 Unsupported Media Type. UA1 strips off the ISUP and re-sends the INVITE with SDP only.

UA1 UA2 INVITE--> (Content-type: multipart/mixed; Content-type: application/sdp; Content-disposition: session; handling=required; Content-type: application/isup; Content-disposition: signal; handling=required;) <--415 (Accept: application/sdp) ACK--> INVITE--> (Content-type: application/sdp) <--18x

Support for ISUP is mandatory

UA2 does not support the ISUP and rejects the INVITE with a 415 Unsupported Media type. UA1 then directs its request to UA3.
UA2

UA1

INVITE--> (Content-type:multipart/mixed; Content-type: application/sdp; Content-disposition: session; handling=required; Content-type: application/isup; Content-disposition: signal; handling=required;) <--415 (Accept: application/sdp) ACK-->

Support for ISUP is mandatory (cont.)


UA1 UA3 INVITE--> (Content-type: multipart/mixed; Content-type: application/sdp; Content-disposition: session; handling=required; Content-type: application/isup; Content-disposition: signal; handling=required;)

You might also like