Hey all. I installed a Zultys MX 250 and connected it via T1 to an old Executone IDS. I can call between the two system with no issue. The problem is when a call comes in on a PRI into the EXECUTONE and I transfer it to an extension in Zultys, Zultys drops the call.
In SYSLOG it shows the call as failure "not found;calling party - ids_Tie;called party-; "
Where am i going wrong ?

Don't know if I can help but let me get this straight in my head first.
Executone system had a Regular T1 card in it and you connected that T1 to
the other system? Also how is that set up Line Type on and T1 Type in the B-Screen.

Also you have a PRI card in the Executone system and call come into it and then user
attempts to transfer the call over the Tie (T1) line to the other system and it disconnects.

But extension calls to the other system over the Tie (T1) works it just does not keep the
PRI call connected after transfer.

Close....... The T-1 is set up as Line Type 1 T1 Type TIE. I can dial from an executone set to the Zultys, via Transparent Intercom dialing, over this tie line and get answered by the Auto Attendant in the Zultys.This works fine.
I can dial from my Zultys phone to an Executone extension over the PRI and talk to anyone on the Executone. This works fine.

The problem i am having is when i attempt to transfer a call from Executone to Zultys. The call follows the Y-C screen, hops on the same T1 channel as when i call it, but the Zultys does not see any digits.
If i transfer a call from one Executone system over T-1 to another Executone System i can see 3 digits being passed in Ctrl-C. Those digits do not seem to be getting to the Zultys.

So I can get this straight in my head:

E-System T1 card >>>> to other E-Sys T1 card ICM call and transfer of CO calls work.

E-System T1 card >>>> to Zultys-System (PRI) card ICM calls works both ways but unable to transfer CO call from E-Sys and you are not seeing digits in Ctrl-C (J) screen (Which I'm not sure if you will
see outgoing digits but yes you should see incoming)

E-System to E-System are T1 >>> ~ <<< to T1 (cards in E-Systems) ICM works and Transfer of CO calls work. Also what type of lines are the CO calls coming in on.

E-System to Zultys are T1>>> ~ <<< to PRI (In Zyltys) (T1 Card in E-Systems) ICM works and Transfer of CO calls fail. (Does transfer of CO calls from the Zyltys to E-System work?) (Just not from E-System to Z)
Also what type of lines are the CO calls coming in on.

so, I'm " thinking " well, trying to remember, You May ..have to load a Dummy LCR into the executone system and then do " something " ( That part I can not remember)

How is your Transparent Intercom Dialing set up. Do you have the Tie lines in different trunk groups.
Some going to the IDS and others going to the Z system

Executone A - T-1 in Trunk group 10 direct to - Executone B - T-1 This has been installed for 3 years and works flawlessly

Executione A - T-1 in TG 9 direct to - - Zultys T-1. I can call from Executone to Zultys and it works fine. I cant transfer a call to Zultys. Something in the transfer sequence interferes with the completion of this. The Zultys does not see digits and doesn't know how to process the call. I used the second executone system to look at what is sent over the T-1 when transferring and all i see are the last 3 digits. That would be fine but the Zultys does not see the digits.


I have LCR in the Executone system.

OK I understand now. And it looks like the issue is with the Zultys System as the Executone System is sending the digits. It doesn't know what it is connected to and is working fine when going to another Executone system. So maybe this can help. Reminder when the incoming digits are expected on and Executone to Executone Tie Line set up each has to have DTMF sender/receiver cards in it.
I.E. A DTMF card is involved to SEE the incoming digits from the Far End System.
From what I Google on the Zultys system it is a VOIP system so it may be looking for packet info?. (Sort of like the 24 channel on a PRI in the Executone System where info is sent?)
Anyway I would suggest looking into the setup of the Zultys system and when connected to an older system, do you need extra hardware (DTMF Sender/Receiver card) that isn't present or being
told to look at things coming in on the Tie Line.

Ok.Thank you for your input....I like where you are going and I think you might be on to something. I will look into that today.

So i heard from Zultys tech support. The problem lies in the transfer. Zultys sorted the CAS logs and provided some information. It seems that on the calls coming in via transfer, the Executone is prepending the call with the # character. Zultys sees # as a delimiter character, so it doesn’t recognize it as coming through correctly, and ends the call. Is there a way to eliminate the # when calls are transferred over this tie line ?`

Is there maybe a d-Bug routine that could accomplish this ?

