This class implements the routing for all messages leaving a node. Please note: This object is meant to be instantiated and manipulated by the {@link Dempsy} orchestrator and not used directly. However, it is important to understand how routing within Dempsy works.
Routing a message to a message processor happens in three stages. Given an {@link ApplicationDefinition} that contains many message processor clusters, messages leaving any one {@link Node} need to be routed to the appropriate message processorsin other clusters. The stages are as follows:
As mentioned, if the particular cluster that the node that this Router is instantiated in has explicitly defined destinations, then the message routing will be limited to only those destinations.
A router requires a non-null ApplicationDefinition during construction.
For backwards compatibility reasons, the default behavior of the stack is to consult the application provided Router implementation for all requests outside of a dialog. This is controlled through the stack property javax.sip.USE_ROUTER_FOR_ALL_URIS which defaults to true when not set.
This specification recommends to set the stack property javax.sip.USE_ROUTER_FOR_ALL_URIS to false. This will cause the stack to only consult the application provided Router implementation for requests with a non-SIP URI as request URI (such as tel: or pres:) and without Route headers. This enables an application to implement DNS lookups and other resolution algorithms
When javax.sip.USE_ROUTER_FOR_ALL_URIS is set to false, the next hop is determined according to the following algorithm:
javax.sip.OUTBOUND_PROXY is set, use its value as the next hop Note: In case the topmost Route header contains no 'lr' parameter (which means the next hop is a strict router), the implementation will perform 'Route Information Postprocessing' as described in RFC3261 section 16.6 step 6 (also known as "Route header popping"). That is, the following modifications will be made to the request:
The location (classname) of the user-defined Router object is supplied in the Properties object passed to the {@link javax.sip.SipFactory#createSipStack(Properties)} method upon creationof the SIP Stack object. The Router object must accept a SipStack as an argument to the constructor in order for the Router to access attributes of the SipStack The constructor of an object implementing the Router interface must be RouterImpl(SipStack sipStack, String outboundProxy) {}
The routing policy can not be changed dynamically, i.e. the SipStack needs to be deleted and re-created. Outbound proxy should be passed to the {@link javax.sip.SipFactory#createSipStack(Properties)} method upon creationof the SIP Stack object.
Application Notes
A UAC application which desires to use a particular outbound proxy should prepend a Route header with the URI of that proxy (and 'lr' flag if appropriate). Alternatively, it may achieve the same result by setting the OUTBOUND_PROXY property (although the Route header approach is more flexible and therefore RECOMMENDED)
A proxy application may either rewrite the request URI (if the proxy is responsible for the domain), or prepend a Route header. @author BEA Systems, NIST @version 1.2
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |