Cmpe 491 / 492

Cmpe 491 / 492

Graduate Project
Graduate Project
Java Based SIP Agent
Java Based SIP Agent
SIP Programming
By
Alp Eren YILMAZ Alp Eren YILMAZ
Serdar YALCINKAYA Serdar YALCINKAYA
SIP Programming:
Session Initiation Protocol, so called SIP, is designed to be end to end , client
server session signaling protocol and by its nature it neither dictates network
configuration not product features or services. However any application that has a
notion of session most likely Internet telephoning or voice over IP application can be
implemented on SIP infrastructure. Since the applications heavily focus on sessions,
SIP primarily indicates session setup, termination and changes. Before going on the
arbitrary applications lets focus on the eisting Internet telephony applications
developed.
!he applications implemented on basis of SIP can be grouped into two ma"or
sub groups. !he first group of applications run as end devices on user site and the
others are servant programs running on the network as SIP proy, redirect or registrar
servers.
SIP follows H!!P programming model in order to allow the users or third
parties to program service applications like user agent clients, which are originating
calls, or user agent servers, which listens the incoming calls. Service applications
can be implemented using well#defined generic application program interface $%PI&
provided by the '%I(. Before the %PI implementation is handled Internet )ngineering
!ask *orce, I)!*, suggest three mechanism for SIP programming. !hese three
mechanisms are +ommon ,ateway Interface $+,I&, +all Processing -anguage $+PI&
and Servlets respectively.
In the following paragraphs, a comparative analysis of each mechanism is
handled in detail to understand the costs and benefits of each approach. It is beneficial
to remember similarity in the SIP programming model with H!!P.
!he first mechanism suggested by the I)!* is a special purpose call process
language similar to ./- that may be used by SIP servers. +P- provides the lowest
generality in case of the programming because only the +P- commands are allowed
to be eecuted. !he users determine call processing logic at the server site and
implements the scripts in +P- by manually or a third party ,0I tool. !here is one
ma"or disadvantage of +P- scripts. !hat is, +P- scripts need to be interpreted and
interpreting process causes high processing delays. 1n the other hand the limited
scope of the scripting language makes sure that the servers security and portability of
the services are satisfied.
!he I)!* suggest +ommon ,etaway Interface $+,I& programming for SIP
applications .%s SIP 2 +,I follows standard 3eb 2 +,I infrastructure, it also
supports proy services and processes responses. !he communication between the
client and server is through environment variables in order to keep state of each party.
!he main advantage of the +,I programming is the language independency that gives
the users the highest generality in usage. 1n the other hand, since the +,I programs
are relatively unlimited in power, more risk involves on the server site.
!he last approach for SIP programming rises from the 'ava site. !he general
H!!P Servlet architecture is applicable in SIP programming which compromises the
power of +,I programs with the security 4 portability of +P- scripts. However the
security issue is left to the 'ava site where the 'ava 5irtual /achine $'5/& is used to
protect server from the vulnerable scripts. % well#defined %PI is crucial in case of
SIP servlets implementation thus the implementation still continues under '%I(
initiative. !he %PI supplied '%I( thought to be a generic one that is applicable to not
only SIP but also any signaling protocols $PS!(, H676 etc&. !his generic approach
focus on telephony and thus restricts SIP services from integration with web and e#
mail.
Beside the suggested mechanism, there eists half do8en of call control
application interfaces are being developed by third party initiatives which try to
combine the advantages of different the mainstream mechanism, like Parlay or
improve the eistent ones such as '!%PI, +!I.
%s a conclusion, a uni9ue solution for the SIP service implementation does not
eists yet but there seems to be a huge interest 4 effort in creating and standardi8ing
the %PIs. However as the arena becomes more and more crowded, the choice of
appropriate service creation mechanism depends on different scenarios and use cases
where security, reliability, performance, portability and have different roles of
importance.
References:
Sisalem :., ;uthan ', 0nderstanding SIP, !utorial
Http<==iptel.org=sip=siptutorial.pdf
>osenberg :.', Shockey >., !he Session Initiation Protocol $SIP& ,
+omputer!elephony , 'une 7???
IP!el organi8ation web site 2 Http<==iptel.com
!he Source for 'ava !echnology, Http<=="ava.sun.com
'%I( %PI web site, http<=="ava.sun.com=products="ain=
'ava Servlet !echnology site, http<=="ava.sun.com=products=servlet=inde.html