I have publicVoiceXML-2.6.1 setup on a W2K machine communicating with a Lucent Definity PBX and an Eicon Diva PCI 2.02 ISDN card with CAPI driver.
I cannot get it to answer an incoming call. In the traces it looks like the NCCI valaue is wrong in one area just after the incoming call indication. In other places it looks correct.
I have applied the patch and tried various configurations of the ISDN card and switch with no change in behaviour.
Aug 30 17:41:24.95|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Line found
Aug 30 17:41:24.95|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Searching for line PLCI matching 0x101 (from NCCI)
Aug 30 17:41:24.96|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Line found
Aug 30 17:41:24.97|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[NOTICE ] ----------------------------------------------------------------
Aug 30 17:41:24.98|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[NOTICE ] [B3IND] Incoming (logical) Call
Aug 30 17:41:24.98|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[NOTICE ] ----------------------------------------------------------------
Aug 30 17:41:24.99|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Searching for logical line with NCCI 0x40101
Aug 30 17:41:25.00|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Line found
Aug 30 17:41:25.01|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Searching for logical line with NCCI 0x101 <-- LOOKS WRONG!!!
Aug 30 17:41:25.01|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[WARNING ] No line found with NCCI 0x101 <-- Not found!!!
Aug 30 17:41:25.03|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Searching for logical line with NCCI 0x40101
Aug 30 17:41:25.04|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Line found
Aug 30 17:41:25.10|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Searching for logical line with NCCI 0x40101
Aug 30 17:41:25.10|TUCPU=0|TKCPU=0|-1|60001|CC|CC:[DEBUG ] Line found
.. Continues until originator hangs up.
this looks strange. it seems as if a PLCI is provided where PVX is expecting a NCCI (0x101 is the physical identifier). so the basic problem _could_ be that pvx cannot locate the line due to this issue. on the other hand, pvx can afterwards locate the correct NCCI (0x40101), which means that the connection should be established. additionally, hanging up seems to work...
up to the point you have described, the call has already been accepted. which tts do you use? what does your VoiceXML file look like?
imho, pvx does answer the call, the issue should be located somewhere else (hoepfully *g*)
Thanks for your reply.
Looking through the code in "Controller.c" and "PVXControllerInfo.h" I suspect that the issue is due to assumptions made by the compiler regarding the size of "adrPLCI" (the lower half of adrNCCI). In CAPI20.H "adrPLCI" and "adrNCCI" are both declared asa union of _cdword values where adrPLCI should only be a 16 bit value.
Currently we changed the NCCI comparison to succeed if only the bottom 16 bits match and the connection succeeds and correctly emits my prompt(I am using the simple helloworld.vxml script).
I am in the US so I had to modify the A-LAW encode functions (wav.c) in order to get intelligible speech.
While running under the debugger I can see that the NCCI value is getting corrupted somewhere but I haven't found where yet.
I am not working on getting record to work - I get a couple of errors (including a mutex assertion failure) just after playing prompts before going into record.
thanks for any insight.
Segment of trace file follows:
Sep 03 10:06:52.04|TUCPU=1602|TKCPU=270|-1|60001|CC|CC:[DEBUG ] Starting Record
Sep 03 10:06:52.05|TUCPU=1602|TKCPU=270|-1|60001|CC|CC:[INFO ] Recording: *c:\publicVoiceXML/recordings/20040903_100651AM_message_0.wav*
Sep 03 10:06:52.06|TUCPU=1602|TKCPU=270|0|8000||GrammarManager::InternalRecognize - VXIrecInterface::Recognize returned status -842150451
Sep 03 10:06:52.07|TUCPU=1602|TKCPU=270|0|com.yourcompany.vxi|420|message=function returned an invalid VXIrecStatus code
Sep 03 10:06:52.07|TUCPU=380|TKCPU=230|-1|60001|CC|CC:[DEBUG ] Searching for logical line with NCCI 0x20101
Sep 03 10:06:52.08|TUCPU=390|TKCPU=230|-1|60001|CC|CC:[DEBUG ] Line found using full NCCI
Sep 03 10:06:52.09|TUCPU=1602|TKCPU=270|-1|60001|CC|CC:[DEBUG ] Searching for line with VXI-Channel-No 0x0
Sep 03 10:06:52.10|TUCPU=1602|TKCPU=270|-1|60001|CC|CC:[DEBUG ] Line found
Sep 03 10:06:52.10|TUCPU=1602|TKCPU=270|-1|60001|CC|CC:[DEBUG ] Line found
(from console) Assertion failed: "VXItrdMutexLock( ) on already locked mutex" == NULL, file c:\
publicvoicexml\src\trd\osbtrdwin32.cpp, line 201
are you restricted to a windows-environment? because if you are not and you are planning to make heavy code-changes, i'd really advise you to use version 3.0.
i am not 100% sure, but if i remember correctly, the CAPI 2.0 spec requires both PLCI and NCCI to be 32-bit (or rather 2 word) values.
i gather that accepting calls works with your modifications? interesting...
if you do a re-write of the replaying code, can you provide it e.g. as patch so that other users from the U.S. can use it, too? that would be great!
concerning your issue with recording a message: (a) a lock on an already locked mutex should not result in an assertion, but in a situation where the code-execution stops until the lock is released. probably this error indicates a dead-lock, though i am not sure.
the most obvious reason i can gather from the log you provided is the fact that the VXIrecInterface::Recognize() returns an invalid status, though i previously was not aware of such a return code. it looks as if the function enters a branch of execution where the value of the return-variable remains uninitialized. strange.... i'll look into the code this weekend, if i have time. today it's just too late to do so ;-) sorry.
i hope this helps you in some way,
Thanks for the additional info and recommendation. I suspected it may be better to use versin 3.0 on Linux so I am just in the process of bringing up a machine sith Suse Linux to use.
The CAPI spec is slightly inconsistent regarding the definition of PLCI - it is defined as a double word 32 bit) with the top 16 bits being zero. But it also states that bits 8-15 of the the PLCI are the PLCI!
The controller and an ext/int bit make up the bottom 8 bits so that a 16 bit word is all that is required to define the actual Physical Link. The NCCI is also a dword and has an identical layout for the bottom 16 bits with 16 bits of NCCI(!) for the top half. So the way you are using it is reasonable but if the dword PLCI is ever written into the shared variable the top 16 bits of the NCCI/PLCI will be cleared (the problem I am seeing).
I will submit the changes to wav.c when I have them all running correctly although my current plan is to both play and record wav files in the native telephone format (uLaw for me, but should work for Alaw as well) as the files will be smaller and any external player already has the capability for playing ulaw/alaw files. I will need a lin to ulaw/alaw encoder for TTS but that should be simple enough, TTS is not an important part of my requirements.
if i remember, CAPI defines a common Controller/PLCI/NCCI field for all messages. thus, it is sensible to make PLCI a double word, too. otherwise, if it was only one word and written into the message, it would not be ensured that all previous entries are cleared. since the NCCI is basically composed of the PLCI plus an identifier, i'd assume the desired behaviour for writing a PLCI into the message is to erase all previous contents (including the NCCI). This should not be a problem, sind the PLCI/NCCI field should contain only either PLCI or NCCI, not both at the same time.
i am really looking forward to your patch, since i assume that using the native format has the capability to save an amount of processing power.
I seem to have a similiar problem.
I am trying out publicVoiceXML 261 on a Win2K machine, with a Zyxel Omni.net Plus....
Initially it wouldn't even pick up calls... Now, after the DDILen=0, patch (https://sourceforge.net/tracker/index.php?func=detail&aid=887677&group_id=69144&atid=523557) it seems to detect incoming calls and detects it as disconnected after I hang up the phone....
However, I still get the message [WARNING] No line found with NCCI 0x1000F00
I don't hear anything on the phone (with the hello_world.vxml)
thats it, it just keeps waiting there until I hang up.... ... (doesnt keep showing new messages the way kevinjwhite's setup was doing)
After I give up and hang up, it says [INFO] [B3DIS] Disconnect reason 0x0 (..)
I was hoping that the issue was the same one being discussed here... Did anyone manage a workaround for it yet? Or do we have some kind of patch for it?
Any help would be really appreciated ...
I am using the binary build and haven't had a chance to try building the code myself.... So I was really hoping for a patch :) But if a code change is necessary, I would be grateful if someone could point me in the right direction...
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.