Octel 250 will not network after conversion to Cisco/VG248

[PMcCallum50]

New install -VG248 works for FAX, Modems etc and internal Octel VM. When the Octel attempts to network to other Octels, call is started, remote end answers, before messages transfer, we can hear using buttset Octel saying "Goodbye" while DTMF continues. The Octel 250 is unable to establish or authenticate. Moved VG248 port used for networking to POTS line and networking is established and works fine. any ideas? btw, this was on a nortel opt 11 which worked perfectly fine before the change - has to do with the VG248 ports if our troubleshooting is correct.

 

[kxboy]

Interesting. The 250 performs some handshaking with the called system. This is done using DTMF tones, that are tested for db loss, noise etc. The systems also exchange serial numbers to verify the correct system is being called.
The timing of the tones is pretty tight, if one end or the other detects that the tone duration is off the sequence will fail. This is for security reasons, if the tone duration is off, or distorted, it could mean that the line is being monitored.

Since it works on the old analog line, the VG248 must be distorting those tones or upsetting the timing causing the handshaking to fail. If there are any setting on the VG248 to give a better grade of service tothe one line used for networking, you may try changing those.

Check the systems managers mailbox, it sould have some network error messages that may provide some information on the errors. Also, log in the the SMT, and at teh debug prompt type "nwstats" it will show a screen with some info that may also help.

 

[KenMeans]

The Octel also uses autovon tones a b c & d it sounds like the VG248 is not passing them or it is but not at a level that the octel can hear. We have customers that use this config and it works fine sounds like the cisco needs some tuning. What codex are you using ?


Initial Call Sequence
The originating system shall dial the destination system access number. This is the number that the user will enter when sending a message. Upon the absence of ring-back tone, the originating system shall transmit a "C" to the destination. In the event that a human has answered the call, the originating system will also transmit a voice message indicating that the recipient can press a l to disconnect from the call. If this should happen, the originating system will return network messages to sender with an error message. The originating system shall re-transmit the "C" if no response from the destination up to a maximum of 7 tries. Retry schedules can then be put into effect.

If the destination system answers the call and detects the "C" digit it shall respond with a "D" after a 4 second delay, but not longer than 8 seconds. After transmitting the "D", the destination system will be expecting a START SESSION frame. If the destination system receives an additional "C" from the originating system , the destination system will assume that it's "D" was not heard, and shall re-transmit up to 3 times prior to disconnect.



Ken Means

http://www.tel-is.com

 

[PMcCallum50]

Everyone was right on, except Cisco. The brand new unit had ver 1.21 which had a known problem. SW version 1.31 (came out Sept 2004) is suppose to fix the problem. We will find out tonight. From Cisco: Symptom:
VG248 does not detect the fourth row DTMF digits A,B,C,D.

Conditions:
A device attached to an analog port on the vg248 attempts to
send a fourth column digit A,B,C, or D. The vg248 will incorrectly
relay this digit in the SCCP message to the callmanager server
and the destination device will not receive the digit A,B,C, or D.

Workaround:
None