|
Mobicents SIP Services
1. Overview High availability, scalability,modularity easy management - these drove this design of sip services. Availability is something that is common with SLEE specs and is secured by container itself - along with scalability. Reason to have basic set of services modular is quite simple - often users have their own components or want to create some part from scratch. Its easier to use defined set of interfaces to interact with different blocks rather than writing everything from scratch. To achieve this we made simple split according to block usage into:
1.1 ProxySbb, service and itnerface Is first logical building block of this set. It is an entry point for processed messages, it receives SIP messages and depending on their content makes routing decissionsAs it is it does not provide any special interface - except one that is required by sip ra and SLEE contract. 1.2 LocationSbb and interface LocationSbb is second logical block. As it provides service that can be of potential use to more than proxy it is standalone service. Its purpose is to store and manage location inforamtion passed in various ways - for instance in REGISTER messages. It utilizes four classes from org.mobicents.slee.services.sip.common package which declare contract on handling and exposing location information. Those four classes are:
/**
LocationSbb is used by all other componets to access and store information regarding users - in case of SIP Services, users is Proxy and Registrar. Both depends on LocationInterface methods.
1.3 RegistrarSbb and interface One might think that registrar is obsolete because location performs all the tasks. However its nto so easy in telco world. First thing here is taht someone has to unwrapp information from sip message, second - it might need some more processing. For instance someone might have a need to do a credit controll on registration to monitor user activities. Thats why LocationSbb takes care of storing logic and allows users to introduce some other logic into Registrar(One thing that is not here yet is callback on expiration of user information, but till know there has not been demand on it). 2. Overall diagram NOTE: 1. Currenly LocationSbb uses cache to store all information
3. Configuration - Management
3.1 ProxySbb Proxy Sbb configuration options are exposed via JMX MBean. It is registered under object name "slee:sipproxyconfigurator=only_human". It provides following methods(fields): /** * If proxy supports more than sips and sip uri schemes this is the method to add them. * @param schemeToAdd */ public void addSupportedURIScheme(String schemeToAdd); /** * This method removes uri scheme from allowed set * @param schemeToRemove */ public void removeSupportedURIScheme(String schemeToRemove); /** * Adds local domain - domain which after addition is considered to be served by this proxy. After add operation proxy resolves all contacts localy, allow to register. * @param localDomainToAdd */ public void addLocalDomain(String localDomainToAdd); /** * Removes domain from local set. * @param localDomainToRemove */ public void removeLocalDomain(String localDomainToRemove); /** * Sets this sip host name, in case of multiple interfaces and names its mandatory. * @param sipHostName */ public void setSipHostName(String sipHostName); /** * Sets port on which proxy should work * @param port */ public void setSipPort(int port); /** * Sets set of allowed transports * @param transport */ public void setSipTransports(String[] transport); /** * Currently commented out code. Adds host through which messages must pass through after leaving this proxy * @param pos * @param host */ public void addMustPassThrough(int pos,String host); public void removeMustPassThrough(int pos); public void removeMustPassThrough(String host);
All above values can be configured via sbb-jar.xml file with use of enviroment entries. They are defined as follows: <env-entry> configuration-MBEAN allows to change MBean name, it has to create, with conjunction with static prefix, valid Object Name. Allowe values could look like: "v1Reg,type=test" or just "v1Reg". Names are selfexplanatory - they should match setter/getters from MBean. Provided values are defaults, are always picked up when service is created. 3.2 RegistrarSbb Registrar configuration is quite plain, as there was no demand on more complex options. JMX MBean allows to controll accepted values of min/max expires SIP headers - thus controlling minimal and maximal registration time. MBean is registered under object name "slee:sipregistrarconfigurator=v1RegistrarConf". Here are method signatures:
public long getSipRegistrationMinExpires();
One can also configure those options along with MBean suffix from sbb-jar.xml file with config options: <env-entry> Names are selfexplanatory - they should match setter/getters from MBean. Provided values are defaults, are always picked up when service is created. configuration-MBEAN allows to change MBean name, it has to create, with conjunction with static prefix, valid Object Name. Allowe values could look like: "v1Reg,type=test" or just "v1Reg" 3.3 LocationSbb LocationSbb is component responsible for storing registration information. Logicaly it is resonable to asume that it will allow to browse its data via JMX. So far this is only requierement that has been set for this component management. MBean is registered under oobject name "". It exposes following methods: public static final String MBEAN_NAME_PREFIX="slee:siplocationservice=";
In sbb-jar.xml one can define specific name of MBean via enviroment entries: <env-entry>
configuration-MBEAN allows to change MBean name, it has to create, with conjunction with static prefix, valid Object Name. Allowe values could look like: "v1Reg,type=test" or just "v1Reg"
|
|
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2008 Google |