asterisk-java-users

[Asterisk-java-users] parsing dial plan extension patterns

[Aaron E. <aar...@gm...>]

Hi all,

I didn't see anything in the asterisk java API for parsing dial plan
extension patterns and I suppose it might be beyond the scope of the
problems the API solves anyway.

But I was wondering if anyone knows of any utilities out there for
parsing patterns.

Specifically, I'd like to be able to parse a pattern and determine:

1. If the set of possible matches is bounded or not (ie. fixed length).
2. In the case of bounded sets, whether it is purely numeric.
3. Some kind of match function to see if a given string matches the
pattern (perhaps by converting to a regular expression). It would be
cool if the match pattern could also accept a caller ID number as well
in case there is a filter there as well.
4. In the case of bounded sets, being able to iterate through the possibilities.

I realize this is quite a laundry list. I'll need to implement
something myself for my specific cases if there is nothing out there
already...

-aaron

Re: [Asterisk-java-users] parsing dial plan extension patterns

[Martin S. <ma...@be...>]

Hi Aaron,

I think the Asterisk JTAPI has some code that parses the dialplan and
internally uses Asterisk-Java. Last I tried, it failed to parse the
dialplan on one of my virtual machines, but I don't remember if that was
Asterisk 1.4 or 1.2. I believe some of the requirements of JTAPI
included providing information about available outgoing lines and
detecting pre-existing calls on startup, both of which could require
some dialplan analysis.

Though I have no need for it, the idea of parsing the dialplan does
sound intriguing to me. I would imagine others would find it useful too.
When I first considered it (when I tried to use Asterisk JTAPI a few
months back), I assumed the most useful part of parsing the dialplan
would be finding syntax errors without having to fiddle with the
dialplan on a production system.

Finally, I think you'll find that Asterisk itself obviously has a parser
for the dialplan and AEL, and that they would be trivial to port. You
might even be able to drop those source files into a JINI wrapper and
call them from Java, which would be a very simple solution.

But yes, I'm interested. No, I have no business requirements for it, but
do keep us informed if you attempt it :). I can't imagine there'd be a
strong case for NOT including that kind of functionality in AJ. Besides,
the actions to get configuration files already exist in the manager
interface :).

Martin Smith, Systems Developer
ma...@be...
Bureau of Economic and Business Research
University of Florida
(352) 392-0171 Ext. 221=20

=20

> -----Original Message-----
> From: ast...@li...=20
> [mailto:ast...@li...] On=20
> Behalf Of Aaron Evans
> Sent: Thursday, September 13, 2007 11:51 AM
> To: ast...@li...
> Subject: [Asterisk-java-users] parsing dial plan extension patterns
>=20
> Hi all,
>=20
> I didn't see anything in the asterisk java API for parsing dial plan
> extension patterns and I suppose it might be beyond the scope of the
> problems the API solves anyway.
>=20
> But I was wondering if anyone knows of any utilities out there for
> parsing patterns.
>=20
> Specifically, I'd like to be able to parse a pattern and determine:
>=20
> 1. If the set of possible matches is bounded or not (ie.=20
> fixed length).
> 2. In the case of bounded sets, whether it is purely numeric.
> 3. Some kind of match function to see if a given string matches the
> pattern (perhaps by converting to a regular expression). It would be
> cool if the match pattern could also accept a caller ID number as well
> in case there is a filter there as well.
> 4. In the case of bounded sets, being able to iterate through=20
> the possibilities.
>=20
> I realize this is quite a laundry list. I'll need to implement
> something myself for my specific cases if there is nothing out there
> already...
>=20
> -aaron
>=20
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Asterisk-java-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-users
>=20

Re: [Asterisk-java-users] parsing dial plan extension patterns

[Aaron E. <aar...@gm...>]

Hey Martin,

Thanks for the info.  If I do come up with something, I will certainly share it.

Speaking of Asterisk JTAPI, there doesn't seem to be a lot out there
in terms of asterisk specific examples.

I would like to know for instance how to implement a simple Originate
action in JTAPI.  It is unclear to me how the terminals, addresses and
so on map to the asterisk nomenclature.

Do you know of any good resources out there for JTAPI? Also, is it
even compatible with asterisk-java 0.3?

I guess this is a little off topic...

-aaron

