The Parlay API consists of an umbrella architecture providing complete network independence and application portability. It provides an additional layer of abstraction for the application of the underlying communications network.

The API is independent of platform, vendor and technology. Ericsson uses Corba/IIOP as the mechanism to deliver Parlay based application towards the network operator. Ericsson Network Resource Gateway is used as it is very common within the telecommunications networks and provides various advantages. Applications can be developed using different technologies like e.g. JAVA, C, C++ or other.

IN solutions have been designed to meet the needs of telecommunication network operators by using protocols (not open APIs) within a network. The development of services based on these telecommunication standards requires in-depth knowledge of the protocols used and of the network behavior.
The open Parlay/OSA interface provides access to the network information and its capabilities by carefully encapsulating them in capability features. This forces the access to be integrated with the framework mechanisms and also ensures network integrity and safety. It further provides complete access to call control of the telecommunication networks.

The Ericsson Mobility World centers will soon offer lab facilities. This allows the application developer to connect his or her application to the Ericsson Service Capability Server (Parlay Gateway) and run various test suites. The Parlay Group will not offer Parlay compliance or certification tests. It is up to the industry to support the developers to make the development and provision of Parlay based applications as smooth as possible.

The current release supports:

• Initial Contact (IpInitial, IpFwInitial)  
• Authentication & authorisation (IpAuthentication, IpAccess, IpFwAuthentication, IpFwAccess)  
• Service Discovery (IpServiceDiscovery)  
• Service Registration (IpFwServiceRegistration)

The API of the Ericsson Network Resource Gateway SDK can be subdivided into three components, called the Core, Test and Utility API. The Core API contains all classes and interfaces as specified by HOSA, and offers core functionality such as connecting to Ericsson Network Resource Gateway. The Utility API contains classes and interfaces that are not specified by HOSA but that may be useful in HOSA applications. The Test API is comparable to the Core API, but is intended for testing HOSA applications prior to actual deployment.

You don't. Ultimately, you have to be willing to get your feet wet and read HOSA specifications, API descriptions, example source code, etc. The Ericsson Network Resource Gateway Programmers' Guide is a useful document to get you started.

When a callback is created, resources are automatically allocated by the API implementation to enable communication between Ericsson Network Resource Gateway and the callback.  If the application does not dispose of callbacks (by invoking dispose), these resources are never freed. If this happens often, the application eventually grinds to a halt or crashes.

Class DebugCallbackManager can be used to detect and analyze memory leaks that are a result of forgotten disposals.

The API implementation will assume that the first callback interface it encounters is the intended callback interface. Effectively, an application cannot use the same callback class in different callback roles. Earlier versions of the SDK enforced this rule by throwing an exception at run-time if a callback class signature did not explicitly specify the callback interface. This rule has been relaxed because as it was considered a nuisance when it is clear from the context which callback interface is intended (such as when a class extends a callback interface adapter).

The SDK libraries consists of a public API and a private implementation. Only the public API is documented and can be used by an application. The private implementation is used internally. It is neither documented nor subject to attempts to achieve compatibility between versions. If you feel there is a valid reason to use the private implementation directly, or to modify either the private implementation or the public API, contact Ericsson.

On a multi-homed computer (i.e. containing of multiple network interfaces) requests can be sent via one network interface, while responses can be received via another. The Sun ORB does not support this. Set parameter com.sun.CORBA.ORBServerHost to the IP address of network interface that should be used. Other ORBs may require similar solutions (consult the documentation of the ORB that is used).

This sounds like the Java Virtual Machine cannot find all the libraries (the jar files). Make sure that you have specified the locations to the jar files correctly. Keep in mind that the location of the jar files has been changed in version R4A06 of the SDK.

Make sure you have the following three jar files included in your classpath:

-corba_sun.jar
-coreapi.jar
-utilityapi.jar

As explained in the statement of compliance documentation, the method CallAppAlertingMechanism(int) is not supported by the Network Resource Gateway. Receiving ALERTING without causing the phone to ring is not possible; the two are related to each other.

However, you can find out the status of mobile phones by using user status, which gives status as reachable, not reachable or busy, without the need for any call control.

Keep in mind that only triggered user status is implemented in the Network Resource Gateway Simulator, if you want to test other user status functionality, you need to use the Automated Test Tool or a real Network Resource Gateway.

To use both CS1+ and CAPv2 MPCC both service profiles need to be assigned to your Service Level Agreement.

To be able to specify which of the two you want to obtain, you can use the method obtainSCF on the class FWproxy. In this case, you will not only specify the name of the service (NETWORK_PROTOCOL_IDENTIFIER) but you also need to specify protocol via a service property.

----------------------------
TpServiceProperty protocolProperty = new TpServiceProperty(
    "P_NETWORK_PROTOCOL", new String[] {NETWORK_PROTOCOL_IDENTIFIER});

itsMPCCManager = (IpMultiPartyCallControlManager) itsFramework.obtainSCF(
    "P_MULTI_PARTY_CALL_CONTROL", protocolProperty);
----------------------------

NETWORK_PROTOCOL_IDENTIFIER can have the values 1 or 2. If you use the value 1 you are indicating CAPv2, if you use the value 2 you are indicating CS1+.

Question continues: The Charging Origin is sent to the network by means of the CS1+ operation sendChargingInformation (SCI). The CO is embedded in the SciBillingChargingCharacteristics parameter.

However, it seems that the Ericsson Network Resource Gateway does not support the SCI operation or, at least, the CO parameter. What kind of workaround can I try to send the CO to the network if the Ericsson Network Resource Gateway does not support this information?

I know the NRG has support to map Parlay methods, such as the setAdviceOfCharge method, to the SCI operation, but does it have support to map the CO to be included it in the SCI?

Answer: The Ericsson Network Resource Gateway does not support the setAdviceOfCharge() method. At the moment the CO parameter is not supported. There is no work around available to include the CO in the SCI.