PRI Backhaul and IUA Support Using SCTP

SCTP is a reliable datagram-oriented IP transport protocol specified by RFC 2960. It provides the layer between an SCTP user application and an unreliable end-to-end datagram service such as IP. The basic service offered by SCTP is the reliable transfer of user datagrams between peer SCTP users, within the context of an association between two SCTP hosts. SCTP is connection-oriented, but SCTP association is a broader concept than, for example, TCP connection.

SCTP provides the means for each SCTP endpoint to provide its peer with a list of transport addresses during association startup (address and UDP port combinations, for example) through which that endpoint can be reached and from which messages originate. The association spans transfer over all of the possible source and destination combinations that might be generated from the two endpoint lists (also known as multihoming).

SCTP provides the following services and features:

• Acknowledged reliable nonduplicated transfer of user data
• Application-level segmentation to conform to the maximum transmission unit (MTU) size
• Sequenced delivery of user datagrams within multiple streams
• Optional multiplexing of user datagrams into SCTP datagrams
• Enhanced reliability through support of multihoming at either end or both ends of the association
• Congestion avoidance and resistance to flooding and masquerade attacks
• Interoperability with third-party call agents

SCTP allows you to terminate multiple switches and trunk groups on a gateway to add scalability. Adding trunk groups does not require more memory or processing resources because SCTP supports multiple streams in a single SCTP association. SCTP is a reliable transport protocol for message-oriented communications; SCTP is specifically designed to support PSTN signaling messages over IP networks.

SCTP allows you to configure at least one trunk group per T1 or E1 interface available on a given platform. A gateway platform with four T1 or E1 interfaces, for example, can control four unique trunk groups per device. Certain platforms, such as the Cisco AS5800 and Cisco AS5850, can deliver the individual T1 or E1 trunk groups over a high-speed interface, such as T3, which operates at 45 Mbps.

The table below shows the number of trunk groups supported per gateway platform.

In a typical network topology, only one SCTP association is configured between a signaling controller and a gateway. Multiple IP addresses on either side can be designated to the same association to achieve link redundancy. On a gateway, signaling messages for all trunk groups are carried over on the same SCTP association to the same signaling controller. Trunk groups on a gateway can also be controlled through different signaling controllers. In such cases, you can configure multiple associations on a gateway and direct them to different signaling controllers.

IUA is the adaptation layer that makes SCTP services available to Q.921 services users, such as Q.931, Q Signaling (QSIG), and National ISDN-2 with Cisco extensions (Cisco NI2+). IUA supports the standard interlayer primitives provided by Q.921. As a result, an upper-layer protocol (ULP) that typically used Q.921 services can easily migrate to IUA.

IUA service points are represented to the upper-layer protocol as application servers. Each application server is bound to an SCTP local endpoint managed by an SCTP instance. A remote signaling controller is known as an ASP. An ASP is connected to the local endpoint through a single SCTP association.

The IUA module creates associations between the signaling gateway and the MGC based on configuration requests. It also manages multiple ASPs as defined in the IETF IUA specification. IUA performs the following functions:

• Requests SCTP associations based on configuration information.
• Manages the destination address list and requests a new primary destination in the event of a failure.
• Manages the ASP state machine for each association.
• Manages the application-server state machine across all ASPs associated with a single application.
• Provides service for multiple applications simultaneously to handle different Layer 3 signaling protocols (Q.931 and Q.SIG, for example), or to communicate with different sets of call agents.

The figure below shows IUA with SCTP transport stack.

Figure 1

IUA with SCTP Transport Stack

To use IUA services, you must make the application server and ASP available and bind a trunk group to an application server for its Layer 2 server. For configuration information, see the Configuring IUA.

On a gateway, trunk groups are defined as Non-Facility Associated Signaling (NFAS) groups. An NFAS group is a group of ISDN PRI trunks with a single dedicated D channel. In a voice-gateway solution, the D channel in a trunk group is symbolic because SS7 is used as the signaling mechanism. The D channels defined for each NFAS group are actually DS0 bearer channels for voice or modem calls. Therefore, each NFAS has a corresponding D channel for which it is allocated.

