detection of analog CONNECT

[Andreas Boeckler]

Hi,

im trying to establish an connection between an ISDN-Card and an analog
modem.(B1=8,B2=1,B3=7)
Dialing works perfectly, but receiving a call is difficult.

Situation:
CapiApp -- ISDN-Card(AVM) <----------> Modem -- Minicom (Terminal)

* Minicom dials
* CONNECT_B3_ACTIVE_IND is sent far too early. Minicom is still
connecting
* After that the application gets many DATA_B3_IND-Messages, but minicom
is still in dial-mode.
* At a certain time minicom signals: it's connected. DATA_B3_IND-messages
have stopped.
* Now I can type in characters in minicom. They are transferred correctly
to the CapiApp. (as DATA_B3_IND)

Does anybody know the correct way to detect the carrier?
I thought, that CONNECT_B3_ACTIVE_IND should be send after the
protocol-negotiation ends (CONNECT 38400-message on the terminal) and not
before?

Is it aproblem with AVM-Cards (Fritz and C4)?

Bye

Andy

[mm]

Hi Andy;

You receive a CONNECT_B3_ACTIVE_IND when CAPI picks up the call; when a
connection has been established. Only afterwards modem negotiation can
commence. A modem on the other hand signals connect only after
negotiation. So, everything works as it should.

I guess your problem is that your capi app has difficulties to discover
what is payload data and what is not. The usual thing to do here is to
'frame' the payload. Some scheme that signals beginning and end of
payload data.

A few things that spring to mind, but might be complete bullocks :)

Try to emulate HDLC frames on the modem side. Maybe then you can use
B1=0 and capi sends you only the payload of these frames.
An HDLC frame if I remember right is
0xff for point to point connection
0xc0 or 0x08 0xc0 frames follow; 0x08 last frame
payload bytes
2 byte CRC sum (google)

I.e. modems send fax data in HDLC frames . Maybe you could even use AT
commands like +FTH, +FRH ..., but I guess those are only working within
a fax transfer.

Nevertheless I don't think you can blame AVM here ;)

Bye
Michael

Post by Andreas Boeckler
Hi,
im trying to establish an connection between an ISDN-Card and an analog
modem.(B1=8,B2=1,B3=7)
Dialing works perfectly, but receiving a call is difficult.
CapiApp -- ISDN-Card(AVM) <----------> Modem -- Minicom (Terminal)
* Minicom dials
* CONNECT_B3_ACTIVE_IND is sent far too early. Minicom is still
connecting
* After that the application gets many DATA_B3_IND-Messages, but minicom
is still in dial-mode.
* At a certain time minicom signals: it's connected. DATA_B3_IND-messages
have stopped.
* Now I can type in characters in minicom. They are transferred correctly
to the CapiApp. (as DATA_B3_IND)
Does anybody know the correct way to detect the carrier?
I thought, that CONNECT_B3_ACTIVE_IND should be send after the
protocol-negotiation ends (CONNECT 38400-message on the terminal) and not
before?
Is it aproblem with AVM-Cards (Fritz and C4)?
Bye
Andy
--
Dipl.-Ing. (FH) Andreas Böckler
netlands edv consulting GmbH

[Andreas Boeckler]

Post by mm
Hi Andy;
You receive a CONNECT_B3_ACTIVE_IND when CAPI picks up the call; when a
connection has been established. Only afterwards modem negotiation can
commence. A modem on the other hand signals connect only after
negotiation. So, everything works as it should.

Hi and thanks for the answer.

But why is the procedure working like I thought when I'm doing the call?
When I'm calling the modem, CONNECT_B3_ACTIVE_IND is send to the app
_AFTER_ negotiation with the modem has ended?
It's immediately possible for app to talk on the application protocoll
layer with the other end of the line.
Something i'm not able to do, when I'm picking up a call.

Shouldn't be the behavior the same?

Thanks

Andy

[mm]

Hi again;

Maybe you get the CONNECT_B3_ACTIVE_IND after negotiation because you
use b3-protocol 7. But frankly I don't know.

But what I do know is that I cannot verify your problem.

Following scenario:
minicom -> /dev/modem [one of eicons diva server tty devices]
<---> back into /dev/capi20 -> a little capi program that echoes every
character back to minicom.

Works without any problems.