Do You have access to any of the " old " info on what each Type of COS on the Tie lines did...as I remember ( and it's been a Long time ago) that there were some differences of what each type of line could do.?

I have info on the COS for the Lines but think it would be more on the line type will check after work today and get back to you
The issue with doing that it may cause issues with the calls going to the Executone system then. And yes I remember it does send
a # for the transfer of calls between systems

OK here you go this will remove the # from the dialing: You access the Maintenance menu
Then go to Diagnostics menu Clt-C then N for Software Diagnostics menu:
You will then go to Tie Groups 1 section : Since the Tie Group you are using you will have to Tap over to the 9th group
Right now it reads 00 (TIE GROUPS 1 00 00 00 00 00 00 00 00 00 00) )
(To get there use the Enter key and once on Release Tie Y Hit the Tap Key) (Then Tap over to the 9th 00 Entry)
Then enter 01 to remove the # from the Transfer sequence,
(Yes it use to be a Debug) I do believe this will resolve the issue.


S/W DIAGNOSTICS MENU [C]AB 01
––––––––––––––––––––––––––––––––
SOFT RESET: 103019 102095 STK FRM:0C01 0000 00000000 005A 0000 00000000
[W]ATCH DOG: 18 18 01 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000
MAINT ON : Y [M]AINT DATA: 0000 00 00 00 00 00 00 00 00 00 00 00
01 0000 00 00 00 00 00 00 00 00 00 00 00
RELEASE TIE: Y TIE GROUPS 1 00 00 00 00 00 00 00 00 00 00
RST DISABLE: N GROUND TRUNK: N
AGNT RFRESH: 005 ALRM CLK OFF: N
TEST MODE : N SLI HOOK DEB: N
PICK ENABLE: N SLI PBX CONF: N
RCVR VOL : 13 NO_BUSY_TONE: N
T1RCVR VOL : 10 VMS 140 CODE: 4
DTMF VOL : 08 SLI RCV TIME: 60
RCRD VOL : 13 TOLL TIMEOUT: 03
PILOT ICM : N PRIME RING : 06
VMS DISCONN: N SECOND RING : 09
DIVERT VOL : 00 RELAY EXT : 0000
PRTN TIMER : 120 RELAY RATE : 000
ALARM VOL : 06 ACD TSF TIME: 019
WRAP UP OPT: N DIAL 10 : N
REL KEY DEB: N SMDI_DIAL :080

I drink Bush (Cheap) Beer Let us know if it resolves the issue.
I wouldn't change anything on the Executone trunk group you are using as it is working
IF it's NOT broke don't fix it as they say.

4.11.7 Tie Group 1 & 2
Use Tie Group 1 for Trunk Groups 1 to 10. Use Tie Group 2 for Trunk Groups 11 to 20. Use
the I and D keys to change between Tie Group 1 and Tie Group 2. Program each of the trunk
groups to be used as Release Link Tie Lines as follows:
• 01 – to remove the DTMF # on CO transfers across tie lines.
• 02 – to provide a flash on the tie line group for the programmed Flash Timer.
• 03 – to both remove the DTMF # on CO transfers across tie lines and to provide a
flash on the tie line group for the programmed Flash Timer.
• 04 – This allows the system to serve as a tandem switching system. Programming a
group for 04 allows incoming tie line calls to reference the translation tables (DID
Programming and Transparent Intercom Dialing screens) and be routed back out of the
system on another tie line group. Programming a group for 04 allows a call that was
routed of the system to be transferred back to an extension in the system. Without the
04, if a call is transferred back to the system the flash and digits would be sent to the
carrier instead of being detected as a transfer.

