Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Need a second opinion on some ISDN protocol issues

Status
Not open for further replies.

ISDNman

Vendor
Nov 12, 2004
645
US
OK folks. This is the kind of question normally I'd be answering. But in this case I'd like a second opinion.

I have a major client who is trying to interface a piece of our gear (called "Xst" in the logs) to a HiPath switch.

The Siemens folks did some log captures and it sure looks to me that their protocol is simply not compliant with the National ISDN (Bellcore) standards.

Our customer has thousands of our units nationwide and is not questioning our assessment. Siemens so far is acting like it is not their problem. We'll be having a conference call next week. My plan at the moment is to:

1) Fax them them the standards and tell them they are not compliant

2) Point out to them that the customer (who has Definity PBXes at many sites) already owns our equipment and if so if Siemens wants their future business they really had better fix this (I know this is also the customer's basic feeling as well).

But before I do so, I'd like to have a second (outside) opinion on the protocol (Myself and our other ISDN guru are in agreement, as is our ISDN protocol vendor) just to CMA.

BTW, there are may of our units in use on HiCom switches. It seems odd that Siemens reinvented the wheel in terms of their ISDN protocol.

The following is a log from the Siemens switch showing the outgoing call setup from our Xst unit and also shows the call being routed out the PRI (I have replaced the first digit of the area code involved with an X to protect our customer's privacy). TW is the PRI provider:

Port 7510 is the dialing Xst. It is attempting to place a call to 9 338 7512. The calling party number is 7510. The call is a 64 kbps unrestricted circuit mode data call (my understanding is that voice calls are working fine).

The first log shows the dialing Xst on port 7510 and also shows the HiPath routing the call out the PRI, port 7869.

These logs show two areas of incompatibility between the HiPath switch and the relevant Bellcore National ISDN standards.

My comments are like this:

ROLF> Comment

<begin first Siemens log (outgoing side)>

1505879 Clear Channel
Monitoring Port : 7510 STMD 11 - 1 - 1
-----------------------------------------------------------------------------


Nr | Time | Callnumber/Access | State | Event | Direction | Info
-----+----------+------------------------------+------------------------------+------------------------------+--------------------+------------------
0001 | 12:25:59 | 7510 STMD 11 - 1 - 1 | Idle | Monitor On | |
Time = 12:26:05
Slot/Port =

ROLF> The dialing Xst sends SETUP (Call request) to HiPath requesting a connection.

Hipath <- SETUP
cr : 1 (from originating side)
bearer capab : 04 02 88 90
Coding Standard: CCITT
Information Transfer Capability: unrestricted
digital information
Transfer Mode: circuit mode
Information Transfer Rate: 64 kbit/s
channel id : 18 01 83
Interface type: basic interface
Preferred/Exclusive: preferred
D-Channel Indicator: not the D-channel
Information Channel Selection: any channel
keypad fac : 2C 08 39 33 33 38 37 35 31 32
Keypad Information: 93387512
calling num : 6C 05 80 37 35 31 30
Type of Number/Numbering Plan: unknown/unknown
Presentation Indicator: presentation allowed
Screening Indicator: user-provided, not screened
Digit(s): 7510
ROLF> Number dialed is 9 338 7512
ROLF> Dialing number is 7510, provided by the Xst (user provided, unscreened)
ROLF> This is a digital circuit mode call, at 64 kbps

Time = 12:26:05
Slot/Port = 7510 STMD 11 - 1 - 1

ROLF> Hipath Acknowledges the setup.

Hipath -> SETUP ACKNOWLEDGE
cr : 1 (to originating side)
channel id : 18 01 8A
Interface type: basic interface
Preferred/Exclusive: exclusive
D-Channel Indicator: not the D-channel
Information Channel Selection: B2 channel


<SNIP>
Slot/Port = 7869 TMST1 6 - 1 - 23

ROLF> HiPath routes the call out the PRI (port 7869) channel 23 by issuing a SETUP to TW.

Hipath -> SETUP
cr : 1 (from originating side)
bearer capab : 04 02 88 90
Coding Standard: CCITT
Information Transfer Capability: unrestricted
digital information
Transfer Mode: circuit mode
Information Transfer Rate: 64 kbit/s
channel id : 18 03 A1 83 97
Interface type: other interface
Preferred/Exclusive: preferred
D-Channel Indicator: not the D-channel
Information Channel Selection: as indicated in
following octets
Coding Standard: CCITT
Number/Map: number
Channel/Map Element Type: B-channel units
Channel number: 23
calling num : 6C 0C 21 80 35 30 35 38 33 30 36 34 30 30
Type of Number/Numbering Plan: national/ISDN
Presentation Indicator: presentation allowed
Screening Indicator: user-provided, not screened
Digit(s): X058306400
called num : 70 08 C1 33 33 38 37 35 31 32
Type of Number/Numbering Plan: subscriber/ISDN
Digit(s): 3387512

ROLF> HiPath has substituted X05 830 6400 for the calling party number (still user provided, unscreened)
ROLF> Called party number is 338 7512 (the 9 has been stripped off, of course)


0011 | 12:26:05 | 7869 TMST1 6 - 1 - 23 | Idle | Setup | Outgoing | DAD: 3387512
0012 | 12:26:05 | 7869 TMST1 6 - 1 - 23 | Call Request | | |
Time = 12:26:05
Slot/Port = 7869 TMST1 6 - 1 - 23

ROLF> TW Switch acknowledges call on PRI with CALL PROCEEDING.

Hipath <- CALL PROCEEDING
cr : 1 (to originating side)
channel id : 18 03 A9 83 97
Interface type: other interface
Preferred/Exclusive: exclusive
D-Channel Indicator: not the D-channel
Information Channel Selection: as indicated in
following octets
Coding Standard: CCITT
Number/Map: number
Channel/Map Element Type: B-channel units
Channel number: 23


0014 | 12:26:05 | 7869 TMST1 6 - 1 - 23 | Call Request | Call Proc | Incoming |
Time = 12:26:05
Slot/Port = 7510 STMD 11 - 1 - 1

ROLF> HiPath send a CALL PROCEEDING to the dialing Xst (display would change from ConnW to ConnP)

Hipath -> CALL PROCEEDING
cr : 1 (to originating side)


0016 | 12:26:05 | 7510 STMD 11 - 1 - 1 | Overlap Sending | Call Proc | Outgoing |
0017 | 12:26:05 | 7510 STMD 11 - 1 - 1 | Outgoing Call Proc | | |
0018 | 12:26:05 | 7510 STMD 11 - 1 - 1 | Outgoing Call Proc | Call Proc | Outgoing |
Time = 12:26:06
Slot/Port = 7869 TMST1 6 - 1 - 23

ROLF> TW Switch sends an ALERTING to the HiPath. Note that the logs shows a call reference only, no other information elements are shown.
ROLF> The ALERTING messages is to report that the far end has acknowledged the call and is "ringing" (e.g. alerting the user).

Hipath <- ALERTING
cr : 1 (to originating side)


0020 | 12:26:06 | 7869 TMST1 6 - 1 - 23 | Call Request | Alert | Incoming |
0021 | 12:26:06 | 7869 TMST1 6 - 1 - 23 | Call Present | | |
Time = 12:26:06
Slot/Port = 7510 STMD 11 - 1 - 1

ROLF> HiPath sends an ALERTING message to the dialing Xst. Note that the ALERTING message now has the "Progress Indicator" information element (IE).

Hipath -> ALERTING
cr : 1 (to originating side)
progress ind : 1E 02 81 88
Coding Standard: CCITT
Location: private network serving the local user
Progress Description: in-band information now
available


ROLF> According to Bellcore TR-TSY-000268 "ISDN Access Call Control Switching and Signaling Requirements" standard the "Progress Indicator" Information element in the network-to-user direction in the ALERTING message is "conditional" and is "included for Speech, 3.1 kHz audio and 7 kHz audio calls".

ROLF> According to Bellcore SR-NWT-001953 standard the "Progress Indicator" Information element in the Network-to-user direction in the ALERTING message is "conditional" and is "included for Speech, 3.1 kHz audio calls".


ROLF> According to Bellcore TR-TSY-000268 "ISDN Access Call Control Switching and Signaling Requirements" standard the "Signal" element in the network-to-user direction in the ALERTING message is Mandatory (e.g. "must include").

ROLF> According to Bellcore SR-NWT-001953 standard the "Signal" information element in the Network-to-user direction in the ALERTING message is Mandatory (e.g. "will include").


ROLF> NOTE - Since the HiPath is attempting to emulate a CO switch, messages from the HiPath to to the Xst would be considered to be in the "network-to-user" direction.

ROLF> So this log proves conclusively that HiPath is exhibiting two areas of non-compliance with the Bellcore National ISDN standards:
ROLF> 1) Erroneous inclusion of the "Progress Indicator" IE in the Network-to-User ALERTING message during setup of a Circuit Mode Data Call.
ROLF> 2) Failure to include the mandatory "Signal" IE in the Network-to-User ALERTING message during setup of a Circuit Mode Data Call.


