[Asterisk-Dev] VXML (was Call control problems from Java)

Zac Wolfe zacw at safisys.com
Sat Oct 2 20:53:15 MST 2004


That sounds like a good plan.  That roughly corresponds to our approach as
well.

	>Parsing the CCXML documents into a runtime representation -- a
      >no-brainer for an interpreted version, some boundable work for a
      >compiled version (something that would compile the CCXML docs into
      >Java bytecode for faster execution)

I don't expect expect execution time to be much of an issue here.
Especially if you can cache the runtime representation of the VXML doc at
the server so the doc only needs to be parsed once.

      >The core Asterisk interface -- That's pretty much done

That's awesome.  Did you create a JNI bridge to the existing * files or did
you make your own java_res or something containing a bunch of utility
methods (I kinda did both)?

If you can help me with the following issue I'd *deeply* appreciate it:

When I call app_dial (using pbx.pbx_exec() )from Java, the call is made
correctly and, if answered, the 2 parties are connected.  However, if the
called party tries to transfer the call, both sides are disconnected instead
of the caller being transfered.  If I check the caller channel, its exten
and context values have been changed correctly (they correspond to the
transfer value entered by the callee).  I suspect it has something to do
with the jmp_buf but I'm not sure.  Are you seeing this behavior?  If not,
can you please describe how you're  executing * apps.  This issue has been
bugging me all week and is likely related to some other issues I'm fighting
as well.


Thanks,
Zac
-----Original Message-----
From: David Pollak [mailto:dpp-asterisk at projectsinmotion.com]
Sent: Friday, October 01, 2004 4:46 PM
To: zacw at safisys.com; Asterisk Developers Mailing List
Subject: Re: [Asterisk-Dev] VXML (was Call control problems from Java)


Zac,

I'm starting out with a Java-based CCXML module (August) and a very
light weight "dialog" module that will do single voice prompts with
associated DTMF responses.  August is a generic CCXML system with an
Asterisk interface.  It will initially only work with Asterisk, but the
interface to the transport/media layer will be pluggable so other it
supports other voice systems.

Here's the rough work scope:

    * Parsing the CCXML documents into a runtime representation -- a
      no-brainer for an interpreted version, some boundable work for a
      compiled version (something that would compile the CCXML docs into
      Java bytecode for faster execution)
    * Doing some of the CCXML document retrieval stuff -- a little work,
      but boundable
    * Implementing the JavaScript engine -- Rhino (an open source
      project under Mozilla) is an excellent JavaScript engine.  The
      only work would be to make sure the Rhino variable scopes match
      the CCXML spec
    * The core Asterisk interface -- That's pretty much done
    * Mapping Asterisk events to CCXML -- There may be a few events
      missing, but adding them is trivial
    * Mapping the CCXML commands to Asterisk -- this is probably going
      to be the most work.  Conferencing will have to be re-worked to
      map more closely to CCXML.  Some of the redirects may need some
      work as well
    * Maintaining state in a database and having fail-over with
      heartbeat -- non-trivial and may not be a 1.0 feature.  I can code
      with that in mind, but that part's probably 30% to 50% of the
      over-all project.

I'm working on finding a commercial/open source license a la the MySQL
license.  The product will be available for free as long as it's not
used in commercial production.  If it's used in commercial production,
there'll be some reasonable license fees.

Any contribution you can offer will be appreciated.

Thanks,

David


Zac Wolfe wrote:

>Ya I agree completely (especially after I read your earlier post about
>"changing *'s module invocation"). In some ways it's convenient for
>development to start asterisk from your java app but not the way you want
to
>go for production.  The version of JAsterisk i'm playing with right now is
>modified so I can go either way, JVM in * or * in JVM.  I haven't released
>it yet since my classpath is currently hardcoded into asterisk.c (doh!) for
>the former configuration.
>
>As you probably know, there are some strategies to reduce GC time and make
>Java more amenable to real-time applications (I think there's even a JSR
for
>a real-time api) but I agree it's not Java's strongpoint.  Are you building
>a VXML engine for Asterisk or a general purpose one? If it's going to be
>opensource (or even if it's not), please let me know if I can be of
service.
>
>Zac
>
>
>-----Original Message-----
>From: David Pollak [mailto:dpp-asterisk at projectsinmotion.com]
>Sent: Friday, October 01, 2004 2:18 PM
>To: zacw at safisys.com; Asterisk Developers Mailing List
>Subject: Re: [Asterisk-Dev] VXML (was Call control problems from Java)
>
>
>Guys,
>
>Doing CCXML and VoiceXML in Java is a great idea.  I've been working on
>it myself for a couple of weeks.  However, I'd strongly recommend
>against doing it in the same process as Asterisk for a number of reasons:
>- JVMs crash.  A crashing JVM should not bring your Asterisk process down.
>- If you run the JVM in a separate process that enables running it on a
>different machine and having one control machine handling multiple
>Asterisk instances.
>- You'll want to control the CCXML process from a web browser (e.g.,
>check on call status, etc.) Putting a web server (e.g., Tomcat) inside
>the Asterisk process doesn't make a lot of sense
>- If you want to access corporate data via Enterprise Java Beans
>(something that folks might want to do in a CCXML/VoiceXML application)
>you'll need an EJB container (WebLogic, WebSphere, JBoss)... which you'd
>also have to run in the Asterisk process.
>
>There's no real benefit to running the JVM in the Asterisk process and
>there are a lot of downsides to it.  My 2 cents -- do a bridge to an
>external JVM.
>
>Thanks,
>
>David
>
>Zac Wolfe wrote:
>
>
>
>>Actually VXML/CCXML isn't that huge.  Once we get the Java stuff sorted
out
>>(which is almost there), building a VXML interpreter in Java isn't that
big
>>a deal.  And, I like Java.
>>
>>Zac
>>-----Original Message-----
>>From: Steve Underwood [mailto:steveu at coppice.org]
>>Sent: Friday, October 01, 2004 12:11 PM
>>To: zacw at safisys.com; Asterisk Developers Mailing List
>>Subject: Re: [Asterisk-Dev] Call control problems from Java
>>
>>
>>Zac Wolfe wrote:
>>
>>
>>
>>
>>
>>>Hi Miroslav,
>>>
>>>I'd *love* to have some help on this project but lets see if our goals
are
>>>in sync.
>>>
>>>My overall goal is to develop a Java-based VXML/CCXML engine for
Asterisk.
>>>Achieving this requires that I have complete call control from Java.
>>>Optimally, we could then do away with the Asterisk Dialplan entirely and
>>>
>>>
>do
>
>
>>>everything via VXML/CCXML.  The AGI interface is OK but for my
application
>>>
>>>
>>>
>>>
>>I
>>
>>
>>
>>
>>>need fine-grained event-driven processes where we can track each call
from
>>>setup to tear-down and everything in between.
>>>
>>>
>>>
>>>
>>>
>>>
>>Why would it make any sense to build a huge thing like a VoiceXML again
>>in Java, when a perfectly good free one in C++ already exists? Reusing
>>OpenVXI seems far more sane.
>>
>>Regards,
>>Steve
>>
>>
>>
>>
>>
>>_______________________________________________
>>Asterisk-Dev mailing list
>>Asterisk-Dev at lists.digium.com
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>To UNSUBSCRIBE or update options visit:
>>  http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>
>>
>>
>
>
>
>
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>








More information about the asterisk-dev mailing list