SIP-T 相关 RFC 重温

SIP for Telephones (SIP-T)

SIP-T 是 IETF 制定的规范，由 RFC3372、RFC2976、RFC3204、RFC3398 等组成，用于阐

述 SIP 与 SS7 ISUP 的互通。

SIP-T 定义了 SIP-ISUP Gateway 如何在 SIP 消息里面封装(Encapsulation, RFC 3204) ISUP 信

令，以便在 SIP 网络里面端到端传输 ISUP 信令。同时 SIP-T 也阐述了 SIP-ISUP Gateway 如何将

ISUP 信令映射(Translation, RFC 3398)成 SIP 请求，以及需要将 ISUP 信令里面的一些重要信息翻

译成 SIP headers，以便 SIP Proxy 等纯 SIP 设备可以路由这些呼叫。

对于 mid-call 状态下的 ISUP 信令，SIP-T 使用 RFC 2976 定义的 SIP INFO 方法去封装传输这

些信息。

下表是 RFC 3372 列举的 ISUP-SIP 互通的要求，以及 SIP-T 规范对应的解决方式

SS7-SIP Interworking Requirements SIP-T Functions

==================================================================

Transparency of ISUP Encapsulation of ISUP in the

Signaling SIP body

Routability of SIP messages with Translation of ISUP information

dependencies on ISUP into the SIP header

Transfer of mid-call ISUP signaling Use of the INFO Method for mid-

messages call signaling

Table 1: SIP-T features that fulfill PSTN-IP inter-connection

Requirements

Originator requirements: encapsulate ISUP, translate information from

ISUP to SIP, multipart MIME support (for gateways only)

Terminator requirements: standard SIP processing, interpretation of

encapsulated ISUP (for gateways only), support for multipart MIME,

graceful handling of unknown MIME content (for non-gateways only)

Proxy requirements: ability to route based on choice of routable

elements

4.4 Behavioral Requirements Summary

If the SIP-T originator is a gateway that received an ISUP request,

it must always perform both encapsulation and translation ISUP,

regardless of where the originator might guess that the request will

terminate.

If the terminator does not understand ISUP, it ignores it while

performing standard SIP processing. If the terminator does

understand ISUP, and needs to signal to the PSTN, it should reuse the

encapsulated ISUP if it understands the variant. The terminator

should perform the following steps:

o Extract the ISUP from the message body, and use this ISUP as a

message template. Note that if there is no encapsulated ISUP in

the message, the gateway should use a canonical template for the

message type in question (a pre-populated ISUP message configured

in the gateway) instead.

o Translate the headers of the SIP request into ISUP parameters,

overwriting any values in the message template.

o Apply any local policies in populating parameters.

An intermediary must be able to route a call based on the choice of

routable elements in the SIP headers.

SIP-T 只界定基本呼叫，没有涉及补充业务。

另外 RFC 3398 对于 ISUP 信令非呼叫控制部分的一些说明

This document also only takes into account the call functionality of

ISUP. Maintenance messages dealing with PSTN trunks are treated only

as far as they affect the control of an ongoing call; otherwise these

messages neither have nor require any analog in SIP.

Messages indicating error or congestion situations in the PSTN (MTP-

3) and the recovery mechanisms used such as User Part Available and

User Part Test ISUP messages are outside the scope of this document

RFC 3398 对 SIP Stack 的一点要求

SIP Mechanisms Required

1. 'Transparent' Transit of ISUP Messages

To allow gateways to take advantage of the full range of services

afforded by the existing telephone network when placing calls from

PSTN to PSTN across a SIP network, SIP messages MUST be capable of

transporting ISUP payloads from gateway to gateway.

"MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.

2. Understanding MIME Multipart Bodies

PSTN interworking nodes MUST understand the MIME type of

"multipart/mixed" as defined in RFC2046 [4]. Clients express support

for this by including "multipart/mixed" in an "Accept" header.

"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types",

RFC 2046, November 1996.

3. Transmission of Dual-Tone Multifrequency (DTMF) Information

This transmission MAY be performed as described in RFC2833 [5].

4. Reliable Transmission of Provisional Responses

When interworking with the PSTN, SIP messages MUST be sent reliably

end-to-end; reliability of requests is guaranteed by the base

protocol. One application-layer provisional reliability mechanism

for responses is described in [18].

"Reliability of Provisional Responses in SIP", RFC 3262, June 2002.

5. Early Media

One mechanism that provides a way of initiating a fully-featured early

media system is described in [20].

"The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.

6. Mid-Call Transactions which do not change SIP state

In support of mid-call transactions and other ISUP events that do not

correspond to existing SIP methods, SIP gateways MUST support the

INFO method, defined in RFC2976 [6]. Note that this document does

not prescribe or endorse the use of INFO to carry DTMF digits.

Gateways MUST accept "405 Method Not Allowed" and "501 Not

Implemented" as non-fatal responses to INFO requests - that is, any

call in progress MUST NOT be torn down if a destination so rejects an

INFO request sent by a gateway.

7. Privacy Protection

The base SIP protocol supports a method of specifying that a user is

anonymous. However, this system has a number of limitations - for

example, it reveals the identity of the gateway itself, which could

be a privacy-impacting disclosure. Therefore gateways MAY support

more sophisticated privacy systems. One mechanism that provides a

way of supporting fully-featured privacy negotiation (which interacts

well with identity management systems) is described in [9B]

"A Privacy Mechanism for the Session Initiation

Protocol (SIP)", RFC 3323, November 2002.

8. CANCEL causes

Therefore gateways MAY support a mechanism for end-to-end delivery of such failure

reasons. One mechanism that provides this capability is described in

[9].

"The Reason Header Field for the Session Initiation Protocol", RFC 3326, December

2002.

SIP to ISUP mapping 的一些细节, 查看 7.2.1 --- 7.3

4. The "called party status" code in the ACM message is mapped to a

SIP provisional response (as described in Section 7.2.5 and

Section 7.2.6) and returned to the SIP node.

5. If the ISUP variant permits, the remote ISUP node may issue a

variety of Call Progress (CPG) messages to indicate, for example,

that the call is being forwarded.

6. Upon receipt of a CPG message, the gateway will map the event

code to a SIP provisional response (see Section 7.2.9) and send

it to the SIP node.

ISUP to SIP mapping 的一些细节, 查看 8.2.1 --- 8.2.8

4. Upon receipt of a provisional response of 180 or greater, the

gateway will generate an ACM message. If the response is not

180, the ACM will carry a "called party status" value of "no

indication."

Suspend/Resume and Hold, 查看 9.1 --- 9.2

Normal Release of the Connection, 查看 10.1 --- 10.2

ISUP Maintenance Messages, 查看 11.1 --- 11.3

Construction of Telephony URIs, 查看 12.1 --- 12.2

Other ISUP flavors, 查看 13.1