Cause 100- Invalid IE contents

[pacojonezl40]

Having an issue with calls between Cisco Call Manager and Nortel 81C Succession 3.0. I have both at my site and calls from the CCM at my site work fine when dialing Nortel. There was just a merger with another company and when calling from the new company's cluster to Nortel here the call goes through fine as well. The issue is when unanswered calls forward to voicemail, the call is rejected and sent back to the Call Manager. I am wondering is it because the voicemail platform is Octel or is it something as simple as sending/recieving wrong number of digits. I took some D-Channel messages and posted them below.

This is from a good call from Cisco on my site to Nortel on my site:

CH 56 UIPE_IMSG CC_SETUP_IND REF 00007C98 CH 56 3 TOD 18:49:56 CK 22EE215D
CALLED #:5599 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLING #:3456 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 56 UIPE_OMSG CC_PROCEED_REQ REF 0000FC98 CH 56 3 TOD 18:49:56 CK 22EE2164

DCH 56 UIPE_OMSG CC_ALERT_REQ REF 0000FC98 CH 56 3 TOD 18:49:56 CK 22EE2167
PROGRESS: TERMINATING END IS NOT ISDN


DCH 56 UIPE_OMSG CC_FAC_REQ REF 0000FC98 CH 0 TOD 18:50:16 CK 22EEBD2F

DCH 56 UIPE_OMSG CC_FAC_REQ REF 0000FC98 CH 0 TOD 18:50:16 CK 22EEBD31



DCH 56 UIPE_OMSG CC_SETUP_RESP REF 0000FC98 CH 56 3 TOD 18:50:18 CK 22EECF28
PROGRESS: TERMINATING END IS NOT ISDN
CONNECT #:707708 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 56 UIPE_IMSG CC_SETUPCOMP_IND REF 00007C98 CH 56 3 TOD 18:50:18 CK 22EECF7B


DCH 56 UIPE_IMSG CC_DISC_IND REF 00007C98 CH 56 3 TOD 18:50:22 CK 22EEF536
CAUSE: #16 - NORMAL CALL CLEARING

DCH 56 UIPE_OMSG CC_RELEASE_REQ REF 0000FC98 CH 56 3 TOD 18:50:22 CK 22EEF537


DCH 56 UIPE_IMSG CC_RELEASE_CONF REF 00007C98 CH 56 3 TOD 18:50:22 CK 22EEF577


3456 is the Call Manager number and 5599 is on my 3904. 707708 is one of the roll-over ports from the Octel. The pilot number for voicemail is 4044 and if the first port is busy, the hunt ports are programmed as 6 digit numbers.

Here is a failed call from off-site Call Manager (different cluster) to my site 81C:

DCH 57 UIPE_IMSG CC_SETUP_IND REF 00007E92 CH 57 1 TOD 18:48:50 CK 22EC23C0
CALLED #:5599 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLING #:3343 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 57 UIPE_OMSG CC_PROCEED_REQ REF 0000FE92 CH 57 1 TOD 18:48:50 CK 22EC23C8

DCH 57 UIPE_OMSG CC_ALERT_REQ REF 0000FE92 CH 57 1 TOD 18:48:50 CK 22EC23CA
PROGRESS: TERMINATING END IS NOT ISDN


DCH 57 UIPE_IMSG CC_DISC_IND REF 00007E92 CH 57 1 TOD 18:48:58 CK 22EC62E4
CAUSE: #100 - INVALID IE CONTENTS


DCH 57 UIPE_OMSG CC_RELEASE_REQ REF 0000FE92 CH 57 1 TOD 18:48:58 CK 22EC62E6

DCH 57 UIPE_IMSG CC_RELEASE_CONF REF 00007E92 CH 57 1 TOD 18:48:58 CK 22EC632C


3343 is the incoming call and is trying to reach 5599 voicemail when not answered.

The calls incoming to the Nortel are using the same Gateways from the Cisco side. There are 6 E-1 connected from Nortel to the Cisco Gateways.

Any suggestions of what to change? I think it may be number of digits as stated before, but I'm also seeing that it might be some kind of Protocol Mismatch as I investigate the cause 100- invaild IE contents error message.

 

[Avaya911PLM]

I see the site that is working is DCH 56, and the problem site is on DCH 57.

Did you compare the RDB and DCH for each of these?
If these are in fact identical, then compare the programming of the Cisco at 3456 with the Cisco at 3343

The fact that you are OK, with the first scenario leads me to believe that the problem is in the far end AS LONG AS the Nortel is identical on the 2 routes.

--
Fletch

Nortel Emergency Services PLM

http://nortel.com/e911

Check out this month's E911 Talk podcast at Nortel E911 Talk Podcast

 

[pacojonezl40]

Actually both DCH 56 and DCH 57 are in the same Route. And the DCH are identical since they are both going into the same Gateway.

 

[Avaya911PLM]

Then you problem is most likely the far end Cisco based on what you have posted. They are the ones complaining about bad IE contents.

DCH 57 UIPE_IMSG CC_DISC_IND   REF 00007E92 CH 57 1 TOD  18:48:58 CK 22EC62E4
CAUSE: #100 - INVALID IE CONTENTS

This is an incoming messge indicating a disconnect on their side due to invalid IE.

--
Fletch

Nortel Emergency Services PLM

http://nortel.com/e911

Check out this month's E911 Talk podcast at Nortel E911 Talk Podcast

 

[1998xj8]

i thought i remember this before...it was dchannel stating in set up call is on bchannel xx, but in reality bchannel call is not there...sometimes due to incorrect programming on the additional t1 loop interface id numbering on dchannel or t1s not being aligned in same order 1 to 6
on each side..

 

[pacojonezl40]

Thanks everyone, but the issue was found to be on the Cisco Call Manager. There is apparently a known issue with the Cisco Gateways and the version of CCM we are running when utilizing H.323 trunks. Below is the solution Cisco gave. It wound up not being a Nortel problem at all.

Copied from Cisco response:
The cisco tac engineer at this time suspects that this may be a CUCM 5.1 defect.

Problem
The CallManager is attempting to negotiate the media channel before the call connects. In some instances this is the proper behavior, however in this case since we are using H.323 slow start the media should only be negotiated after the call is connected. As a result the behavior the Media Exchange Interface Capability Timer expires while the phone is ringing.

The TAC engineer is working on determining the root cause of the defect, however a temporary work around is available.

Work Around
The interim work around defined by TAC would be to change the Media Exchange Interface Capability Timer. The default is 8 seconds. TAC suspects that by increasing the timer to 30 Secs seconds that the call should be transferred to voicemail before the Media exchange timer expires.

Also had to change another Service Parameter in CCM:
"Outgoing Media Connect Time for PRI" change from default "Connect ASAP" to "Connect".

Basically it makes the gateway wait for the connect message before building the media channel as opposed to the media channel being establish from the start of the call before it actually connects.