JBoss.orgCommunity Documentation

JBoss Communications JAIN SLEE Sip Service Example User Guide

by Eduardo Martins, Bartosz Baranowski, and Alexandre Mendonça

Abstract

This is user guide to SIP Services example.


This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.

In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default.

Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.

Mono-spaced Bold

Used to highlight system input, including shell commands, file names and paths. Also used to highlight key caps and key-combinations. For example:

The above includes a file name, a shell command and a key cap, all presented in Mono-spaced Bold and all distinguishable thanks to context.

Key-combinations can be distinguished from key caps by the hyphen connecting each part of a key-combination. For example:

The first sentence highlights the particular key cap to press. The second highlights two sets of three key caps, each set pressed simultaneously.

If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in Mono-spaced Bold. For example:

Proportional Bold

This denotes words or phrases encountered on a system, including application names; dialogue box text; labelled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:

The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in Proportional Bold and all distinguishable by context.

Note the > shorthand used to indicate traversal through a menu and its sub-menus. This is to avoid the difficult-to-follow 'Select Mouse from the Preferences sub-menu in the System menu of the main menu bar' approach.

Mono-spaced Bold Italic or Proportional Bold Italic

Whether Mono-spaced Bold or Proportional Bold, the addition of Italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:

Note the words in bold italics above username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.

Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in the the Issue Tracker, against the product JBoss Communications JAIN SLEE Sip Service Example, or contact the authors.

When submitting a bug report, be sure to mention the manual's identifier: JAIN_SLEE_SipServices_EXAMPLE_User_Guide

If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

This example is a JAIN SLEE application which processes SIP Messages from SIP UAs to act as a simple proxy and registrar.

Example implements proxy routines defined in section 16 and registrar routines defined in section 10 of RFC3261.

It is not a trivial example as it provides usage of

  • child relations

  • timers

  • null activities

  • SBB activity context interfaces

  • activity context interfaces variables

  • SBB environment entries

  • SBB local interfaces

  • SBB local interfaces

  • JAIN SIP RA code

Thus it should be considered as target for more advanced users.

Example service is capable of routing SIP messages based on registrar entries or target domain. Registrar entries are based on received SIP REGISTER request for example local domains.

This section provides instructions on how to obtain and build the Sip Service Example from source code.

  1. Downloading the source code

    Use SVN to checkout a specific release source, the base URL is ?, then add the specific release version, lets consider 2.2.0.FINAL.

    [usr]$ svn co ?/2.2.0.FINAL slee-example-sip-services-2.2.0.FINAL
  2. Building the source code

    Important

    Maven 2.0.9 (or higher) is used to build the release. Instructions for using Maven2, including install, can be found at http://maven.apache.org

    Use Maven to build the deployable unit binary.

    				    [usr]$ cd slee-example-sip-services-2.2.0.FINAL
    				    [usr]$ mvn install
    				    

    Once the process finishes you should have the deployable-unit jar file in the target directory, if JBoss Communications JAIN SLEE is installed and environment variable JBOSS_HOME is pointing to its underlying JBoss Enterprise Application Platform directory, then the deployable unit jar will also be deployed in the container.

The Sip Service Example is JAIN SLEE 1.1 Application which handles incoming SIP messages. Depending on message target and message method, example takes different action. General rule of message traversal through this example look as follows:

Sip Service Example Flow

Example consist of three SBBs. Each one performs different task:

ProxySbb

Is responsible for routing procedures. It performs operations defined in section 16 of RFC3261 and sends message to proper node. It is first SBB to receive any incoming message.

RegistrarSbb

Is responsible for proper REGISTER request processing. It performs operations defined in section 10 of RFC3261. Registrar creates AOR(Address Of Record) and based on REGISTER content performs update to location data.

LocationSbb

Is responsible for storing and invalidating entries for AORs. That is - it stores mapping between AOR and contact addresses, and on contact address expiration, removes it.