On 9/13/07, Martin Smith <ma...@be...> wrote:
> Hi Aaron,
>
> I think the Asterisk JTAPI has some code that parses the dialplan and
> internally uses Asterisk-Java. Last I tried, it failed to parse the
> dialplan on one of my virtual machines, but I don't remember if that was
> Asterisk 1.4 or 1.2. I believe some of the requirements of JTAPI
> included providing information about available outgoing lines and
> detecting pre-existing calls on startup, both of which could require
> some dialplan analysis.
>
> Though I have no need for it, the idea of parsing the dialplan does
> sound intriguing to me. I would imagine others would find it useful too.
> When I first considered it (when I tried to use Asterisk JTAPI a few
> months back), I assumed the most useful part of parsing the dialplan
> would be finding syntax errors without having to fiddle with the
> dialplan on a production system.
>
> Finally, I think you'll find that Asterisk itself obviously has a parser
> for the dialplan and AEL, and that they would be trivial to port. You
> might even be able to drop those source files into a JINI wrapper and
> call them from Java, which would be a very simple solution.
>
> But yes, I'm interested. No, I have no business requirements for it, but
> do keep us informed if you attempt it :). I can't imagine there'd be a
> strong case for NOT including that kind of functionality in AJ. Besides,
> the actions to get configuration files already exist in the manager
> interface :).
>
> Martin Smith, Systems Developer
> ma...@be...
> Bureau of Economic and Business Research
> University of Florida
> (352) 392-0171 Ext. 221
>
>
>
> > -----Original Message-----
> > From: ast...@li...
> > [mailto:ast...@li...] On
> > Behalf Of Aaron Evans
> > Sent: Thursday, September 13, 2007 11:51 AM
> > To: ast...@li...
> > Subject: [Asterisk-java-users] parsing dial plan extension patterns
> >
> > Hi all,
> >
> > I didn't see anything in the asterisk java API for parsing dial plan
> > extension patterns and I suppose it might be beyond the scope of the
> > problems the API solves anyway.
> >
> > But I was wondering if anyone knows of any utilities out there for
> > parsing patterns.
> >
> > Specifically, I'd like to be able to parse a pattern and determine:
> >
> > 1. If the set of possible matches is bounded or not (ie.
> > fixed length).
> > 2. In the case of bounded sets, whether it is purely numeric.
> > 3. Some kind of match function to see if a given string matches the
> > pattern (perhaps by converting to a regular expression). It would be
> > cool if the match pattern could also accept a caller ID number as well
> > in case there is a filter there as well.
> > 4. In the case of bounded sets, being able to iterate through
> > the possibilities.
> >
> > I realize this is quite a laundry list. I'll need to implement
> > something myself for my specific cases if there is nothing out there
> > already...
> >
> > -aaron
> >
> > --------------------------------------------------------------
> > -----------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Asterisk-java-users mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/asterisk-java-users
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Asterisk-java-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/asterisk-java-users
>

Re: [Asterisk-java-users] parsing dial plan extension patterns

[Martin S. <ma...@be...>]

> -----Original Message-----
> From: ast...@li...=20
> [mailto:ast...@li...] On=20
> Behalf Of Aaron Evans
> Sent: Thursday, September 13, 2007 3:48 PM
> To: ast...@li...
> Subject: Re: [Asterisk-java-users] parsing dial plan=20
> extension patterns
>=20
> Hey Martin,
>=20
> Thanks for the info.  If I do come up with something, I will=20
> certainly share it.

Glad to help. My interest in it was to replace SIPTAPI with a Java-based
solution. I have Windows applications that only speak the Microsoft
Telephony API, and one happened to speak TAPI very poorly, and
deferenced null pointers from SIPTAPI that it shouldn't have (like when
SIPTAPI said the structure was zero bytes). I was looking to make
outgoing calls from our Windows application in this fashion:

Windows app --> GJTAPI --> Asterisk-JTAPI --> Asterisk

Unfortunately, GJTAPI mostly implemented the other way around, i.e.:

Java app --> GJTAPI --> MS TAPI --> Telephony Device

> Speaking of Asterisk JTAPI, there doesn't seem to be a lot out there
> in terms of asterisk specific examples.

Yes, I ended up going through the sources myself to find out what to do.
What it lacks in documentation, it makes up for in runtime exceptions
that complain when you don't give the right commandline arguments.

> I would like to know for instance how to implement a simple Originate
> action in JTAPI.  It is unclear to me how the terminals, addresses and
> so on map to the asterisk nomenclature.

>From what I can tell, the point of JTAPI is that (like TAPI), everyone
writes to the JTAPI API and then you don't need Asterisk-specific
examples. This is very similar to Microsoft Tapi -- you have clients
that know the API, and people who provide TAPI-like devices make a
service-provider (a TSP) that speaks the API from the other side.
=20
> Do you know of any good resources out there for JTAPI?

I think I remember discovering that I needed JTAPI 1.3 to get GCJTAPI
working, which made me go looking for the Java API files (they aren't in
Java SE). I got them at http://java.sun.com/products/jtapi/, which does
provide some HTML and PDFs about the specification. Beyond that, it was
Google and trying to run some examples and call some methods in a blank
main method :). I got it working, but discovered the chain (the one I
mentioned above) was in the wrong direction.

> Also, is it
> even compatible with asterisk-java 0.3?

JTAPI and AJ-3.0 are only related through Asterisk-JTAPI, and last I
looked, it wasn't able to use any Asterisk-Java version that was new (it
expected the org.sf... Packages from Asterisk-Java).

> I guess this is a little off topic...

Nah :)

Martin Smith, Systems Developer
ma...@be...
Bureau of Economic and Business Research
University of Florida
(352) 392-0171 Ext. 221=20