A symbolic D-channel interface is dedicated to a trunk group. Each D-channel interface is bound to an application server and a dedicated stream is associated with this interface. Thus, the NFAS group identification can be recovered on each side of the SCTP association through this two-stage mapping as long as both sides share the same configuration information. Multiplexing of multiple trunk groups through a single association is accomplished this way, for example. If all interfaces on a gateway are controlled through a single SC, all interfaces are bound to the same application server.

The SCTP stream is a logical identification of the grouping of messages and consumes little additional memory and processing power. Each association can support as many as 65,355 streams.

The figure below shows the mapping between the trunk group, D-channel interface, and SCTP stream.

Figure 2

Mapping Between Trunk Group, Interface, and Stream

The figure below shows the NFAS group and SCTP association.

Figure 3

NFAS Group and SCTP Association

The IUA transport protocol using SCTP is supported on the Cisco PGW 2200; the Cisco PGW 2200 now uses IUA to communicate with Cisco access servers.

IUA with SCTP on the Cisco PGW 2200 provides the following services:

• Eliminates the scaling limitations in previous releases of Cisco MGC software for the number of NFAS-groups allowed per RLM.
• Supports upgrading from RLM-based communication to IUA-based communication without losing stable active calls.
• RLM-based communication is still supported. However, since this is a new functionality, the backward compatibility of the SCTP-based transports is not applicable.
• IUA interface can be used with Cisco access servers that support NAS and Digital Private Network Signaling System (DPNSS) signaling.
• Introduces IUA and SCTP operational measurements.

Note	For more information about IUA and SCTP on the Cisco PGW 2200, see Support for IUA with SCTP .

The following features use SCTP:

• PRI Backhaul Using SCTP and the ISDN Q.921 User Adaptation Layer
  
• Support for IUA with SCTP for Cisco Access Servers
  

To configure the PRI Backhaul Using SCTP and the ISDN Q.921 User Adaptation Layer feature, perform the following tasks:

Caution

When the Fast Ethernet interface is configured for auto negotiation, it can take up to two seconds to initialize. Two examples of the interface initializing is when the no shutdown command is entered, or if the cable is removed and then plugged back in. To avoid any problems, the Fast Ethernet interface should not be configured for auto negotiation. The duplex and speed parameters should be set according to the requirements of the network, and should not be set to auto.

• Configuring IUA
  
• Configuring ISDN Signaling (PRI) Backhaul
  
• Verifying PRI Backhaul
  

This section contains the following procedures:

• Configuring IUA for Cisco Access Servers
  
• Configuring the SCTP T1 Initiation Timer
  
• Creating NFAS Groups and Bind Them to the Application Server
  
• Migrating from RLM to IUA with SCTP
  
• Modifying a PRI Group on an MGC
  
• Verifying Support for IUA with SCTP
  

In a live system, debug commands for performance, state, signal, and warnings are most useful. These commands show any association or destination address failures and can be used to monitor the stability of any established associations.

Caution

Use debug commands with extreme caution or not at all in live systems, depending on the amount of traffic. Debug commands other than those for performance, state, signal, and warnings can generate a great deal of output and therefore cause associations to fail. Use these commands only in test environments or during times of very low traffic volume.

Note	SCTP debug commands display information for all current SCTP associations and cannot be limited to particular associations.

• SCTP debug commands that display statistical information show only the information that is available since the last time a clear ip sctp statistics command was executed. The clear ip sctp statisticscommand clears all SCTP statistics, both those compiled for individual associations and those compiled overall.
• Sample outputs for the debug commands are shown in the Examples.
• You can use debugs with timestamps enabled to see the relevant timing of the events indicated. To add timestamps to debug output, use the service timestampscommands (service timestamps debug and service timestamps log), optionally with the msec keyword. Output is in the format MMM DD HH:MM:SS, which indicates the date and time according to the system clock. If the system clock is not set, the date and time are preceded by an asterisk (*) to indicate that the date and time are probably not correct.
• For more information on SCTP debug commands, see Stream Control Transmission Protocol (SCTP) .

