Missing parameters when transfering calls between channels

fesquivel · **Posted:** Fri Aug 08, 2008 9:04 am

I have an NMS CG6060 board with a PRI ISDN T1 in Trunk 0. managed by three applications implemented with enGenic''s TeleFlow, like this:

17 channels will receive incoming customer calls, which will be attended by an IVR system (application A)
3 channels will perform outgoing calls to a call center (application B)
3 channels will perform outgoing calls to send out faxes on demand (application C)

One of the options in the IVR''s menu (application A) offers the calling customer the chance to be attended by a customer representative on the call center and I plan this transfer to work like this:

1. Customer in channel X asks for call center attention from application A, which issues a request to application B

2. Channel Y running application B gets the request and places an outbound call

3. When application B detects an answer to the outbound call (an off-hook), it performs a Transfer to channel X

4. Assuming both channels are connected (that is, the customer is actively speaking to the call center agent), both applications hang up their channels, as the call is being managed by the T1''s provider

You know this kind of transfer as a "2 bearer transfer", only possible when the T1 is configured as PRI ISDN with the NI2 protocol variant, which is exactly the case here.

However, it''s not working: According to the T1''s provider, when the outbound call is placed (step 2 above), some data is expected on the signaling D-Channel:

The Numbering Plan Indicator (NPI)
The Call Type (CT)
The Called Number (CN)

When testing call transfers internally (that is, not using my T1 nor my IVR system), they see values like this:

NPI=e164
CT=national_number
CN=18093662540

But when using my T1 and the included ctatest.exe program (or even my IVR system), they report some of the values are missing:

NPI=unknown
CT=unknown
CN=8097326006

... and they insist these missing (unknown) values are required for a successful call and eventual transfer.

Do you know if I have to configure/activate something somewhere so these missing values get properly filled up?

Thanks in advance for your support.

Tim · **Posted:** Fri Aug 08, 2008 6:09 pm

Check your Place Call step and see if you have two fields named, "ISDN calling number plan" and "ISDN calling number type". These will allow you to set the ISDN parameters that your telco says they want. By default, the NMS card will send 0 in each field, which is either "Default" or "Unknown" depending on your carrier. These fields have pull-down values, which list the only options supported at this time.

If you don't have those fields, you'll need to upgrade to the latest version of TeleFlow. You can access the download page from http://www.teleflow.org.

Also note that in order to use the Transfer step to activate 2B-transfer, you will have to know the "call reference number" of the other port. This number is available as long as a port connected in a call, and you can retrieve it by using the @SYS_CALLREF system variable.

fesquivel · **Posted:** Wed Oct 01, 2008 8:58 am

Hi, Tim.

Tim wrote:

Check your Place Call step and see if you have two fields named, "ISDN calling number plan" and "ISDN calling number type". These will allow you to set the ISDN parameters that your telco says they want. By default, the NMS card will send 0 in each field, which is either "Default" or "Unknown" depending on your carrier. These fields have pull-down values, which list the only options supported at this time.

If you don't have those fields, you'll need to upgrade to the latest version of TeleFlow. You can access the download page from http://www.teleflow.org.

I have those fields and they were blank. However I put ISDN for the first one and NATIONAL for the second one and re-tested... Same behaviour: The telco just sent me their test logs and both values still come as "unknown":

Code:

<== 05:10:16:30.20   (CM Time: 26:12:41:42.28).
<== Q931: SETUP:     from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,02 80
  BC:  speech
       64 kbit/s
       circuit mode
       mu-law speech
  CID: 18
       LENGTH: 03
       Channel Selection Info: As Indicated in Following Octets
       D-Channel Indicator: D-Channel NOT indicated
       Preferred/Exclusive: Exclusive
       Interface type = primary rate
       Interface Identifier: IID Implicitly Identified
       Channel Type: B - Channel Units (3).
       Number Map: Channel is indicated by the number following.
       Coding Standard: CCITT
       Channel Number = 18
  CDN: unknown
       unknown
       8095611096