Root SBB of service is ProxySbb, which receives messages as first. Relation between SBB s look as follows:

Sip Service Example components relations

Important

To obtain the example's complete source code please refer to Section 2.2, “JBoss Communications JAIN SLEE Sip Service Example Source Code”.

Chapter Chapter 3, Design Overview explains top level view of example. This chapter explains how components perform their tasks. For more detailed explanation of JSLEE related source code and xml descriptors, please refer to simpler examples, like sip-wakeup

Proxy SBB is top component in this example - it is declared as root SBB . It declares event handlers for all SIP11 ResourceAdaptor transactional events.

ProxySbb expects transactional events to be fired, that is, it assumes that if in-Dialog event is fired, some other application is responsible for messages. ProxySbb expects also that at any given time it is attached only to one incoming transaction(Server) and one or more ongoing(Client). That is because ProxySbb uses SbbContext facility to retrieve list of current activities it is attached to. Class org.mobicents.slee.services.sip.proxy.ProxySbb has all the logic linking JSLEE with routing logic declared in inner class org.mobicents.slee.services.sip.proxy.ProxySbb$ProxyMachine .

As root of service proxy declares requests as initial. It does that with xml descriptor of event handler in sbb-jar.xml, for instance:



        <event event-direction="Receive" initial-event="True">
            <event-name>InviteEvent</event-name>
            <event-type-ref>
                <event-type-name>javax.sip.message.Request.INVITE</event-type-name>
                <event-type-vendor>net.java.slee</event-type-vendor>
                <event-type-version>1.2</event-type-version>
            </event-type-ref>
            <initial-event-selector-method-name>
                callIDSelect
            </initial-event-selector-method-name>
        </event>
        
        

Event handlers declaration has initial-event-selector-method-name element. This element identifies callback method name, which is invoked by JSLEE for all fired events. This callback is used by JSLEE to determine if event should create SBB Entity if it does not exists and determine name which distinguishes it. ProxySbb has following definition of initial event handler callback:



        public InitialEventSelector callIDSelect(InitialEventSelector ies) {
            Object event = ies.getEvent();
            String callId = null;
            if (event instanceof ResponseEvent) {
                ies.setInitialEvent(false);
                return ies;
            } else if (event instanceof RequestEvent) {
                // If request event, the convergence name to callId
                Request request = ((RequestEvent) event).getRequest();
                if (!request.getMethod().equals(Request.ACK)) {
                    callId = ((ViaHeader) request.getHeaders(ViaHeader.NAME).next())
                        .getBranch();
                } else {
                    callId = ((ViaHeader) request.getHeaders(ViaHeader.NAME).next())
                        .getBranch()
                            + "_ACK";
                }
            }
            // Set the convergence name
            if (logger.isDebugEnabled()) {
                logger.debug( "Setting convergence name to: " + callId);
            }
            ies.setCustomName(callId);
        
            return ies;
        }
        

Response events are not considered as initial because there should be SBB Entity attached to client transactions activity context interface. This entity will handle those responses.

Request handlers are only responsible for relying message to ProxyMachine . Example request handler look as follows:



        
        public void onInviteEvent(RequestEvent event, ActivityContextInterface ac) {
        
           if (logger.isDebugEnabled())
              logger.debug("Received INVITE request");
        
           processRequest(event.getServerTransaction(), event.getRequest(), ac);        
        }
        
        private void processRequest(ServerTransaction serverTransaction,
            Request request, ActivityContextInterface ac) {
        if (logger.isInfoEnabled())
            logger.info("processing request: method = \n"
                    + request.getMethod().toString());
        
        try {
            if (getServerTransactionTerminated()) {
                if (logger.isDebugEnabled())
                    logger.debug("[PROXY MACHINE] txTERM \n" + request);
                return;
            }
            // if (getServerTX() == null)
            // setServerTX(serverTransaction);
            // Go - if it is invite here, serverTransaction can be CANCEL
            // transaction!!!! so we dont want to overwrite it above
            new ProxyMachine(getProxyConfigurator(), getLocationSbb(),
                    this.addressFactory, this.headerFactory,
                    this.messageFactory, this.provider)
                .processRequest(serverTransaction, request);
        } catch (Exception e) {
            // Send error response so client can deal with it
            logger.warn( "Exception during processRequest", e);
            try {
                serverTransaction.sendResponse(messageFactory.createResponse(
                        Response.SERVER_INTERNAL_ERROR, request));
            } catch (Exception ex) {
                logger.warn( "Exception during processRequest", e);
            }
        }
    }
        
        

