When a web server receives an http requests, the server identifies which application need to be run, depending on the context-root of the request. However SIP communication is designed to be between two parties and the message does not contain something like context root to identify the application.
The Service Execution Environment is a key layer of any Service Delivery Platform (SDP), and the application servers and databases are the key components of this layer. MySQL and SailFin (GlassFish) fit in very well into the Service Execution Environment.
Let me explain this issue, step by step.
What is Record-Route?
In the first part of this blog, I explained how a third person Join a call between two parties. This part explains how one party is replaced by another in a call. RFC 3891 specifies Replaces SIP header, that help SIP applications implement this capability.
In a typical customer support scenario, a customer support executive (E) might want his manager (M) to join his call with a customer (C). How to achieve that? In SIP world, Join header specified by RFC 3911 helps in handling this situation. It defines a new header named Join, which holds the call-information.
This time, my work had about 800 lines changes/new lines spanning 16 files and was implementing two RFCs. All that was plain simple java code and not very complicated, but still the worry I always had about presenting the changes to the reviewers (in different geos) came up on my head. It is still my code and not their code.
Lately I have been a spending significant amount of time analyzing issues coming from sailfin performance team and system testing team. One of them was particularly tricky. Testing team was running a test 24x7 on a 10 instance sailfin cluster with CLB etc.