And YES the OLD (Retired Executone System Will DO More that other's think. What a shame it was put off to the side) Just my feelings
they had such potential and GREED knocked it out but many other future systems were developed off it's features and what it could do.

Sorry it took so long to respond but new work takes priority right now..

Great Info ! mc601 ( I Used to know what a lot of that stuff did)

Wow. Thank you so much. I was able to make that change. I knew it was capable but couldn't remember where. Now its up to the engineer at Zultys to see what the problem new is.
After changing that field to 01 i am able to transfer the call and i get answered by Zultys while in a PrTn state. Once i release the call or hang up the transferring phone the state changes to TiTr and the call still drops. I'm no longer getting the error in the ZUltys switch.

Do you have documentation on the rest of the Ctrl C N screen that you could send me ?.

Yes but you will need to send me a private message with you email address

Brian,
What's with sundance no longer being https? Non secure

Not sure what you are seeing, I'm seeing
https://sundance-communications.com/forum/....

All good now must have been some path my provider was routing me through
Tks

Good morning guys. I thought we had this figured out. Zultys is telling me that the Executone is dropping the call now. The below is fromthe Zultys call log. Im calling ext 8201 from my executone. It looks like Zultys is seeing the digits 2 0 1 starting with this line--- Dec 11 10:58:43:560. Do you guys know what this data means ?


Dec 11 10:58:42:683 - 2 - {0x20009} [147.464] [ptl_fsm] [CAS: 0/11] CAS_PTL_ST_IDLE -> CAS_PTL_ST_WINK_ON Rx 0xf
Dec 11 10:58:42:922 - 2 - {0x20009} [147.703] [ptl_fsm] [CAS: 0/11] CAS_PTL_ST_WINK_ON -> CAS_PTL_ST_WINK_OFF Rx 0xf
Dec 11 10:58:42:924 - 2 - {0x20009} [147.705] [ptl] [CAS: 0/11] Port 0 On(Ptl Notf Wink Off) state st_CC_IDLE
Dec 11 10:58:42:924 - 2 - {0x20009} [147.705] [ptl] [CAS: 0/11] Port 0 SetState: st_CC_IDLE(1) -> st_CC_WAIT_FOR_DTMF(26)
Dec 11 10:58:42:924 - 2 - {0x20009} [147.705] [cas_dsp] [CAS: 0/11] >> DSP_start_dtmf_collection
Dec 11 10:58:43:560 - 2 - {0x20009} [148.341] [cas_dsp] [CAS: 0/11] DSP:digit rx 0x32 2:
Dec 11 10:58:43:758 - 2 - {0x20009} [148.539] [cas_dsp] [CAS: 0/11] DSP:digit rx 0x30 0:
Dec 11 10:58:43:977 - 2 - {0x20009} [148.758] [cas_dsp] [CAS: 0/11] DSP:digit rx 0x31 1:
Dec 11 10:58:45:031 - 2 - {0x20009} [149.812] [ptl] [CAS: 0/11] End of Dialing
Dec 11 10:58:45:031 - 2 - {0x20009} [149.812] [ptl_fsm] [CAS: 0/11] CAS_PTL_ST_WINK_OFF -> CAS_PTL_ST_ANSWER Rx 0xf
Dec 11 10:58:45:031 - 2 - {0x20009} [149.812] [ptl] [CAS: 0/11] Port 0 On(Ptl Notf Answer) state st_CC_WAIT_FOR_DTMF
Dec 11 10:58:45:031 - 2 - {0x20009} [149.812] [ptl] [CAS: 0/11] Port 0 SetState: st_CC_WAIT_FOR_DTMF(26) -> st_CC_SETUP_AWAIT_MEDIA_TRM(6)
Dec 11 10:58:45:031 - 2 - {0x20009} [149.812] [ptl] [CAS: 0/11] media_request_frontend: port 0 ch 4107 media_status 0
Dec 11 10:58:45:040 - 2 - {0x20009} [149.821] [cas_dsp] [CAS: 0/11] DSP:media_info_rsp
Dec 11 10:58:45:040 - 2 - {0x20009} [149.821] [ptl] [CAS: 0/11] Port 0 SetState: st_CC_SETUP_AWAIT_MEDIA_TRM(6) -> st_CC_SETUP_SEND(7)

Are you transferring a call then hanging up or just trying to call and extension and wait for it to answer and it just drops the call?
The Executone is only sending 3 digits and that looks like what they are seeing.
And what the heck is the Z system mean on the entries after End of Dialing It just saw the 201
Why is it wink off and waiting for DTMF again:
Dec 11 10:58:45:031 - 2 - {0x20009} [149.812] [ptl_fsm] [CAS: 0/11] CAS_PTL_ST_WINK_OFF -> CAS_PTL_ST_ANSWER Rx 0xf
Dec 11 10:58:45:031 - 2 - {0x20009} [149.812] [ptl] [CAS: 0/11] Port 0 On(Ptl Notf Answer) state st_CC_WAIT_FOR_DTMF
Dec 11 10:58:45:031 - 2 - {0x20009} [149.812] [ptl] [CAS: 0/11] Port 0 SetState: st_CC_WAIT_FOR_DTMF(26) -> st_CC_SETUP_AWAIT_MEDIA_TRM(6)
Dec 11 10:58:45:031 - 2 - {0x20009} [149.812] [ptl] [CAS: 0/11] media_request_frontend: port 0 ch 4107 media_status 0
Dec 11 10:58:45:040 - 2 - {0x20009} [149.821] [cas_dsp] [CAS: 0/11] DSP:media_info_rsp
Dec 11 10:58:45:040 - 2 - {0x20009} [149.821] [ptl] [CAS: 0/11] Port 0 SetState: st_CC_SETUP_AWAIT_MEDIA_TRM(6) -> st_CC_SETUP_SEND(7)

Did it not like what it saw in the stream above?

Also is Release Link option activated on the Executone system?

I sent you a message about sending me Private Message with email. I can send you a manual via 2 zip files

If i call and wait for it to answer, it works fine. Auto Attendant on the Zultys answers me and i can go through the prompts and even get transfered back to another executone extension.
Im having this problem only when i transfer a call. When i hang up my executone phone to complete the transfer, the call drops.If i stay on the call and talk to the A.A. myself, the call stays up until i hang up to complete the transfer.

Well to me that seems to be the answer the Z system is waiting for you to do something after the AA answers if I'm reading this correct.
And when you hang on and go through the prompts (I guess your dialing something to respond to the AA's questions) it works fine.
Well what happens if you call and the AA answers and you don't do anything? Does it drop you? Or like the Executone system does with and AA
it waits and maybe transfers you to the extension assigned to no response? Think the AA in Voicemail (CCR) of the Executone it had 2 places
to enter wrong digits or no digits and you could either assign it to transfer the caller to and extension. Or if nothing make it hang up the call.
If the Z-System is looking for something and it doesn't see anything what is it told to do. It may see you as no caller. My other question is how
come the Z-System once it sees the digits the AA isn't sending it to the extension in it's routing list and it is waiting for more information (digits) The Executone
has already sent digits, seems like the AA is not responding correctly/or doesn't know what to do with them.


Will send you the other thing tomorrow sometime as I did get your PM

I got it working. MC601, Did you know there is an option 05 in the Tie Line group programming ? Me either. Try it. Thats what worked here. Im not sure what exactly it does to the line, but it worked.

Hmm, That is what I was thinking...Glad you got it working ! Those Old IDS's could do just about Everything !

Did you mean Type 5 Here is what it does
Line Type 5
This Line Type is used with tie lines or T1. This line type is used when the need for a wink on
incoming calls, and a wink on outgoing calls is required.

Nope. I changed the CTRL C - N screen under Tie Groups. I changed my Tie group 8 to 05. The manual lists options 1 thru 4. I made it 05 and it worked. I changed it back to 01 and it stopped working. I left it at 05 and it works.

OFT RESET: 103019 102095 STK FRM:0C01 0000 00000000 005A 0000 00000000
[W]ATCH DOG: 18 18 01 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000
MAINT ON : Y [M]AINT DATA: 0000 00 00 00 00 00 00 00 00 00 00 00
01 0000 00 00 00 00 00 00 00 00 00 00 00
RELEASE TIE: Y TIE GROUPS 1 00 00 00 00 00 00 00 00 00 00

Well glad to see it is fixed. It does seem like I remember reading some tech fact (In World and Time LONG AGO) about more options>>>>> Even looked for it for a little while last night. It is going to bug me to no end now! But couldn't find it. So many books piled in so many boxes.. Oh well main thing all is working

Thank you for your help. I was at the end of my rope when i started taking shots in the dark. I too remember lots reading about other options. I had the same boxes of manuals but have no idea where to start looking. This was and still is to a lesser degree, a great system that many newer systems were designed after. I will keep this one up and running forever if possible.

Hey guys...Another quick question. This is from my Ctrl C , H screen.
LOOPBACK ENABLED is new to me. How did i do that and how do i make it go away ?

REVISION: D4.119 DATE: Fri 02-02-18 07:07 a [A]SSIGN 2 SLOTS N
ALARM STATUS: 14
BPV STATUS: 00 [V]OLUME 09
LOOPBACK ENABLED
MISC. INFO MSG_in: 525 MSG_out: 827 Board Reset[s]: 6

That is the T1/PRI monitor screen it shows the activity on the different channels and if it is in an alarm status the state changes. 14 is good I don't see where it says loop back enabled
perhaps it just saw a loop back condition at one time. About the only thing you can do in that screen is hit Space bar to refresh. Or hit R then it will ask channel to reset. (Never used that) but if you type in 33
and hit enter it resets the card. Of course it drops all calls during reset. Then wait a few and hit space bar to refresh or go out and back into screen.
Can't remember what manual I sent you but the codes are explained on pg 33 of older manual and pg 94 of the Eclipse manual.

If working all good.