==> 05:10:16:30.26   (CM Time: 26:12:41:42.34).
==> Q931: CALL PROC: to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,02 80
  CID: 18
       LENGTH: 03
       Channel Selection Info: As Indicated in Following Octets
       D-Channel Indicator: D-Channel NOT indicated
       Preferred/Exclusive: Exclusive
       Interface type = primary rate
       Interface Identifier: IID Implicitly Identified
       Channel Type: B - Channel Units (3).
       Number Map: Channel is indicated by the number following.
       Coding Standard: CCITT
       Channel Number = 18

==> 05:10:16:31.04   (CM Time: 26:12:41:43.12).
==> Q931: ALERT:     to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,02 80
  PI:  user
       in_band_info_or_pattern_now_avail

<== 05:10:17:26.26   (CM Time: 26:12:42:38.34).
<== Q931: DISC:      from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,02 80
  CSE: user
       normal_call_clearing

Note the both "unknown" values besides the CDN?

Tim wrote:

Also note that in order to use the Transfer step to activate 2B-transfer, you will have to know the "call reference number" of the other port. This number is available as long as a port connected in a call, and you can retrieve it by using the @SYS_CALLREF system variable.

You lost me here... Where do I need to specify that value and when?

Is there a way to verify that the Place Call step is actually using/sending these values to the telco?

How can I specify these values when testing manually with NMS's ctatest.exe progam?

Thanks for your support.

Tim · **Posted:** Tue Oct 07, 2008 4:30 pm

Hi Fabio:

Lets start with the easiest stuff to check first and see where that gets us. The first possibility is that your TFDesigner is new enough to have those fields, but TFServer is not. Please download the latest and greatest server files from this link:

http://www.engenic.com/library/TFServerPatch2008-0626.zip

Un-zip the patch into your C:\Program Files\TeleFlow\ folder, overwriting any files that already exist.

Next, check the TeleFlow log file for the port in question and make sure the values are being set with the Place Call step. You should see output similar (but not necessarily the same as) the following:

...
2008/10/07 16:24:24.719: Calling Number Plan: 0x0
2008/10/07 16:24:24.719: N_PLAN_ISDN: 0x1
2008/10/07 16:24:24.719: Calling Number Type: 0x0
2008/10/07 16:24:24.719: N_TYPE_NATIONAL: 0x2
...

Try that and let me know what happens.

Tim · **Posted:** Tue Oct 07, 2008 5:05 pm

In order to perform a "2 bearer transfer" in TeleFlow, you need to use the Transfer Call step. This step works similar to the Switch Call step, with two distinct differences:

1. You have to reference the other port via its "call reference number" (explained below) instead of its @PORT number.

2. The transfer request is sent to the telco, and the result of the transfer will be that both ports receive a hangup signal from the telco.

"Call Reference Number" is a value that is set by the telco's switch equipment. They assign the reference number, and TeleFlow collects it behind the scenes, whenever it receives or places a call on ISDN. The number is automatically populated in the @SYS_CALLREF system variable.

The tricky bit is that in order to perform a 2B-Transfer, the call reference number you need is the one for the OTHER port, ie: the one that is not executing the Transfer Call step. And so, in this phase of your example:

Quote:

1. Customer in channel X asks for call center attention from application A, which issues a request to application B

"Application A" has to pass its @SYS_CALLREF value to "Application B".

Perhaps an example would help: http://www.engenic.com/temp/2BTransfer.zip

This demo app is a variation on the "Transfer Demo 2" application that is included with TeleFlow. The in-bound side passes its @SYS_CALLREF into the "swipool" table. The out-bound side retrieve that value into an application variable @REQCALLREF, and uses it in the Transfer Call step.

Have a look, and see if that clears things up for you. Feel free to post more questions if not.

fesquivel · **Posted:** Tue Oct 21, 2008 10:00 am

I'm having a really hard time trying to convice the telco (T1 provider) that I'm actually sending the so-called "missing parameters". I updated the TeleFlow Server with the one you suggest and checked for the @SYS_CALLREF variable in the channel that receives the incoming call... this variable is null ('') upon hook up. I know they should assign a value to that so I can perform the 2B-Transfer, but that's another fight I have to hold later...

From what I understand, they manage two different sets of records in their T1, one for the "calling number" (the channel which receives the incoming call) and one for the "called number" (the channel which performs an outbound call).

Then, each record contains the plan, the type and the telephone number itself. For the incoming call they name these values as the "calling number plan", the "calling number type" and the "caller ID". For the channel which performs the outbound call they name these values as the "called number plan", the "called number type" and the "called number" itself.

They insist the "called number" record has no "number plan" nor "number type" (as shown below, on the "CDN" line).

Look a their e-mail:

Quote:

De: Guillermo Bussi,TRI [mailto:gbussi@tricom.com.do]
Enviado el: Tuesday, October 21, 2008 8:29 AM

Los valores que no nos están llegando son en el CALLED NUMBER, no en el CALLING NUMBER. Todo lo que Fabio resalta que está enviando es en el CALLING NUMBER.

Este es el trace de Fabio:

That means:
"The values we are not receiving are in the CALLED NUMBER [record], not in the CALLING NUMBER [record]. Everything Fabio highlights are in the CALLING NUMBER [record]".

This is Fabio's trace:".

Quote:

Code:

2008/10/09 11:17:53.578:        ISDN Calling Number Plan is 'ISDN'
2008/10/09 11:17:53.578:        ISDN Calling Number Type is 'NATIONAL'

2008/10/09 11:17:53.578:           @@@ DEBUG:
2008/10/09 11:17:53.578:           Calling Number Plan: 0x1
2008/10/09 11:17:53.578:               N_PLAN_ISDN:     0x1
2008/10/09 11:17:53.578:           Calling Number Type: 0x2
2008/10/09 11:17:53.578:               N_TYPE_NATIONAL: 0x2
2008/10/09 11:17:53.578:           @@@ END

Este es el trace de TRICOM:

Code:

<== Q931: SETUP:     from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,01 00
  BC:  speech
       64 kbit/s
       circuit mode
       mu-law speech
  CID: 18
       LENGTH: 03
       Channel Selection Info: As Indicated in Following Octets
       D-Channel Indicator: D-Channel NOT indicated
       Preferred/Exclusive: Exclusive
       Interface type = primary rate
       Interface Identifier: IID Implicitly Identified
       Channel Type: B - Channel Units (3).
       Number Map: Channel is indicated by the number following.
       Coding Standard: CCITT
       Channel Number = 19

This is the part where they say the missing parameters ("unknown" values) are in the "called number" record:

Quote:

Code:

  CDN: unknown                 Esto es CALLED NUMBER, no CALLING NUMBER
       unknown
       01150688431712

==> 04:08:54:37.83   (CM Time: 09:11:19:05.04).
==> Q931: CALL PROC: to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,01 00
  CID: 18
       LENGTH: 03
       Channel Selection Info: As Indicated in Following Octets
       D-Channel Indicator: D-Channel NOT indicated
       Preferred/Exclusive: Exclusive
       Interface type = primary rate
       Interface Identifier: IID Implicitly Identified
       Channel Type: B - Channel Units (3).
       Number Map: Channel is indicated by the number following.
       Coding Standard: CCITT
       Channel Number = 19

==> 04:08:54:43.11   (CM Time: 09:11:19:10.32).
==> Q931: ALERT:     to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,01 00
  PI:  user
       in_band_info_or_pattern_now_avail

==> 04:08:54:48.80   (CM Time: 09:11:19:16.01).
==> Q931: CONN:      to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,01 00

