Just after hitting the “Publish” button last week for my previous post on NuGram and CouchDB, I realized the code I wrote had a serious flaw.
Remember it? Here’s an excerpt:
#...
post '/ask_street.json' do
session = GrammarServer.new.create_session "username", "password"
tropo_event = Tropo::Generator.parse request.env["rack.input"].read
zipcode = tropo_event.result.actions.zip_code.value
grammar = session.instantiate "streets.abnf",
:zipcode => database.get(zipcode)
tropo = Tropo::Generator.new do
on :event => 'continue', :next => '/say_street.json'
on :event => 'hangup', :next => '/hangup.json'
ask({ :name => 'street',
:bargein => 'true' }) do
say :value => "What is your street address, beginning with your street number?"
choices :value => grammar.get_url("grxml")
end
end
tropo.response
end
#...
There are basically two problems with this code:
- On line 3, the application creates a new session on NuGram Hosted Server and the unique session ID is returned to the application. But there is no code to free the session. We cannot free the session on line 20 because the speech recognition engine will have to fetch a resource (the speech grammar) associated with the session.
- The other handlers of the application cannot reuse the same session, making it impossible to reuse resources (like grammars) from one request to the other.
Problem #1 is not a very serious one. The session will be automatically reclaimed by the server after 15 minutes of inactivity on the session.
But problem #2 is more serious, as it can lead to wasted resources on server side. If an application wants to ask the same question from two different handlers, using the same dynamic grammar, it can’t using the approach above. Two or more sessions will have to be created, and the grammar will have to be instantiated at least twice.
Providing a session ID explicitly
In fact, NuGram’s RESTful API was not the culprit. The Ruby API was simply missing a little something (I have since fixed it on github and the Ruby gem will soon be updated to reflect the change): a way to specify the session ID explicitly instead of letting NuGram forge a new one. This way, each handler can use a shared session ID when accessing NuGram.
(The Sinatra/Rack web framework provides a session management API to let the application store data that survives a single request. This would solve our problem too. But, as will be explained below, the explicit session ID is a superior solution.)
The updated Ruby API can now specify a session ID explicitly:
session = GrammarServer.new.session "username", "password", sessionid
The question is now: what do we use as the session ID?
Every communication platform I know (VoiceXML platforms, cloud telephony platforms, Asterisk, etc.) associates a unique identifier with each call. This is usually referred to as the call ID or the session ID. This is certainly one of the best IDs for your NuGram session. Why? Because this greatly simplifies debugging your application. If a problem occurs, it becomes very easy to correlate the communication platform’s logs and NuGram’s logs. But it can also be the application’s session ID (the jsessionid in the case of a Java web application). The idea is to use an ID that uniquely identifies your session across all the servers: communication platform, application server, grammar server, etc.
For instance, Tropo provides a session ID with each response. Here is how to use it in our previous example:
#...
post '/ask_street.json' do
tropo_event = Tropo::Generator.parse request.env["rack.input"].read
zipcode = tropo_event.result.actions.zip_code.value
sessionId = tropo_event.result.sessionId
session = GrammarServer.new.session "username", "password", sessionId
grammar = session.instantiate "streets.abnf",
:zipcode => database.get(zipcode)
#...








