Presented by Zhi-Hong Guo Instructed by Assistant Professor Quincy Wu 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) 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 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) VoIP Network SIP Proxy PSTN MGC SS7 ISUP SIP SIP Proxy PSTN Phone PSTN MGC SS7 ISUP PSTN Phone

Call-flow PSTN Phone PSTN Phone MGC#1 MGC#2 IAM INVITE IAM 100 TRYING SIP Proxy IAM INVITE IAM 100 TRYING ACM 18X ACM ANM 200 OK ANM ACK CONVERSATION REL RLC BYE REL 200 OK RLC

PSTN origination - IP termination VoIP Network SIP Proxy SIP Proxy SIP SIP SIP Proxy SIP Phone PSTN MGC SS7 ISUP PSTN Phone

Call-flow PSTN Phone SIP Phone MGC IAM INVITE INVITE 100 TRYING 18X SIP Proxy IAM INVITE INVITE 100 TRYING 18X 18X ACM 200 OK 200 OK ANM ACK ACK CONVERSATION REL BYE RLC BYE 200 OK 200 OK

IP origination - PSTN termination VoIP Network SIP Proxy PSTN MGC SS7 ISUP SIP SIP Proxy SIP Proxy PSTN Phone SIP SIP Phone

Call-flow SIP Phone SIP Proxy MGC PSTN Phone INVITE INVITE 100 TRYING IAM 100 TRYING ACM 18X 18X ANM 200 OK 200 OK ACK ACK CONVERSATION BYE BYE REL 200 OK 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 <-> 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;)