Post by Simon HäniPost by Danilo KempfCould you please post the CONNECT_REQ you send down to the CAPI? Have you
tried using another CAPI application to dial the same number? Does that
work? (You could try using Phoner, to be found at http://www.phoner.de)
-----------------------
JcapiMessage call = (JcapiMessage)capi.createMessage(appID,
JcapiMessage.CONNECT_REQ,mn++);
call.setDwordValue("Controller",1);
THAT's how it's done in Java/JCAPI? That looks mighty strange to my
untrained eyes -- but on the other hand ... all those pretty cycles Intel
giveth are there to be burned, arent' they? Looks a little bit like a
chainsaw-approach when all you need is a screwdriver. :-)
On a more serious note, this mn++ is going to get you into trouble, assuming
"mn" means "Message Number" and the postfix-increment in Java happens to
work like it does in other languages -- i.e. it works in a
sample-value-then-increment fashion. (You'll notice that I have absolutely
no clue regarding Java.)
If it does, then you've just overwritten the message number you've put into
the CONNECT_REQ with its successor. Since a CONNECT_REQ cannot include a
PLCI yet (as those are assigned by the CAPI), the Message Number is the
only thing you have to correlate the CONNECT_CONF message to a CONNECT_REQ
you sent. I'd seriously consider storing this value somewhere. (Ouf course,
if you store the whole message object anyway, this point is moot.)
This can cause some problems when you send multiple CONNECT_REQs at the same
time -- from the CONNECT_CONF messages you cannot (without checking the
Message Number) know which CONF belongs to a certain REQ. CAPI doesn't
guarantee those CONFs to arrive in order.
Should you only want to have one call active or one CONNECT_REQ running at
any time, feel free to ignore this -- but it's bad style nevertheless.
Please note that the underlying CAPI won't use the Message Numbers you pass
down in any way -- the only thing the CAPI implementation does is returning
the same Message Number in a CONF corresponding to a REQ. So you could
(nifty trick ahead!) ignore those message numbers most of the time. Simply
pass 0 or whatever pleases you best in every REQ (except for CONNECT_REQs)
you send.
In a CONNECT_REQ you could use the Message Number to identify a "line" or
"call" you're going to establish. So, if you're planning to manage 30
simultaneous calls, you could have an array of "lines"/"calls" and use the
Message Number from the CONNECT_REQ/CONNECT_CONF as an index into it. Might
help to keep things on the easy side.
Post by Simon Hänicall.setWordValue("CIP Value",1);
byte [] calling = " 222".getBytes();
byte [] called = " 333".getBytes();
called[0] = (byte) 0x80;
calling[0] = (byte) 0x00;
calling[1] = (byte) 0x80;
Wouldn't this assignment overwrite the first digit of the Calling Party
Number with 0x80? It seems like you only have a single space before the
three digits. This, however, shouldn't influence call setup.
Post by Simon Hänicall.setStructValue("Called party number", calling);
call.setStructValue("Calling party number", called);
Now, this looks suspicious. Mind you, I have no clue regarding Java and have
never used JCAPI -- both of which is likely to never change.
But -- guessing wildly -- could it be the case that you've got your
capitalization wrong? If you follow the CAPI specification, those
parameters are named "Called Party Number" and "Calling Party Number",
respectively. With a capital P and a capital N, that is.
What does JCAPI do if you try to set a parameter that doesn't exist? Have
you tried something like "call.setStructValue("Hack and Slash", calling);"?
What does it do? Does it throw an exception? Does it continue silently?
That's the only idea that comes to mind -- as unlikely as it might be.
On the other hand, taking a second look into the CAPI specification it's
apparent that "Calling/Called party number" are spelt in both
capitalization variants, so most probably I'm way off here.
You could try setting the B-Protocol. CAPI defaults to HDLC/X.75
SLP/Transparent. While this must be supported by your CAPI implementation,
it's generally not what you'll want. Try setting it to
Transparent/Transparent/Transparent. This is, what's normally used for
speech transmission. Perhaps this already does the trick.
Post by Simon Hänicapi.putMessage(call);
--------------------------------
When I asked for posting the CONNECT_REQ, I meant the "packed" CAPI format,
i.e. a octet string like this: (It sets the B-Protocol suitable for a fax
transmission and has no Calling Party Number, but still...)
unsigned char msg[] = {
0x3A, 0x00, 0x1C, 0x00, 0x02, 0x80, 0xCF, 0x02,
0x01, 0x00, 0x00, 0x00, 0x04, 0x00, 0x05, 0x81,
0x34, 0x36, 0x33, 0x31, 0x00, 0x00, 0x00, 0x1A,
0x04, 0x00, 0x04, 0x00, 0x05, 0x00, 0x08, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x06, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
0x01, 0x00, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00,
0x00, 0x00,
};
Does JCAPI offer some means to extract the assembled message? I think this
would be immensely helpful in finding out what goes wrong.
Post by Simon Hänii hope this will help you. With phoner it works proper, the numbers are
also right.
If JCAPI indeed does offer some way to extract the message in a similar
manner, you could try to compare it to the CONNECT_REQ the Phoner software
sends. I think Phoner has a Debug-window where you can see exactly what it
sends and receives. Perhaps this could guide you a little in finding the
error. This, however, won't spare you from delving into the CAPI encodings
- which aren't too complicated anyway.
Regards,
Danilo