It has been a while since I last wrote on my experiences implementing code that consumes Broadsoft events. I’ve been reworking the code, upgrading it to version 19 of the spec, and I noticed an improvement since version 18. That’s what this post is about. 

Recap: You need a persistent HTTP connection to the Broadsoft provider in order to process Broadsoft XSI events, as the provider will push XML documents containing events on that connection. You’ve been throught the HTTP connection setup, the keep-alive message sequence and you’re ready to create a call subscription. Creating a subscription is pretty straightforward, but the provider breaks your connection shortly after confirming the subscription using a ChannelTerminatedEvent.

Why is the provider terminating the connection? Well, pretty simple. You’ll need to respond to a number of events, allowing the provider to verify that the remote end – your application – is still active. The Broadsoft environment will conclude that your application has gone inactive when a response is not received. It’s in the documents. You’ll need an account to access the documents, though.

The XSI event now contains a reason indication as well, which I consider to be an improvement. You’ll receive a ChannelTerminatedEvent with NonResponsiveChannel reason. Add the confirmation and you’re set.

Hope this helps. Feel free to comment.