WeSIP

From Wesip

Converged applications use two deployment descriptors, web.xml and sip.xml, to configure the behaviour of the HTTP and SIP components respectively. The web.xml file follows the standar j2ee rules and syntax for web application deployment. The sip.xml descriptor is very similar to it except for a few differences worth to mention

• - It uses <sip-app> as the root
• - The tags form-login-config, mime-mapping, wel-come-file-list, error-page, taglib, jsp-file do not apply
• - Servlet filters are not supported
• - Resource collections as specified as a set of servlet names instead of a set of URLs.

Since in the application is defined across two deployment descriptors several rules for integraty must be taken into consideration

• - distributable,display-name and icons tags if present, must be in both files with the same values.
• - context-param attributes described on both files are merged into the converged context. If one param is present in both descriptors it should take the same value in both declarations.
• - The application listeners are the union of those declared for HTTP and SIP.

But for sure the biggests change is the definition of servlet mappings. In SIP applications the servlet mappings are used to route incoming requests that do not belong to a dialog known by the container to the proper application. Those mappings are expressed as rules that consist of a combination of conditions (equal,exists,contains,subdomain) expressed over the contents of the request to be routed (i.e. request.from.display-name,request.method,request.to.uri.user,request.uri.param.param-name,etcetera...). Several conditions are added using the 'and','or' and 'not' logical connectors.

Let's see an example. One rule that matches INVITE requests coming from any subdomain of foo.com provided they don't come with an ignore param in the request URI

 <pattern> 
   <and> 
     <equal> 
       <var>request.method</var>
       <value>INVITE</value> 
     </equal> 
     <subdomain-of> 
       <var>request.from.uri.host</var> 
       <value>foo.com</value> 
     </subdomain-of>
     <not> 
       <exists > 
         <var>request.uri.param.ignore</var> 
       </exists> 
     </not> 
   </and> 
 </pattern> 

The complete list of available variables is the following

request.method

request.uri.scheme
           .user
           .host
           .port
           .tel
           .param.name

request.to.display-name
          .uri.scheme
              .user
              .host
              .port
              .tel
              .param.name
  
request.from.display-name
            .uri.scheme
                .user
                .host
                .port
                .tel
                .param.name

<< Deployment | Listeners >>