So far it looks a good and valid option. However, there is a hidden risk.
A pure Java implementation would have a fatal limitation with regard
to interoperability with other native applications. They could not work
at the same time. The reason is subtle yet quite simple: competition
for shared resources - network ports. To accept incoming SIP requests
over the default SIP port (or another shared port) both the pure Java
implementation and the native SIP stack would try to acquire the port
number (e.g., 5060, the default SIP port). The first application execution
environment to take ownership of the port would be the one whose hosted
SIP applications would receive incoming SIP requests. Such behavior that
violates interoperability is not acceptable in Symbian OS, which is
designed to run multiple applications simultaneously.
Let us consider a scenario in which the Java ME execution environ-
ment is competing with native Symbian applications. A user might have
a native VoIP client that uses the native SIP API and which requires
the loading of the native SIP Client Resolver framework. At the same
time, a Java application, which was added to the MIDP Push Registry
during installation, is waiting for its activation by an incoming SIP INVITE
request, signaling the Java application to join a multimedia streaming
session. The first application to be activated causes its application exe-
cution environment (Java or native) SIP stack to load, preventing the
other application execution environment and all of its applications from
receiving SIP messages.
A pure Java implementation for JSR-180 SIP is indeed fit for purpose
on mobile platforms which have no native SIP stack or can run only
Java applications. But in Symbian OS, which is designed to run multiple
applications simultaneously, such a solution would not be acceptable.
Using JSR-180 SIP we discussed a case where tight integration was
applied to enforce consistent behavior and functionality. Later, when
suggesting an alternative implementation, we discovered that in this case,
surprisingly, the integration was essential for interoperability with native
Another facet of integration demonstrated in this case is an integration
which is final and does not require Symbian OS licensees to provide
extensions or customization; JSR-180 and the native SIP stack are both
shipped ready to go.
One last issue that was obvious to identify is the possible complexity
of providing a tightly integrated JSR. In the example of JSR-75 FileCon-
nection, the Java APIs mapped well to the native APIs. A straightforward
implementation was sufficient to provide bindings for all functionality. In
the integration of JSR-180 SIP, the size of the native architecture and the
different designs have made the integration more challenging by an order