• Use the debug ip sctp api command to show all SCTP calls to the application programming interface (API) that are being executed and the parameters associated with these calls.
• Use the debug ip sctp congestion command to display various events related to calculating the current congestion parameters, including congestion window (cwnd) values per destination address and local and remote receiver window (rwnd) parameters. Information is displayed when bundling and sending data chunks, indicating the current cwnd and rwnd values and remote rwnd values, thus showing when data can or can not be sent or bundled. When chunks are acknowledged by the remote peer, the number of bytes outstanding and remote rwnd values are updated. Information is also displayed when new chunks are received, thus decreasing the local rwnd space, and when chunks are freed because the ULP is receiving datagrams from SCTP and thus freeing local rwnd space.
• Use the debug ip sctp init command to display datagrams and other information related to the initializing of new associations. All initialization chunks are shown, including the INIT, INIT_ACK, COOKIE_ECHO, and COOKIE_ACK chunks. You can use this command to see the chunks associated with any initialization sequence, but it does not display data chunks sent once the association is established. Therefore, it is safe to use in a live system that has traffic flowing when you have trouble with associations that fail and have to be reestablished.
• Use the debug ip sctp multihome command to display the source and destination of datagrams in order to monitor use of the multihome addresses. More than one IP address parameter can be included in an INIT chunk when the INIT sender is multihomed. Datagrams should mostly be sent to the primary destination addresses unless the network is experiencing problems, in which case they can be sent to the secondary addresses.
• Use the debug ip sctp performance command to display the average number of chunks and datagrams being sent and received per second once every 10 seconds. Averages are cumulative since the last time the statistics were cleared and so may not accurately reflect the number of datagrams and chunks currently being sent and received.
• Use the debug ip sctp rcvchunks command to display information about chunks that are received, including the following: stream number, sequence number, chunk length, and chunk transmission sequence number (TSN) for each chunk received; and whether the chunk is for a new datagram or a datagram that is already being reassembled. Command output shows whether the datagram is complete after receiving this chunk or not and, if complete, whether it is in sequence within the specified stream and can be delivered to the ULP. It shows the SACKs that are sent back to the remote, indicating the cumulative TSN acknowledged, the number of fragments included, and that the datagram is received by the ULP.
• Use the debug ip sctp rto command to display adjustments to the retransmission (retrans) timeout value due to retransmission of data chunks or unacknowledged heartbeats.
• Use the debug ip sctp segments command to display every datagram that is sent or received and the chunks that are contained in each. The command has two forms: simple and verbose. This simple form of the command shows basic information for each chunk type.
• Use the debug ip sctp segmentv command to show every datagram that is sent or received and the chunks that are contained in each. The command has two forms: simple and verbose. This verbose form of the output shows detailed information for each chunk type.
• Use the debug ip sctp signal command to display signals that are sent from SCTP to the application or ULP. These signals inform the ULP of state transitions for associations or destination addresses. Signal s sent to the ULP when new data is available to be received may not be shown because they occur infrequently. You can use this command to determine whether or not the current associations are stable. Because it does not generate output except on state transitions, it is safe to use in a live environment. It still should be used with caution, however, depending on the number of associations being handled by the system and the stability of the network.

Note	The debug ip sctp state and debug ip sctp signalcommands are often used together to provide insight into the stability of associations.

• Use the debug ip sctp sndchunks command to display the following types of information about all chunks that are being sent to remote SCTP peers:
  • Application send requests from the local SCTP peer
  • Chunks being bundled and sent to the remote peer
  • Processing of the SACKs from the remote peer, indicating which chunks were successfully received
  • Chunks that are marked for retransmission
• Use the debug ip sctp state command with the debug ip sctp signal command to provide insight into the stability of associations.
• Use the debug ip sctp timer command to display information about all started, stopped, and triggering SCTP timers. Many SCTP timers, after they are started, are not restarted until they expire or are stopped; the first call starts the timer, and subsequent calls do nothing until the timer either expires or is stopped.
• Use the debug ip sctp warnings command to display information on any unusual situation that is encountered. These situations may or may not indicate problems, depending on the particulars of the situation.
• Use the debug iua as command to display debug messages for the IUA application server when an ISDN backhaul connection is initially established.
• Use the debug iua asp command to display debug messages for the IUA ASP when an ISDN backhaul connection is initially established.

• Examples
  

The following shows sample SCTP configuration options using the help menu for the as and asp commands:

Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# iua
Router(config-iua)# as as1 ?
  A.B.C.D           Specify (up to two) Local IP address
  Fail-Over-Timer   Configure the Fail-Over timer for this AS
  sctp-startup-rtx  Configure the SCTP max startup retransmission timer
  sctp-streams      Configure the number of SCTP streams for this AS
  sctp-t1init       Configure the SCTP T1 init timer
