Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Denial event 1218 1

Status
Not open for further replies.

mojoputter

Technical User
Oct 11, 2005
1,123
US
OK boys & girls hopefully someone can help with this...
I have a user at site A that calls ext 3070, the call goes across a ISDN T1 DCS span to site B where ext 3070 is located. Ext 3070 is forwarded to a cell phone number of 616-222-2222 but the call fails when trying to go out the local ISDN T1 at site B. If someone at site B calls 3070 it routes to the cell number just fine, the problem only happens when the call comes across the DCS T1.

15:50:05 Calling party trunk-group 2 member 16 cid 0x40
15:50:05 Calling Number & Name NO-CPNumber 3109 BC Telle
15:50:05 active trunk-group 2 member 16 cid 0x40
15:50:05 dial 3070
15:50:05 term station 3070 cid 0x40
15:50:05 call-forwarding 961236382
15:50:05 term trunk-group 1 cid 0x40
15:50:05 dial 96123638294 route:HNPA|ARS
15:50:05 route-pattern 10 preference 1 cid 0x40
15:50:05 seize trunk-group 1 member 21 cid 0x40
15:50:05 Setup digits 6162222222
15:50:05 Calling Number & Name 6179511555
15:50:05 denial event 1218: Invalid IE contents D1=0x830002 D2=0x200264
15:50:05 idle trunk-group 1 member 21 cid 0x40

 
consulting the manual for avaya ...


Invalid IE contents Invalid IE contents.
See Cause Value 100 on page 170.
UID DIAG/LOC/CV

Cause Value 100
[0x64/0xE4] -
Invalid information element contents
The equipment that sent this Cause Value received a message that includes an Information
Element that it does recognize and implements, however one or more of the fields contained in
the Information Element are coded in such a way that it has not been implemented by the
equipment that sent this Cause Value.
 
I did see that in the documentation, now I need someone to explain all that jibberish. Sounds like something in the D-channel information is not something recognized by the network vendor as it hits the outside trunks.
 
Did you figured out how to solve this issue?
I'm having the same problem when dialing from an Asterisk (Trixbox) extension through Avaya local ISDN.
Thank you
 
No, I did not have a chance to figure this out, the customer has shutdown one of the sites, so we never did fix the issue.
 
Thank you ktripp, I read that post before, it seems old, like over an year ago. Not sure if the ooh323 module got updated after that post was submitted.

Anyways, I need to revisit these "video" settings. Not sure where to start looking though.

If I can get it to work I will post how was solved.
 
on the pbx with the station forwarded to a cell run the command:

ch isdn net

add a new entry and call it 'test' and put the type to a 3
Code:
change isdn network-facilities                                  Page   1 of   2 
                                NETWORK-FACILITIES
                        Facility                             Facility
         Name          Type  Coding Parm      Name          Type  Coding Parm
    sub-operator        0    00110       mega800             1    00010
    operator            0    00101       megacom             1    00011
    outwats-bnd         1    00001       inwats              1    00100
    sdn                 1    00001       wats-max-bnd        1    00101
    accunet             1    00110       lds                 1    00111
    i800                1    01000       multiquest          1    10000
    test                3            n                                    n
                                     n                                    n

Now change the outgoing route pattern and on the bottome of the route pattern add the word 'test to the service feature parameter.

Code:
                    Pattern Number: 200 Pattern Name:                
                             SCCAN? n     Secure SIP? n
    Grp FRL NPA Pfx Hop Toll No.  Inserted                             DCS/ IXC
    No          Mrk Lmt List Del  Digits                               QSIG
                             Dgts                                      Intw
 1: 1    0  200                                                         n   user
 2:                                                                     n   user
 3:                                                                     n   user
 4:                                                                     n   user
 5:                                                                     n   user
 6:                                                                     n   user

     BCC VALUE  TSC CA-TSC    ITC BCIE Service/Feature PARM  No. Numbering LAR
    0 1 2 M 4 W     Request                                 Dgts Format
                                                         Subaddress
 1: y y y y y n  n            rest     test                                none
 2: y y y y y n  n            rest                                         none
 3: y y y y y n  n            rest                                         none

This will strip the IE element from the outgoing call and should give the provider what it wants. Hope this helps.

Matt--Telecom Engineer, Network Operations Center

CCNA
ACA-Voice Management
ACE-IP Telephony
Converged+ Certified
Linux+ Certified
 
I found references to this during my searching. But it only works by CBC trunks.
 
Matt, thanks for the tip, seems promising but it didn't work.

@ktripp my outgoing trunk is CBC

It seems related because I have different error messages.
Prior to change with my original route settings I was getting:
denial event 1218: Invalid IE contents D1=0x830003 D2=0x40f64

After changing as per Matt suggestions the error changed to:
denial event 1367: BCC incompatibility D1=0x830003 D2=0x101

My settings prior to test Matt's idea:

BCC VALUE TSC CA-TSC ITC BCIE Service/Feature PARM No. Numbering LAR
0 1 2 M 4 W Request Dgts Format
Subaddress
1: y y y y y n n bothunr none
2: y y y y y n n rest none

I believe I'm getting the BCC error now because "both" on ITC is needed for 64k connections.

I received the same error by changing "y" to "n" on the BCC column "4" (which is 64k data calls)

So I believe the issue is caused by ooh323 setting the type of call as voice+data or voice+video I'm not 100% sure to tell.

Communication between extensions at both PBX works fine, be able to make external calls would be golden!
 
I believe this post explains the whole situation much better.

I see two possible solutions, find out which ones are the right settings for the ooh323 drivers to correct the Information Elements

or

do something on Avaya like Matt suggested that effectively change the type of call from voice+data to voice only.

Any other ideas?
 
Thanks Matt! That idea worked fine for me. We have an issue when trying to do cross carrier trunk to trunk transfers, that solved it.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top