[jvr-general] Ring Test, what can we do?

[Kevin O'Donnell]

>   $EventDispatcher run MetaEvent{134;evtdev=2;}

Oi! "134" is the type of event that has been received.  If you convert it
to hex (0x86) and look in dxxxlib.h, you see that it is a TDX_CST - a
"Call Status Transition" event.  You can then take TDX_CST and dig deeper
to see that it's a ring received event.

I think this is what is happening:

- when you call dx_wtring(), that function changes the event mask to
  enable notification of DM_RINGS (ring received event).  The mask is
  not returned to the previous state after dx_wtring is finished.

- In the C program, there is no global event handler, so I think
  Dialogic is happy to *sit* on an unreported DM_RING event until the
  next call to dx_wtring.

- In JVR, there is a global event handler.  Since Dialogic is happy
  to report the event then assume that it's been taken care of, there
  is nothing in the event queue the next time dx_wtring comes around.

Attached is a modified version of Answer.java that provides a workaround. 
I'll work on a good solution to the API for the next release.

One question: why do you want the X seconds delay after going back on
hook?  Why not just answer the next call right away?

Don't forget that your caller may hang up after letting the line ring for
10 seconds.  You'll still go offhook, but nobody will be there.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Answer.java
Type: application/octet-stream
Size: 3955 bytes
Desc: not available
Url : http://threebit.net/pipermail/jvr-general/attachments/20040211/a9c88591/Answer.obj