Java Reference
In-Depth Information
String
-based parameterized operations. The native API takes a different
design approach; it is based on a class hierarchy in which there is a
class-based abstraction for every SIP method or header.
SipConnection
, the base interface for SIP connections, defines the
String
-based
addHeader()
and
setHeader()
methods to manage
SIP message headers;
SipClientConnection
defines the
String
-
based
initRequest()
method to initialize the SIP request. In the
native SIP API, the application typically needs to instantiate a
CSIPMes-
sageElements
object when it is going to send a SIP request. The
headers that are put into the
CSIPMessageElements
object are not
String
s but are encapsulated in subclasses of the
CSIPHeaderBase
class (e.g.,
CSIPContactHeader
). Another class,
CSIPRequestEle-
ments
, contains the
CSIPMessageElements
and the mandatory parts
of any SIP request such as the To header, From header, Remote URI, and
request method.
In the native SIP API, each supported SIP method is encapsulated by a
subclass of the
CSIPDialogAssocBase
class (e.g.,
CSIPInviteDi-
alogAssocBase
).
These different design approaches enforce different API usage. For
example, using JSR-180 SIP, the application creates a
SipClientCon-
nection
using the GCF factory method, invokes
initRequest()
with
an INVITE
String
, and adds or sets the headers using
addHeader()
or
setHeader()
. The following snippet of code demonstrates sending
an INVITE:
scc = (SipClientConnection) Connector.open(address.getString());
// initialize INVITE request
scc.initRequest("INVITE", null);
scc.setHeader("From", "sip:user@host.com");
scc.setHeader("Accept-Contact", "*;type="app/chess"");
scc.setHeader("Contact", "sip:user@" + localAddress);
scc.setHeader("Content-Length", "" + sdp.length());
scc.setHeader("Content-Type", "application/sdp");
Using the native API, the application creates the
CSIPInviteDi-
alogAssoc
and
CSIPMessageElements
objects. The application fills
the relevant SIP headers into
CSIPMessageElements
before passing it
to
CSIPInviteDialogAssoc
using the
SendInviteL()
function.
In short, the two APIs are fundamentally different. The solution to those
different design approaches was to have native peers for Java objects,
which would include an internal layer whose functionality is to translate
between
String
s and classes.
Since there is no exact equivalent in native code to the Java classes,
a peer object is actually a container of native SIP classes executing upon
them according to changing states, triggered by Java method invocations.