ProxyMachine class performs all required operations to forward request :



        class ProxyMachine extends MessageUtils implements MessageHandlerInterface {
        protected final Logger log = Logger.getLogger("ProxyMachine.class");
        // We can use those variables from top level class, but let us have our
        // own.
        protected LocationService reg = null;
        protected AddressFactory af = null;
        protected HeaderFactory hf = null;
        protected MessageFactory mf = null;
        protected SipProvider provider = null;
        protected HashSet<URI> localMachineInterfaces = new HashSet<URI>();
        protected ProxyConfiguration config = null;
        public ProxyMachine(ProxyConfiguration config,
                LocationService registrarAccess, AddressFactory af,
                HeaderFactory hf, MessageFactory mf, SipProvider prov)
                throws ParseException {
            super(config);
            reg = registrarAccess;
            this.mf = mf;
            this.af = af;
            this.hf = hf;
            this.provider = prov;
            this.config = config;
            SipUri localMachineURI = new SipUri();
            localMachineURI.setHost(this.config.getSipHostname());
            localMachineURI.setPort(this.config.getSipPort());
            this.localMachineInterfaces.add(localMachineURI);
        }
        public void processRequest(ServerTransaction stx, Request req) {
            if (log.isDebugEnabled()) {
                log.debug("processRequest");
            }
            try {
                Request tmpNewRequest = (Request) req.clone();
                // 16.3 Request Validation
                validateRequest(stx, tmpNewRequest);
                // 16.4 Route Information Preprocessing
                routePreProcess(tmpNewRequest);
                // logger.debug("Server transaction " + stx);
                // 16.5 Determining Request Targets
                List targets = determineRequestTargets(tmpNewRequest);
                Iterator it = targets.iterator();
                while (it.hasNext()) {
                    Request newRequest = (Request) tmpNewRequest.clone();
                    URI target = (URI) it.next();
                    // Part of loop detection, here we will stop initial reqeust
                    // that makes loop in local stack
                    if (isLocalMachine(target)) {
                        continue;
                    }
    
                    // 16.6 Request Forwarding
                    // 1. Copy request
                    // 2. Request-URI
                    if (target.isSipURI() && !((SipUri) target).hasLrParam())
                        newRequest.setRequestURI(target);
                    // *NEW* CANCEL processing
                    // CANCELs are hop-by-hop, so here must remove any existing
                    // Via
                    // headers,
                    // Record-Route headers. We insert Via header below so we
                    // will
                    // get response.
                    if (newRequest.getMethod().equals(Request.CANCEL)) {
                        newRequest.removeHeader(ViaHeader.NAME);
                        newRequest.removeHeader(RecordRouteHeader.NAME);
                    } else {
                        // 3. Max-Forwards
                        decrementMaxForwards(newRequest);
                        // 4. Record-Route
                        addRecordRouteHeader(newRequest);
                    }
                    // 5. Add Additional Header Fields
                    // TBD
                    // 6. Postprocess routing information
                    // TBD
                    // 7. Determine Next-Hop Address, Port and Transport
                    // TBD
                    // 8. Add a Via header field value
                    addViaHeader(newRequest);
                    // 9. Add a Content-Leangth header field if necessary
                    // TBD
                    // 10. Forward Request
                    ClientTransaction ctx = forwardRequest(stx, newRequest);
                    // 11. Set timer C
                }
            } catch (SipSendErrorResponseException se) {
                se.printStackTrace();
                int statusCode = se.getStatusCode();
                sendErrorResponse(stx, req, statusCode);
            } catch (SipLoopDetectedException slde) {
                log.warn("Loop detected, droping message.");
                slde.printStackTrace();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        
        
        ...
        
        
        }
        

Response handlers are invoked for incoming responses. In case multiple final responses incoming in sequence, first response is forwarded in stateful manner, others are forwarded in stateles manner. Example response handler look as follows:



        public void onRedirRespEvent(ResponseEvent event,
            ActivityContextInterface ac) {
        if (logger.isDebugEnabled())
            logger.debug("Received 3xx (REDIRECT) response");
        processResponse(event.getClientTransaction(), event.getResponse(), ac);     
    }
        
        private void processResponse(ClientTransaction clientTransaction,
            Response response, ActivityContextInterface ac) {
        
        if (logger.isInfoEnabled())
            logger.info("processing response: status = \n"
                    + response.getStatusCode());
        try {
            if (getServerTransactionTerminated()) {
                return;
            }
            // Go
            ServerTransaction serverTransaction = getServerTransaction(clientTransaction);
            if (serverTransaction != null) {
                new ProxyMachine(getProxyConfigurator(), getLocationSbb(), this.addressFactory,
                        this.headerFactory, this.messageFactory, this.provider)
                .processResponse(serverTransaction,
                        clientTransaction, response);
            } else {
                logger.warn("Weird got null tx for[" + response + "]");
            }
        } catch (Exception e) {
            // Send error response so client can deal with it
            logger.warn( "Exception during processResponse", e);
        }
    }
        

ProxyMachine class performs all required operations to forward response :



        public void processResponse(ServerTransaction stx,
                ClientTransaction ctx, Response resp) {
            // Now check if we really want to send it right away
            // log.info(this.getClass().getName(), "processResponse");
            try {
                Response newResponse = (Response) resp.clone();
                // 16.7 Response Processing
                // 1. Find appropriate response context
                // 2. Update timer C for provisional responses
                // 3. Remove topmost via
                Iterator viaHeaderIt = newResponse.getHeaders(ViaHeader.NAME);
                viaHeaderIt.next();
                viaHeaderIt.remove();
                if (!viaHeaderIt.hasNext())
                    return; // response was meant for this proxy
                // 4. Add the response to the response context
                // 5. Check to see if this response should be forwarded
                // immediately
                if (newResponse.getStatusCode() == Response.TRYING) {
                    return;
                }
                // 6. When necessary, choose the best final response from the
                // 7. Aggregate authorization header fields if necessary
                // 8. Optionally rewrite Record-Route header field values
                // 9. Forward the response
                forwardResponse(stx, newResponse);
                // 10. Generate any necessary CANCEL requests
            } catch (Exception e) {
                e.printStackTrace();
            }
        

ProxySbb relies on its children to perform task on AOR, that is store, manage and retrieve bindings. Child relation is declared in SBB descriptor as follows:



        <sbb-ref>
            <sbb-name>SipRegistrarSbb</sbb-name>
            <sbb-vendor>org.mobicents</sbb-vendor>
            <sbb-version>1.2</sbb-version>
            <sbb-alias>RegistrarSbb</sbb-alias>
        </sbb-ref>
        
        ...
        
        <sbb-classes>
            <sbb-abstract-class>
                <sbb-abstract-class-name>
                    org.mobicents.slee.services.sip.proxy.ProxySbb
                </sbb-abstract-class-name>
                
                ....

                <get-child-relation-method>
                    <sbb-alias-ref>RegistrarSbb</sbb-alias-ref>
                    <get-child-relation-method-name>
                        getRegistrarSbbChildRelation
                    </get-child-relation-method-name>
                    <default-priority>0</default-priority>
                </get-child-relation-method>

                
            </sbb-abstract-class>
        </sbb-classes>
        
        

Parent declaration in descriptor defines method name, in case of example its getRegistrarSbbChildRelation, implented by JSLEE. This method allows parent to access javax.slee.ChildRelation object representing link to defined child. ChildRelation object gives access to SbbLocalObject interface. This object allows parent to:

ProxySbb invokes its children with both. RegistrarSbb is beeing attached to ActivityContextInterface. LocationSbb is invoked in synchronous way. It exposes SbbLocalObject extending org.mobicents.slee.services.sip.location.LocationService interface. It is defined and used as follows:



            
public interface LocationSbbLocalObject extends SbbLocalObject,LocationService {
    
}
            
public abstract class ProxySbb implements Sbb {
    public abstract ChildRelation getLocationSbbChildRelation();
    public LocationSbbLocalObject getLocationSbb() throws TransactionRequiredLocalException
    , SLEEException, CreateException {      
        final ChildRelation childRelation = getLocationSbbChildRelation();
        if (childRelation.isEmpty()) 
        {
            return (LocationSbbLocalObject) childRelation.create();
        }
        else {
            return (LocationSbbLocalObject) childRelation.iterator().next();
        }
    }
    ...
    private void processRequest(ServerTransaction serverTransaction,
            Request request, ActivityContextInterface ac) {
    ... 
        new ProxyMachine(getProxyConfigurator(), getLocationSbb(),
        this.addressFactory, this.headerFactory,
        this.messageFactory, this.provider)
        .processRequest(serverTransaction, request);
    ...
    }
    class ProxyMachine extends MessageUtils implements MessageHandlerInterface {
        ...
        protected LocationService reg = null;
        ...
    
        public ProxyMachine(ProxyConfiguration config,
                LocationService registrarAccess, AddressFactory af,
                HeaderFactory hf, MessageFactory mf, SipProvider prov)
        throws ParseException {
            ...
            reg = registrarAccess;
            ...
        }
        
        /**
         * Attempts to find a locally registered contact address for the given
         * URI, using the location service interface.
         */
        public LinkedList<URI> findLocalTarget(URI uri)
        throws SipSendErrorResponseException {
            String addressOfRecord = uri.toString();
            Map<String, RegistrationBinding> bindings = null;
            LinkedList<URI> listOfTargets = new LinkedList<URI>();
            try {
                bindings = reg.getBindings(addressOfRecord);
            } catch (LocationServiceException e) {
                e.printStackTrace();
                return listOfTargets;
            }
            if (bindings == null) {
                throw new SipSendErrorResponseException("User not found",
                        Response.NOT_FOUND);
            }
            if (bindings.isEmpty()) {
                throw new SipSendErrorResponseException(
                        "User temporarily unavailable",
                        Response.TEMPORARILY_UNAVAILABLE);
            }
            Iterator it = bindings.values().iterator();
            URI target = null;
            while (it.hasNext()) {
                String contactAddress = ((RegistrationBinding)it.next()).getContactAddress();
                try {
                    listOfTargets.add(af.createURI(contactAddress));
                } catch (ParseException e) {
                    log.warn("Ignoring contact address "+contactAddress+" due to parse error",e);
                }
            }
            if (listOfTargets.size() == 0) {
                throw new SipSendErrorResponseException(
                        "User temporarily unavailable",
                        Response.TEMPORARILY_UNAVAILABLE);
            }
            return listOfTargets;
         }
    }
}
        

RegistrarSbb is responsible for handling REGISTER requests and sending proper response. RegistrarSbb receives requests on ActivityContextInterface to which it is attached by its parent, please see Section 4.1.4, “Register handler” for explanation and code example.

Class org.mobicents.slee.services.sip.registrar.RegistrarSbb includes all the service logic required to perform registry tasks.

RegistrarSbb operate on RegistrationBindings managed by LocationService.

RegistrarSbb performs following operations in REGISTER event handler:

RegistrarSbb defines LocationSbb as child. LocationSbb child is used as manager for RegistrationBindings. Child relation is declared in sbb-jar.xml descriptor:



 <sbb-jar>
    <sbb id="sip-registrar-sbb">
            <description>JAIN SIP Registrar SBB</description>
            <sbb-name>SipRegistrarSbb</sbb-name>
            <sbb-vendor>org.mobicents</sbb-vendor>
            <sbb-version>1.2</sbb-version>

            <sbb-ref>
                <sbb-name>LocationSbb</sbb-name>
                <sbb-vendor>org.mobicents</sbb-vendor>
                <sbb-version>1.2</sbb-version>
                <sbb-alias>LocationSbb</sbb-alias>
            </sbb-ref>


            <sbb-classes>
                <sbb-abstract-class>
                    <sbb-abstract-class-name>
                        org.mobicents.slee.services.sip.registrar.RegistrarSbb
                    </sbb-abstract-class-name>
                    <get-child-relation-method>
                        <sbb-alias-ref>LocationSbb</sbb-alias-ref>
                        <get-child-relation-method-name>
                            getLocationSbbChildRelation
                        </get-child-relation-method-name>
                        <default-priority>0</default-priority>
                    </get-child-relation-method>
                </sbb-abstract-class>
            </sbb-classes>
            
            ... 
    </sbb>
</sbb-jar>
        
        

Parent declaration in descriptor defines method name, in case of example its getLocationSbbChildRelation, implented by JSLEE. This method allows parent to access javax.slee.ChildRelation object representing link to defined child. ChildRelation object gives access to SbbLocalObject interface. This object allows parent to:

Its defined in source as follows:



public abstract class RegistrarSbb implements Sbb {
        
    ...
        
    // location service child relation
    public abstract ChildRelation getLocationSbbChildRelation();
    public LocationSbbLocalObject getLocationSbb() throws TransactionRequiredLocalException
        , SLEEException, CreateException {
        return (LocationSbbLocalObject) getLocationSbbChildRelation().create();         
    }
    ...
}
        

LocationSbb is responsible for storing and managing expiration of address bindings.

Class org.mobicents.slee.services.sip.location.LocationSbb includes all the service logic required to perform management of contact addresses.

LocationSbb declares custom SbbLocalObject interface. Declared methods are used by ProxySbb and RegistrarSbb to access registration data. Declaration in sbb-jar.xml look as follows:



 <sbb-jar>
    <sbb id="sip-registrar-location-sbb">
        
        <description>Location Service - JPA based</description>
        
        <sbb-name>LocationSbb</sbb-name>
        <sbb-vendor>org.mobicents</sbb-vendor>
        <sbb-version>1.2</sbb-version>

        <library-ref>
            <library-name>sip-services-library</library-name>
            <library-vendor>org.mobicents</library-vendor>
            <library-version>1.2</library-version>
        </library-ref>

        <sbb-classes>
            <sbb-abstract-class>
                <sbb-abstract-class-name>
                    org.mobicents.slee.services.sip.location.LocationSbb
                </sbb-abstract-class-name>

            </sbb-abstract-class>
            <sbb-local-interface>
                <sbb-local-interface-name>
                    org.mobicents.slee.services.sip.location.LocationSbbLocalObject
                </sbb-local-interface-name>
            </sbb-local-interface>
            ...
        </sbb-classes>
            
            ... 
    </sbb>
</sbb-jar>
        
        

org.mobicents.slee.services.sip.location.LocationSbbLocalObject is defined as follows:



        package org.mobicents.slee.services.sip.location;
        import javax.slee.SbbLocalObject;
        public interface LocationSbbLocalObject extends SbbLocalObject,LocationService {
            
        }
        
        
        
        package org.mobicents.slee.services.sip.location;
        public interface LocationService extends ... {
        
            /**
             * Adds new contact binding for particular user..
             * 
             * @param sipAddress -
             *            sip address of record sip:ala@ma.kota.w.domu.com
             * @param contactAddress -
             *            contact address - tel:+381243256
             * @param comment -
             *            possible comment note
             * @param expires -
             *            long - seconds for which this contact is to remain valid
             * @param registrationDate -
             *            long - date when the registration was created/updated
             * @param qValue -
             *            q parameter
             * @param callId -
             *            call id
             * @param cSeq -
             *            seq numbers
             * @return - binding created in this operation
             * @throws LocationServiceException
             */
            public RegistrationBinding addBinding(String sipAddress,
                    String contactAddress, String comment, long expires,
                    long registrationDate, float qValue, String callId, long cSeq)
                    throws LocationServiceException;
        
            /**
             * Returns set of user that have registered - set contains adress of record
             * for each user, something like sip:ala@kocia.domena.com
             * 
             * @return
             * @throws LocationServiceException 
             */
            public Set<String> getRegisteredUsers() throws LocationServiceException;
        
            /**
             * Returns map which contains mapping contactAddress->registrationBinding
             * for particular user - address of record sip:nie@ma.mnie.tu
             * 
             * @param sipAddress
             * @return
             * @throws LocationServiceException
             */
            public Map<String, RegistrationBinding> getBindings(String sipAddress)
                    throws LocationServiceException;
        
        
            /**
             * Updates the specified registration binding.
             * 
             * @param registrationBinding   
             * @throws LocationServiceException
             */
            public void updateBinding(RegistrationBinding registrationBinding)
                    throws LocationServiceException;
        
            /**
             * Removes contact address from user bindings.
             * 
             * @param sip address of record -
             *            sip:ala@kocia.domena.au
             * @param contactAddress -
             *            tel:+481234567890
             * @throws LocationServiceException
             */
            public void removeBinding(String sipAddress, String contactAddress)
                    throws LocationServiceException;
        
        
            ...
            
        }
        

Methods defined by LocationSbbLocalObject are implemented by LocationSbb class. Those methods are invoked in synchronous manner in order to perform binding operations:

LocationSbb defines custom Activity Context Interface with variables. Variables are used to store data required to manage expiration timer and access binding in storage, that is:

Custom Activity Context Interface is defined in sbb-jar.xml descriptor as follows:



<sbb id="sip-registrar-location-sbb">
        
        <description>Location Service - JPA based</description>
        
        <sbb-name>LocationSbb</sbb-name>
        <sbb-vendor>org.mobicents</sbb-vendor>
        <sbb-version>1.2</sbb-version>

        <library-ref>
            <library-name>sip-services-library</library-name>
            <library-vendor>org.mobicents</library-vendor>
            <library-version>1.2</library-version>
        </library-ref>

        <sbb-classes>
            <sbb-abstract-class>
                <sbb-abstract-class-name>
                    org.mobicents.slee.services.sip.location.LocationSbb
                </sbb-abstract-class-name>

            </sbb-abstract-class>
            ...
            <sbb-activity-context-interface>
                <sbb-activity-context-interface-name>
                    org.mobicents.slee.services.sip.location.RegistrationBindingActivityContextInterface
                </sbb-activity-context-interface-name>
            </sbb-activity-context-interface>
        </sbb-classes>
        ...
    </sbb>
</sbb-jar>
        
        

Custom Activity Context Interface accessor is defined as follows:



public abstract class LocationSbb implements ... {
    public abstract RegistrationBindingActivityContextInterface asSbbActivityContextInterface(
            ActivityContextInterface aci);
}
        

Variables are defined in Java Bean convetion, by declaration of setter and getter pair in custom Activity Context Interface:



public interface RegistrationBindingActivityContextInterface extends ActivityContextInterface {
    public abstract TimerID getTimerID();
    public abstract void setTimerID(TimerID timerID);
    
    public abstract String getContactAddress();
    public abstract void setContactAddress(String contactAddress);
    
    public abstract String getSipAddress();
    public abstract void setSipAddress(String sipAddress);
    
}
        

Timer supervising expiration is created with binding. Its attached to named ACI. Timeout value is based on data passed from RegistrarSbb.

Timer event handler is invoked in case of contact address expiration, its purpose is to:

Timer event handler is defined as follows:



    public void onTimerEvent(TimerEvent timer, ActivityContextInterface aci) {
        if (logger.isFineEnabled()) {
            logger.fine("onTimerEvent()");
        }
        
        aci.detach(sbbContext.getSbbLocalObject());
            
        // cast to rg aci
        RegistrationBindingActivityContextInterface rgAci = asSbbActivityContextInterface(aci);
        // get data from aci
        String contactAddress = rgAci.getContactAddress();
        String sipAddress = rgAci.getSipAddress();
        
        // unbind from aci so it ends
        try {
            activityContextNamingFacility.unbind(getACIName(contactAddress, sipAddress));
        } catch (Exception e) {
            logger.severe("",e);
        }
        // remove rg from location service  
        try {
            locationService.removeBinding(sipAddress, contactAddress);
        } catch (Exception e) {
            logger.severe("",e);
        }
        if(logger.isInfoEnabled()) {
            logger.info("binding expired: sipAddress="+sipAddress+"
                ,contactAddress="+contactAddress);
        }
        
    }
        

LocationSbb environment entry controls LocationService type used(JPA and local). XML descriptor defines entry as follows:



<sbb id="sip-registrar-location-sbb">
        
        <description>Location Service - JPA based</description>
        
        <sbb-name>LocationSbb</sbb-name>
        <sbb-vendor>org.mobicents</sbb-vendor>
        <sbb-version>1.2</sbb-version>

        <library-ref>
            <library-name>sip-services-library</library-name>
            <library-vendor>org.mobicents</library-vendor>
            <library-version>1.2</library-version>
        </library-ref>

        ...
        <env-entry>
            <env-entry-name>LOCATION_SERVICE_CLASS_NAME</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <!-- choose your location service, filtered on compliation -->
            <env-entry-value>
                org.mobicents.slee.services.sip.location.nonha.NonHALocationService
            </env-entry-value>
        </env-entry>
    </sbb>
</sbb-jar>
        
        

Environment entries are accessible with JNDI lookups:



        
        Context myEnv = (Context) new InitialContext().lookup("java:comp/env"); 
        String value  = (String) myEnv.lookup("LOCATION_SERVICE_CLASS_NAME");
        
        

The easiest way to test example is to deploy example and start container, register two UACs and make call from one to another. UACs must be configured to use container as proxy, by default each UAC should point to proxy at 127.0.0.1:5060 and have domain set to either nist.gov or mobicents.org

Two components can be configured in example:

LocationSbb

location components supports two different storage providers: HA and local. Default storage is local. It can be changed with sbb-env property: LOCATION_SERVICE_CLASS_NAME . It can have one of two values:

LocationSbb exposes JMX properties which can be accessed under ObjectName: slee:sipservice=Location . Supported properties:


ProxySbb

Configuration can be changed in configuration.properties file or during runtime with JMX Bean. Bean is accessible under ObjectName: slee:sipproxyconfigurator=only_human , where sipproxyconfigurator value is equal to configuration name. Supported properties:


RegistrarSbb

Configuration can be changed during runtime with JMX Bean. Bean is accessible under ObjectName: slee:sipregistrarconfigurator=v1RegistrarConf . Supported properties:


Revision History
Revision 1.0Mon Feb 8 2010Bartosz Baranowski
Creation of the JBoss Communications JAIN SLEE Sip Service Example User Guide.