<== 04:08:54:48.83   (CM Time: 09:11:19:16.04).
<== Q931: CONN ACK:  from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,01 00

<== 04:08:54:48.83   (CM Time: 09:11:19:16.04).
<== Q931: FACILITY:  from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,01 00

==> 04:08:55:29.02   (CM Time: 09:11:19:56.23).
==> Q931: DISC:      to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,01 00
  CSE: user
       normal_call_clearing

<== 04:08:55:29.09   (CM Time: 09:11:19:56.30).
<== Q931: REL:       from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,01 00
  CSE: user
       normal_call_clearing

==> 04:08:55:29.09   (CM Time: 09:11:19:56.30).
==> Q931: REL COM:   to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,01 00
>

My logs clearly show that I'm sending the 0x1 & 0x2 values for these parameters when executing the Place Call step... I don't know why they aren't receiving these values!

When they study my logs they seem to confuse the "calling number plan" with the "number plan" present in what they name the "calling number" record, though the log refers to the "outbound channel's calling number plan". Right?

Same confusion persists with the "calling number type" which refers to the parameter used in the channel which performs the outbound call, not to the channel that receives the call...

I had tried to explain this to them, to no avail... Any suggestions?

Tim · **Posted:** Tue Oct 21, 2008 6:52 pm

When placing a call on ISDN, you are supposed to be able to set the extended parameters for Calling Number (that is the number you are calling from), and the Called Number (that is the number you are trying to reach).

TeleFlow only allows you to set the Calling Number parameters, because that's all we've ever had to do. In fact, of all the installations I've done (and there's been quite a few), I've only had to set it in two instances.

Since they aren't explicitly set, the Called Number parameters will be defaulted to 0x0, which translates to "unknown".

I think this explains the difficulties. Of course, there could still be further confusion.

I can't effect a TFDesigner change at present, but I can probably get you a patch that will hard-code the Called parameters to the desired setting. I will see what I can do, and follow up with another post.

Tim · **Posted:** Tue Oct 21, 2008 8:30 pm

Fabio:

Here's that test build:

TFCalledNumber.zip

Be sure to backup your Program Files\TeleFlow folder before you unzip it!
Let me know if this satisfies your telco's requirements. If it does, we have to look at getting this made into a permanent fix.

fesquivel · **Posted:** Tue Oct 21, 2008 8:50 pm

Thanks a lot, Tim!

I'll test it tomorrow first time in the morning and let you know the results.

fesquivel · **Posted:** Wed Oct 22, 2008 12:31 pm

