rfc3372 session initiation protocol for telephones (sip-t): context and architectures presented by...
TRANSCRIPT
RFC3372 Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures
Presented by Zhi-Hong GuoInstructed 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)
– The transmission facilities 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 ha
s no use for the encapsulated ISUP and ignores it. IP origination - PSTN termination: The terminating ga
teway only performs translation. IP origination - IP termination: This is a case for pure
SIP.
SIP Bridging (PSTN - IP - PSTN)
VoIP Network
VoIP NetworkSIP Proxy
SIP Proxy
MGC
MGCPSTN
PSTN
PSTN Phone
PSTN Phone
SS7 ISUP
SS7 ISUPSIP
Call-flow
PSTN Phone MGC#2MGC#1 SIP Proxy
INVITEIAM
100 TRYINGACM
IAM
18XACM
ANMANM
200 OKACK
CONVERSATION
RELRLC
RELRLC
BYE200 OK
PSTN Phone
PSTN origination - IP termination
VoIP Network
VoIP NetworkSIP Proxy
SIP ProxyMGCPSTN
PSTN Phone
SS7 ISUP
SIP
SIP Proxy SIP
SIP Phone
Call-flow
PSTN Phone MGC SIP Proxy
INVITE100 TRYING
IAM
18XACM
ANM200 OKACK
CONVERSATION
REL
RLCBYE
200 OK
INVITE18X
200 OK
ACK
BYE200 OK
SIP Phone
IP origination - PSTN termination
VoIP Network
VoIP Network
SIP Proxy
SIP Proxy
MGCPSTN
PSTN Phone
SS7 ISUPSIP
SIP Phone
SIP Proxy
SIP
Call-flow
SIP Phone
CONVERSATION
SIP Proxy MGC PSTN Phone
INVITEINVITE
IAM100 TRYING100 TRYING
18X18X
200 OK200 OKACK
ACK
BYEBYE
200 OK 200 OK
ACM
ANM
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 IN
VITE) 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;)