0023 | 12:26:06 | 7510 STMD 11 - 1 - 1 | Outgoing Call Proc | Alert | Outgoing |
Time = 12:26:06
Slot/Port = 7510 STMD 11 - 1 - 1

ROLF> Dialing Xst ends the call by sending a RELEASE with a cause 96 ("Mandatory Information element is missing"). Note that this diagnostic, from the Xst, correctly identifies the missing "Signal" IE as non-compliant. Note only a single cause value can be sent.

Hipath <- RELEASE
cr : 1 (from originating side)
cause : 08 03 80 E0 34
Coding Standard: CCITT
Location: user
Cause Value: mandatory information element is
missing


Time = 12:26:06
Slot/Port = 7510 STMD 11 - 1 - 1

ROLF> HiPath confirms call is ended by sending RELEASE COMPLETE.

Hipath -> RELEASE COMPLETE
cr : 1 (to originating side)

0026 | 12:26:06 | 7510 STMD 11 - 1 - 1 | Outgoing Call Proc | Release | Incoming |
0027 | 12:26:06 | 7510 STMD 11 - 1 - 1 | Disconnect Indication | | |
Time = 12:26:06
Slot/Port = 7869 TMST1 6 - 1 - 23

ROLF> HiPath clears call on TW PRI side

Hipath -> DISCONNECT
cr : 1 (from originating side)
cause : 08 02 80 E0
Coding Standard: CCITT
Location: user
Cause Value: mandatory information element is
missing

<end Siemens log (outgoing call side)>

Many thanks for looking this over.
 
ISDNman,

I agree with your assessment, but humor me - why would you have a progress indicator on an unrestricted 64k call? Wouldn't that only be for a 3.1khz call?
 
rtfmdude,

Love your nickname, reminds me of a coworker who has that as his screen saver. Thanks for your post.

I agree with your question and it gets to the heart of the matter. This is exactly what I intend to ask Siemens.

The systems works for 3.1 kHz and Voice calls, where the Progress Indicator is expected and correct.

We don't know for sure if our equipment is reacting to the missing Signal IE or to the incorectly present Progress Indicator. Since voice calls worked they Siemens on-site guy did not send me a log of a 3.1 or Voice call.

But certainly we think if Siemens is going to claim NI-1 or NI-2 compatibility, they should fix both problems.

Thanks again
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top