..

What ISDN protocol to use while connecting to Avaya T1 trunk

..

Developer Group

Developer Group
Connect with thousands of other developers to brainstorm ideas, share best practices and tips - or just chat about the latest emerging technologies making noise in the field. And of course, get the most up-to-date service and support news from Dialogic.
Dialogic PowerMedia HMP GlobalCall and R4 API

What ISDN protocol to use while connecting to Avaya T1 trunk

This question is answered

I am connecting a D/240JCT-T1 to Avaya S8300 via DS1 board which is configured as ISDN trunk.

I am unclear as to which ISDN protocol I should use for this purpose. I tried 5ESS, NI2, etc.

On the dialogic side I am able to initialise the channels. However on the Avaya side, I see level 3 out-of-service message on the signalling group page.

In the Dialogic Configuration Manager, which ISDN protocol should be used while connecting to Avaya trunk?

I have checked 5ESS.prm and NI2.prm to confirm that the error code, framing, D-channel settings match with the Avaya setting.

Sharath

Verified Answer
  • You need to make sure that you are not using dtiBxT24 ! This is the D channel on T1 ISDN. If you are trying to make a call or wait for a call on that device, your D channel will get confused and goes down.

     

  • Ah! You mean I should not even open (gc_OpenEx) the 24th channel. Stupid me, that's the problem then.Embarrassed

  • Indeed, you should not use T24.

    If you do device discovery using the NCM and SRL functions, you will get a device for timeslot 24 on Springware T1 boards. If you are running T1 ISDN you must skip that device.

    Please post back if that fixes the issue.

  • Yes, Christian. That was it. I was using SRL functions to detect the devices. I skipped opening the 24th channel and it went through fine. Avaya remains in service now.Big Smile

    Thanks everybody for your help.Yes

    Sharath