Router(config-iua)# as as1 sctp-startup-rtx ?
  <2-20>  Set SCTP Maximum Startup Retransmission Interval
Router(config-iua)# as as1 sctp-streams ?
  <1-56>  Specify number of SCTP streams for association
Router(config-iua)# as as1 sctp-t1init ?
  <1000-60000>  Set SCTP T1 init timer (in milliseconds)
Router(config-iua)# asp asp1 as as1 ?
  A.B.C.D  Specify (up to two) IP addresses of the call-agent
Router(config-iua)# asp asp1 ?
  AS                Specify which AS this ASP belongs to
  IP-Precedence     Set IP precedence bits for a IP address in this ASP
  sctp-keepalives   Modify the keep-alive behaviour of an IP address in this
                    ASP
  sctp-max-assoc    Set SCTP max association retransmissions for this ASP
  sctp-path-retran  Set SCTP path retransmissions for this ASP
  sctp-t3-timeout   Set SCTP T3 retransmission timeout for this ASP
Router(config-iua)# asp asp1 sctp-keep ?
  A.B.C.D  specify the IP address to enable/disable keep alives
Router(config-iua)# asp asp1 sctp-keepalive 10.10.10.10 ?
  <1000-60000>  specify keep alive interval (in milliseconds)
Router(config-iua)# asp asp1 sctp-max-assoc ?
  A.B.C.D  specify the IP address
Router(config-iua)# asp asp1 sctp-max-assoc 10.10.10.10 ?
  <2-20>   specify maximum associations
  default  use default value of max associations for this address
Router(config-iua)# asp asp1 sctp-path-retran ?
  A.B.C.D  specify the IP address
Router(config-iua)# asp asp1 sctp-path-retran 10.10.10.10 ?
  <2-10>   specify maximum path retransmissions
  default  use default value of max path retrans for this address
Router(config-iua)# asp asp1 sctp-t3-timeout ?
  A.B.C.D  specify the IP address
Router(config-iua)# asp asp1 sctp-t3-timeout 10.10.10.10 ?
  <300-60000>  specify T3 retransmission timeout (in milliseconds)
  default      use default value of T3 for this address

The following example shows a running application-server configuration with IUA configured with one application server (as1) and two application-server processes (asp1 and asp2). Four T1s (T1 1/0, 1/1, 2/0, 2/1) are configured to use IUA backhaul.

Router# show running-config
Building configuration...
Current configuration :2868 bytes
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname iua_3660_b
!
logging rate-limit console 10 except errors
!
memory-size iomem 30
voice-card 1
!
voice-card 2
!
voice-card 3
!
voice-card 4
!
voice-card 5
!
voice-card 6
!
ip subnet-zero
!
no ip domain-lookup
!
no ip dhcp-client network-discovery
iua
  AS as1 10.21.0.2 9900
   ASP asp1 AS as1 10.23.0.16 9900
   ASP asp2 AS as1 10.23.0.16 9911
isdn switch-type primary-5ess
!
fax interface-type modem
mta receive maximum-recipients 0
!
controller T1 1/0
 framing esf
 clock source line primary
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 1/1
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 2/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 2/1
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 3/0
 framing sf
 linecode ami
!
controller T1 3/1
 framing sf
 linecode ami
!
controller T1 4/0
 framing sf
 linecode ami
!
controller T1 4/1
 framing sf
 linecode ami
!
controller T1 5/0
 framing sf
 linecode ami
!
controller T1 5/1
 framing sf
 linecode ami
!
controller T1 6/0
 framing sf
 linecode ami
!
controller T1 6/1
 framing sf
 linecode ami
!
interface FastEthernet0/0
 ip address 10.21.0.3 255.255.0.0 secondary
 ip address 10.21.0.2 255.255.0.0
 speed 10
 half-duplex
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial1/0:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial1/1:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn guard-timer 3000
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial2/0:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn guard-timer 3000
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial2/1:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
ip classless
ip route 10.0.0.0 255.0.0.0 10.21.0.17
ip route 11.0.0.10 255.255.255.255 FastEthernet0/0
ip route 172.0.0.0 255.0.0.0 172.18.194.1
ip http server
!
snmp-server manager
!
call rsvp-sync
!
voice-port 1/0:23
!
voice-port 1/1:23
!
voice-port 2/0:23
!
voice-port 2/1:23
!
no mgcp timer receive-rtcp
!
mgcp profile default
!
dial-peer cor custom
!
line con 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

