[comp.dcom.telecom] all this new stuff has been confusedly presented

AWalker@RED.RUTGERS.EDU (*Hobbit*) (10/08/87)

Okay, my recent reading of Telecom has raised many questions.  Could some
persons who know provide the following info:

Is this new "ID the caller" beta-test service handled by / the same as /
utterly unrelated to / etc ISDN?

Exactly, and by this I mean electrically down to the bit level, how does
the beta-test service [I forget its name offhand] work?  How is the number
of the caller passed to the recipient's equipment, and what is required on
the called end to display it?  [I'm thinking "build my own" here...]

It seems to me that for this service to work the caller must be in an office
where the service is being tested too.  Present ["normal"] offices wouldn't
have the capability to pass a packet containing the caller's number to the
destination end, right?  Is this packet the same kind of thing an office
passes to a TSPS on 0+ calls?  Grubby internal details, please??

And finally, where is the documentation for ISDN protocols located?

_H*
-------

jr@LF-SERVER-2.BBN.COM (John Robinson) (10/09/87)

In article  <12340678224.21.AWALKER@RED.RUTGERS.EDU> AWalker@RED.RUTGERS.EDU (*Hobbit*) writes:
>Okay, my recent reading of Telecom has raised many questions.  Could some
>persons who know provide the following info:
>
>Is this new "ID the caller" beta-test service handled by / the same as /
>utterly unrelated to / etc ISDN?
>
>Exactly, and by this I mean electrically down to the bit level, how does
>the beta-test service [I forget its name offhand] work?  How is the number
>of the caller passed to the recipient's equipment, and what is required on
>the called end to display it?  [I'm thinking "build my own" here...]
>
>It seems to me that for this service to work the caller must be in an office
>where the service is being tested too.  Present ["normal"] offices wouldn't
>have the capability to pass a packet containing the caller's number to the
>destination end, right?  Is this packet the same kind of thing an office
>passes to a TSPS on 0+ calls?  Grubby internal details, please??
>
>And finally, where is the documentation for ISDN protocols located?
>
>_H*
>-------

This is something that comes under the ISDN service umbrella probably.
The protocols are specified in the ISDN standards, CCITT I.xxx series
of standards in the 1984 Red Book, plus possible draft iprovmenets for
the 1988 book.  The information on calling number is probably passed
in signalling system #7 (SS#7) out-of-band data packets; this system
is an outgrowth of internal Bell protocols and now will be public
worldwide in ISDN systems.

SS#7 (or its predecessor in the U. S., CCIS) probably already provides
the calling party's identification to the callee's central office; all
that was missing until now was the out-of-band channel to pass it in
to the home.  One way of thinking about ISDN is that it makes
available to every residence the services that are already or almost
available to PBX's that utilize certain types of access to the
backbone (meaning, T1 trunks with signalling in one of the channels);
this does not necessarily mean that these PBX's can get caller's
number today (this service would need to be tarriffed etc.), but the
protocols are already in place that, in principle, would allow the
interaction to take place.
-- 
/jr
jr@bbn.com or jr@bbn.uucp

obroin@hslrswi.UUCP (Niall O Broin) (10/21/87)

In article <231@lf-jr.BBN.COM> jr@LF-SERVER-2.BBN.COM (John Robinson) writes:
>
>In article  <12340678224.21.AWALKER@RED.RUTGERS.EDU> AWalker@RED.RUTGERS.EDU (
>>
>>Is this new "ID the caller" beta-test service handled by / the same as /
>>utterly unrelated to / etc ISDN?

unrelated to. The signalling of the caller's number goes over your standard
non ISDN line. ISDN can of course provide this capability.

>>It seems to me that for this service to work the caller must be in an office
>>where the service is being tested too.  Present ["normal"] offices wouldn't
>>have the capability to pass a packet containing the caller's number to the
>>destination end, right?

Wrong. All non primitive signalling systems have the ability to request and
receive the caller's number. So the "ID the caller" service just requires
software in the CALLED PARTY's exchange to request the caller's number (if it
has not yet been received - it often already has) and software/hardware (and a
signalling protocol) to transmit the number to the called party's telephone.
This is fairly simple, though I don't know exactly how it will be done in this
case.

>This is something that comes under the ISDN service umbrella probably.

Yes and no, but a lot more no than yes.

>The information on calling number is probably passed
>in signalling system #7 (SS#7) out-of-band data packets

Just a tad unlikely ! Overkill by about n orders of magnitude - the cost
of having a processor to handle C7 signalling attached to your phone would
be horrible just to get "ID the caller" service.

>this system (C7 signalling) is an outgrowth of internal Bell protocols

Not unless you regard the whole principle of common channel signalling
as an internal Bell protocol, it isn't.

>and now will be public worldwide in ISDN systems.

Yes, but C7 signalling and the ISDN are completely seperate entities.
Signalling for 99.9' % of ISDN lines will be C7, but C7 is a telephony
signalling system, and is currently in use worldwide on many different types
of non ISDN trunk circuits

Briefly, a C7 signalling system has two parts, a message transfer part
and a user part. There are and will be many different user parts, a
telephone user part (the area in which I have worked), an ISDN user part
and more.


Regards,

       #\\\\\-----\\\\\       Niall  O Broin
      ###\\\\\-----\\\\\      AXE Software Development
     #####---------------     Hasler AG      +-----------------------------+
    #######---------------    Berne          +This space available for rent|
   #########\\\\\-----\\\\\   Switzerland    +-----------------------------+
  ###########\\\\\-----\\\\\
 #######     /////     /////  BITNET       obroin%hslrswi.UUCP@cernvax.BITNET
#######     /////     /////   UUCP .. {uunet,mcvax ..}!cernvax!hslrswi!obroin
 #####               /////
  ###               /////     Any resemblance between this message and the
   #     /////     /////      opinions of anyone else, living or dead, is
        /////     /////       purely coincidental.