All Replies
  • Hi Sharath,

     

    I think you neet to ask the manager whom is the Avaya manager. But I have a experience of connection with the D/MV board. I remember I used QSIG E1 PRI, suggest you can try QSIGT1 T1 PRI.

     

  •  

    Hi Sharath,

    Can you find out which ISDN protocol the line is configured for from your CO or avaya switch provide?

    Once you know that, then someone will be able to suggest what configuration changes need to be made.

    Jeff

  • Hi Jeff,

    I have full authority to change anything on the Avaya side too. Right now I am willing to change anything on both Avaya and Dialogic side to make it work on ISDN-PRI T1.

    I am attaching the Avaya DS1, trunk and signalling setting pages.

    Sharath

  • Eventhough I am able to open the channels and get GCEV_UNBLOCKED on all channels, the status remains out-of-service on the Avaya side.

    Sharath

  • Hi Sharath,

     

    I think the protocol is correct now because you are receiving GCEV_UNBLOACKED. Can you try to check you are user mode or network mode?

     

  • Hi Robin,

    I have set the Avaya DS1 to network side. How do I set Dialogic to user side?

    dxxxB1C1(0): ST_UNUSED => GCEV_UNBLOCKED => ST_RESET
    dxxxB1C1(0): ST_RESET => GCEV_RESETLINEDEV => ST_WAIT

    I call gc_ResetLineDev() after getting GCEV_UNBLOCKED, and call gc_WaitCall() after getting GCEV_RESETLINEDEV.

    Still, Avaya thinks all channels are out-of-service.

    Sharath

  • Hi Sharath,

    You need to to add this parameter to your .prm (parameter file). There is no this parameter in .prm file by default. Hop it works!

    Problem #5: Network or User side? - How is Dialogic configured, and how should it be configured?
    Solution: The default Network Mode configuration for ISDN on DM3 products is USER side. To change this to NETWORK side, the user must modify the appropriate .config file and generate an updated .fcd file by running FCDGEN.exe. Here is the procedure:
    1) Stop the Dialogic System Service
    2) Open config file.
    3) Add 'Setparm=0x17,1 ! Network Mode. 1=NETWORK 0=USER' under the '[CCS]' section, and save the file.
    4) Run fcdgen with the filename.
    5) Start the Dialogic System Service.

    ** For springware, use the appropriate .prm file for the Network side (for T1 only … NT1.prm for most ISDN protocols, or QTN.prm for QSIG).

     

  • You are saying springware can only act as network side for ISDN. Does that mean I should configure Avaya as user side? That is not a problem for me. I will try that. This board is springware.

    BTW, the default values in 4ess.prm, 5ess.prm, nt1.prm and qtn.prm are all identical. What difference does it make which one I pick?

  • Nope, making Avaya DS1 user side didn't work either. The layer 3 is still out of service.

    Meanwhile I checked the RTF log. I see the following error, this happens when I call gc_GetMetaEvent() while processing GCEV_RESETLINEDEV message.

    libisdnr..ll            ERR1                   ::::> cc_GetCRN() returns 0x386 due to (invalid ec_crn)
    spwrgcis                ERR1         gcis                  gcis_GetCRN() returns -1 due to cc_GetCRN() failed

    The CRN is part of layer 3 message, but CRN is not expected in GCEV_RESETLINEDEV. This is getting too confusing.

    Sharath

  • No, Springware can act both as network and user. It depends on the protocol you set on the board in DCM.

    4ess, 5ess, qtt are user, while nt1 and qtn are network.

    Even if the corresponding .prm files are the same as content, Dialogic NCM uses your setting to load different .fwl files. For example, if you set the protocol to 4ess, NCM will try to load in the board the firmware is4ess.fwl (or something like this, you get the idea). The .fwl files are different, as tehy contain the protocol behaviour.

    Hope this helps,

    Chris

  • Please, try all protocols. Dialogic and PBX vendors seem to have slightly different names for ISDN protocols, so it's more like guessing what each other needs. Usually, for T1-PRI, setting Dialogic to 4ess did the job. Of course, you need to set the PBX to be network side.

    Chris

  • This is a correct behaviour. CRN is Dialogic's terms stands ffor Call Reference Number. CRN is generated by GlobalCall library upon call setup. This CRN is associated with the line device handle until the call tears down.

    gc_ResetLineDev releases a call deletes and invalidates the CRN assocated with the line device (if any). The GCEV_RESETLINEDEV, therefore event is not assocated with a CRN, because after completion of ResetLineDev there is no call on that line.

    If you are using DM33 boartd, please also make sure that the parameter 0x1312 is set to 0 (send SERVICE message). It is 1 by default, and no SERVICE or SERVICE ACK is sent to the switch, which may be why the switch shows all your lines OOS

    Thanks,

    Leonid.

  • Ok, I have set Avaya to behave like network by making connect type as line-side. See the first image I had posted earlier. Then I set Dialogic to 4ESS protocol, that is user side. And I have configured only one B channel apart from the D channel, to keep it simple while debugging.

    When I start the Dialogic service, the Avaya side too comes online, the signaling group and trunk group show in-service status. Both sides are happy.

    In the RTF log, these are the only ISDN related log at that time.

    11/12/2008 18:04:17.731   2140 500 libisdnr..ll  DEBG   ----- IsdnCRNInit() is called
    11/12/2008 18:04:17.762   2140 500 libisdnr..ll  DEBG   ----- IsdnCleanUpCRNs() is called
    11/12/2008 18:04:21.775   6500 7504 libisdnr..ll DEBG  ----- IsdnCRNInit() is called
    11/12/2008 18:04:21.806   6500 7504 libisdnr..ll DEBG  ----- IsdnCleanUpCRNs() is called

    Now, I start my IVR application. Hell breaks loose, Avaya goes out of service. How do I debug this?

  • And here is the weird part. Eventhough I have configured only one B channel, I still get 24 GCEV_UNBLOCKED messages, even on the D channel.

    The device name looks like this-> :N_dtiB1T1:P_isdn

    Something missing here?

  • You need to make sure that you are not using dtiBxT24 ! This is the D channel on T1 ISDN. If you are trying to make a call or wait for a call on that device, your D channel will get confused and goes down.