Signaling System No.7 Protocol Architecture And Sevices part 55 ppsx

ISDN User Adaptation (IUA)
In addition to addressing SS7 over IP, the SigTran group also addressed the
backhaul of ISDN over an IP network. RFC 3057 [142
] defined the IUA, which is
supplemented by an Implementer's Guide [143
] that seamlessly supports the Q.921
user (Q.931 and QSIG). It also supports both ISDN Primary Rate Access (PRA)
and Basic Rate Access (BRA) as well as Facility Associated Signaling (FAS),
N
on-Facility Associated Signaling (NFAS), and NFAS with backup D channel.
Further, extensions to IUA are defined for DPNSS/DASS2 [144
], V5.2 [145], and
GR 303 [146
] that will most likely become RFCs in the future.
Figure 14-25


< Day Day Up >



< Day Day Up >

Early Cisco SS7/IP Solution
Cisco was working on a SLT device before the SS7/IP IETF standardization efforts
began. The Cisco SLT is a modular access router (Cisco 2611 or 2651) that
terminates SS7 signaling links and backhauls MTP Level 3 and above to a PGW
2200 (formerly SC 2200 and VSC 3000) MGC. Figure 14-26
shows an example
configuration of two Cisco SLTs providing SS7 termination and backhaul for the
Cisco PGW 2200 Softswitch.

Figure 14-26. Cisco SLT Example
[View full size image]



N
OTE
For additional information about Cisco Softswitch products, including the
PGW2200 and BTS10200, visit the following Web site:
/>.

The SLT supports either SS7 A-link or F-link configurations. As noted previously,
some SS7 links are deployed with bearer channels that are provisioned on the time
slots that are not used by signaling channels. The SLT supports a drop-and-insert
feature, which allows the signaling channels to be groomed from the facility. The
bearer channels are hair pinnned on the interface card that is to be sent to a MG.
Figure 14-27
shows an example of the drop-and-insert feature.
Figure 14-27. Example of SLT Drop-and-Insert Feature
[View full size image]



Each 2611 SLT can terminate up to two SS7 links, and the 2651 SLT can terminate
up to four links. Both have support for ANSI, ITU, TTC, and NTT variants.
Several physical layer interfaces are supported on the SLT, including V.35, T1,
and E1.
The SLT function can also be integrated into the MG, as is done on some of the
Cisco universal gateways. The following Web site contains more information
about the Cisco SLT:

/>186a0080091b58.html
To deliver the backhauled messages to the PGW2200 reliably, the SLT makes use
of Reliable UDP (RUDP) and Session Manager (SM) protocols. A generic
backhaul protocol layer is used to provide adaptation between MTP Level 2 and
MTP Level 3. Figure 14-28
shows the protocol stacks used by the SLT and
PGW2200.
Figure 14-28. Cisco SLT Protocol Stack


RUDP is a simple packet-based transport protocol that is based on Reliable Data
Protocol (RFC 1151 [148
] and RFC 908 [149]). RUDP has the following features:
• Connection-oriented
• Guarantees packet delivery with retransmission
• Maintains session connectivity using keepalive messages
• Provides notification of session failure
The SLT maintains up to two RUDP sessions to each PGW2200 host. The use of
two sessions provides for additional reliability because they provide for two
different network paths between the SLT and the PGW2200.
The SM layer manages the RUDP sessions under control of the PGW2200. A
single RUDP session is used to pass messages between the SLT and PGW2200
based on RUDP session availability and the PGW2200 hosts' Active/Standby state.
The Active PGW2200 selects one or two possible RUDP sessions and indicates its
selection to the SLT via the SM protocol.
The generic backhaul protocol layer is very similar to M2UA; it provides the same
basic functionality for backhauling MTP Level 3 and above over IP to the
PGW2200.

< Day Day Up >

< Day Day Up >

SS7 and SIP/H.323 Interworking
The ITU-T originally developed the H.323 [125
] for multimedia over Local Area
N
etworks (LANs). It is not a single protocol; rather, it is a vertically-integrated
suite of protocols that define the components and signaling. Though it was
originally used for video-conferencing, H.323 was enhanced to better support VoIP
with the Version 2 release. It is currently the most widely-deployed VoIP solution
today.
One of the main complaints about H.323 is its complexity. With H.323, many
messages must be passed to set up even a basic voice call. SIP [124
], is considered
a simpler, more flexible alternative to H.323. SIP is a signaling protocol that
handles the setup, modification and teardown of multimedia sessions. It was
developed in the IETF as a signaling protocol for establishing sessions in an IP
network. A session can be a simple two-way telephone call or a multimedia
conference. SIP is becoming a popular favorite as the future of VoIP.
So, how does SigTran play a role in H.323 and SIP? SigTran can provide PSTN
connectivity to H.323 and SIP networks. A PSTN Gateway application can be used
to fulfill this need. The PSTN Gateway sits on the edge of the circuit-switched and
p
acke
t
-switched networks and provides SIP or H.323 interworking to SS7 in the
PSTN. Figure 14-29
shows an example of an SIP PSTN Gateway application. In
this example, the MGC connects to the SGs using SigTran.

Figure 14-29. SIP-PSTN Gateway Application
[View full size image]



Figure 14-30
shows a similar example of an H.323 PSTN Gateway application.
Figure 14-30. H.323-PSTN Gateway Application
[View full size image]



Another interesting application is the PSTN transit application, in which calls
originate and terminate on TDM interfaces and then transit a voice packet network
(such as SIP or H.323). Service providers can use this application to offload their
tandem and transit Class 4 and Class 3 switches. This application creates the need
for an ISUP transparency. SIP-T [150
] (SIP for Telephones) provides a framework
for the integration of the PSTN with SIP. Figure 14-31
shows an example of using
SIP-T for a PSTN transit application.
Figure 14-31. SIP Transit Application
[View full size image]



SIP-T meets the SS7 to SIP interworking requirements by providing the following
functions:
• A standard way of mapping ISUP information into the SIP header for calls
that originate in the PSTN. This function ensures that the SIP contains

sufficient information to route calls (for example, in the case where routing
depends on some ISUP information).
• Use of the SIP INFO [151] Method to transfer mid-call ISUP signaling
messages.
• A means for MIME [152] encapsulation of the ISUP signaling information
in the SIP body provides for ISUP transparency.
When the MGC receives an ISUP message, the appropriate ISUP parameters are
translated to the SIP header fields and the ISUP message is encapsulated in a
MIME attachment, which intermediate SIP entities treat as an opaque object. If the
SIP message terminates the call, it ignores the ISUP attachment because it has no
need for it. However, if the call terminates on the PSTN, the encapsulated ISUP
message is examined and used to generate the outgoing ISUP message. The
version parameter included in the MIME media type information indicates the
encapsulated ISUP message's ISUP variant. If there are different ISUP variants on
the origination and termination side, it is up to the terminating MGC to perform
ISUP translation between the variants.
