H.323 Trunk "denial event 1220"

[NinjaUK51]

I am trying to setup an H.323 trunk between a S8700/G600 and a S8300/G700.
I have setup node names, signalling groups, trunk groups, network regions as dsecribed in the documentation but when I try and sieze a channel on the trunk group and send digits I receive a denial event 1220.
Does anyone have any pointers to what I thought would be a reasonably simple configuration?
Many thanks,

Ninja

 

[4merAvaya]

http://support.avaya.com/elmodocs2/comm_mgr/r2_2/pdfs/03_300190_3.pdf

Kevin

1220 Recovery on timer expiry Recovery on timer expiry.
See Cause Value 102.
UID DIAG/LOC/CV

Cause Value 102
[0x66/0xE6] -
Recovery on timer Expiry
The equipment sending this Cause Value sent or received a Layer 3 Q.931 message. Sending
or receiving this message has initiated a Layer 3 timer that has expired. This Cause Value is
being generated in conjunction with Q.931 protocol error handling procedures.
This Cause Value has local significance only. The ISDN network between the user and the
equipment generating the Cause Value might:
? Send no cause indication through the network
? Send a more generic Cause Value through the network
Communication Manager logs timer expiry errors that it generates to the hardware error log
against the signaling group of the D-channel where the error occurred. The signaling group
(ISDN-SER) error is Error Type 1 and the Aux Data contains the identifier of the Layer 3 timer
that expired.
Communication Manager does not generate the diagnostic information for the Cause Value IE.

Table 46: Cause Value 102, Signaling Group Error Type 1, Aux Data information
Aux
Data
Value
Timer
Name
Timer
Value
Description
1 T302 4s SETUP_ACK messages (overlap receiving mode)
2 T303_1 4s SETUP message 1st timer expiration
3 T303_2 4s SETUP message 2nd timer expiration
4 T305 4/30s DISCONNECT message
5 T308_1 4s RELEASE message 1st expiration
6 T308_2 4s RELEASE message 2nd expiration
7 T310 10s CALL_PROCEEDING message
8 T313 4s CONNECT message
9 T313_2 4s “no longer used”
10 T316 120s RESTART message
11 TL3 30s Layer 3 timer expired (d-channel dropped)
12 T309 90s d-channel reestablishment expiration stable calls are
dropped
13 T_WRN h FACILITY message (waiting for ACK or REJ)
14 T321 120s SERVICE message (waiting for ACK)
15 TSM h retransmission of SERVICE on d-channel switchover
16 TM100 h ISDN-BRI maintenance (MIM timer)

Troubleshooting
? Check the diagnostic information for the timer number that has expired. See Cause Values
and their meanings/interpretations on page 122.
? Check that the protocols at each end of the interface match (for example, both sides are
AT&T Custom or both sides are NI-2).
- If the ends of the interface are running different protocols, they might be running with
different values for their Layer 3 timers.
- If the protocols at each end of the interface match, the Communication Manager timer
might have expired because:

? the far end never saw the message because the message was corrupted in
transmission by noise on the D-channel. Check for any type of T1/E1 facility errors.
? the far end is experiencing a high traffic condition and did not have the processing
time to parse the sent message before the timer expired.
? even though the message was seen to be generated in an internal Communication
Manager trace, the message was never transmitted out onto the D-channel. Perform
an external protocol capture on the D-channel to confirm the transmission of the
suspect message.
? To interpret the receipt of Cause Value 102 from the far end, look at a trace/protocol
capture of the messaging taking place, and find the last message received from the far end
before Cause Value 102 is received. The timer that expired is most likely the Layer 3 timer
associated with that last message. If Communication Manager generated a message in
between those 2 events that should have stopped the timer, the cause might be:
- the far end never saw the message because the message was corrupted in transmission
by noise on the D-channel. Check for any type of T1/E1 facility errors.
- the far end might be experiencing a high traffic condition and did not have the processing
time to parse the sent message before the timer expired.
- even though the message was seen to be generated in an internal Communication
Manager trace, the message was never actually transmitted out onto the D-channel.
Perform an external protocol capture on the D-channel to confirm the transmission of the
suspect message.
? If Communication Manager did not respond to the receipt of the last message from the far
end, then Communication Manager internal hardware and software becomes suspect, and
trouble shooting the problem must proceed from that point.
Communication Manager administration that can contribute to seeing timer expiry errors:
? Trunk group form: Incoming call handling table. If the Per call CPN/BN field is incorrectly
populated in comparison to how the CO is programmed to send CPN or BN, it causes
Communication Manager to send a FACILITY message to the CO requesting CPN/BN
information and the CO will never respond. Communication Manager will log many timer
expiry errors against the signaling group (Error Type 1, Aux Data 13).
? DS1 form: Protocol version: If Communication Manager is running custom protocol
(protocol version “A”) and is connected to a Nortel DMS central office running custom
protocol, Communication Manager will log timer expiry errors against signaling group for
DISCONNECT problems (Error Type 1, Aux Data 4) during high traffic conditions.
? The DMS CO custom protocol implementation uses the ANSI recommended timer values
for their Layer 3 timers while Communication Manager uses the ITU recommended timer
values. Thus the T305 timer in the Communication Manager is 4 seconds while the same
timer in the DMS is 30 seconds, this difference causes timer expiry problems in high traffic
conditions. Change Communication Manager’s protocol version to c to line up the timers.

 

[NinjaUK51]

Many thanks,

port 1720 wasn't allowed through the firewalls, rule added and problem solved.