The following sample output shows that Layers 1, 2, and 3 are enabled and active. Layer 3 shows the number of active ISDN calls.

Notice that the Layer 2 protocol is Q.921 and the Layer 3 protocol is BACKHAUL. This verifies that the system is configured to backhaul ISDN.

If you are connected to a live line, you should see that Layer 1 is active and Layer 2 is MULTIPLE_FRAME_ESTABLISHED, meaning that the ISDN line is up and active.

Router# show isdn status
*00:03:34.423 UTC Sat Jan 1 2000
Global ISDN Switchtype = primary-net5
ISDN Serial1:23 interface
        dsl 0, interface ISDN Switchtype = primary-net5
        L2 Protocol = Q.921  L3 Protocol(s) = BACKHAUL
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        NLCB:callid=0x0, callref=0x0, state=31, ces=0 event=0x0
        NLCB:callid=0x0, callref=0x0, state=0, ces=1 event=0x0
        0 Active Layer 3 Call(s)
    Activated dsl 0 CCBs = 0
    Number of active calls = 0
    Number of available B-channels = 23
    Total Allocated ISDN CCBs = 0

The following is an example of an application-server configuration on a gateway:

as as5400-3 10.4.8.69 10.4.9.69 2577

In the configuration above, an application server named as-named as5400-3 is configured to use two local IP addresses and a port number of 2577. IP address values that are set apply to all IP addresses of the ASP.

The following configuration example defines a remote signaling controller asp1 at two IP addresses for the application server named as5400-3. The remote SCTP port number is 2577:

Router(config-iua)# as as5400-3 10.4.8.69 10.4.9.69 2477
Router(config-iua)# asp asp1 as as5400-3 10.4.8.68 10.4.9.68 2577

Multiple ASPs can be defined for a single application server for the purpose of redundancy, but only one ASP can be active. The other ASP is inactive and only becomes active after fail-over.

In the Cisco MGC solution, a signaling controller is always the client that initiates the association with a gateway. During the initiation phase, you can request outbound and inbound stream numbers, but the gateway only allows a number that is at least one digit higher than the number of interfaces (T1/E1) allowed for the platform.

The number of streams to assign to a given association is implementation dependent. During the initialization of the IUA association, you need to specify the total number of streams that can be used. Each D channel is associated with a specific stream within the association. With multiple trunk group support, every interface can potentially be a separate D channel.

At startup, the IUA code checks for all the possible T1, E1, or T3 interfaces and sets the total number of inbound and outbound streams supported accordingly. In most cases, there is only a need for one association between the GW and the MGC. For the rare case that you are configuring multiple application-server associations to various MGCs, the overhead from the unused streams would have minimal impact. The NFAS D channels are configured for one or more interfaces, where each interface is assigned a unique stream ID.

The total number of streams for the association needs to include an additional stream for the SCTP management messages. So during startup the IUA code adds one to the total number of interfaces (streams) found.

You have the option to manually configure the number of streams per association. In the backhaul scenario, if the number of D channel links is limited to one, allowing the number of streams to be configurable avoids the unnecessary allocation of streams in an association that will never be used. For multiple associations between a GW and multiple MGCs, the configuration utility is useful in providing only the necessary number of streams per association. The overhead from the streams allocated but not used in the association is negligible.

If the number of streams is manually configured through the CLI, the IUA code cannot distinguish between a startup event, which automatically sets the streams to the number of interfaces, or if the value is set manually during runtime. If you are configuring the number of SCTP streams manually, you must add one plus the number of interfaces using the sctp-streams keyword with the as command. Otherwise, IUA needs to always add one for the management stream, and the total number of streams increments by one after every reload.

When you set the SCTP stream with the CLI, you cannot change the inbound and outbound stream support once the association is established with SCTP. The value takes effect when you first remove the IUA application-server configuration and then configure it back as the same application server or a new one. The other option is to reload the router.

