Missing parameters when transfering calls between channels

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

If that doesn't work, also try "-o88", which is "Northern Telecom DMS250"

Code:

isdncta -b0 -a0 -o88 -c1

fesquivel · **Posted:** Fri Nov 14, 2008 4:37 pm

By configuring DMS100 or DMS250, will I be able to perform 2B-transfers with the CRV or should I then use the port number in the Transfer step? I already insisted to them that by using DMS the CRV cannot be sent... Am I wrong?

BTW, is there another way to perform a call transfer similar to the 2B-transfer without the CRV? The telco engineers are really baffled about the CRV (they genuinely ignore what the heck that is!).

Tim · **Posted:** Fri Nov 14, 2008 6:55 pm

You're not wrong. This is just a test, to see what (if any) difference it makes.
CRV is a part of the Q.931 specification, upon which all ISDN is (supposedly) built.

I'd like you to try the DMS 100 and DMS 250 just to see if TFServer will be stable again, and if you can actually get the CRV via Place Call or Wait For Call. I'm not completely sure what that would tell us, but it could be that the circuit simply isn't NI2.

But, you're quite right. According to the NMS documentation, 2B-Transfer is only supported on the NI2 protocol variant

There are other options... Every variant does things a little differently, and only some of them support "transfer" features. Unfortunately, not all are supported by NMS, and only one is currently supported by TeleFlow (the 2B one).

I know you didn't want to do this, but... as a stop-gap measure, you could use the Switch step to connect the two ports together. I still think we should try this DMS100/250 test.

Hope this clarifies things a bit better.

fesquivel · **Posted:** Wed Nov 19, 2008 8:30 am

Tim wrote:

[...]
I'd like you to try the DMS 100 and DMS 250 just to see if TFServer will be stable again, and if you can actually get the CRV via Place Call or Wait For Call. I'm not completely sure what that would tell us, but it could be that the circuit simply isn't NI2.

[...]
I know you didn't want to do this, but... as a stop-gap measure, you could use the Switch step to connect the two ports together. I still think we should try this DMS100/250 test.

Hope this clarifies things a bit better.

Actually no:

How do I specify DMS100 in the NMS configuration file? I can only specify the T1 Type, the Impedance (DSX1), the LineCode (B8ZS), the FrameType (ESF), the SignalingType (PRI) and the D_Channel code ISDN... Where do I specify the use of the NI2 protocol variant? Or is it a telco-only configuration parameter?
If I tell the telco to use DMS100, how do I specify the use of DMS100 as well?

Nevermind: I just re-read your above posts about configuring with the ISDNCTA (I just temporarily forgot it's done that way, sorry).
And most important: Once settled on DMS100, should I use the channel number (of the incoming customer call) on the Transfer Step, or should I expect to get the CRV in the @SYS_CALLREF and use it instead?
If I should expect and use the CRV, should I invoke something or specify some special property in the Wait For Call step to get it into the @SYS_CALLREF? Currently I only see the "Setting system variable '@SYS_CALLREF' to ''" line in my logs, but I'm not sure if I should get it from somewhere else...
Finally, I've been studying the ITU-T Q.931 Recommendation on this issue and I noticed the CRV is the second element of every message; item 4.1 says the CRV is "common to all the messages and shall always be present"... there is no mention of the NI2 protocol variant so as to make the CRV's presence, dependant on the protocol variant. Actually, the caller ID number is an optional information element in the message! How come I get the optional caller ID value but not the CRV which should always be present (as part of the message header, apparently)?

Thanks for your support.

Tim · **Posted:** Thu Nov 20, 2008 11:32 am

I should clarify here. I'm not expecting this latest round of test will get the transfer working. I believe that your telco has not provided you with NI2. This could prove that, but that is the most you can hope for.

Quote:

Once settled on DMS100, should I use the channel number (of the incoming customer call) on the Transfer Step, or should I expect to get the CRV in the @SYS_CALLREF and use it instead?

Neither. The Transfer Step only works with the CRV, and only on NI2.

Quote:

If I should expect and use the CRV, should I invoke something or specify some special property in the Wait For Call step to get it into the @SYS_CALLREF? Currently I only see the "Setting system variable '@SYS_CALLREF' to ''" line in my logs, but I'm not sure if I should get it from somewhere else...

There is no other way to get that value. It is automatically populated by the Wait For Call step or the Place Call step. Out of curiosity, what do you see @SYS_CALLREF set to on the Place Call side?

Your interpretation of the Q.931 Recommendation is correct. The CRV should always be present on all calls, but what recommendations say and what manufacturers build are often different. For NMS's part in this, they only make the CRV available through their API on the NI2 protocol variant (source: NMS ISDN for Natural Call Control Developer's Manual, pg.57-58). I guess they felt that application developers would only need it for 2B-Transfer, which is only available on NI2. Caller ID (or ANI) is a very popular feature, and so the switch manufacturers almost always include that feature. But, I have had problems getting ANI in the past. In the "old days", Nortel used to charge $15,000 for that option.

I wish I had a better answer for you, but short of proving that your protocol variants are a match on both sides, I don't have any other suggestions. I would love it if someone could point out where the CRV is in telco's trace. But, since they don't know what a CRV is, that's not going to happen.

Tim · **Posted:** Thu Nov 20, 2008 12:05 pm

Sent you a private message.

fesquivel · **Posted:** Thu Nov 20, 2008 12:48 pm

Thanks, Tim... It's all clear for me now.

Yesterday I told the telco that we don't think their logs show the CRV anywhere and that the CR line in particular does not seem like it either. I'm still expecting their answer about it, but I feel like in a dead-end

Tim wrote:

