In 1998 there were no common industry standard Application Programming Interfaces (APIs) available to enable applications across multiple networks. In response to this a number of companies formed the Parlay Group and started working towards creating open APIs. Parlay is an open, non-profit organization currently consisting of more than 50 members.

The Parlay Group is not a standardization organization. It is an open, multi-vendor forum whose aim is to create APIs that are open and technology independent. In turn this enables a lot of players to develop applications across multiple networks.

The Parlay Group has an on-going working relationship with standards forums and consortiums. For example, the Parlay Group bases a lot of their activities on the work of these bodies with the objective to re-use already existing results and specifications.

Question continues: 

1. Use Parlay User Interaction SCF to play the announcement to the user using methods such as sendInfoReq(), and thus have all the application logic run in the telecom operator's domain (performance issues)?
2. Route the call to our own voice server (supporting VoiceXML and full-featured PBX) in the IP domain. In this case, how do we reroute the call to an SIP address (assuming our server uses SIP) using Parlay? Does the Ericsson Network Resource Gateway enable tpAdressPlan of type P_ADDRESS_PLAN_SIP in its call control route methods? And how do we route back the call from the voice server to the user when our application receives an event that the destination number has answered?

Answer: The first approach, which does not have any performance issues that we are aware of, is recommended. A further benefit of this approach is that only one trigger in the operator's network is needed. The second approach would require at least two triggers – one to trigger the Ericsson Network Resource Gateway and another for the reroute to the SIP address.

A further disadvantage of the second approach is that it limits you to the SIP protocol, which not every operator supports. In other words, you are narrowing your own market.

With the first approach, it does not matter which protocol is used, as Parlay is protocol independent.

From a Parlay perspective, it should not be a problem. However, the operators concerned would need to have an agreement in place for sharing location information. Operators generally do not have these kinds of agreements at present.

Question continues: Assuming that this is the right approach and Heartbeats indicates the application is available, what will happen to the service instance? Should the framework terminate the service agreement for the service instance? What is the right approach in this case?

Answer: According to the statement of compliance documentation, the Ericsson Network Resource Gateway does not support the IpFwFaultManager interface. Since there is no support for this kind of fault management, the rest of your question will be answered in terms of the Parlay specification.
 
According to the Parlay specification the method appUnavailableInd() can be used by the services to inform the framework that the application no longer responds. This would give the framework the possibility to clean up resources in the Parlay Gateway and to terminate the Service Level Agreement for the specific service instance (but that's up to the framework).

There is no relation between the appUnavailableInd() method and the usage of Heartbeat in the Parlay specifications.