The following is an example of an application-server configuration on a gateway. The configuration shows that an application server named as5400-3 is configured to use two local IP addresses and a port number of 2577:

Router(config-iua)# as as5400-3 10.1.2.34 10.1.2.35 2577

The following example sets the failover time (in milliseconds) between 1 and 10 seconds. Entering a value of 1000 would equal one second. Entering a value of 10000 would equal 10 seconds. In this example, the failover timer has been set to 10 seconds:

Router(config-iua)# as as5400-3 fail-over 10000

The following example specifies the number of SCTP streams for this association. In this example, 57 is the maximum number of SCTP streams allowed:

Router(config-iua)# as as5400-3 sctp-streams 57

The following example sets the SCTP maximum startup retransmission interval. In this example, 20 is the maximum interval allowed:

Router(config-iua)# as as5400-3 sctp-startup 20

The following example sets the SCTP T1 initiation timer in milliseconds. In this example, 60000 is the maximum time allowed:

Router(config-iua)# as as5400-3 sctp-t1init 60000

The following example specifies the IP address to enable and disable keepalives:

Router(config-iua)# asp asp1 sctp-keepalive 10.1.2.34

The following example specifies the keepalive interval in milliseconds. Valid values range from 1000 to 60000. In this example, the maximum value of 60000 ms is used:

Router(config-iua)# asp asp1 sctp-keepalive 10.10.10.10 60000

The following example specifies the IP address for the SCTP maximum association and the maximum association value. Valid values are from 2 to 20. The default is 20, which is the maximum value allowed:

Router(config-iua)# asp asp1 sctp-max-association 10.10.10.10 20

The following example specifies the IP address for the SCTP path retransmission and the maximum path retransmission value. Valid values are from 2 to 10. The default is 10, which is the maximum value allowed:

Router(config-iua)# asp asp1 sctp-path-retransmissions 10.10.10.10 10

The following examples specifies the IP address for SCTP T3 timeout and specifies the T3 timeout value in milliseconds. Valid timeout values are from 300 to 60000. The default is 60000, which is the maximum timeout value allowed:

Router(config-iua)# asp asp1 sctp-t3-timeout 10.10.10.10 60000

The following example configures the following:

1. Creates an IUA application server (Cisco AS5300-17) that has two local IP addresses (10.0.0.07 and 10.1.1.17) and local port 2097.
2. IUA application server Cisco AS5300-17 is connected by two SCTP associations (ASP PGW A and ASP PGW B) to two hot-standby Cisco PGW 2200s (Cisco PGW 2200 PGW A and Cisco PGW 2200 PGW B). Cisco PGW 2200 PGW A has remote IP addresses 10.0.0.00 and 10.1.1.10, and Cisco PGW 2200 PGW B has remote IP addresses 10.0.0.06 and 10.1.1.16.
3. Two NFAS groups (nfas-group 1 and nfas-group 2), which are both bound to IUA application server as5300-17.
4. Two trunk groups (trunk-group 11 and trunk-group 22)--Trunk-group 11 is bound to interface Dchannel0 and trunk-group 22 is bound to interface Dchannel2.

Router(config-iua)# as as5300-17 10.0.0.07 10.1.1.17 2097
Router(config-iua)# asp pgwa AS as5300-17  10.0.0.00 10.1.1.10 2097
Router(config-iua)# asp pgwb AS as5300-17  10.0.0.06 10.1.1.16 2097

The figure below shows the configuration above in diagram form with two outgoing POTS dial-peers (dial-peer 1 and dial-peer 2)--dial-peer 1 points to trunk-group 11, and dial-peer 2 points to trunk-group 22.

Figure 7

Specific ASP Example Configuration

The following is example output from the above configuration:

iua
   AS as5300-17 10.0.0.07 10.1.1.17 2097
   ASP pgwa AS as5300-17  10.0.0.00 10.1.1.10 2097
   ASP pgwb AS as5300-17  10.0.0.06 10.1.1.16 2097
!
!
controller E1 0
 framing NO-CRC4
 clock source line primary
 pri-group timeslots 1-31 nfas-d primary nfas-int 0 nfas-group 1 iua as5300-17
