[openss7] RE: Defining CAPI-extension to support MTP2...

[Tobias Erichsen <erichsen@te-systems.de>]

> Hi Tobias,

Hi Brian
 
> How's it going?  I think that the last time we talked
> was September of last year.

Just fine.  A little too busy this last year - thatīs why
I havenīt gotten down to doing any SS7-stuff yet - still
one trade fair to get done this week in Munich - and I hope
that afterwards things relax a little ītil the end of year ;-)

I have still kind of followed the progress on the webside
and in the mailing-list though.  And I have done some
reading (the SS7-books from Russell & Black). Hope to be
doing some real stuff myself in the near future...

> In general I don't think that CAPI can be placed on top of ISUP
> signalling.  Let me expain:
> 
> ISUP is a switch-to-switch signalling protocol.  ISDN is a user
> to network signalling protocol.  The differences are as great
> as, say, UNI and NNI.
> 
> In general, a switch supports ISDN and ISUP signalling; however,
> the function that converts between the two is call processing in
> its entirety.  If you look at, say, Q.699, "Interworking betwen
> ISDN access and non-ISDN access over ISDN User Part of
> Signalling System No. 7," you will see that ISDN to ISUP
> interworking is not a trivial mapping.  This is the function of
> a switch.

Ok - I will take a look there - have only looked at Q.700 and up
so far...

> Looking at the COMMON-ISDN-API (CAPI) Version 2.0 Part I, it is
> obvious from the message descriptions that the CAPI is directed
> at the User-side of the ISDN interface only and does not support
> Network-side calls.  For example, there are messages to generate
> an ALERT_REQ and receive an ALERT_CONF, however there is no
> ALERT indication or ALERT response.  This makes CAPI very
> one-sided and unsuitable for use with ISUP.

Itīs true that CAPI is a pretty asymetrical API, just providing
service to the user-side.  But I think that would be ok for service-
platforms which just want to switch from Q.931 to ISUP for signaling.

By the way ALERT_CONF is just a local confirmation, that CAPI has
checked the parameters etc. and will now be sending ALERT to the
network.  And an ALERT indication is available by setting the bit
for call-progress detection in the listen-mask.  Afterwards one
will get an INFO_IND in case an ALERT from the network side has
been received...
 
> The architecture for CAPI/ISDN looks like this:
> 
>   +------+      +--------+  BRI  +---------+         +---------+
>   |      | CAPI |  ISDN  |<----->|  ISDN   |  ISUP   |   ISDN  |
>   | Appl |<---->|  User  |  PRI  | Network |<------->| Network |
>   |      |      | Device |<----->|  Switch |         |  Switch |
>   +------+      +--------+       +---------+         +---------+
> 
>                 |                          |
>                 +-------- CP Function------+
> 
> To use CAPI to control ISUP would require that both the ISDN
> User Device and the ISDN Network Switch be emulated in the
> capabilitiy that would convert bewteen CAPI and ISUP (that I
> have labelled as "CP Function").
> 
> For ISDN supplementary services (which are supported to the User
> side by CAPI), the ISDN Network Switch performs provides the
> switching and conferencing services necessary to support the
> supplementary service.  Not all of these supplementary services
> have NNI (ISUP) equivalents.  So, for example, when an ISDN
> conference call is invoked, this requires two separate call legs
> over ISUP and a conferernce bridge in the ISDN Network Switch.
> Where CAPI normally just invokes the conferencing service from
> the ISDN Network Switch, a CAPI to ISUP interface would have to
> perform these functions directly within the driver performing
> this "CP Function".

There are certainly some supplementary services which donīt
exist within ISUP.  But either those services then will not
be offered to the application, or they will be emulated
within the CAPI-framework (something like this is being done
already with Q.sig Path-replacement - first establishing a
cross-connect within a software-switch-matrix & afterwards
trying to optimize the call-path to not include the CAPI-
device anymore...) And even with Q.931, if you have p2p
configuration (which one will have with primary access
anyway), lotīs of supplementary services are not even
implemented by the carriers anymore as they normally expect
a PBX to be connected to this port which implements supp
services locally...

> Because of this, CAPI is an unsuitable framework for use with
> ISUP.  It is perfectly suited to ISDN User applications that
> invoke functionality in the Network Switch, but is completely
> unsuitable for signalling between switches.

Ok - I see your point - and I wasnīt point to CAPI as beeing a
all-encompassing API-solution.  I was only looking at it to be
an API to be used for the periperal side of the network. Like
written above - enabling service-platform to also be connected
using ISUP instead of Q.931.

And the first step I thought about was not even to let CAPI
do call-control at all, but rather let CAPI provide access
to the b-channels and providing a MTP2/MTP3 layer for the
d-channel, so the application can do the rest.  This has
already been used to implement proprietary d-channel-prots
like Siemens-Cornet within the application.  That was the
reason for my question about the options to be configurable
for these two protocols in the signaling-endpoint configu-
ration...

Tobias