Difference between revisions of "Components"

Latest revision as of 13:28, 26 August 2013

This is the main part of the message holding the data specific to each protocol (like MAP, CAMEL, etc.)

There can be zero or more components in a message. Zero components can happen only in an error return message.

<component remoteCID="1" type="Invoke" operationCode="updateLocation">
	application-specific
 	...
	application-specific
</component>

[edit] Parameters

• type – Type of the TCAP component, may be one of: Invoke, ResultLast, ResultNotLast, U_Error, L_Reject, R_Reject, U_Reject

• localCID – ID for a locally created component. This is mandatory for components that are invoked on the local end. Results will be received with the same parameter.

• remoteCID – ID for a remotely received component. This is designated the ID set by the remote end for the component. Results that are locally sent for this component should contain this parameter.

• operationCode – Code of the requested operation

• errorCode – Code of the returned error if applicable

• problemCode – Code of the encountered problem if applicable

• timeout - Time in seconds to wait for a response

• operationClass - Specify which type of operation this is. It can have one of the following values:
  • reportAll - expects a result, either being a ReturnResult, either a ReturnError.
  • reportFail - expects a result only in case of error or failure.
  • reportSuccess - expects a result only in case of succesful handling.
  • reportNone - does not expect any kind of result.

It is important to note that most components of type Invoke do not wait for an answer and the transaction should be terminated silently as described for TCAP.

The direction of each component is determined by the presence or absence of localCID and remoteCID.

The operation code indicates which operation is requested from the application context. A known code is translated into a keyword, an unknown code is returned in numeric format.

[edit] Application Specific

The structure of the XML follows the structure of the protocol as defined by the standards. The names of the tags are taken directly from the ASN.1 description.

[edit] Mapping of ASN.1 components

An ASN.1 constructor is mapped to an XML element that has children but no text content – or rather the text consists exclusively from whitespace.

An ASN.1 primitive is usually mapped to an XML element that has the main decoded value of the primitive as text content. Additional information about the content is provided in attributes of the element.

To avoid ambiguities no formatting whitespaces are allowed around the text content of a primitive. Unless the content is a string that actually embeds a newline the XML element of a primitive will appear on a single line.

<correct>Hello, World!</correct>

<wrong>
   This should be one line
</wrong>

[edit] Encodings

Elements containing parameters may indicate the encoding of the parameter using an "enc" attribute. This indication is mandatory for values that were not decoded from their binary representation and are encoded in hexadecimal:

<param1>This is a string</param1>
<param2 enc="hex">56 78 9a bc</param2>

For troubleshooting purposes the converter can be configured to add encoding information to all parameters.

Some common encodings are:

• str – a string

• int – an integer

• bool – a boolean value, true or false

• hex – hexadecimal representation of undecoded octets

• bcd – a string of digits with no other indication

• e164, e212, e214 – phone number specific representations (E.164, E.212, E.214)

• oid – an Object Identifier in dotted format like 1.1.186.2.14.3

• null – there is no value, the simple presence of the parameter has a meaning

[edit] Unsupported components

ASN.1 components for which the name is unknown or unsupported are decoded as <u> elements. Additional information is provided to help report and improve the parser:

• the type="..." and tag="..." of the component is always added

• for constructors their content is also added as <u> elements

• for primitives the content is provided in the text content, in decoded (if standard encoding) or raw hexadecimal format

Example:

<SomeConstructor>
 	<someKnown enc="e164">+492115550000</someKnown>
      <u type="application" tag="7">
  		<u type="universal" tag="2" enc="int">12345</u>
  		<u type="universal" tag="19" enc="str">Some text</u>
  		<u type="context" tag="117" enc="hex">67 89 ab cd</u>
  	</u>
</SomeConstructor>

[edit] Errors

Depending on their nature the errors are Rejects or User Errors. The type of the returned component indicates what kind of error it is and carry futher information.

[edit] Rejects

A reject indicates the operation could not be started at all – for example because the component or operation are unknown. Most of these errors are created automatically by lower layers so they will appear only in answers.

Example:

<component type="U_Reject" problemCode="General-UnrecognizedComponentType"/>

[edit] User Errors

An User Error indicates the operation was understood and possibly started but some error occurred during the processing, either because of the provided data or because of external conditions unrelated to the component itself.

Example:

<component type="U_Error" errorCode="unknownSubscriber">
	<unknownSubscriberDiagnostic>imsiUnknown</unknownSubscriberDiagnostic>
</component>