1 / 27

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

RFC3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures . Presented by Zhi-Hong Guo Instructed by Assistant Professor Quincy Wu. In troduction. It is vital for a SIP telephony network to interwork with the PSTN.

bonnie
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RFC3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures Presented by Zhi-Hong Guo Instructed by Assistant Professor Quincy Wu

  2. 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.

  3. 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.

  4. 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

  5. PSTN architecture (cont.)

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

  7. Signaling System No. 7 (SS7) • SS7 is a global standard for telecommunications defined by ITU-T. • SS7 follows ISO 7 layer architecture.

  8. 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

  9. Basic call setup IAM: Initial Address Message ACM: Address Complete Message ANM: Answer Message

  10. Basic call release REL: Release Message RLC: Release Complete Message

  11. 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.

  12. 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.

  13. SIP Proxy SIP Proxy SIP Bridging (PSTN - IP - PSTN) VoIP Network PSTN MGC SS7 ISUP SIP PSTN Phone PSTN MGC SS7 ISUP PSTN Phone

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

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

  16. Call-flow SIP Phone MGC PSTN Phone 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

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

  18. Call-flow SIP Proxy SIP Phone 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

  19. 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

  20. ISUP-SIP message mapping • IAM<->INVITE • ACM<->18X • REL<->BYE

  21. 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.

  22. 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.

  23. 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.

  24. 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

  25. 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

  26. 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-->

  27. 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;)

More Related