Fusion enables applications to monitor information about RTP sessions in a chassis by using an OAM Extended Management Component (EMC) for RTP. The topics that follow provide a brief introduction to this EMC. For more information about OAM and its EMCs, refer to the Dialogic® NaturalAccess™ OAM API Developer's Manual.
This topic provides the following information:
The Fusion RTP EMC caches data for in-bound and out-bound RTP packet flows. It performs this task for all flows on all CG boards under OAM API management in a chassis. Each MSPP channel is equivalent to either an in-bound flow (RTP IN), out-bound flow (RTP OUT), or a combination of the two (RTP FDX). Each RTP flow is associated with a unique identifier. The syntax is described in this topic.
The Fusion RTP EMC generates OAM events. Each event contains a list of flow identifiers. Clients must use these flow identifiers together with the keyword structure to create a valid keyword name. That keyword name can then be used with the OAM service function oamGetKeyword to retrieve information about the flow.
Clients typically access data from the Fusion RTP EMC through two keywords:
|
RTP EMC keyword |
Description |
|
rtp.in-flow-identifier.struct |
Accesses inbound RTP simplex channel information. |
|
rtp.out-flow-identifier.struct |
Accesses outbound RTP simplex channel information. |
The application replaces the bracketed expressions (in-flow-identifier or out-flow-identifier) with valid flow identifiers to obtain valid values from oamGetKeyword. The .struct elements in the keyword names indicate that the value is structured. Refer to Using structured values for more information.
There are other keywords that do not involve flow identifiers. The names can be taken directly from the table shown RTP EMC keyword hierarchy. Each field separator in a flow identifier is unique, which allows the client to find a particular field quickly with a single call. The flow identifier syntax is as follows:
flow-identifier-list:
flow-identifier
flow-identifier, flow-identifier-list
flow-identifier:
in-or-out - dest-udp-port / start-time @ dest-ip-address
in-or-out : one of
in out
dest-ip-address :
n : n : n : n
n :
0 . . 255
dest-udp-port :
0 . . 65535
start-time :
0 . . MAX_UNSIGNED_LONG
An in-flow-identifier begins with in, and an out-flow-identifier begins with out.
The Fusion RTP EMC provides keyword values that can be simple or structured. Leaf-node keywords ending with struct have structured values. All other keywords have simple values. Simple values are scalar; structured values are not, and require further explanation.
Structured values are C-style aggregate initializers, without the braces. A structured value is a sequence of one or more fields, separated by commas. They contain no white space. Fields contain simple values, without commas. The syntax for structured values follows:
structured-value:
simple-value
simple-valueopt, structured-valueopt
simple-value:
Any string of characters without commas or white space
The optional values (indicated by opt) in this syntax indicate that there can be any number of empty fields, or empty simple values, in a structured keyword value. Structured values represent the entire tree of values under a keyword formed by removing the .struct element from its name, for example:
Keyword:rtp.<in-flow-identifier>.local.struct
Value:ipAddress,udpPort,SSRC,CNAME,TOOL
Where <in-flow-identifier> is replaced by a valid flow identifier and the value is a legal value, usually an integer or a string.
The Fusion RTP EMC produces two primary events, one to indicate new flows that have just started (RTPEVN_FLOW_START), and another to indicate existing flows that have just stopped (RTPEVN_FLOW_STOP). These are referred to as flow start and flow stop events. These events are relatively independent of the EMC data cache.
Keyword values for an in-flow or out-flow are valid almost immediately after the flow start event is generated. There is a very small chance that the cache will not have been updated when the client accesses the keyword. In that case, a later attempt will probably obtain a valid value.
Attempts to read keywords for stopped flows (that is, flows for which flow stop events have been returned) always fail.
The relative order between flow start and stop events cannot be preserved, due to the aggregation of flow identifiers into homogeneous lists. In particular, an identifier from a flow start event can have a start time later than an identifier from a following flow stop event.