The cool aussi guys at Atlassian had another FedEx day. One of the plugins for their issue tracker JIRA they implemented is JIRA Caller ID.

Though JIRA is mainly used to track issues in software development projects this is by far not the only way to use the tool. JIRA is used to track support requests, project issues and Atlassian even uses it to track candidates in their recruitment process. Issues can be entered directly through their web UI, they can result from incoming emails and of course phone calls. So they had the following idea:

Why not improve JIRA's abilities as a tool for capturing and responding to telephone enquiries? Most calls include Caller ID, showing the called party the caller's telephone number. Why not use this information to automatically retrieve the caller's information in JIRA, saving time and frustration for both parties?

The solution they came up with extracts the Caller ID from the current call and finds the corresponding JIRA user so you can easily access the the caller's profile from which you can search for his open issues. In addition to that the new plugin saves a call history complete with recordings of answered calls:

The plugin will soon be publicly available from Atlassian's plugin library. For now you can get the details from Adrian Hempel's blog entry: JIRA Caller ID.

Add a comment

Posted by Stefan Reuter on September 13, 2007 11:51:52 PM CEST #

Patrick has joined our small team of developers and will help us improve the Live API which is the part of Asterisk-Java we will focus on for our 1.0 release:

While checking for new versions I noticed the "new" Live-API. I am really pleased for that feature. but I miss some things. For example a function to retrieve the logged in/out agents for a queue. My first approach was to extend asterisk-java for my own, but I would like to offer my participation on asterisk java development.

So welcome again, Patrick, and thanks for your support!

Responses[1]

Posted by Stefan Reuter on September 12, 2007 11:30:00 PM CEST #

Asterisk-Java 0.3.1 has been released and is available from http://asterisk-java.org/download/0.3.1.

0.3.1 is a maintenance release, here is the Changelog:

Bug

• [AJ-81] - executeCliCommand() always executes "show voicemail users"
• [AJ-86] - getChannelByName doesn't return the latest channel

Improvement

• [AJ-79] - Support for the CallWeaver protocol identifier
• [AJ-80] - getMeetMeRooms() should only return active rooms

New Feature

• [AJ-68] - Support for Bridge Action
• [AJ-74] - Support Strategy property in QueueParamsEvent

Task

• [AJ-78] - Documentation needs thorough examples of the Live API

Add a comment

Posted by Stefan Reuter on September 5, 2007 6:12:00 PM CEST #

"BioCluster is a clustering platform for Asterisk. It is installed alongside Asterisk on several machines and can turn them into a VoIP cluster.
BioCluster doesn't require changes to the Asterisk code, but communicates with it as needed by using Asterisk-Java. Although the peer-to-peer protocol used by BioCluster was originally designed to make Asterisk clusterable, it is separate from any Asterisk-dependent parts and can be adapted to make other platforms clusterable.

All data is shared across nodes in the cluster. This includes extensions, trunks, dialplan data, AGI scripts, configuration and many other types of data. Thus there's no single point of failure. Expanding a cluster with another machine is just a matter of connecting it to the network and giving it the right shared network secret. When a new node connects to the network, it discovers other nodes in the cluster and retrieves all relevant data.

BioCluster uses Asterisk-Java for several uses. It is used to monitor events, for example for keeping track of active channels on a local machine and sending updates about these channels to other nodes in the cluster. We also use it for sending events to Asterisk, e.g. hanging up a channel. Another feature used is the FastAGI server functionality provided in Asterisk-Java to support AGI scripts.

Using the Asterisk Management Interface would have normally been inconvenient and prone to trouble, but Asterisk-Java turned it into a simple task. Its API is extensively documented, which helped easily find the right classes for the task."

Meni Livne, BioCluster Maintainer, Atelis PLC

Responses[2]

Posted by Stefan Reuter on July 23, 2007 9:16:15 PM CEST #

I thought it might be interesting to see what kind of applications other users of Asterisk-Java are building on top of our library. Therefore we will see a series of blog entries here featuring the products of our users.

iSymphony is an easy-to-use, Java-based client/server software for managing phone calls via the Open Source Asterisk platform.

It uses Asterisk-Java to connect to a plain Asterisk server or iPBX, an Asterisk appliance sold by i9 Technology. iSymphony consists of a server and a client application both written in Java for platform independence.

A free edition for non-commercial use is available for download.

Do you also have an interesting project or product that makes use of Asterisk-Java? Let me know and present it here.

Responses[1]

Posted by Stefan Reuter on July 6, 2007 4:02:00 PM CEST #

Steve Prior has ported the sample application of the LumenVox Speech Engine to Asterisk-Java. His code is now available at the Asterisk Speech Application Zone.

What do you think about speech-enabled applications? Would you like to see native support for the LumenVox API in Asterisk-Java?

Responses[4]

Posted by Stefan Reuter on July 5, 2007 11:28:00 AM CEST #

Asterisk-Java 0.3 has been released and is available from http://asterisk-java.org/download/0.3.

Asterisk-Java 0.3 is the new stable release with full support for Asterisk 1.4 and the new Live API (org.asteriskjava.live). The Live API takes care of the lowlevel action and event handling of the Manager API and offers an intuitive API for Java developers. Asterisk-Java takes advantage of the features of Java 5.0 and therfore requires a Java Virtual Machine of at least version 1.5.0.

Here is the Changelog:

Bug

• [AJ-30] - Version detection does not work when restarting Asterisk
• [AJ-59] - Incorrect class and method names when using JavaLoggingLog
• [AJ-60] - DefaultManagerConnection.sendEventGeneratingAction() doesn't work with Asterisk 1.4.1

Improvement

• [AJ-50] - Support for Asterisk 1.4
• [AJ-54] - AsteriskQueue observer and Park events fixes
• [AJ-55] - Add "videoSupport" and "realtimeDevice" to PeerEntryEvent
• [AJ-56] - Add "callerIdNum" to AbstractChannelEvent
• [AJ-57] - Add "memberName" to AbstractQueueMemberEvent
• [AJ-58] - Support for OpenPBX

New Feature

• [AJ-43] - Support GetConfig and UpdateConfig actions
• [AJ-62] - Add executeCliCommand() method to AsteriskServer

Task

• [AJ-2] - Update design doc and tutorial according to AGI changes

Thanks to Martin B. Smith for working on Asterisk 1.4 support and fixing the remaining issues

Documentation for 0.3 is available at http://asterisk-java.org/0.3/.

Responses[3]

Posted by Stefan Reuter on July 1, 2007 11:45:00 PM CEST #

Whenever you want to place a call between two extensions in the dialplan you have to use Local channels.
The OriginateAction that you use when placing calls through the Manager API requires a channel name for the first leg. Usually your application has no knowledge of the dialplan details, i.e. it does not know which channel is triggered by an extension (maybe it's a SIP hardphone, an IAX device or a link to another Asterisk server). What you want to do is "place a call between number a and number b" and leave the rest to Asterisk.

Local channels act as a proxy to the real channels mapped to an extension. So to place a call from 1310 to 1299 your Originate looks like:

Channel: Local/1310@from-local
Context: from-local
Exten: 1310
Priority: 1

instead of

Channel: SIP/1310
Context: from-local
Exten: 1399
Priority: 1

There is an article about Local Channels at voip-info.org that covers the basics.

So that's all very nice and looks straight forward. It becomes more interesting if you have a look at what happens under the hood:

A Local channel actually consists of two channels in Asterisk: Local/XXX,1 and Local/XXX,2. The Local/XXX,2 channel traverses the dialplan starting at the context and extension you provided. In our example this is the extension 1310 in from-local. If you watch the CLI or the events triggered you will see:

Set(_ALERT_INFO=<Bellcore-dr1>)
Macro(localexten|1310|SIP/1310)
Dial(SIP/1310|30|t)

This corresponds to the defintion of 1310 in my dialplan:

[from-local]
exten => 1310,1,Set(_ALERT_INFO=<Bellcore-dr1>)
exten => 1310,n,Macro(localexten,${EXTEN},SIP/${EXTEN})

[macro-localexten]
exten => s,1,Dial(${ARG2},30,t)
exten => s,n,Goto(s-${DIALSTATUS},1)
exten => s-NOANSWER,1,Voicemail(u${ARG1})
exten => s-NOANSWER,n,Hangup
exten => s-BUSY,1,Busy
exten => _s-.,1,Goto(s-NOANSWER,1)

The Dial command triggers an additional channel (SIP/1310). This is the actual channel that is proxied by the Local channel.

The other side of the Local channel, Local/XXX,1, is used for the desination. In our example this is the extension 1299 in from-local. You see similar events for this channel. The actual channel that is triggered for 1299 is an IAX channel to another Asterisk server: IAX2/iax_reucon_net-3.

Now we reach the point where we have four channels set up: The two sides of the Local channel and the two "real" channels SIP/1310 and IAX2/iax_reucon_net. Two channels are now longer needed and will vanish. Before this happens all data of the proxied channel is copied (masqueraded) to Local/XXX,1 so that Local/XXX,1 is renamed to SIP/1310. The "old" SIP/1310 channel is renamed to SIP/1310-0820f718<MASQ> and finally to Local/1310@from-local-1e71,1<ZOMBIE> before it is hung up. Local/XXX,2 is hung up without any renaming.
So in the end you have exactly what you would have expected: Two channels, SIP/1310 and IAX2/iax_reucon_net up and connected.

I have prepared a nice diagram that shows all these steps in detail and helps you understand what happens:

• Diagram: Originate with Local channel

Responses[12]

Posted by Stefan Reuter on April 18, 2007 12:31:00 AM CEST #

The most important issue we have to resolve before we can release Asterisk-Java 0.3 is full support for Asterisk 1.4

The challenge is to find all changes. Unfortunately the Changelogs do not record all of them so the only way to go is looking through the whole source tree and checking all events and actions for the Manager API and the supported requests for FastAGI.

Many thanks to Martin B. Smith who continued that work and provided support for the GetConfig and UpdateConfig actions and is currently working on AJ-50.

You can also help us by providing feedback on what's still missing. Just post a short comment to AJ-50 and tell us which new properties, actions, events or FastAGI changes you encountered.

Add a comment

Posted by Stefan Reuter on March 23, 2007 12:36:00 AM CET #

Using a dependency injection framework like the Spring Framework to exernalize your configuration is often a great enhancement for maintainance and deployment of your application.

If you are building an AGI application using Asterisk-Java the following code snippets will show you how do it.

<beans xmlns="...">

	<bean id="agiServer" class="org.asteriskjava.fastagi.DefaultAgiServer"
		init-method="startup" destroy-method="shutdown">
		<property name="mappingStrategy" ref="mappingStrategy" />
	</bean>

	<bean id="mappingStrategy" class="org.asteriskjava.fastagi.SimpleMappingStrategy">
		<property name="mappings">
			<map>
				<entry key="hello.agi" value-ref="helloAgi" />
			</map>
		</property>
	</bean>
	
	<bean id="helloAgi" class="HelloAgi">
		<property name="voicePrompt" value="tt-monkeys" />
	</bean>

</beans>

Read more...

Responses[5]

Posted by Stefan Reuter on March 22, 2007 10:58:00 PM CET #