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)

–
The transmission facilities

–
Telephone set, private branch exchanges (PBX)
Trunks and subscriber lines
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
SIP
SIP Proxy
PSTN
MGC
SS7 ISUP
PSTN Phone
PSTN Phone
Call-flow
PSTN Phone
IAM
ACM
ANM
REL
RLC
MGC#1
SIP Proxy
INVITE
100 TRYING
18X
200 OK
ACK
CONVERSATION
BYE
200 OK
MGC#2
PSTN Phone
IAM
ACM
ANM
REL
RLC
PSTN origination - IP termination
SIP Proxy
SIP Proxy SIP
SIP
SIP Phone
SIP Proxy
PSTN
MGC
SS7 ISUP
PSTN Phone
Call-flow
PSTN Phone
IAM
ACM
ANM
MGC
SIP Phone
SIP Proxy
INVITE
100 TRYING
18X
200 OK
ACK
CONVERSATION
INVITE
18X
200 OK
ACK
REL
RLC
BYE
200 OK
BYE
200 OK
IP origination - PSTN termination
PSTN
SIP Proxy
MGC
SS7 ISUP
SIP
SIP Proxy
SIP
SIP Phone
SIP Proxy
PSTN Phone
Call-flow
SIP Proxy
SIP Phone
INVITE
100 TRYING
18X
200 OK
ACK
BYE
200 OK
MGC
PSTN Phone
INVITE
100 TRYING
18X
200 OK
IAM
ACM
ANM
ACK
CONVERSATION
BYE
200 OK
REL
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 <-> To、Request-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.
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-->
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;)