Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!bionet!hayes.ims.alaska.edu!accuvax.nwu.edu!nucsrl!telecom-request
From: asuvax!rako!rakoczynskij@ncar.ucar.edu (Jurek Rakoczynski)
Newsgroups: comp.dcom.telecom
Subject: Re: Distinctions and Definitions Needed
Message-ID: <14448@accuvax.nwu.edu>
Date: 1 Nov 90 17:29:35 GMT
Sender: news@accuvax.nwu.edu
Organization: AG Communication Systems-Phoenix, AZ
Lines: 60
Approved: Telecom@eecs.nwu.edu
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 10, Issue 797, Message 8 of 10


In article <14055@accuvax.nwu.edu>, floyd@hayes.ims.alaska.edu (Floyd
Davidson) writes: 

> In article <14030@accuvax.nwu.edu> George S Thurman <0004056081@ 
> mcimail.com> writes: 

>>Could some of you Telecom Experts out there tell me (in simple
>>terms) the difference between SS7 and CCIS.  

> CCS (Common Channel Signaling) removes the signaling functions from 
> the individual trunks (ie.  multifreq tones for dialing numbers) and text
> deleted  CCIS (Common Channel Interoffice Signaling) is AT&T's
> implementation of CCS.  CCITT Signaling System No. 7 is the most
> recent CCS implementation.  SS7 provides more information to the
> terminating end office and does more trunk testing before setting up
> a path.

CCIS introduced Out-of-Band signaling in Class 1-4 offices (pre-
divestiture usage :-) ).  In actual implementation, I don't think it
was continued down to the Class 5 end office. There was, however, some
development by GTE (and AT&T?) to put it in Class 5 offices.  BTW:
AT&T may not have 'officially' implemented all of the Data Bits on the
STP link required in the CCIS specs.

SS7 extended the general principle of Out-of-Band signaling to the end
office. It also implements the 7 layer signaling protocol, which CCIS
did not have.

CCIS is still in use, but will be phased and replaced with SS7.

The above is VERY short but to the point.

Some trivia: An interesting problem came up when telcos were being
given classes on development of CCIS on the end office.

With CCIS on an end office, if the originating end office was able to
complete its' part of the call set-up, but the terminating end office
could not (eg. busy phone, etc.), the originating office was to return
reorder tone (120 ips), instead of the terminating office, since the
voice path had not been established.

A trivial matter you say! :-) HA!  The peg counters (old term) that
recorded the uncompleted traffic, would also show the uncompleted CCIS
call as uncompleted in the originating office log.  These records are
used to monitor the office for the PUC, salaries for the CO people,
etc.  Even though a certain amount of traffic is expected to be
uncompleted for legitimate reasons (caller goes on-hook before call
completion, Mother's Day, etc.), excess uncompleted calls could mean
poor switch maintenance.  CCIS would obviously increase the
uncompleted call record.  A soution to have another record type, log
CCIS problems, was to be developed if SS7 did not come around.

Thanks to Heinz Berg at my office for filling me in on some of the
above info.


UUCP: {ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!rakoczynskij
Inet: gtephx!rakoczynskij@asuvax.eas.asu.edu
Voice: +1 602 581 4867  Fax: +1 602 582 7111