Ok, I updated the binaries (backup made, don't worry), but I got another problem...

Tim wrote:

Also note that in order to use the Transfer step to activate 2B-transfer, you will have to know the "call reference number" of the other port. This number is available as long as a port connected in a call, and you can retrieve it by using the @SYS_CALLREF system variable.

The telco says, literally, that they don't know what the heck is a "call reference number"; therefore, they don't know how to set it or use it during 2B-Transfers...

Given that I now check the value of @SYS_CALLREF to see if I get something upon answering the incoming call, and the fact that its value is null (''), I avoid performing the Place Call+Transfer sequence without having that value at hand first.

Is the "call reference number" known by another name? How can I tell the telco where and how to set and use that value during 2B-Transfers?

I already asked them the brand/model/specs & configuration parameters of the equipment controlling and providing the T1 connection, in case any of these is useful for anything...

Thanks for your support.

Tim · **Posted:** Wed Oct 22, 2008 5:15 pm

Can you verify if the telco is at least satisfied with the Called change?

I'll look into that "call reference number" and see if it goes by any other name. Will post again tomorrow.

Tim · **Posted:** Fri Oct 24, 2008 12:59 pm

Call Reference Value / CRV

"A number carried in all Q.931 (I.451) messages, providing a local identifier for a given ISDN call. Also called Call Reference Number"
Source: Newton's Telecom Dictionary, 17th Edition, by Harry Newton, ISBN 1-57820-069-5

Tim · **Posted:** Fri Oct 24, 2008 2:33 pm

According to NMS ISDN for Natural Call Control Developer's Manual, the "callreference" value is only available under the NI2 protocol variant. I know you said they were providing NI2, but it could be DMS. The two protocols are very similar. In fact, NI2 is built on top of DMS. You could get them to double check that the protocol variant is correct.

Tim · **Posted:** Fri Oct 24, 2008 2:52 pm

I should clarify the above. This would appear to be an NMS restriction, not part of the ISDN specifications generally. Still a good idea to double-check that protocol.

Also... in Dialogic parlance, they used the acronym: CRN for call reference number.

fesquivel · **Posted:** Fri Oct 24, 2008 3:08 pm

I just sent all of this to them, let's hope they can come up with the CRV!

I still have pending a test with them to see if the other values do come to them during the Place Call step execution. I'll post any progress about it.

Thanks a lot for your help.

fesquivel · **Posted:** Mon Oct 27, 2008 4:21 pm

Still expecting to perform a controlled test to see if the values finally come to the T1 provider...

I was searching a little more information on the call reference value and found this link to be useful: http://www.itu.int/rec/T-REC-Q.931-199805-I/en

Item 4.3 details what is the CRV and how to use it. I just sent the provider this link and some text extracts about it. Still, no answer from them...

fesquivel · **Posted:** Mon Nov 03, 2008 1:34 pm

Ok, got good news and bad news...

Good ones first: The T1 provider confirms reception of the hard-coded values, so you may proceed with the UI programming in the Place Call step, so as to fill the "called number" register instead of the "calling number" register.

Bad news: They still have no clue about the CRV! I even gave them the URL for the spanish version of the UIT recommendation Q.931 and mentioned item 4.3 where the CRV is clearly defined.

They just sent me their logs... Can you spot the CRV for the initiating call in (809) 476-4520? Could it be the "CR" line mentioned several times in the log?

Code:

==> 03:10:56:49.37   (CM Time: 29:13:04:20.71).
==> Q931: SETUP:     to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,03 DE
  BC:  speech
       64 kbit/s
       circuit mode
       mu-law speech
  CID: 18
       LENGTH: 03
       Channel Selection Info: As Indicated in Following Octets
       D-Channel Indicator: D-Channel NOT indicated
       Preferred/Exclusive: Exclusive
       Interface type = primary rate
       Interface Identifier: IID Implicitly Identified
       Channel Type: B - Channel Units (3).
       Number Map: Channel is indicated by the number following.
       Coding Standard: CCITT
       Channel Number = 1
  PI:  public_network_serving_local_user
       origination_address_is_non_ISDN
  CGN: e164
       national_number
       network_provided
       presentation_allowed
       8094764520
  CDN: e164
       national_number
       8093386006

<== 03:10:56:49.40   (CM Time: 29:13:04:20.74).
<== Q931: CALL PROC: from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,03 DE
  CID: 18
       LENGTH: 03
       Channel Selection Info: As Indicated in Following Octets
       D-Channel Indicator: D-Channel NOT indicated
       Preferred/Exclusive: Exclusive
       Interface type = primary rate
       Interface Identifier: IID Implicitly Identified
       Channel Type: B - Channel Units (3).
       Number Map: Channel is indicated by the number following.
       Coding Standard: CCITT
       Channel Number = 1

<== 03:10:56:49.40   (CM Time: 29:13:04:20.74).
<== Q931: ALERT:     from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,03 DE

<== 03:10:56:49.42   (CM Time: 29:13:04:20.76).
<== Q931: CONN:      from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,03 DE

==> 03:10:56:49.42   (CM Time: 29:13:04:20.76).
==> Q931: CONN ACK:  to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,03 DE

<== 03:10:57:02.06   (CM Time: 29:13:04:33.40).
<== Q931: SETUP:     from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,01 70
  BC:  speech
       64 kbit/s
       circuit mode
       mu-law speech
  CID: 18
       LENGTH: 03
       Channel Selection Info: As Indicated in Following Octets
       D-Channel Indicator: D-Channel NOT indicated
       Preferred/Exclusive: Exclusive
       Interface type = primary rate
       Interface Identifier: IID Implicitly Identified
       Channel Type: B - Channel Units (3).
       Number Map: Channel is indicated by the number following.
       Coding Standard: CCITT
       Channel Number = 20
  CDN: e164
       national_number
       8099872626

==> 03:10:57:02.10   (CM Time: 29:13:04:33.44).
==> Q931: CALL PROC: to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,01 70
  CID: 18
       LENGTH: 03
       Channel Selection Info: As Indicated in Following Octets
       D-Channel Indicator: D-Channel NOT indicated
       Preferred/Exclusive: Exclusive
       Interface type = primary rate
       Interface Identifier: IID Implicitly Identified
       Channel Type: B - Channel Units (3).
       Number Map: Channel is indicated by the number following.
       Coding Standard: CCITT
       Channel Number = 20

==> 03:10:57:02.58   (CM Time: 29:13:04:33.92).
==> Q931: ALERT:     to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,01 70
  PI:  user
       in_band_info_or_pattern_now_avail

==> 03:10:57:10.95   (CM Time: 29:13:04:42.29).
==> Q931: CONN:      to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,01 70

<== 03:10:57:11.00   (CM Time: 29:13:04:42.34).
<== Q931: CONN ACK:  from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,01 70

<== 03:10:57:11.00   (CM Time: 29:13:04:42.34).
<== Q931: DISC:      from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,01 70
  CSE: user
       normal_call_clearing

==> 03:10:57:11.21   (CM Time: 29:13:04:42.55).
==> Q931: REL:       to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,01 70

<== 03:10:57:11.26   (CM Time: 29:13:04:42.60).
<== Q931: REL COM:   from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,01 70

==> 03:11:10:55.25   (CM Time: 29:13:18:26.59).
==> Q931: DISC:      to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,03 DE
  CSE: user
       normal_call_clearing

<== 03:11:10:55.30   (CM Time: 29:13:18:26.64).
<== Q931: REL:       from S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  1,03 DE
  CSE: user
       normal_call_clearing

==> 03:11:10:55.30   (CM Time: 29:13:18:26.64).
==> Q931: REL COM:   to S[7054] L[1,58,0] E[405,57,0] SPA[----]
  CR:  0,03 DE

==> 03:12:13:58.21   (CM Time: 29:14:21:29.79).

Tim · **Posted:** Mon Nov 03, 2008 4:20 pm

I don't know what the 'CR' is in their trace. It doesn't look like a CRV because it seems there are 3 numbers listed there, eg "0,03 DE". Maybe you could ask them what that line means? Otherwise, I don't see anything that looks like the CRV in that output.

I think its time to investigate whether or not you have to protocol variant you need. As per my previous post:

Quote:

According to NMS ISDN for Natural Call Control Developer's Manual, the "callreference" value is only available under the NI2 protocol variant. I know you said they were providing NI2, but it could be DMS. The two protocols are very similar. In fact, NI2 is built on top of DMS. You could get them to double check that the protocol variant is correct.

Is there any way you can get them to verify that the protocol variant is truly NI2, and not a version of DMS?

Something else I'd like you to try:
In your CG 6060 configuration file, it is probably loading the general ISDN module. Can you change that to instead load the specific NI2 module?

Change:

Code:

DLMFiles[1] = isdngen

to

Code:

DLMFiles[1] = isdnni2

I always use the specific protocol I want. It *should* make no difference at all. Then again, I am getting call reference and you are not, so it is worth a try.

While you're at it, it may help if you sent me a log of one of your applications performing the Place Call. Email to "support" AT "engenic.com". This is a real long-shot, but maybe I will see something in it that will help.

fesquivel · **Posted:** Thu Nov 13, 2008 11:41 am

I just got the confirmation from the telco about NI2: They are using it, they insist.

However, when I press about the CRV, they later confuse me with this answer:

Quote:

Según lo conversado, los modelos de nuestras centrales son:
- DMS-100 de Nortel
- Softswitch METASWITCH class 4/5 V 6.0

That is, "the models of our [PBX]s are:
- DMS-100 from Nortel
- Softswitch METASWITCH class 4/5 v6.0"

I don't care what kind of PBX they use as long as I get an ISDN T1 PRI in NI2 and the CRV on the incoming calls!

Anyway, about the DLM file configuration, I use "cg6060igen". I just changed that to "isdnni2" and restarted, but the board fails to boot:

Code:

oamcfg -s
Starting all boards.

Thu Nov 13 14:27:46 - OAMEVN_ALERT INFO Board 0 "Name0"
12:1 - log cg6x6x boot info to file e:\drivers\NMS\OAM\log\CG_6060boot_12_1.txt

Thu Nov 13 14:27:47 - OAMEVN_ALERT INFO Board 0 "Name0"
Writing at SDRAM 0x7ce4bc0 for 1417832 bytes ...

Thu Nov 13 14:27:51 - OAMEVN_ALERT ERROR Board 0 "Name0"
 EXEC_DLM_LOAD_MODULE failed with error code 0x6033
Thu Nov 13 14:27:51 - OAMEVN_ALERT ERROR Board 0 "Name0"
ELFLNK_ERR_WRONG_CPU
Thu Nov 13 14:27:51 - OAMEVN_ALERT ERROR "cg6kpi.bpi"
Cannot start board Name0 - failed to configure board
Thu Nov 13 14:27:51 - CLKEVN_CONFIG_FAILED ERROR Board 0 "Name0"
CLKMGR.EMC: Board fail to Boot

Thu Nov 13 14:27:51 - OAMEVN_STARTBOARD_DONE OAM_REASON_FAILED ERROR Board 0 "Name0"
Failed to start board.

... so I'm back to "c6060igen".

Finally, I'm observing some TeleFlow failures on the Application Event Log in Windows... This is from before I installed the patch you sent me for the "called number" parameters:

Quote:

Faulting application TFServer.exe, version 2008.6.26.0, faulting module borlndmm.dll, version 6.0.6.163, fault address 0x0000433e.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

... and this is the current error:

Quote:

Faulting application TFServer.exe, version 2008.10.10.0, faulting module borlndmm.dll, version 6.0.6.163, fault address 0x0000433e.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Sometimes I have to manually restart the TeleFlow service several times until it stays there (monitoring with the TeleFlow Monitor)... any ideas?

Tim · **Posted:** Fri Nov 14, 2008 1:23 pm

That's funny; isdnni2 works on a CG6000, but not on a 6060. I just tried it and got the same result as you. Sorry about that.

That is a confusing answer. The "DMS 100" protocol is older than the NI2 protocol, but that is not the same thing as a DMS 100 PBX or switch, which could well be capable of producing the NI2 protocol. NI2 was derived from DMS 100, so that would make sense.

I hate to harp on this point, since your telco is insistent. I have had similar problems with TeleFlow when the ISDN variants dont match. In my case, it was an NI2 configuration of a CG6060 against a 5ESS switch (which you wouldn't expect to work).

Try this, then. Change the parameters of the ISDNCTA command you are running background to DMS100. Replace the "-o20" (NI2) with "-o8" (Northern Telecom DMS100). The complete command string would look like so:

Code:

isdncta -b0 -a0 -o8 -c1

You'll have to repeat that for any additional trunks you have.

Run that and see if TFServer is better behaved, and/or if you're getting the CRV now.