!
controller E1 1
 framing NO-CRC4
 clock source line secondary 1
 pri-group timeslots 1-31 nfas-d none nfas-int 1 nfas-group 1
!
controller E1 2
 framing NO-CRC4
 pri-group timeslots 1-31 nfas-d primary nfas-int 0 nfas-group 2 iua as5300-17
!
controller E1 3
 framing NO-CRC4
 pri-group timeslots 1-31 nfas-d none nfas-int 1 nfas-group 2
!
!
interface Ethernet0
 description the ip is 10.0.0.06 for interface e0
 ip address 10.0.0.06 255.255.255.0
 no ip route-cache
 no ip mroute-cache
!
interface FastEthernet0
 description the primary ip is 10.1.1.16 for interface f0
 ip address 10.1.1.10 255.255.255.0
 no ip route-cache
 no ip mroute-cache
 duplex auto
 speed auto
!
interface Dchannel0
 no ip address
 trunk-group 11
 isdn timer t309 100
 isdn timer t321 30000
 isdn incoming-voice modem
 isdn T303 20000
 isdn negotiate-bchan resend-setup
 no cdp enable
!
interface Dchannel2
 no ip address
 trunk-group 22
 isdn timer t309 100
 isdn timer t321 30000
 isdn incoming-voice modem
 isdn T303 20000
 isdn negotiate-bchan resend-setup
 no cdp enable
!
trunk group 11
!
trunk group 22
!
dial-peer voice 1 pots
 incoming called-number
 destination-pattern 997001
 direct-inward-dial
 trunk-group 11
 forward-digits all
!
dial-peer voice 2 pots
 incoming called-number
 destination-pattern 997002
 direct-inward-dial
 trunk-group 22
 forward-digits all
!

The following example shows a running application-server configuration with IUA configured with one application server (as1) and two ASPs (asp1 and asp2). Four T1s (T1 1/0, 1/1, 2/0, 2/1) are configured to use IUA backhaul.

Router# show running config
Building configuration...
Current configuration :2868 bytes
!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname iua_3660_b
!
logging rate-limit console 10 except errors
!
memory-size iomem 30
voice-card 1
!
voice-card 2
!
voice-card 3
!
voice-card 4
!
voice-card 5
!
voice-card 6
!
ip subnet-zero
!
no ip domain-lookup
!
no ip dhcp-client network-discovery
iua
  AS as1 10.21.0.2 9900
   ASP asp1 AS as1 10.23.0.16 9900
   ASP asp2 AS as1 10.23.0.16 9911
isdn switch-type primary-5ess
!
fax interface-type modem
mta receive maximum-recipients 0
!
controller T1 1/0
 framing esf
 clock source line primary
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 1/1
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 2/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 2/1
 framing esf
 linecode b8zs
 pri-group timeslots 1-24 service mgcp
!
controller T1 3/0
 framing sf
 linecode ami
!
controller T1 3/1
 framing sf
 linecode ami
!
controller T1 4/0
 framing sf
 linecode ami
!
controller T1 4/1
 framing sf
 linecode ami
!
controller T1 5/0
 framing sf
 linecode ami
!
controller T1 5/1
 framing sf
 linecode ami
!
controller T1 6/0
 framing sf
 linecode ami
!
controller T1 6/1
 framing sf
 linecode ami
!
interface FastEthernet0/0
 ip address 10.21.0.3 255.255.0.0 secondary
 ip address 10.21.0.2 255.255.0.0
 speed 10
 half-duplex
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial1/0:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial1/1:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn guard-timer 3000
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial2/0:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn guard-timer 3000
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
interface Serial2/1:23
 no ip address
 ip mroute-cache
 no logging event link-status
 isdn switch-type primary-5ess
 isdn incoming-voice voice
 isdn T203 10000
 isdn bind-l3 iua-backhaul as1
 no cdp enable
!
ip classless
ip route 10.0.0.0 255.0.0.0 10.21.0.17
ip route 11.0.0.10 255.255.255.255 FastEthernet0/0
ip route 172.0.0.0 255.0.0.0 172.18.194.1
ip http server
!
snmp-server manager
!
call rsvp-sync
!
voice-port 1/0:23
!
voice-port 1/1:23
!
voice-port 2/0:23
!
voice-port 2/1:23
!
no mgcp timer receive-rtcp
!
mgcp profile default
!
dial-peer cor custom
!
line con 0
 transport input none