Out of curiosity, what do you see @SYS_CALLREF set to on the Place Call side?

To satisfy your curiosity:

Code:

[265] Place Call
   Telephone Number '@pPrimary' evaluates to '18095018747'
   Rings before TIMEOUT is '10'
   Do not capture answering voice length to TeleFlow variable
   Silence timeout is ''
   Empty Silence timeout defaults to none
   Maximum voice length timeout is ''
   Empty Maximum voice length timeout defaults to none
   ISDN Calling Number Plan is 'ISDN'
   ISDN Calling Number Type is 'NATIONAL'
   Place call to 18095018747
   and wait for up to 10 rings
   Do not connect on CED
   Connect on SIT
   Do not perform initial voice length detection.
   Open port 20
      Board: 0 stream: 0 slot: 19
   NMS Services:
      0. NCC, ADIMGR, 0, 0:19, 15
      1. ADI, ADIMGR, 0, 0:19, 15
      2. SWI, SWIMGR, 0, 0:19, 15
      3. VCE, VCEMGR, 0, 0:19, 15
      Event: CTAEVN_OPEN_SERVICES_DONE, Finished  
   Using 'isd0' protocol...
   Echo canceller not started
      Event: NCCEVN_START_PROTOCOL_DONE, CTA_REASON_FINISHED
      @@@ DEBUG:
      Calling Number Plan: 0x1
          N_PLAN_ISDN:     0x1
      Calling Number Type: 0x2
          N_TYPE_NATIONAL: 0x2
      Called Number Plan: 0x1
      Called Number Type: 0x2
      @@@ END
      Event: NCCEVN_PLACING_CALL
      Event: NCCEVN_CALL_PROCEEDING
      Event: NCCEVN_EXTENDED_CALL_STATUS_UPDATE, NCC_X_STATUS_INFO_PROGRESSDESCR
    u-Event: NCCEVN_EXTENDED_CALL_STATUS_UPDATE, NCC_X_STATUS_INFO_PROGRESSDESCR
      Event: NCCEVN_EXTENDED_CALL_STATUS_UPDATE, NCC_X_STATUS_INFO_PROGRESSDESCR
    u-Event: NCCEVN_EXTENDED_CALL_STATUS_UPDATE, NCC_X_STATUS_INFO_PROGRESSDESCR
      Event: NCCEVN_EXTENDED_CALL_STATUS_UPDATE, NCC_X_STATUS_INFO_PROGRESSDESCR
    u-Event: NCCEVN_EXTENDED_CALL_STATUS_UPDATE, NCC_X_STATUS_INFO_PROGRESSDESCR
      Event: NCCEVN_EXTENDED_CALL_STATUS_UPDATE, NCC_X_STATUS_INFO_PROGRESSDESCR
    u-Event: NCCEVN_EXTENDED_CALL_STATUS_UPDATE, NCC_X_STATUS_INFO_PROGRESSDESCR
      Event: NCCEVN_CALL_CONNECTED, NCC_CON_SIGNAL
   Setting system variable '@CALLOUT_RESULT' to 'CONNECT'
   Setting system variable '@CALLOUT_REASON' to 'CONNECT'
   Setting system variable '@SYS_CALLREF' to ''

You see, it's just null (''), just like the one set by the Wait For Call step when an incoming call is answered.

fesquivel · **Posted:** Fri Nov 21, 2008 10:16 am

Ok, finally the telco answered back.

They insist that the "0,03 DE" is the CRV. Well, actually, that the 0xDE value is the CRV.

I was studying the ITU-T Recommendation document on http://www.itu.int/rec/T-REC-Q.931-199805-I/en to see how may I interpret that string.

Based on "Figure 4-3/Q.931 - Call reference information element" (page 49) and the examples on page 50, what if "0,03 DE" means:

"0" are bits 8..5, first octect
"03" are bits 4..1 first octect, stating the use of 3 more octects (excluding this one which is meant to indicate the number of octects used for the CRV)
First octect, all zeroes, including the flag 0 in bit 8 (incoming CRV given by the PBX which administers the T1)
Second octet, all zeroes
Third octet, 0xDE == 11011110, the CRV itself

Does that make sense at all?

If so, why I'm not getting the 0xDE as the CRV? Might be because TeleFlow "assumes" it's just one octect (besides the first one), taking thus the First octect (all zeroes) and setting the null value to the @SYS_CALLREF?

If so, should TeleFlow be fixed to correctly interpret the number of octects or should/can the telco specify the use of just one octect so TeleFlow can get that value right away?

fesquivel · **Posted:** Mon Nov 24, 2008 3:49 pm

Here refining my assumption about what the telco says is the CRV...

Studying the telco's log, I found other values for CR like "1,03 DE", "0,03 DE", "1,01 70"...

What if the first digit is actually the flag's value? So, "1" would indicate the CRV is being sent to the T1 in a Place Call step, for example...

Thus, "03" or "01" would still tell the number of octects conforming the CRV and the hexadecimal value should then be interpreted as this:

"01 70" == 01110000
"03 DE" == 00000000 00000000 11011110

If that makes sense, my guess is that TeleFlow assumes the CRV is given in just one octect, so for the tests where I get "0,03 DE" TeleFlow gets only the first octect (the one in bold)...

Tim · **Posted:** Mon Nov 24, 2008 6:57 pm

I worked on this on Friday in order to free an NMS CG 6060 board from active duty to run some tests on it. With that card, I can't get the Call Reference either. Today, I've built some debug statements into TeleFlow server and am conducting more tests.

Your interpretation is entirely possible. Although, at this point I am confused as to why TeleFlow can get the CRV when the same build is running against an NMS AG 4040 or CG 6000, but not a CG 6060.