Testing your Broadsoft XSI backend

A quick post on Broadsoft XSI again. Why? Well, because it’s an interesting subject. I learned that there are not too many people actually developing to it. So here’s something about testing the software, assuming you’re developing against RoutIt VOIP platform.

Here’s what I used to test the way the software deals with connectivity changes to the provider:

  • Make sure your code allows access through a proxy as it enables you use Fiddler. This is a valuable tool that’ll show you how your software reacts to a rainy day scenario, like slow response times and broken connections. Check this post for additional details. There’s a nice side-effect that occurs when you close Fiddler while your application is connected through the proxy in Fiddler
  • Use Windows firewall to manage connectivity. Change settings while your software is active to learn how your application reacts when connectivity is suddenly lost. You would typically forbid access by adding a rule for an outgoing connection, as explained in the article on this page
  • RoutIt has a test application available for both actions and events. You can use these pages to learn how your software reacts to unexpected channel closure. And when that happens to a subscription. Take caution when you actually use a function on these pages as you might crash test a live application

Thanks for reading this and feel free to contact me. Hope this helps and let me know when I missed something.

One thought on “Testing your Broadsoft XSI backend”

  1. Hi, could you please email me regarding XSI HTTP implementation for inbound call monitoring?

    Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *