VOCAL is not a shrink-wrapped product; it’s a project, and we encourage you to help us with its development. Here are some areas of the RS that could be enhanced by members of our community.
One proposed project is redesigning VOCAL to eliminate the need for each server to send an INVITE to the RS in order for it to determine the next hop in the call.
In this new design, the first server to handle a call sends an INVITE to the RS for routing information. The RS generates a list of contacts according to the calling party and the called party. The call’s current place within the list is determined by using the Via fields. The remaining contacts are validated and prepared for return in a 302 Moved Temporarily response message.
The first contact in the list to be returned is placed in the Contact header’s SIP URI. The remaining contacts are added to the Contact header as embedded routes. The server extracts the contacts and places the first address in the Request URI of the INVITE message and the remaining addresses in the Route header before sending it to the next hop in the system. Thereafter, servers remove themselves from the top of the Route list and add themselves to the route record before passing the INVITE to the next server in the Route list.
If a server changes the Req URI or From fields of the INVITE message or finds that the next server to receive the INVITE is unavailable, it queries the RS again for a new route list as if it were ...