ch.ecma.csta.binding
Class ConnectionID

java.lang.Object
  ch.ecma.csta.CastorObject
      ch.ecma.csta.binding.ConnectionID

All Implemented Interfaces:

java.io.Serializable

public class ConnectionID
extends ch.ecma.csta.CastorObject
implements java.io.Serializable

Describes a device's connection in a given call. Connections and connection identifiers are described in ECMA 269, Section 6.1.5, "Connection".

This component is a choice of one of the following:

• A device ID only Connection ID
• A complete Connection ID (that is, call ID and device ID).
• A call ID only Connection ID

Functional Implementation:

1. The computing function shall not fabricate its own Connection IDs. This will lead to unpredictable results.
2. The Connection IDs in events and service acknowledgements are always allocated by the switching function.
3. Computing functions can extract Device IDs from Connection IDs and use them on services that have Device ID parameters only if the Device ID extracted is a static Device ID that the switching function accepts. Otherwise, the Device ID cannot be used.
4. Computing functions shall extract Call IDs from Connection IDs, provided by the switching function, to correlate event reports associated with devices that are connected together in a call.
5. The computing function will always receive an event to indicate the termination of a Connection ID if the appropriate monitor is started. Refer to the individual services and events to better understand the meaning of individual events with respect to connection states.
6. If the computing function issues a service with a Connection ID that cannot be controlled by the switching function, the service will be rejected with a negative acknowledgement.
7. Connection IDs used as parameters can only have three formats:
   • A complete Connection ID (that is, call ID and device ID). This is extracted from either events received by the computing function or positive acknowledgements received as a result of services issued.

     When supplied as a parameter, the Connection ID will be validated by the switching function with respect to the service being issued. If this Connection ID is not valid, the service request will be rejected with a negative acknowledgement.

   • A device ID only Connection ID. If a service has more than one Connection ID parameter, the switching function supports this type of Connection ID, and the computing function wants to use this type of Connection ID, then all Connection ID parameters in the service shall be of this type.

     If this type of Connection ID is used as the Connection ID parameter for a service, then rules documented in the services sections will determine whether it is accepted or not by the switching function. If this type of Connection ID is not accepted, then the service will be rejected with a negative acknowledgement.

   • A call ID only Connection ID. In events, this format can only be used for the Call Cleared and Failed event. If this format is used for any service other than Clear Call, Monitor Start, or Snapshot Call, it will be rejected with a negative acknowledgement.
8. If a call changes its Call ID when a Conference or Transfer occurs, Connection IDs shall be provided to link the old Call IDs to the new Call IDs. When this occurs, the event will contain a list of originally known Connection IDs of devices that are still in the call along with the new replacement Connection IDs. When the new Connection IDs are created in such cases, new dynamic Device IDs may also be used to create the Connection IDs.
9. Connection IDs that come from the switching function (events and positive acknowledgements to services) will always contain both the Call ID and Device ID portions (see item 7a above) except for the Call Cleared and Failed events that may also contain only a valid call ID in the connection ID (see item 7c above).
10. The computing function should never assume the reuse of callIDs, although some switching functions may reuse one or the other.

Version:

$Revision: 1.2 $ $Date: 2004/01/20 23:19:36 $

Author:

AVAYA, Inc.

See Also:

Serialized Form

Constructor Summary

ConnectionID()

Method Summary

boolean	equals(java.lang.Object obj) Note: hashCode() has not been overriden
java.lang.String	getCallID() Get the call identifier.
LocalDeviceID	getDeviceID() Get the device identifier.
boolean	isValid() Method isValid
void	marshal(org.xml.sax.ContentHandler handler) Method marshal
void	marshal(java.io.Writer out) Method marshal
void	setCallID(java.lang.String callID) Set the connection identifier sequence.
void	setDeviceID(LocalDeviceID deviceID) Set the device identifier.
java.lang.String	toString() Calls super.toString() and appends getDeviceID(); getCallID()
static ConnectionID	unmarshalConnectionID(java.io.Reader reader) Method unmarshalConnectionID
void	validate() Method validate

Methods inherited from class ch.ecma.csta.CastorObject

getOldSessionID, hashCode, setOldSessionID

Methods inherited from class java.lang.Object

getClass, notify, notifyAll, wait, wait, wait

Constructor Detail

ConnectionID

