by gvag

Mobicents Arquillian Sip Servlets Extension 1.0.0-ALPHA1

The 1.0.0-ALPHA1 release of the Arquillian Sip Servlets extension has been released.

This extension will bring all the goodies of Arquillian to Sip Servlets testing. It provides two embedded containers, Tomcat 6 and Tomcat 7, running Mobicents Sip Servlets 1.7.0.

Together with SipUnit 2.0.0, this extension will provide a complete environment to test Sip Servlets applications. And of course since SipUnit uses Junit, tests can be performed either inside an IDE such as Eclipse or using Maven surefire.

You can have complete control over the container’s lifecycle and also the test archive deployment (your Sip Servlets application) in order to meet the special needs of any testing scenario.

User Guide can be found here

Several examples of the project can be found here

Any bug you discover or you have a feature that you would like to see in the next release, please post it here

Maven artifacts can be found in the following repository:

    <repository>
            <id>mobicents-releases-repository</id>
            <name>Mobicents Releases Repository</name>
            <url>https://oss.sonatype.org/content/repositories/releases/</url>
    </repository>

Any feedback would be much appreciated in order to improve the project.

by gvag

Locating SIP Servers – Comments on the RFC3263 for SIPS URIs

RFC3263 describes the DNS procedure and guidelines to be followed in order to locate SIP Servers. From the abstract of RFC3263:

The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform
Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It
also uses DNS to allow a server to send a response to a backup client if the primary client has failed.
This document describes those DNS procedures in detail.
When it comes to implement the proposed guidelines from RFC3263 in order to locate SIP server, the specification doesn’t seem to cover enough all the possible situations, specially for SIPS URI, and that is why we should consider to change some points there.
The purpose of this post is, first to indicate which points of the proposed RFC3263 mechanisms could create problems when it comes to resolve the transport for SIPS URIs and how these points should be changed by applying some rules on the results of the DNS query. Second this post provides what is the minimum DNS configuration for SIP, that is the minimum required NAPTR, SRV and A records according to the RFC3263.

Continue reading →

by gvag

CDI-Telco-Framework

With the advent of JSR 299 CDI it was about time to present a framework for Sip Servlets based on CDI and so CDI-Telco-Framework is here. Check the release announcement in the Mobicents google group.
In this article I will try to provide an overview of what CDI-Telco-Framework can do for you and a tutorial for your first application based on CTF.

Continue reading →

by gvag

Converged HTTP/SIP applications using asynchronous processing

Mobicents Sip Servlets 2.0.0 Alpha1 on top of Tomcat 7.0.5 is already here and the efforts of the MSS team continues toward complete integration with JBoss AS 7.

Tomcat 7 implements the fresh Java Servlets 3.0 spec – and JBoss AS 7 is targeted to implement it as well – which among others brings two significant features, the asynchronous processing of requests and a new set of annotations, to add on top of the existing annotations, that can be used to define a web servlet, thus make the web.xml deployment descriptor optional (Sip Servlets 1.1 – JSR 289 already provides a set of annotations that can be used in order to define a sip servlet, so make optional the sip.xml deployment descriptor also).

Continue reading →

by gvag

JTapi hands-on, part II

This is the next article in the JTapi hands-on series that will present the Call and Connection interfaces from the Jtapi API. Using the Call and Connection interface, this article shows how to create and disconnect calls, and also inspect Connections of a call. This tutorial could be the base for a dialler application or a connector for a PBX with a CRM application.

Also please note that this article builds upon the previous articles JTapi Overview and JTapi hands-on, part I.

Continue reading →

by gvag

JTapi hands-on, part I

The story so far

In the first article there was an introduction to the basic interfaces of JTAPI, that is JtapiPeer, Provider, Address, Terminal, Call and Connection. These are the basis on which we will built upon and continue in this article.

Starting from this article, I will leave the plain theory behind, and I will delve into the Jtapi objects using code examples. Off course, each code snippet, will be supported by the appropriate theory in order to elaborate and deeply analyze each object.

This iteration will concentrate on the JTapiPeer and Provider interfaces, and will present the way can be used to further inside an application using two example classes. The first one ProviderService mainly shows how to use JtapiPeer in order to instantiate and supply the Provider object for the second class JTapiDiscovery which purpose is just to discover the Addresses and Terminals from the Provider’s domain.
Continue reading →