line aux 0
line vty 0 4
 login
!
end

To modify a PRI group on a third-party call agent (MGC), the isdn bind commands must be removed from the D channel. The binding of the NFAS groups now takes place when you use the pri-group (pri-slt) command for IUA with SCTP.

Use the following examples to help you with your configuration:

• Controller configuration for primary span in an NFAS group for RLM. You can choose any time slot other than 24 to be the virtual container for the D channel parameters for ISDN:

controller T1 3/0:1
 framing esf
 pri-group timeslots 1-23 nfas-d primary nfas-int 0 nfas-group 1

• Controller configuration for primary span in an NFAS group for IUA:

controller T1 3/0:1
 framing esf
 pri-group timeslots 1-23 nfas-d primary nfas-int 0 nfas-group 1 iua as-1

You can implicitly configure the number of streams in SCTP by specifying only the serial interfaces that are configured to use IUA. The number of streams is bound to the actual number of interfaces supporting IUA. To support Cisco MGC solutions, you can configure any number of streams for each NFAS D channel, up to the total number of interfaces available in a given GW. For platforms using the PRI backhaul with SCTP and the ISDN Q.921 User Adaptation Layer (UAL), such as the Cisco 3660, you can configure the number of streams to match the number of PRIs that are actually backhauled to the Telcordia session manager.

The following example sets the failover time (in milliseconds) between 1 and 10 seconds. Entering a value of 1000 would equal one second. Entering a value of 10000 would equal 10 seconds. In this example, the failover timer has been set to 10 seconds. The default value is 4000 msec. Once you have set the failover timer to a value, you can return it to its default of 4000 msec by using the no form of this command.

Router(config-iua)# as as5400-3 fail-over 10000

The following example sets the SCTP maximum startup retransmission interval. Valid values are from 2 to 20:

Router(config-iua)# as as1 sctp-startup-rtx 20

The following example specifies the number of SCTP streams for an association. Valid values are from 1 to 56:

Router(config-iua)# as as1 sctp-streams 56

The following example sets the SCTP T1 initiation timer in milliseconds. Valid values are from 1000 to 60000:

Router(config-iua)# as as1 sctp-t1init 60000

The following changes have been made between RLM and IUA with SCTP. Use the examples in this section to help you with your configuration:

• The D channel interface serial commands are now replaced by interface D channel commands.

For RLM, the following format was used:

interface Serial3/0:1:23

Note	The :23 in the RLM example above, which typically corresponds with T1 configuration (:15 for E1 configuration), is no longer used.

For IUA, the following format is used:

interface Dchannel3/0:1

• The RLM group configuration must be removed from the D channel configuration.

For RLM, remove the "isdn rlm-group 1" line shown in bold:

interface Serial3/0:1:23
 no ip address
 isdn switch-type primary-ni
 isdn incoming-voice modem
 isdn T321 30000
 isdn T303 20000
 isdn T200 2000
 isdn rlm-group 1
 isdn negotiate-bchan resend-setup
 isdn bchan-number-order ascending
 no cdp enable

For IUA, use the following format:

interface Dchannel3/0:1
 no ip address
 isdn timer t309 100
 isdn timer t321 30000
 isdn incoming-voice modem
 isdn T303 20000
 no isdn send-status-enquiry
 isdn negotiate-bchan resend-setup
 isdn bchan-number-order ascending
 no cdp enable

You can configure the NFAS primary D channel on one channelized T1 controller, and bind the D channel to an IUA application server by using the pri-group (pri-slt) command.

This example uses a Cisco AS5400 and applies to T1, which has 24 timeslots and is used mainly in North America and Japan. You can choose any timeslot other than 24 to be the virtual container for the D channel parameters for ISDN.

Router(config-controller)# pri-group timeslots 1-23 nfas-d primary nfas-int 0 nfas-group 1 iua as5400-4-1

The following example applies to E1, which has 32 timeslots and is used by countries other than North America and Japan. You can choose any timeslot other than 32 to be the virtual container for the D channel parameters for ISDN.

Router(config-controller)# pri-group timeslots 1-31 nfas-d primary nfas-int 0 nfas-group 1 iua as5400-4-1