public ConnectionID()

Method Detail

equals

public boolean equals(java.lang.Object obj)

Note: hashCode() has not been overriden

Overrides:

equals in class ch.ecma.csta.CastorObject

Parameters:

obj -

getCallID

public java.lang.String getCallID()

Get the call identifier. This is defined to be an identifier used by the switching function to represent a valid call. The maximum length supported by the switching function is provided via the capabilities exchange services. These IDs are created by the switching function and are globally unique among all calls within the switching sub-domain.

Returns:

the value of field 'callID'.

getDeviceID

public LocalDeviceID getDeviceID()

Get the device identifier. This is defined to be an identifier which is used to represent a device in the switching sub-domain.

This identifier can be either one of the two following values:

• Static - This type of identifier is defined in ECMA-269 Section 6.1.3, "Device"
• Dynamic - This type of identifier is one that is created by the switching function for a device when it enters into a call and shall remain constant for the life of the device's participation in the call (that is, the creation of a connection identifier for the device). As soon as the device leaves the call, the identifier becomes invalid. The use of a dynamic identifier by a switching function is determined when the switching function does not have a static identifier for the device or the identifier can not uniquely identify the device in a call. This type of identifier is an octet string. It is never a dialable number and can never be used outside the context of the connection identifier. This type of identifier is not directly related to a device element but is strictly used to make the connection identifier unique. Refer to Management of Dynamically-Assigned Identifiers for more information.

Returns:

the value of field 'deviceID'.

isValid

public boolean isValid()

Method isValid

marshal

public void marshal(java.io.Writer out)
             throws org.exolab.castor.xml.MarshalException,
                    org.exolab.castor.xml.ValidationException

Method marshal

Parameters:

out -

Throws:

org.exolab.castor.xml.MarshalException

org.exolab.castor.xml.ValidationException

marshal

public void marshal(org.xml.sax.ContentHandler handler)
             throws java.io.IOException,
                    org.exolab.castor.xml.MarshalException,
                    org.exolab.castor.xml.ValidationException

Method marshal

Parameters:

handler -

Throws:

java.io.IOException

org.exolab.castor.xml.MarshalException

org.exolab.castor.xml.ValidationException

setCallID

public void setCallID(java.lang.String callID)

Set the connection identifier sequence. This is comprised of the following parameters.

1. callID (M) Octet String - An identifier used by the switching function to represent a valid call. The maximum length supported by the switching function is provided via the capabilities exchange services. These IDs are created by the switching function and are globally unique among all calls within the switching sub-domain.
2. deviceID (M) DeviceID - An identifier which is used to represent a device in the switching sub-domain.

Parameters:

callID - the value of field 'callID'.

setDeviceID

public void setDeviceID(LocalDeviceID deviceID)

Set the device identifier. This is defined to be an identifier which is used to represent a device in the switching sub-domain.

This identifier can be either one of the two following values:

• Static - This type of identifier is defined in ECMA-269 Section 6.1.3, "Device"
• Dynamic - This type of identifier is one that is created by the switching function for a device when it enters into a call and shall remain constant for the life of the device's participation in the call (that is, the creation of a connection identifier for the device). As soon as the device leaves the call, the identifier becomes invalid. The use of a dynamic identifier by a switching function is determined when the switching function does not have a static identifier for the device or the identifier can not uniquely identify the device in a call. This type of identifier is an octet string. It is never a dialable number and can never be used outside the context of the connection identifier. This type of identifier is not directly related to a device element but is strictly used to make the connection identifier unique. Refer to Management of Dynamically-Assigned Identifiers for more information.

Parameters:

deviceID - the value of field 'deviceID'.

unmarshalConnectionID

public static ConnectionID unmarshalConnectionID(java.io.Reader reader)
                                          throws org.exolab.castor.xml.MarshalException,
                                                 org.exolab.castor.xml.ValidationException

Method unmarshalConnectionID

Parameters:

reader -

Throws:

org.exolab.castor.xml.MarshalException

org.exolab.castor.xml.ValidationException

validate

public void validate()
              throws org.exolab.castor.xml.ValidationException

Method validate

Throws:

org.exolab.castor.xml.ValidationException

toString

public java.lang.String toString()

Calls super.toString() and appends getDeviceID(); getCallID()

Overrides:

toString in class ch.ecma.csta.CastorObject