Is there any data in your DATA_B3_IND ? They can be empty if I remember
right.

In any case I only receive the bytes I type in, nothing else.

Bye
Michael

[Andreas Boeckler]

Post by mm
Hi again;
Maybe you get the CONNECT_B3_ACTIVE_IND after negotiation because you
use b3-protocol 7. But frankly I don't know.

I use the same protocoll for the incoming call.

Post by mm
But what I do know is that I cannot verify your problem.

Maybe because of the different branding of the card ;)?

Post by mm
minicom -> /dev/modem [one of eicons diva server tty devices]
<---> back into /dev/capi20 -> a little capi program that echoes every
character back to minicom.
Works without any problems.
Is there any data in your DATA_B3_IND ? They can be empty if I remember
right.

Yes! I get aprox. 18000 Bytes of garbage (via
capiChannel.getInputStream()) until the line is silent! That's odd because
I'm expecting not a single byte, because i's a master-slave communication
and the CAPI-App is the master.

Post by mm
In any case I only receive the bytes I type in, nothing else.

Which B-Protocoll-combination do you use?
Is an Eicon Diva Server BRI better suited for such a type of application?

Thanks

Andreas Böckler

[mm]

Hi again

I've tried the following this morning:

minicom -> /dev/modem [one of eicons diva server tty devices] <--->
AVM's Fritz Card -> a little capi program that echoes every character
back to minicom.

I do receive as well some data. A lot of [0x11 0x91 ...] in 8 bit mode
and [0x11 0x11 ...] in 7 bit per byte mode. But all this happens after
the CONNECT_B3_ACTIVE_IND which seems to pop-up when minicom shows the
CONNECT message.
If you run the program in 7 bit mode with the Eicon card, you will see
the same behaviour. Lots of [0x11 ...] data before it goes quiet.

I wonder where this data is coming from?

Bye
Michael

[Georg Reichel]

Hi mm!

Post by mm
minicom -> /dev/modem [one of eicons diva server tty devices] <--->
AVM's Fritz Card -> a little capi program that echoes every character
back to minicom.

Is it possible to monitor all received and echoed data in your CAPI app?


Regards, Georg

[mm]

Hi Georg;

I would say so, yes.

The application accepts calls that fit the given B protocol, sends
every byte it receives one by one to stdout and straight back to the
peer.
What happens now is that I receive a lot of 0x11 bytes or similar in
the beginning although I did not enter anything in minicom. After a
while I don't receive anything anymore. If you now key some data into
minicom the application receives exactly that very input data and
sends it back correctly. Effectively, the application acts like a
rather dumb terminal server.

Bye
Michael

Post by Georg Reichel
Hi mm!

Post by mm
minicom -> /dev/modem [one of eicons diva server tty devices] <--->
AVM's Fritz Card -> a little capi program that echoes every character
back to minicom.

Is it possible to monitor all received and echoed data in your CAPI app?
Regards, Georg

[Georg Reichel]

Hi Andreas!

Post by Andreas Boeckler

Post by mm
You receive a CONNECT_B3_ACTIVE_IND when CAPI picks up the call; when a
connection has been established. Only afterwards modem negotiation can
commence. A modem on the other hand signals connect only after
negotiation. So, everything works as it should.

The CAPI spec (CAPI 2.0) says that the CONNECT_B3_IND should be sent at
the start of the modem negotiation. Since there is no special note for
protocols 0 and 7 (as for CONNECT_B3_IND) for the CONNECT_B3_ACT_IND, I
would expect the normal behavior of sending it after the logical
connection is established.

Post by Andreas Boeckler
But why is the procedure working like I thought when I'm doing the call?
When I'm calling the modem, CONNECT_B3_ACTIVE_IND is send to the app
_AFTER_ negotiation with the modem has ended?

I would see it as a bug in the CAPI implementation. Ask the manufacturer
for a fix.

Ciao, Georg

[Andreas Boeckler]

Am Thu, 17 Nov 2005 14:17:47 +0100 schrieb Georg Reichel:
Hi Georg!

Post by Georg Reichel
I would see it as a bug in the CAPI implementation. Ask the manufacturer
for a fix.

We replaced the card with an Eicon Diva 4BRI.
Now it works like I expected and
CONNECT_B3_ACTIVE_IND is sent, when negotiation is finished.

Bye

Andy