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

["Brian F. G. Bidulock" <bidulock@openss7.org>]

Hi Tobias,

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

Tobias Erichsen wrote:                       Sat, 13 Oct 2001 17:33:50
>
> Hi there,
> 
> I don´t know if any of you guys have heard of CAPI.
> This is an api which has been defined for manufacturer
> independent usage of ISDN-boards.  Both signaling and
> data-transfer are supported by this interface.  There
> have even been some extensions to also support GSM and
> ATM (Q.2931/UNI 4.0).  Up to now there has not been
> an integration of SS7 into this API.  As some of our
> customers require SS7 instead of Q.931 signaling, we
> are trying to get manufacturers to support this stuff.

I have reviewed the CAPI documents several times.  For those
that don't know what they are, they are available for download
from http://www.capi.org/

> 
> To not burden them with implementing the full protocol
> stack (with ISUP & TCAP) I thought about proposing them
> to first implement MTP2 (or perhaps even MTP2) within
> the driver and let the application do the ISUP part.
> 
> So right now I´m looking for the options which have to
> be defined for MTP2 and MTP3 to be configurable at run-
> time and those to be configured at installation-time.
> 
> For MTP2 I really only see two options: 
> a.) Emergency Alignment / Normal Alignment
> b.) Basic Method / PCR Method
> 
> I have not looked into the MTP3-part that much - but
> I think as this setup will only be a signaling-end-
> point, the parts to be configured should be pretty
> small.  
> 
> Do you see any stuff I have left out for MTP2 and do
> you have some good suggestions for MTP3?
> 
> One further point I´d like to point to is the isdn4linux
> project. This is accompanied by capi4linux which is
> developing a open-source-CAPI for linux.  It could be
> a cool thing to also have ISUP signaling based on your
> project as an additional option to the Q.931 based stuff
> which is in use right now...
> 
> Any suggestions and/or comments highly welcome ;-)

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.

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.

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".

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.

There are call processing frameworks which accomodate both
CAPI and ISUP by modelling the ISDN Network Switch.  My favorite
is AIN 1.0/CS-2.  This provides a framework for ISDN, ISUP, and
non-ISDN interfaces such as POTS, and non-ISUP interface such
as MF/CAS.

I'm rather interested just what applications you see clients
using such an interface.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