[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [openss7] RE: Defining CAPI-extension to support MTP2...
Tobias,
Well, if you are interested in a simple mapping (no supp
services) from CAPI to ISUP, a good starting place might
be the STREAMS module described in CAPI 2.0 Section 8.5.
Do you know much about STREAMS?
Then a subset of the CAPI commands could be mapped directly
onto ISUP messages within the module. The module could
be "pushed" over the MTP driver. The more complicated thing
will be handling CIC mapping. That would look something like
this:
+--------+
| CAPI |
| Module |
+--+--+--+
| |
| |
+--+--+--+
| MTP |
| Driver |
+--------+
The MTP driver supports the NPI connectionless.
Another way to arrange it would be to use the OpenSS7
ISUP connection-oriented stub for MTP. This allows a
pseudo-connection-orietned NPI interface over MTP like
this:
+--------+
| CAPI |
| Module |
+--+--+--+
| |
+--+--+--+
| ISUP |
| Module |
+--+--+--+
| |
+--+--+--+
| MTP |
| Driver |
+--------+
The ISUP stub allows you to "connect" between the local
point code and the remote point code for ISUP. So, for
example, all ISUP messages from remote PC B sent to local
PC A would be delivered to the stream. The CAPI module
would still need to decode ISUP messages and convert them
to CAPI commands.
Is that something like what you had in mind?
--brian
Tobias Erichsen wrote: Sun, 14 Oct 2001 11:23:38
>
> > 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
--
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 Ķ