all calls to operator

[adamvozip]

First of all sorry for my low alcatel knowledge. I'm just trying to get som hints and information about what can be happening:
A reseller has a 4400 connected to ISDN line with no problem. Connecting a Teles Gateway in between makes all calls go to operator no matter which number is called.

The only difference in the trace is a change from
(direct trace)
ie 0x70 Called party number: A1 31 31 31 31 31 31
Number type: National number
Numbering plan: ISDN/Telephony(CCITT Recommendation E.164/E.163)
Number: 111111

to
(trace with Teles in between)
ie 0x70 Called party number: 81 31 31 31 31 31 31
Number type: Unknown
Numbering plan: ISDN/Telephony(CCITT Recommendation E.164/E.163)
Number: 111111

So, when the Teles is in between the first byte is changed from A1 to 81 although the number is correctly sent to the Alcatel.(real number changed to hide customer info)

Can anyone provide some info about what Alcatel's 4400 configuration option need to adapt to this change?

I appologize in advance if this is not the right place and would appreciate pointers to the right place to ask.
Thank you very much in advance for any hint or information about this issue.

Samuel

[tot3nkopf]

Post complete traces from 4400 side when calling from Teles.

[adamvozip]

First of all thank you for the fast respone. The following is a trace about an incoming call with the Teles in between:

ISDN3_00036 03/11 11:27:31 RX d_channel: 27 (S:00 T:000) payload: (43) 08 01 04 05 A1 04 03 90 90 A3 18 01 8A 1E 02 84 83 6C 0F 01 81 30 30 33 33 34 36 37 36 36 34 32 32 39 70 07 81 31 31 31 31 31 31
0x05 SETUP Ref: O,4
ie 0xA1 Sending complete
ie 0x04 Bearer capability: 90 90 A3
Coding: CCITT standardized
Information transfer capability: 3.1 kHz audio
Transfer mode: Circuit mode
Transfer rate: 64 Kbit/s
User info layer 1: G.711 A-law
ie 0x18 Channel identification: 8A
Interface identifier: Implicit
Interface type: Basic
Indicated channel: Exclusive
D-channel identified: Yes
Information channel selection: B2 channel
ie 0x1E Progress indicator: 84 83
Coding: CCITT standardized
Location: Public network serving the remote user
Progress: Origination address is non-ISDN
ie 0x6C Calling party number: 01 81 30 30 33 33 34 36 37 36 36 34 32 32 39
Number type: Unknown
Numbering plan: ISDN/Telephony(CCITT Recommendation E.164/E.163)
Presentation: presentation allowed
Screening: user-provided, verified and passed
Number: 0033467664229
ie 0x70 Called party number: 81 31 31 31 31 31 31
Number type: Unknown
Numbering plan: ISDN/Telephony(CCITT Recommendation E.164/E.163)
Number: 111111
ISDN3_00037 03/11 11:27:31 TX d_channel: 27 (S:00 T:000) payload: (4) 08 01 84 02
0x02 CALL_PROCEEDING Ref: D,4
ISDN3_00038 03/11 11:27:31 TX d_channel: 27 (S:00 T:000) payload: (4) 08 01 84 01
0x01 ALERTING Ref: D,4
ISDN3_00041 03/11 11:27:37 TX d_channel: 27 (S:00 T:000) payload: (14) 08 01 84 07 4C 08 21 81 38 30 30 39 39 39
0x07 CONNECT Ref: D,4
ie 0x4C: 21 81 38 30 30 39 39 39
ISDN3_00042 03/11 11:27:37 RX d_channel: 27 (S:00 T:000) payload: (4) 08 01 04 0F
0x0F CONNECT_ACK Ref: O,4
SAN_00045 at line 2828 "cbarr.c"
on 03.11 at 11:27:51 (355286797)
info : 0000 0000 FFFF FFF9 FFFF FFFF 0000 0124
SAN_00046 at line 2828 "cbarr.c"
on 03.11 at 11:27:51 (355286797)
info : 0000 0000 FFFF FFF9 FFFF FFFF 0000 0124
SAN_00047 at line 2828 "cbarr.c"
on 03.11 at 11:27:51 (355286797)
info : 0000 0000 FFFF FFF9 FFFF FFFF 0000 0124
SAN_00048 at line 2828 "cbarr.c"
on 03.11 at 11:27:51 (355286797)
info : 0000 0000 FFFF FFF9 FFFF FFFF 0000 0124
ISDN3_00049 03/11 11:27:54 TX d_channel: 26 (S:00 T:000) payload: (8) 08 01 59 45 08 02 85 90
0x45 DISCONNECT Ref: O,89
ie 0x08 Cause: 85 90
Coding: CCITT standardized
Location: Private network serving the remote user
Class: Normal event
Value: Normal release
ISDN3_00050 03/11 11:27:54 RX d_channel: 26 (S:00 T:000) payload: (4) 08 01 D9 4D
0x4D RELEASE Ref: D,89
ISDN3_00051 03/11 11:27:54 TX d_channel: 26 (S:00 T:000) payload: (4) 08 01 59 5A
0x5A RELEASE_COMP Ref: O,89
SAN_00052 at line 6060 "cot_ael.c"
on 03.11 at 11:27:56 (355291570)
info : 0000 0001 0000 0004 0000 0142 0000 010C

[tot3nkopf]

This is an OXO (Alcatel OmniPCX Office) trace, not a 4400 trace.

Cause of disconnect:

0x45 DISCONNECT Ref: O,89
ie 0x08 Cause: 85 90

Cause No. 85 - no call suspended [Q.850]
This cause indicates that the network has received a call resume request containing a Call
identity information element which presently does not indicate any suspended call within
the domain of interfaces over which calls may be resumed.

I think the mediation box sends some IE that OXO cannot interpret and waits for an answer from OXO. OXO doesn't send that info and Teles disconnects the call.

[adamvozip]

Thank you very much again for your response.

Indeed the trace is an unsuccessful call but I have been reported of successful incoming calls, all of them ending up in the operator instead of the right extension. May the misunderstanding between alcatel's isdn stack and Teles' isdn stack be the cause of this behaviour and not a problem of the configuration of the OXO (customer reported the model, sorry and thank you again for the hint) ?

Best regards,

[tot3nkopf]

Most probably either OXO or Teles sends an IE that the other party doesn't understand. Thre are things that you can change in OXO regarding its behavior to ISDN messages.
Check noteworthy addresses document Maybe IsdnStatuE label in Other Labels is relevant in your case.

Regards.