This chapter covers ME actions, from H through Z in alphabetical order. For actions A through G, see "Actions A Through G." An action immediately acts on ME and effects one of the components (manipulates data), whereas objects and properties describe the configuration. Actions are only available at the top-level prompt of the CLI (or through the ME Management System Actions tab).
Most actions become available when ME starts, but some may only become available when the corresponding service or provider registers with ME. The registration is dependent on the configuration. For example, the directory-reset action cannot register if the directory service is not configured.
The ME supports an action that allows you to manually issue an H.225 RAS Location Request (LRQ) to a configured peer gatekeeper (GK). If a peer GK with this remote IP address is configured, the LRQ reports the results. The result can be either a route-server with an address, an LRJ with a reason, or a timeout.
You must enter the configured GK address, a string representing the destination to locate, and the type of destination to locate. Optionally, you can enter a string representing the source and the type of source.
A peer GK and LRQ timeout must be configured for you to execute this action.
NNOS-E>h323-issue-lrq 172.44.200.35:1719 8675309 dialedDigits CXC-h323-1 h323ID
LRQ sent to peerGK at 172.44.200.35:1719
LRQ for '8675309' was Confirmed, Call Address 10.1.20.126:1720
H.225.0 RAS: locationRequest
H.225.0 RAS
0... .... Extension Bit: False
Range = 25 Bitfield length 5, Choice Index: .100 10..
Choice Index: 18
RasMessage: locationRequest (18)
locationRequest
.... ..1. Extension Bit: True
.... ...1 Optional Field Bit: True (endpointIdentifier is present)
0... .... Optional Field Bit: False (nonStandardData is NOT present)
requestSeqNum: 3
Range = 128 Bitfield length 7, Octet String Length: 0001 001.
Octet String Length: 10
endpointIdentifier: CXC-H323-1
Sequence-Of Length: 1
destinationInfo: 1 item
Item 0
0... .... Extension Bit: False
Range = 2 Bitfield length 1, Choice Index: .0.. ....
Choice Index: 0
DestinationInfo item: dialedDigits (0)
Range = 128 Bitfield length 7, Octet String Length: ..00 0011 0... ....
Octet String Length: 7
dialedDigits: 8675309
.... 0... Extension Bit: False
Range = 7 Bitfield length 3, Choice Index: .... .000
Choice Index: 0
replyAddress: ipAddress (0)
ipAddress
ip: 172.44.10.67 (172.44.10.67)
port: 1719
0... .... Small Number Bit: False
Number of Sequence Extensions: 15
.... ...1 Extension Present Bit: True (sourceInfo is present)
0... .... Extension Present Bit: False (canMapAlias is NOT present)
.0.. .... Extension Present Bit: False (gatekeeperIdentifier is NOT present)
..0. .... Extension Present Bit: False (tokens is NOT present)
...0 .... Extension Present Bit: False (cryptoTokens is NOT present)
.... 0... Extension Present Bit: False (integrityCheckValue is NOT present)
.... .0.. Extension Present Bit: False (desiredProtocols is NOT present)
.... ..0. Extension Present Bit: False (desiredTunnelledProtocol is NOT present)
.... ...0 Extension Present Bit: False (featureSet is NOT present)
0... .... Extension Present Bit: False (genericData is NOT present)
.0.. .... Extension Present Bit: False (hopCount is NOT present)
..0. .... Extension Present Bit: False (circuitInfo is NOT present)
...0 .... Extension Present Bit: False (callIdentifier is NOT present)
.... 0... Extension Present Bit: False (bandWidth is NOT present)
.... .0.. Extension Present Bit: False (sourceEndpointInfo is NOT present)
.... ..0. Extension Present Bit: False (canMapSrcAlias is NOT present)
Open Type Length: 23
Sequence-Of Length: 1
sourceInfo: 1 item
Item 0
0... .... Extension Bit: False
Range = 2 Bitfield length 1, Choice Index: .1.. ....
Choice Index: 1
AliasAddress: h323-ID (1)
Octet String Length: 10
h323-ID: CXC-h323-1
Sends an UNREGISTER and then REGISTER request to an external gatekeeper, which renegotiates the registration. Use the show h323-external-gatekeeper command to list gatekeepers and their IP addresses.
NNOS-E>show h323-external-gatekeepers remote-address: 172.10.100.10:1719 local-address: 172.30.0.143:1719 regstate: registered last-registered-time: 06:51:26 Mon 2008-10-06 registration-interval: 3600 gatekeeper-id: OpenH323GK endpoint-id: 1290_endp activecalls: 0 default-gw: false NNOS-E>h323-reregister-gatekeeper 172.10.100.10 Success!
Sends an UNREGISTER request to an external gatekeeper. Use the show h323-external-gatekeeper command to list gatekeepers and their IP addresses.
Manages system software releases and network interface cards (NICs). Note that if you have a file on your PC, and want to install it, you can either use PSCP (if you have SSH configured on the ME) or TFTP (if you have TFTP configured on the ME). Or, you can use the ME Management System Update Software tool.
Select one of the following:
file: Installs a file that exists on the ME in a format that is install-ready (e.g., decompressed). Enter the file name. Optionally, specify whether to install the file on the local box or the entire cluster. However, to upgrade members in a cluster without interrupting call flow, use the controlled option. By default, the ME installs the file on the device.
url: First downloads the specified file, and then installs it onto the ME. Enter a URL for the software upgrade. Optionally, specify whether to install the file on the local box or the entire cluster. However, to upgrade members in a cluster without interrupting call flow, use the controlled option. By default, the ME installs the file on the device.
nic: Updates the stored MAC addresses and associates them to interface names, making the system aware of interfaces it can use. Execute this action if you purchased a new NIC after your system was up and running (i.e., you are adding a NIC). Optionally, for a faster installation, you can specify the hardware platform instead of waiting for the ME to read the IPMI.
nic-reinitialize: Wipes the information from a NIC. Use this action if you selected the wrong system model with the nic action, but only if instructed to do so by technical support.
module: Forces installation of an older module from a release marked as good. This action is used to help regain network connectivity should there be problems, but should only be used under direction of Oracle personnel. You can type a question mark at the command line to see the available modules (install module ?).
cancel: Cancels the operations initiated by the install file controlled action.
You can also schedule this action as part of routine maintenance using the task object.
install file source [box | cluster | controlled] install url source [box | cluster | controlled] install nic [model] install nic-reinitialize install module kernelModule install cancel
NNOS-E>install file release.tar.gz controlled Are you sure (y or n)?y sending release.tar.gz to 172.66.0.10... sending release.tar.gz to 172.66.0.11... sending release.tar.gz to 172.66.0.12... Restarting 172.66.0.10... Restarting 172.66.0.11... Restarting 172.66.0.12... NNOS-E is restarting... NNOS-E>
Displays information about files used for upgrade. Typically this information indicates build, platform, prerequisite, and component data.
NNOS-E>install examine /releases/release-b3.4-32250.tar.gz
-----------------------------------
/releases/release-b3.4-32250.tar.gz
-----------------------------------
summary NNOS-E Application
description
type simple
restart warm
variety app
platform all
platformType none
version 3.4.99
build 32250
branch b3.4
prereqOSBranch
prereqOSBuild 0
prereqAppBranch
prereqAppBuild 0
name
within
untarDir /cxc
preInstallScript
installScript install/install.sh
InstallComponents
component[1] os 1.6 "" 32170
InstallComponents
component[1] postgres "07.02.0005 PostgreSQL 8.1.2"
component[2] postgres "07.02.0005 PostgreSQL 8.1.9"
InstallComponents
component[1] kernel 2.6.11-6-cov kernel-2.6.11-6
Removes all entries from the internal CSTA SIP session cache. The cache contains state information for all active CSTA sessions being handled by the local ME devices. This action is typically used to clear the cache without rebooting in the event of a failover recovery. Use the external-session action to clear state data for all boxes in the cluster.
Manages terminals associated with 3PCC servers and tests PBX connections. See the csta-settings object for a general description, and Identifying the Active Device for a discussion of how the ME uses device ID information. See the Cisco online documentation, Partitions and Calling Search Spaces, for complete information on Cisco partitions.
get-terminals: Returns the unique identifier associated with the terminal(s) residing at the specified phone address. Use the output of this action with the set-active-terminal action.
set-active-terminal: Sets the active terminal for a phone address. Specify the terminal ID and the address to indicate which terminal is active for that address. Use the get-terminals option to returns a list of IDs.
clear-active-terminal: Removes the active terminal designation from the currently active terminal for a specific phone address. You can use set-active-terminal to overwrite the selection; use this to remove without replacing the active terminal selection.
select-active-terminal: Clears the current active terminal designation and then rings all terminals associated with the specified address. The terminal used to answer the query becomes the active terminal.
get-all-terminals: Returns, listed by phone address, all terminals for all users currently logged in to MOC.
test-pbx-connection: Used for debugging, tests to make sure that all terminals have a connection to the PBX. Specify a phone address, and the ME tests each configured 3PCC server to see if that number can reach the PBX through the server.
reload-terminals-from-termdb: Refreshes the ME list of active terminals by overwriting the current list with the list stored in the database.
set-default-partition: Sets the partition that the specified address uses when involved in call operations. Enter the partition name and the phone address. The default partition can also be set with the default-partition property of the session configuration csta-settings object, but the setting of this action overrides the configuration.
set-terminal-partition: Sets the partition that a specific terminal within a specified address uses when involved in call operations. Enter the terminal ID (use the get-terminals option to returns a list of IDs) partition name and the phone address.
show-connections: Lists all JTAPI connections and their status.
jtapi-control get-terminals phoneAddress jtapi-control set-active-terminal terminalID phoneAddress jtapi-control clear-active-terminal phoneAddress jtapi-control select-active-terminal phoneAddress jtapi-control get-all-terminals jtapi-control test-pbx-connection phoneAddress jtapi-control reload-terminals-from-termdb jtapi-control set-default-partition partition phoneAddress jtapi-control set-terminal-partition terminal partition phoneAddress jtapi-control show-connections
NNOS-E>jtapi-control get-all-terminals # Provider # Monitored Addresses 3 Provider: 172.30.3.201 Address: 54815 Active Terminal: Provider: 172.30.3.201 Address: 54804 Active Terminal: SEP003094C3D233 Provider: 172.30.3.201 Address: 54810 Active Terminal: # Provider # Monitored Addresses 1 Provider: 172.30.3.199 Address: 77704 Active Terminal: NNOS-E>jtapi-control get-terminals 77702 SEP000E0C774E0B NNOS-E>jtapi-control test-pbx-connection 77702 Cisco Call Manager 6.0 Provider: 172.30.3.199 16 Address=77702 Exists Terminal=SEP000E0C774E0B cisco 4.0 Provider: 172.30.3.201 16 Address=77702 Not found on Provider
Manages the Oracle-licensed software that contains the your specific product features. You must install a license to unlock your customer-specific features. You can fetch a license from the ME license server, or apply a license that is already on your local system. Use the show licenses command to see whether a license is installed or to determine the license name.
A license contains one or more features. You can have multiple licenses active at any time (displayed with show licenses). You can apply, refresh, and revoke licenses, but not the individual features within a license.
fetch: Downloads a license from the ME license server and installs it on your system. Before executing this action be sure that you have a connection to the public Internet and that port 616 is available and is not blocked by a firewall. You must supply a key to access your file; copy and paste the key you received from your sales representative. Optionally, you can specify a different server. The default server path is https://license.covergence.com:616/.
apply: Applies the specified license file, which must be stored on the system from which the action is executed. Use this if you have multiple devices as part of your license agreement and you have already saved the file locally. Optionally you can specify whether the license application is temporary (the life of the current session) or permanent. By default it is temporary.
revoke: Disables the specified license. You might use this to disable a feature for testing, for example. Optionally you can specify whether the change is temporary (the life of the current session) or permanent. By default it is temporary.
refresh: Refreshes a license expiration or feature change. Use this action if you have an existing license nearing expiration or an evaluation copy. When you execute the action, ME logs in to the license server with the key stored key and updates the license (if available) with a later expiration time. Optionally, you can specify a different server. The default server path is https://license.covergence.com:616/.
Manages the Linksys certificate process. Linksys equipment supports a proprietary version of SRTP. It uses SIP INFO messages to exchange credentials (in mini-certificates) and securely distribute the key used to encrypt/decrypt the RTP packets. The RTP encryption is a variation of RFC 3711, The Secure Real-time Transport Protocol (SRTP). Linksys uses the same encryption algorithm (AES-CM-128), but uses HMAC-MD5 instead of HMAC-SHA1 for authentication. The ME must have access to the key used to generate the mini-certificates for participation in encryption/decryption. This action can generate the mini-certificate and private key needed by each phone.
Note:
You must have a root certificate loaded on the system for this action to be successful. The default location for the root certificate is /cxc/certs/linksys_ca.pem.The linksys action provides five tools.
mini-certificate: Creates a mini-certificate, which will later be used by a Linksys phone to exchange an encrypted symmetric key. When both phones in a call support cryptographic exchange, use this action to create a mini-certificate that is sent in an INFO message to the other phone. (You must execute this action for both phones.) After exchanging mini-certificate, the phones can then exchange an encrypted symmetric key.
Enter the following fields to generate a mini-certificate:
userID: A name that identifies this phone (subscriber) to the other party. The user ID can be up to 32 characters.
displayName: A name used by the caller to verify that the callee is the intended call recipient. Enter the user ID field in the Request URI of the INVITE message sent to the proxy server by the caller UAC when making a call to this subscriber (UAS). The display name can be up to 16 characters.
expiration: The date and time at which this mini-certificate expires. Enter the date in the format hh:mm:ssyyyy-mm-dd.
filename: A name for an output file that will contain the mini-certificate and private key. If you do not specify a file name, the output is not written to a file.
Once you execute this option, the ME returns the content of the mini-certificate and the SRTP private key. You can copy and paste each of these fields into your Web GUI for your phone (or other software interface), as well as test the certificate using the check-mini-cert option.
generate-ca-key: Generates a Linksys/Sipura CA key. This is the public/private key pair that acts as the Sipura certificate authority. It is needed to generate the mini-certificates for each phone and during the key exchange.
The key is stored in /cxc/certs/linksys_ca.pem. When executing this action, you can specify whether to overwrite any previous CA key. The default setting, false, does not overwrite the key. Set the field to true to force an overwrite.
check-mini-cert: Verifies the contents of a certificate created with the mini-certificate option. When executed, the ME checks the expiration date and signature of the certificate. Enter the content of the mini-certificate to invoke this option.
display-mini-cert: Displays the values of the fields that you entered when you created the mini-certificate. Paste the encoded certificate into the system to display output in a readable format.
display-msg: Displays the fields of the SIP INFO messages that were created during key exchange. After a call is established, endpoints send INFO messages to negotiate key exchange. The bodies of these messages are base-64 encoded. Enter a message (which can be taken from the call log or a trace) to display the message in a readable format.
linksys mini-certificate userID displayName expiration [fileName] linksys generate-ca-key [false | true] linksys check-mini-cert certContent linksys display-mini-cert certContent linksys display-msg message
NNOS-E>linksys mini-certificate 9577 9577-display ”23:05:45 2004-11-25” Mini Certificate: OTU3Ny1kdWVyb2QAAAAAAAAAAAAAAAAAAAAAAAAAAAA5NTc3AAAAAAAAAAAAAAAAMDMwNTQ1MjYxMTA0ybYgcwG8IeaYz225Grs7sDJflnfyJxARPehQ+CO6WisAZ77U2zBi8TCapIwqcDhNXwgYKZxljAET3dFnzAxs2ze1/kEHCqvUmDIEjaYL+1WTySaI1TGKy15FbyZb6dQXtbPF+fXiRP//caFfKUBTuuwtjExxaAz0H3u8Tc2YT/wH7a0+snpUTFeK/Sv9vd7aAUbufSxewlL2GeTdOu0v2i4R25/RH6iOHyChGpVt2EJ3BHAlLgXTfJibiwwkrMSe1grSibsCy0D825ezAt66AVKTa/hOmSBvdZvdamJIsbP89vnAJPiOfWNet8T40/wOYyylAE5JDJ/2+G/MDyc5ImzFTvifKvIQ55T7Jr5E0RUbacDZIlHy5oW+x4sfawCiQZunnb11qlAgYhvOeuo4f3JGUKJAld0GRjHfvjRhb3c= SRTP Private Key: Oxq38oJqjhe++yBTtTotoMndnZXulkgnnxFQPd0v96oc81IZ5dug9Szob9ZYQXsPkWAxSb Oxq38oJqjhe++BVpyxz2P2qtZEg== NNOS-E>linksys check-mini-cert OTU3NwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5NTc3AAAAAAAAAAAAAAAAMTU1ODQ4MTEyNTA0z1TBkpXzjmR6PFX5K4S7G5SxdpozH460T14KpwOxZ8ly4KWpFlcC2rTTWEU6WnOufcj5Bfif7cdsAF/89kZu83NFceK2ZBRGrJ4cbxREtuPwy1FqkXpBQcztTFXjeyFaq8K7OESebQayFetBEceIupuzxfedlJPRsMRhsHN1uKpomc/tdJFHJhxSzn+fX+GTACrXQEHzI+ooDL+iQvzhJ1zk/gXTGuk76lkJG2XLvSvdjTp8RjQX/F5h0GnBa02d3bQ51n7IBvJnTeaGKp/U/e5pQvW5u6vD/uHkqkTGkZDZzOyIISIdgWVxdjA9cpaSa2D5nPhr8G/WhOadLZ08fmB0kPwEFjJ0h0dojjknjNJp/qVjR5NEEzuj5kH7Qlvxk25l0MThhydCYpbxShy2GSno7apnyCA02YBQCRlGBOs= Certificate has expired NNOS-E>linksys generate-ca-key Unable to overwrite Linksys CA key NNOS-E>linksys display-message AAAAAMFgaBarzavNNzc3NwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3Nzc3AAAAAAAAAAAAAAAAMDQ1OTU5MTEwMTA4qtnZJ1ER7t64CqEHeDYytppxkTkX0OWl6hR8RKRCLu5yruwXVM4c4QYJ/AjcHZ90vcdyxbEjPXDTO9nZLAZkU8k1iBGUaBUkHZbiae8H3+xa8dIq3m0Ydv28dPqA3UkGg3oIepsfaxDJXi/ci3VSD+J78hYlVEHwOu0JfI+Y0cuyk1wOxSLIJP7smLTb8oDCuN+wGdMUVNuphM+zY6SGJwkaae8sR7sikpun/fG3aFx51aRxSt9AHyAplLZbzPnb Message ID : HELLO (0x00000000) SSRC : 3244320790 (0xc1606816) Flags : 0xabcdabcd Mini-certificate : User name : 7777 User ID : 7777 Expiration : 00:59:59 Sat 2008-11-01 Public key : 0xaad9d9275111eedeb80aa107783632b69a71913917d0e5a5ea147c44a4422eee72aeec1754ce1ce10609fc08dc1d9f74bdc772c5b1233d70d33bd9d92c066453 Signature : 0xc9358811946815241d96e269ef07dfec5af1d22ade6d1876fdbc74fa80dd4906837a087a9b1f6b10c95e2fdc8b75520fe27bf216255441f03aed097c8f98d1cbb2935c0ec522c824feec98b4dbf280c2b8dfb019d31454dba984cfb363a48627091a69ef2c47bb22929ba7fdf1b7685c79d5a4714adf401f202994b65bccf9db
Manipulates the load balancing database. Do not execute this action unless instructed to do so by Technical Support.
Manages the location cache for the current box. Use the location-database action to manage the database that runs on the master. Select one of the following operations:
lookup: Returns location information for the specified AOR.
flush: Removes all entries from the location cache. Optionally you can specify whether to flush the cache immediately or as the entries time out. By default, the system flushes entries immediately.
delete: Deletes the specified entry from the location cache. Enter the address of record for the entry, which can be found in the show location-cache command.
restate: Changes the state of the location cache entry. Enter the AOR and the new state.
audit: Verifies that location bindings are not corrupted. You can enter a specific AOR to verify or verify the entire location cache.
prune: Removes all or the specified corrupted bindings from the location cache.
save: Writes the specified AOR or the entire location cache to the location database on the cluster master.
reload: Reloads the location database to the location cache on the local box, wiping out the current cache. If you enter an AOR, only that entry is rewritten.
cleanup: Immediately removes all location bindings that are not in a registered state. You can automate this action by setting the cache-cleanup-interval property of the location service settings object.
expire: Forces the location cache entry expiration time to 0, resulting in no throttling for the following applicable REGISTER request. You can specify the address of record that this action applies to, or apply it to all AORs.
You can also schedule this action as part of routine maintenance using the task object.
location lookup aor location flush [now | gracefully] location delete aor location restate aor {unregistered | trying | in-service | redirect | registered | out-of-service} location audit [aor] location prune [aor] location save [aor] location reload [aor] location cleanup location expire [aor]
NNOS-E>location restate sip:6667778888@abc.com out-of-service Success! NNOS-E>location lookup sip:6667770001@best.com sip:6667770001@best.com currently has the following locations: Contact: <sip:6667770001@192.168.215.95:5060;transport=UDP;line=g4ced3b1>;expires=59 NNOS-E>location audit Success!>
Manages the location database across the cluster. The primary or master appliance contains the main location database. The external database, which is mirrored from the main database, is the database running on the backup system in a cluster configuration. If a failover happens, the external database becomes the master database. Use the location action to manage the cache that runs on an individual box. Select one of the following operations:
merge: Merges the specified file into the existing master location cache. If the merge file has a new binding (i.e., one with an index not present in the cached AOR), it is added to the existing cache. If the merged copy has a binding that already exists in the AOR, the values from the merged copy take precedence, overwriting the values in the existing cache. By default, the ME uses the file /cxc/location.xml. Optionally, you can specify a different file path.
replace: Writes the specified file to the location database, wiping out the current entries. By default, the ME uses the file /cxc/location.xml. Optionally, you can specify a different file path
save: Writes the location database to the supplied file name. If you do not supply a name, it saves to the default location: /cxc/location.xml.
delete: Deletes the specified entry from the location database. Enter the address of record for the entry, which can be found in the show location-cache command.
flush: Removes all entries from the location database.
You can also schedule this action as part of routine maintenance using the task object.
Turns logging on and off for the current CLI session. You configure the CLI as a log target, including the desired class and severity filters, using the services cli object.
For any given CLI session, you can turn this output on or off using this log-target action. You may want to do this, for example, so that you can record logging in one CLI session, while working in another. In that way, your work will not be interrupted by log messages.
You must have enabled CLI logging and event logging on a global level for this action to take effect. Set admin to enabled for both the cli and event-log objects.
This action is not available from the ME Management System.
Manages user logins. You can either terminate any active login session or unlock users that have been locked out.
kill: To terminate a session, use the show login-sessions -v command to list active sessions with identifiers. Specify the session type and the ID to identify the session to end.
unlock: Reinstates access to a user who has been locked out. (This may happen, for example, if the user violated the password-policy configuration.) Specify the name of the user to unlock. Use the show local-users command to verify that a lockout is the problem for the user.
Establishes an outgoing SIP loopback call. In this call type, the media is looped back to the ME to provide various performance metrics. The loopback process works by an endpoint encapsulating and reflecting RTP packets back to the ME. Data such as media path, round-trip time, and packet loss are written to the ME database, and can be displayed using the ME Management System Call Logs Monitored Calls link or the call-loopback Trend Graph (on the Status page). To execute this action, specify which type of loopback to perform and other parameters:
packet: The ME initiates sending RTP packets. When the endpoint receives an RTP packet it responds by reflecting it back to the ME.
packet-init: When The Session Controller Media Engine initiates the action, the endpoint begins responding immediately by sending packets of the type negotiated in the SDP. When the endpoint receives the RTP packets, it ceases sending SDP packets and reflects RTP back to the ME.
seconds: Specify the duration of the call, between 2 and 600 seconds.
to: Specify the endpoint in the format of a SIP URI.
from: Optionally, specify the endpoint in the format of a SIP URI.
protocol: Optionally, specify the content of the FROM header in the SIP INVITE.
You can also schedule this action as part of routine maintenance using the task object or from the Monitored Calls or Monitored URIs pages in the ME Management System.
Changes the state of a USB stick that was used for a system upgrade. This action is only necessary on those platforms that require removal of the USB stick in order for the ME device to boot from its hard drive. In those cases, you must remove the stick prior to the system rebooting. By doing so, you leave the stick in an unusable state. However, the stick still contains data required for the upgrade (license, configuration, etc.). To retrieve that information:
Start the upgrade and remove the stick from the ME device before the system reboots.
After the system reboots, reinsert the stick.
Execute this action with the true option.
Perform a warm restart to retrieve additional configuration from the stick.
Do not use the false option with this action unless instructed to do so by Technical Support.
Deletes all media files associated with a specific session ID. Use the show media-files command to list the files. The path field of the output is the complete path and file name. That name also contains the session ID.
NNOS-E>show media-files session-id channel date path ---------- ------- ----- ---- 0x4c2264e08bc7098 0 15:30:08 Thu 2006-02-23 /cxc_common/rtp_recorded/04c2/264e/08bc/sess-04c2264e08bc7098-0-0.xml 0x4c2264e08bc7098 1 15:30:08 Thu 2006-02-23 /cxc_common/rtp_recorded/04c2/264e/08bc/sess-04c2264e08bc7098-0-1.xml 0x4c2264e09522afa 0 15:30:17 Thu 2006-02-23 /cxc_common/rtp_recorded/04c2/264e/0952/sess-04c2264e09522afa-0-0.xml 0x4c2264e09522afa 1 15:30:17 Thu 2006-02-23 /cxc_common/rtp_recorded/04c2/264e/0952/sess-04c2264e09522afa-0-1.xml NNOS-E>media-delete 0x4c2264e08bc7098 Success!
Invokes the ME to delete all recorded media files that are older than the specified number of days or seconds. Enter a number and a unit of measure. By default, the ME deletes media files older than seven days when you execute this command.
You can also schedule this action as part of routine maintenance using the task object.
Removes empty recorded media directories. You may have an empty directory, for example, if the ME cleaned a directory as part of a scheduled maintenance operation. That action removes data but leaves the directories. You can also schedule this action as part of routine maintenance using the task object.
Creates a tarball of specified WAV files suitable for installation on other ME devices. Use a wildcard expression to enter multiple source files. The ME verifies that all files are playable WAV files. Enter the desired tar ball file name as the destination.
Sets the minimum age for a media session before it is subject to a media session audit. When you execute this action, the ME checks to ensure that each media session has a matching signaling session. If the ME finds a media session without accompanying signaling, it deletes the orphaned media session. Because the media session is established before signaling is set up, the ME disregards sessions until they have reached an age set by this action. See Setting Time and Time Intervals for information on entry format requirements for minimum age.
Provides utilities to work with the Multimedia Internet KEYing (MIKEY) key management scheme. MIKEY is intended for use with real-time applications, specifically to set up encryption keys for multimedia sessions that are secured using SRTP. (See RFC 3830, MIKEY: Multimedia Internet KEYing, for more information.) Select one of the following options:
display-message: Displays the base-64 encoded MIKEY messages sent in SDP. For encrypted fields (mainly the KEMAC field), the system displays hexadecimal values within the MIKEY message. Both the field values and the derived SRTP Master keys are displayed for each direction (if the KEMAC is not encrypted). Enter the content of the a=key-mgmt:mikey field. The derived-salt Boolean indicates whether the SRTP Master Salt (typically the last 14-bytes of the key) is directly used (false) or derived from the MIKEY message (true). The default is false.
decrypt-message: Decrypts the encrypted portions of the MIKEY message and then displays the base-64 encoded MIKEY messages sent in SDP. If the encryption algorithm in the KEMAC field is not enc-alg=None, use this option to decrypt the field. Once decrypted, the action then provides the same display as the output of the display-message option. For this action to work, the data-type field of the MIKEY message must be Pre-Shared Secret. Enter the content of the a=key-mgmt:mikey field and the pre-shared key (secret) associated with the message. The derived-salt Boolean indicates whether the SRTP Master Salt (typically the last 14-bytes of the key) is directly used (false) or derived from the MIKEY message (true). The default is false.
mikey display-message message [true | false] mikey decrypt-message message secret [true | false]
NNOS-E>mikey display-message AQAVgCSvwBQCAAAAAAAAAAAAAADmKwoBAAAAAAUBAAVtaWtleQsAw6WosRcKPAAKFBDQ7YekSuOfDzXIDepCWouYsdFsAQAAADYCAQEDBAAAAKAEBAAAAHALBAAAAFAAAQEBBAAAAIAJAQAGAQAFAQAIAQEKAQEHAQEMBAAAAAAAAAAkABAAECLFFMcmhxxR1ssTIaW5Zw8ADrQBG2lw7G64M2W3PTLwAA==
MIKEY Message:
Version : 1 (0x01)
Data-type : Preshared - Init (0x00)
Response : true
Pseudo-Random : MIKEY-1 (0x00)
CSB-ID : 615497748 (0x24afc014)
CS Maps : 2 SRTP-ID maps
Policy : #0, SSRC=0 (0x00000000), ROC=0
Policy : #0, SSRC=3861580289 (0xe62b0a01), ROC=0
Attributes : 5 attributes
Extension (0x15) : SDP (01), len=5, 0x6d696b6579
Timestamp (0x05) : NTP-UTC (00), 0xc3a5a8b1170a3c00
Random (0x0b) : 20-byte random=0x10d0ed87a44ae39f0f35c80dea425a8b98b1d16c
Security Policy (0x0a) : #0: SRTP, total-length=54 bytes, Auth-alg (2)=0x01, Auth-key-len (3)=0x000000a0, Salt-key-len (4)=0x00000070, Auth-tag-len (11)=0x00000050, Enc-alg (0)=0x01, Enc-key-len (1)=0x00000080, FEC (9)=0x00, KDR (6)=0x00, PRF (5)=0x00, Rtcp-enc (8)=0x01, Rtp-auth (10)=0x01, Rtp-enc (7)=0x01, Prefix-len (12)=0x00000000
Keymac (0x01) : enc-alg=None, 36-byte value={key-type=TGK-Salt, key-validity=None, length=16, value=0x22c514c726871c51d6cb1321a5b9670f, 14-byte salt value=0xb4011b6970ec6eb83365b73d32f0}, mac-alg=None
Mixes audio files into a WAV file. You can use the file-play action once you have created the file.
When the ME records a call, each direction is stored in an XML format. The XML format contains information about packet timing etc. (SSRCs, timestamps, sequence numbers). The mix-session action takes the audio data out of those XML files (usually two files: one for each direction) and puts it into a single .WAV file. During that process, the ME decodes (if necessary) to a standard linear format, which you select.
Enter:
sessionID: The session ID of the originating audio file. Use the show media-files command to list the files and find the ID.
fileName: The WAV destination file. The ME creates a file with just the name you supply, so append the .wav suffix to the file name if you want it.
outputChannels: The number of channels the file should be mixed for. Enter 1 for mono, 2 for stereo. If you specify stereo, you will hear the different sides of the conversation through different speakers. The default setting is 2.
WAV format: The format you'd like the final WAV file in. The default format is pcmu.
recordedPath: Specifies the location of the files to be mixed. Use this only if the files are not in the default location.
The mix-session-threaded action has does the same thing as the mix-session action, but with improved performance from multi-threading. Valid wave formats are PCMU, PCMA, and PCM16.
Enter:
sessionID: The session ID of the originating audio file. Use the show media-files command to list the files and find the ID.
fileName: The WAV destination file. The ME creates a file with just the name you supply, so append the .wav suffix to the file name if you want it.
outputChannels: The number of channels the file should be mixed for. Enter 1 for mono, 2 for stereo. If you specify stereo, you will hear the different sides of the conversation through different speakers. The default setting is 2.
WAV format: The format you'd like the final WAV file in. The default format is pcmu.
recordedPath: Specifies the location of the files to be mixed. Use this only if the files are not in the default location.
You can specify the number of threads that can be used in this action via the rtp-mixing-action-threads advanced configuration property.
Calculates a MOS score based on various network conditions. Mean Opinion Score (MOS) is a subjective measurement and an ”opinion” of the audio quality heard by the listener on a phone. By plugging values into this action that represent your network conditions, you can determine the call quality. See the Net-Net OS-E – Session Services Configuration Guide for more information on formulating MOS results.
Enter the following parameters:
pktsReceived: The number of RTP packets received.
pktsLost: The number of packets lost during a call, detected by RTP header examination.
pktsDuplicated: The number of duplicate RTP packets during a call, detected by RTP header examination.
jitter: The average jitter, in milliseconds.
latency: The average transmission delay for each packet, in milliseconds.
codec: The CODEC used which to base default values for other fields.
Rfactor: The R-factor, a rating on the overall conversational quality of a call, expressed on a 0-to-100 scale. A value of 0 uses the CODEC defaults, otherwise enter a number up to 100, where 0 is extremely bad quality, and 100 is very high quality.
pktInterval: The ptime (nominal time between adjacent RTP packets) for the CODEC, in milliseconds. Enter a value between 0 and 100. A value of 0 indicates the default ptime for the CODEC.
mos-calculate pktsReceived pktsLost pktsDuplicated jitter latency codec [Rfactor] [pktInterval]]
NNOS-E>mos-calculate 10 0 3 6 Codec : pcmu Packet-interval : 20 msecs R-factor : 93.2 Received : 7 packets Lost : 0 packets Average Jitter : 6 msecs Average Latency : 0 msecs MOS : 4.44 NNOS-E>mos-calculate 10 1 Codec : pcmu Packet-interval : 20 msecs R-factor : 93.2 Received : 10 packets Lost : 1 packets Average Jitter : 0 msecs Average Latency : 0 msecs MOS : 4.06
Mounts a data partition on the selected drive so that the ME can access the data on the device. You can also mount a CD-ROM or USB device. Use this action to insert a device into a live system. (If the device is present at boot, the ME automatically mounts it.) Use the show mounts command to display mount status; the Drive Name field indicates whether a partition is mounted.
Adds a variable and its value to a specific session.
Enter the following parameters:
<session-id>: The session-id for the session you are applying this named variable.
<variable>: The name of the named variable to be added.
<value>: The value of the named variable to be added.
Deletes a named variable for a specified session.
Enter the following parameters:
<session-id>: The session-id for the session whose named variable you are deleting.
<variable>: The name of the named variable to be deleted.
Modifies a specific named variable for a specified session.
Enter the following parameters;
<session-id>: The session-id for the session whose named variable you are modifying.
<variable>: The name of the named variable you are modifying.
<value>: The new value of the named variable.
Causes a restart of the type specified after gracefully terminating any existing connections. By default, the orderly-restart action causes the box to restart at the first point in time when there are no active calls. This is useful for code upgrades on a unit which is currently in service. To immediately restart the box, use the restart action.
Select one of the following restart types:
warm: Exits and restarts the ME application when there are no active calls. This is the default.
cold: Exits the operating system and then restarts.
halt: Stops the ME and does not restart the system.
cnx0, cnx1: Stops and restarts the specified CNX card.
cluster: Performs a warm restart of all boxes within the cluster.
controlled: Performs a warm restart of all boxes within the cluster without interrupting call flow.
cancel: Cancels the operations initiated by the orderly-restart controlled action.
You can also schedule this action as part of routine maintenance using the task object. Use the show orderly-restart command to report on the current status of an invoked orderly-restart action (i.e., to display a report of the number of currently active calls that this system is awaiting termination on.)
Tests whether a specific IP address can accept requests, verifying the existence and connectivity of a host on the Internet. Enter a host name or IP address. Optionally, you can set the number of attempts (packets sent) and the outgoing interface used. The default number of packets sent is 3. The ME does a route lookup to select an outgoing interface unless you specify otherwise. You can also verify connectivity using the arp request action.
NNOS-E>ping 196.84.32.1 no response from 196.84.32.1 no response from 196.84.32.1 no response from 196.84.32.1 3 packets sent, 0 packets received, 3 packets lost (100%) NNOS-E>ping 172.26.0.49 28 bytes from 172.26.0.49: 0.272 ms 28 bytes from 172.26.0.49: 0.236 ms 28 bytes from 172.26.0.49: 0.201 ms 3 packets sent, 3 packets received, 0 packets lost (0%) roundtrip minimum/average/maximum: 0.201/0.236/0.272 ms
Places a call to the specified SIP URI, plays the recorded media specified by the session ID, and then disconnects the call. Compare this to the file-play action. The playback action plays recorded sessions only (the ME takes care of mixing the media for playing). The file-play action plays any file. For example, if you made a file using the mix-session action, you can play it using file-play.
Enter the following information:
sessionID: The session ID of the recorded media. Use the show media-files command to list the files and find the ID.
to: The SIP URI that specifies where to place the call to.
from: Optional. A SIP URI that appears as the caller ID.
transport: Optional. The transport protocol to use, either any, UDP, TCP, or TLS.
Manages the presence cache. The primary or master appliance contains the main presence cache. The external cache, which is mirrored from the main cache, is the database running on the backup system in a cluster configuration. If a failover happens, the external cache becomes the master cache. See the external-presence action for information on managing the external cache.
Select one of the following operations:
merge: Merges the specified file into the existing master presence cache. If the merge file has a new URL entry, it is added to the existing cache. If the merged copy has a URL that already exists, the values from the merged copy take precedence, overwriting the values in the existing cache.
replace: Writes the specified file to the presence cache, wiping out the current cache.
save: Writes the presence cache to the supplied file name. If you do not supply a name, it saves to the default location: /cxc/presence.xml.
delete: Deletes the specified entry from the presence cache. Enter the URL for the entry, which can be found in the show presence-cache command.
flush: Removes all entries from the presence cache.
You can also schedule this action as part of routine maintenance using the task object.
The proxy-accept action tells the proxy state machine that the request referenced by the handle (returned in the SIP message event) can proceed. You can also specify the response code, text string, and session-config reference if additional header or body manipulation is required on the response.
proxy-accept <handle> [response-code] [response-string] [session-config]
Valid arguments for this action are:
<handle>: References the proxy session handling the request (this value is returned in the SIP message event).
[response-code]: The SIP response code to return in response. By default the ME uses the response-code configured in the registration-plan.
[response-string]: The SIP response string to return in the response. By default the ME uses the response-string configured in the registration-plan.
[session-config]: The session-config to use for formatting the response headers and bodies.
The proxy-discard action tells the proxy state machine that the request referenced by the handle (returned in the SIP message event) has been rejected and to silently discard the message.
The proxy-reject action tells the proxy state machine that the request referenced by the handle (returned in the SIP message event) has been rejected. You can also specify the response code, text string, and session-config reference if additional header or body manipulation is required on the response.
proxy-reject <handle> [response-code] [response-string] [session-config]
Valid arguments for this action are:
<handle>: References the proxy session handling the request (this value is returned in the SIP message event).
[response-code]: The SIP response code to return in response. By default the ME uses the response-code configured in the registration-plan.
[response-string]: The SIP response string to return in the response. By default the ME uses the response-string configured in the registration-plan.
[session-config]: The session-config to use for formatting the response headers and bodies.
Immediately removes inactive associations from the location database to reclaim memory. You can also configure this to happen at a regular interval by enabling the prune-association property and defining the frequency with the pruning-interval property, both in the settings object.
Enables, disables, or tests a previously configured server that is part of a RADIUS group. Enter a reference to the configured server (configured with the RADIUS group server object). Enclose the reference path in quotation marks, and keep in mind that the server name is case-sensitive.
When using the test action, you can validate user credentials on the server via the ME. When invoked, the ME sends a test authentication message to the server to ensure that the RADIUS server is configured properly. The RADIUS server has a list of users and their associated passwords. This action verifies the name and, optionally, password, as well as the Digest settings for the user. Enter the following:
radiusServerReference: A reference to the configured server and group. Enter this in quotation marks in the format ”groupNamePath\server ipAddress”
userName: The user name to test. This is the name configured on the RADIUS server.
password: Optional. The password associated with the specified user name, as configured on the RADIUS server.
digest: Optional. The setting for Digest use for the specified user name. Enter true (user sends Digest requests) or false. The default is true.
digestRealm: Optional. The realm the Digest user is associated with. The default setting is testrealm, which is recognized and accepted by most RADIUS servers.
radius deactivate radiusServerReference radius reactivate radiusServerReference radius test radiusServerReference userName [password] [true | false] [digestRealm]
NNOS-E>radius reactivate ”vsp radius-group East server Boston” Invalid object NNOS-E>radius reactivate ”vsp radius-group East server boston” Success! NNOS-E>
The following examples illustrate the radius test action. In the first example, the test succeeds because the Digest
NNOS-E>radius test ”vsp\radius-group East\server 172.26.0.147" user1 password1 false
RADIUS test authentication:
User name: user1
Password: password1
Type: Normal
Result: Accept
The following RADIUS test fails because it is a Digest request (Type=Digest) and the user is not configured on the RADIUS server for Digest:
NNOS-E>radius test ”vsp\radius-group East\server 172.26.0.147" user1 password1
RADIUS test authentication:
User name: user1
Password: password1
Type: Digest
Realm: testrealm
Result: Reject
Authentication attempt failed
This action only applies to the NN 2620 with RAID controller. Starts or stops a consistency check on the specified RAID logical volume. The consistency check compares images on mirrored or mirrored/striped drives, and reports inconsistencies to the event log. (The RAID controller automatically manages resynchronization of inconsistent logical volumes.)
These actions only apply to the NN 2620 with RAID controller. Sets and manages thresholds, rebuild rates, and refresh intervals for the RAID controller. In addition, you can control (silence) the audible alarm.
Select one of the following operations:
alarm: Enables or disables the audible alarm that indicates that a logical volume is not optimal (e.g., physical drive dead, logical drive out of sync). Set to enabled to activate the alarm; disabled deactivates it. The silence option stops the sound of the current alarm, leaving the feature enabled.
cache-flush-interval: Sets the number of seconds between flushes of the RAID controllers battery cache. The option sends the contents of the battery cache memory to the logical drives. Enter a value between 0 and 255.
rebuild-rate: Sets the percentage of the compute cycles that are dedicated to rebuilding data onto a new physical disk after a drive has failed.
patrol-read-rate: Sets the percentage of the compute cycles that are dedicated to preventative scanning. A patrol read scans the system for possible physical disk drive errors that could lead to drive failure. It helps protect data integrity by taking corrective action on the error before failure occurs.
cc-rate: Sets the percentage of the compute cycles that are dedicated to a consistency check of data across logical volumes.
recon-rate: Sets the percentage of the compute cycles that are dedicated to reconstruction (resynchronization and copy) operations. This activity is undertaken automatically by the RAID controller if the logical volumes are not synchronized.
pred-fail-poll-interval: Sets the number of seconds between polls of the hard drives for reliability status. Enter a value between 0 and 65535.
battery-warn: Enables or disables the battery warning message displayed in BIOS. This is the battery backup capability for the RAID array. If enabled, when BIOS boots, if it detects low or no battery, it displays a message to the screen.
raid-set-adapter alarm {enabled | disabled | silence}
raid-set-adapter cache-flush-interval seconds
raid-set-adapter rebuild-rate percentage
raid-set-adapter patrol-read-rate percentage
raid-set-adapter cc-rate percentage
raid-set-adapter recon-rate percentage
raid-set-adapter pred-fail-poll-interval seconds
raid-set-adapter battery-warn {enabled | disabled}
Displays, for a specified URI, the registration-plan settings that the ME assigned, the routing arbitration process, and the selected server. This action simulates the registration routing path, but does not actually trigger an outbound call. It exercises both registration plan and location database lookups. Its output indicates which registration plan entry (or location cache entry) the registration would use and the next hop.
Enter a To URI. The action returns results for any AOR that matches a configured registration plan, or you can find the URI of interest in the AOR field displayed with the show location-cache command.
Displays, for a specified To URI, the content of the session configuration associated with the selected registration-plan. If the SIP URI matches a registration-plan (source-) route or arbiter, the action returns the session configuration for that entry (or the default session configuration if the entry does not have one assigned). If the registration-plan route has the peer set to server, and the server has a session configuration, this action displays the merged session configuration. (The server session configuration takes precedence over the route session configuration.)
NNOS-E>reg-lookup-detail sip:2078548355@elmaple.com
Resulting session config merged from server/group egress:
sip-settings
mode auto-determine
transport any
port auto-determine
route-hdr none
route-hdr-use-fqdn enabled
route-hdr-uri-host
route-hdr-add-register-msg disabled
route-hdr-preprocess-strip disabled
lcs-compatibility disabled
in-server unknown
out-server unknown
utilize-contact enabled
add-contact-nat disabled
compress-signaling disabled
preserve-call-id disabled
preserve-cseq disabled
proxy-generate-100-trying
handle-3xx-locally enabled
handle-3xx-locally-lookup-original-invite disabled
session-timeout 300 seconds
session-duration-max 0 seconds
--more--
Executes an ME call using the ME's. This action allows you to bind a web endpoint to a particular URI. It creates a location cache entry and a unique binding that ties the remote application to the specified URI, allowing remote applications to start receiving calls for the URI without the need to statically configure a dial-plan that routes the calls to a web endpoint.
The URI is a SIP URI in the following formats:
sip:user@domain:port
When the register action is executed, the ME first verifies that the user has permission to register that URI. If not, the ME returns an ”unauthorized” error message.
If the URI is valid, the ME performs a registration-plan lookup. If no matches are found, the ME returns a ”no routes” error message. If a match is found, the ME creates a binding that ties the specified URI with the server returned by the registration-plan lookup. Along with the binding, the ME also creates an identifier that uniquely identifies the binding. This identifier persists throughout the lifetime of the binding. At the completion of a successful binding, the ME returns this identifier along with a ”success” message.
When the URI sent in the register action is linked to an existing SIP server, the registration is executed asynchronously. The ME returns a ”pending” message indicating that the application must monitor for a register event containing the result of the asynchronous registration.
Enter the following arguments:
<URI>: The URI tied to this binding.
[expiration]: The expiration time of the binding in seconds.
Manages the registration information for the ME, specifically the registration routing and client tables. Use the show registration-clients and show registration-routing commands to view bindings and statistics for the tables.
Enter one of the following:
refresh: Resends a REGISTER for each entry to reset the client binding. The ME sends the register to a specific peer, if specified, or all peers if not. To send only to a specific peer, enter the SIP URI set in the server peer-identity property.
purge: Clears all entries from the registration client table.
query: Sends a REGISTER to the specified peer with a query regarding a specified peer. The peer returns its current binding. Enter the address of record you are interested in and the server to which the ME should send the request.
proxy: Simulates the registration proxy process. Instead of sending a registration on behalf of AORs in the location database, the registration proxy sends a registration manually for the specified AOR.
client-save: Restarts collection of client state information if collection was stopped using the client-clear option.
client-clear: Purges the state information from the client table and stops the future collection of client state data. Use client-save to restart client state collection.
status-clear: Clears all registration status counters. These are the entries that can be viewed with the show registration-status, show registration-delegate-status, and show registration-proxy-status commands.
provider-enabled: Enables the location information services provider.
provider-disabled: Disables the location information services provider.
registration refresh [peerURI] | registration purge [peerURI] registration query AORpeer peerURI registration proxy AORpeer peerURI fromURI contactHeader registration client-save registration client-clear registration status-clear registration provider-enabled registration provider-disabled
Removes the specified device from the list of devices that automatically mount at boot-up. Use this action before physically removing a drive from the system. Before executing this action, ensure that you do not have any configuration pointing to mounts that are on the removed device (e.g., recorded files, logs), as writes to that device will fail.
Causes an immediate restart of the type specified. To restart after gracefully terminating any existing connections, use the orderly-restart action. Select one of the following restart types:
warm: Exits and restarts the application.
cold: Exits the operating system and then restarts.
halt: Stops the ME and does not restart the system.
cnx0, cnx1: Stops and restarts the specified CNX card.
cluster: Performs a warm restart of all boxes within the cluster.
controlled: Restarts members in a cluster without interrupting call flow.
cancel: Cancels the operations initiated by the restart controlled action.
The default type is warm.
You can also schedule this action as part of routine maintenance using the task object.
NNOS-E>restart warm Are you sure (y or n)? y NNOS-E is restarting... Acme Packet Net-Net OS-E Copyright (c) 2004-2006 Acme Packet, Inc. NNOS-E> NNOS-E> restart controlled Are you sure (y or n)? y restarting 172.66.0.10... restarting 172.66.0.11... restarting 172.66.0.12... NNOS-E is restarting...
Resets the ME configuration settings to the factory defaults and executes a cold restart of the system. Use this with care, as your startup configuration is deleted.
Creates a bootable USB recovery stick by copying system images to a USB stick plugged into the USB port of the system. When you select the full-backup option, the default, the current image on the ME, including application and configuration files, and all associated software, is written to the stick. The recovery image does not include copies of the ME database, system tar files (.gz), or of media files on the system at the time of creation. When you select the config-backup option, just the current configuration file is written to the stick.
Determine how often to create/update the recovery stick based on the frequency of configuration changes to your system. capture the current software, certificates, and operating system image to the USB stick. Oracle recommends that you use restore-stick-create to preserve the image prior to performing a system software upgrade, or whenever you have made significant and reliable changes to the system configuration.
Refer to the Oracle Communications WSC Installation Guide for more information on use of the recovery stick.
Executes actions for the route server. The following are operations you can execute with this action.
replace-file: Replaces the route-server routing table with the specified file.
commit: Commits replaced route-server routing tables.
replace-url: Replaces the route-server routing table with the specified file URL.
flush: Flushes the route-server routing table.
revert: Revers a previous route-server routing table change.
lookup: Looks up least cost routes.
load: Loads a route.xml file into a temporary non-active routing-table that can be referenced with the table name.
drop: Removes a previously loaded routing table from memory.
route-server replace-file <file> route-server commit route-server replace-url <source> route-server flush route-server revert route-server lookup <to-url> [from-url] [table] [time] [display-mode] route-server load <file> <table> route-server drop <table>
NNOS-E>route-server replace-file 06222011.xml Route-Server action in progress, check route-server-action-status for result. NNOS-E>route-server commit Route-Server action in progress, check route-server-action-status for result. NNOS-E>route-server replace-url http://www.acme.com Route-Server action in progress, check route-server-action-status for result. NNOS-E>route-server flush Route-Server action in progress, check route-server-action-status for result. NNOS-E>route-server revert Route-Server action in progress, check route-server-action-status for result. NNOS-E>route-server lookup http://www.acme.com http://www.abc.com table1 Route-Server action in progress, check route-server-action-status for result. NNOS-E>route-server load 06222011.xml table1 Route-Server action in progress, check route-server-action-status for result. NNOS-E>route-server drop table1 Route-Server action in progress, check route-server-action-status for result.
Provides utilities for route-server. This action is only available from the CLI if the route-server master service is enabled. Select one of the following actions:
replace-file: Replaces the existing route server routing table with the contents of the specified file. Use this to update the routing definition database on the route server. Enter the name of a properly formatted XML file; the default file name is /cxc/carrier_routing.xml. You cannot specify either the current or the most recent backup routing file. (To replace the routing table with the most recent backup, use the revert option.)
commit: Writes appended route server routing table entries from memory to the routing table, clearing the memory. (The memory provides a temporary backup holding area.)
replace-url: Replaces the existing route server routing table with the contents of the file found at the specified URL. Use this to update the routing definition database on the route server. Enter the name of a properly formatted XML file; the default file name is /cxc/carrier_routing.xml.
flush: Removes all entries from the route server routing table on the master.
revert: Reverts the existing route server routing table to the table in use prior to the last update.
lookup: Tests retrieval from the route server routing table. Results display all routes that match the specified To, and optionally the From, URI(s).
route-server replace-file fileName lroute-servercr commit route-server replace-url urlSource route-server flush route-server revert route-server lookup toURL [fromURL]
NNOS-E>route-server lookup 9788972990@acmepacket.com 7818972990@company.com
-----------------------------------------------------------------
Carrier Endpoint Mapping
-----------------------------------------------------------------
S - 10pct Mup Customer, gateway1 ANI:7819376550
S - 10pct Mup Customer, gateway10 ANI:7819376550
N - 10pct Mup Customer, gateway4
-----------------------------------------------------------------
Total routes: 3
This action allows you to manually verify that route servers on each ME in a cluster are synced up properly during a route-set update, activating a new route-set, deleting a backup, or cancelling a controlled update or activation. When executed, the master ME controls and checks the success of each operation on each of the ME slaves.
Any error that occurs during the upgrade and activation processes, either on the master or any slave, results in the master initiating a rollback. The entire operation is retried and all failures that occur are logged and traced.
Before executing the route-server-controlled action, both NTP and logging must be configured on all MEs. This action must always be executed by the master. Any attempt to execute this action on a slave results in the error, ”Execute action on master.”
The following are operations you can execute with this action:
route-server-controlled update <file> [activate-time] [peer-wait-seconds]: Allows you to replace the route-set used by the cluster while ensuring the route server databases on each ME are properly synced. You can optionally configure the specific time for this action to be executed, as well as how many seconds the master will wait for a peer to finish each step in the action. The master allows each peer three attempts at a step. The first attempt, the master waits the configured number of seconds. The second try, the master waits twice the configured number of seconds, and the third time three times the number of seconds before the master will halt the entire action.
route-server-controlled activation [activate-time] [peer-wait-seconds]: Activate a new route-set used by the cluster while ensuring the route server databases on each ME are properly synced. You can optionally configure the specific time for this action to be executed, as well as how many seconds the master will wait for a peer to finish each step in the action. The master allows each peer three attempts at a step. The first attempt, the master waits the configured number of seconds. The second try, the master waits twice the configured number of seconds, and the third time three times the number of seconds before the master will halt the entire action.
route-server-controlled delete-backup <backup-name>: Delete a backup route-set that the cluster does not use anymore while ensuring the route server databases on each ME are properly synced.
route-server-controlled cancel [peer-wait-seconds]: Cancel a controlled update or activation that is currently in progress. You can optionally configure the number of seconds the master will wait for a peer to finish each step in the action. The master allows each peer three attempts at a step. The first attempt, the master waits the configured number of seconds. The second try, the master waits twice the configured number of seconds, and the third time three times the number of seconds before the master will halt the entire action.
Both the master and slave ME cycle through a set of states during a controlled update. The following table shows the states a master ME goes through.
| State | Description |
|---|---|
|
Ready |
The master is ready to receive a new action request. |
|
Loading |
The master is loading. |
|
Peers_Fetching |
Waiting for all slaves to get the file from the master. |
|
Peers_Loading |
Waiting for all slaves to load. |
|
Peers_Activating |
Waiting for all slaves to activate before the master activates itself. |
|
Peers_Cancelling |
Cancel the current operation. |
|
Initializing |
The master ME is initializing its state. |
|
Activate_Scheduled |
A controlled activation is scheduled. |
The following table shows the states a slave ME goes through.
| State | Description |
|---|---|
|
Ready |
The slave is ready to receive a new action request. |
|
Fetching file |
Received route-set .xml file from master. |
|
Loading |
Slave is loading. |
|
Activating |
Slave is activating. |
|
Cancelling |
Master requested a cancel. |
You can test imported DID ranges and prefix changes you have made in the route-server import tool before activating them in a live environment. Via the route-server-test action you can test routes, CDRs, and queries, and analyze, compare, and validate results of the routes.
Enter one of the following:
config: Generates a series of test vectores derived from the routes.xml file and outputs them to a specified test.xml file. If you do not specify a text.xml file, the ME writes the resulting output to the screen. The test.sml file has the following format.
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="mgmt_data.xsd"> <RouteServerTestSuite suite="1"> <description>DID 1000-1002</description> <tests> <RouteServerTestCase> <query>1000-1002</query> <from/> <time></time> </RouteServerTestCase> </tests> </RouteServerTestSuite> </config>
cdr: Generates a series of test vectors derived from accounting records in the CSV format and outputs them to a specified test.xml file. If you do not specify a test.xml file, the ME writes the resulting output to the screen. The test.xml file has the following format.
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="mgmt_data.xsd"> <RouteServerTestSuite suite="1"> <description>DID 1000-1002</description> <tests> <RouteServerTestCase> <query>1000-1002</query> <from/> <time></time> </RouteServerTestCase> </tests> </RouteServerTestSuite> </config>
The CSV file has the following format.
"SessionID","Recorded","CallID","To","From","Method","IncomingRequestURI","Previou sHopIp","PreviousHopVia","OutgoingRequestURI","NextHopIp","NextHopDn","Header","Or igin","SetupTime","ConnectTime","DisconnectTime","DisconnectCause","Duration","scp Name","CallID2","OrigGW","TermGW","PacketsReceivedOnSrcLeg","PacketsLostOnSrcLeg", "PacketsDiscardedOnSrcLeg","PdvOnSrcLeg","MaxJitterOnSrcLeg","CodecOnSrc Leg","MimeTypeOnSrcLeg","LatencyOnSrcLeg","MaxLatencyOnSrcLeg","RFactorOnSrcLeg"," PacketsReceivedOnDestLeg","PacketsLostOnDestLeg","PacketsDiscardedOnDestLeg","PdvO nDestLeg","MaxJitterOnDestLeg","CodecOnDestLeg","MimeTypeOnDestLeg","LatencyOnDest Leg","MaxLatencyOnDestLeg","RFactorOnDestLeg","Rx1000FactorOnDestLeg","Rx1000Facto rOnSrcLeg","MOSFmtOnDestLeg","MOSFmtOnSrcLeg","callType","disconnectErrorType","an i","callSourceRegid","callDestRegid","newAni","cdrType","huntingAttempts","callPDD ","callSourceRealmName","callDestRealmName","callDestCRName","in_peer_dst","in_ anchor_src","in_anchor_dst","in_peer_src","out_peer_dst","out_anchor_src","out_ anchor_dst","out_peer_src","calledPartyAfterSrcCallingPlan","lastStatusMessage","LastMediaPktTimestampOn DestLeg","LastMediaPktTimestampOnSrcLeg","SetupTimeInt","IncomingURIStripped","dni s","newDnis","customData","CreationTimestamp"
lookup: Uses the test vectors generated from the route-server-test config and route-server-test cdr actions and queries the route-server. The results of the queries are outputted to a specified results.xml file. If you do not specify a result.xml file, the ME writes the resulting output to the screen. The result.xml file has the following format.
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="mgmt_data.xsd">
<RouteServerTestSuiteResults suite="1">
<description>DID 1000-1002</description>
<results>
<RouteServerTestResult>
<query>1000</query>
<from/>
<time></time>
<routes>
<RouteServerTestRouteResult>
<match>route-plan:2</match>
<carrier>default</carrier>
<endpoint>a.example.net</endpoint>
</RouteServerTestRouteResult>
</routes>
</RouteServerTestResult>
</results>
<results>
<RouteServerTestResult>
<query>1001</query>
<from/>
<time></time>
<routes>
<RouteServerTestRouteResult>
<match>route-plan:2</match>
<carrier>default</carrier>
<endpoint>a.example.net</endpoint>
</RouteServerTestRouteResult>
</routes>
</RouteServerTestResult>
</results>
<results>
<RouteServerTestResult>
<query>1002</query>
<from/>
<time></time>
<routes>
<RouteServerTestRouteResult>
<match>route-plan:2</match>
<carrier>default</carrier>
<endpoint>a.example.net</endpoint>
</RouteServerTestRouteResult>
</routes>
</RouteServerTestResult>
</results>
</RouteServerTestSuiteResults>
</config>
You can also execute this action with the optional table parameter. This allows you to execute the lookup in a different routing table other than the currently active one.
analyze: Analyzes the results file generated by the route-server-test lookup action and summarizes the results. The results of the analysis are outputted to a specified analysis.xml file. If you do not specify an analysis.xml file, the ME writes the resulting output to the screen. This action allows you to view how various resources are utilized with the current routing configuration being tested. The output of the analysis has the following format.
Analysis of results file : /tmp/results.xml
Analysis created on : 13:09:56.729762 Mon 2010-11-01
Total test suites : 1
Total test cases : 3
Total results with routes : 3
Total results without routes : 0
Smallest hunt result : 1
Largest hunt result : 1
Route position : 1
Total : 3
-------------------------------------------------------
Carrier "default" referenced 3 times
|--- Endpoint "a.example.net" referenced 3 times
Route "route-plan:2" referenced 3 times
Queries with no route results:
-------------------------------------------------------
None
compare: Compares two results files and outputs the differences to a specified diff-results.xml file. If you do not specify a diff-results.xml file, the ME writes the output to the screen. The output of the comparison has the following format.
Comparing results from file /tmp/results.xml with /tmp/results2.xml
----------------------------------------------------------------------
Test suite 1 "DID 1000-1002"
|--- Query "1001"
|--- Route 0
|--- name "route-plan:2" not equal "route-plan:3"
validate: Compares the results file with the active routes and outputs the differences to a specified validation-results.xml file. If you do not specify a validation-results.xml file, the ME writes the output to the screen. Any differences between the results.xml file and the active routing tables has the following format.
Comparing results from file /tmp/results.xml with /tmp/results2.xml
----------------------------------------------------------------------
Test suite 1 "DID 1000-1002"
|--- Query "1001"
|--- Route 0
|--- name "route-plan:2" not equal "route-plan:3"
You can also execute this action with the optional table parameter. This allows you to execute the validation in a different routing table other than the currently active one.
route-server-test config [file] [test-vector-file] route-server-test cdr filename [test-vector-file] route-server-test lookup test-vector-file [test-results-file] [table] route-server-test analyze test-results-file [analysis-results-file] route-server-test compare test-results-file1 test-results-file2 [diff-results-file] route-server-test validate test-results-file [validation-results-file] [table]
NNOS-E>route-server-test config /cxc_common/rs/files/routes.xml
<RouteServerTestSuite suite="293">
<description>DID 3612888825-3612888828</description>
<tests>
<RouteServerTestCase>
<query>3612888825-3612888828</query>
<from/>
<time></time>
</RouteServerTestCase>
</tests>
</RouteServerTestSuite>
<RouteServerTestSuite suite="294">
<description>DID 3612888800-3612888899</description>
<tests>
<RouteServerTestCase>
<query>3612888800-3612888899</query>
<from/>
<time></time>
</RouteServerTestCase>
</tests>
</RouteServerTestSuite>
NNOS-E>route-server-test lookup /tmp/testcases.xml /tmp/results.xml <RouteServerTestSuiteResults suite="293"> <description>DID 3612888825-3612888828</description> <results> <RouteServerTestResult> <query>3612888825</query> <from/> <time></time> </RouteServerTestResult> </results> .... </RouteServerTestSuiteResults> NNOS-E>route-server-test analyze /tmp/results.xml Analysis of results file : /tmp/results.xml Analysis created on : 10:03:10.492217 Thu 2011-06-23 Total test suites : 2 Total test cases : 104 Total results with routes : 103 Total results without routes : 1 Smallest route result : 1 Largest route result : 0 Queries with no route results: -------------------------------------------------------------------------------- Suite 0 test 1 query "3612888825" from (null) time "" NNOS-E>route-server-test compare /tmp/results.xml /tmp/results2.xml Comparing results from file /tmp/results.xml with /tmp/results.xml -------------------------------------------------------------------------------- Results are identical. NNOS-E>route-server-test validate /tmp/results.xml Comparing results from file /tmp/results.xml with active routes -------------------------------------------------------------------------------- Results are identical.
Deletes the specified WAV file or DTMF event from the RTP cache, if the entry is inactive. The ME caches copies of encoded media stream data for music-on-hold and periodic/introduction announcements, instead of re-encoding them for each call. However, if the configuration no longer uses an announcement or if use of a particular CODEC is discontinued, you can free up memory resources occupied by unused announcements by cleaning the cache of these unused entries. The ME checks to make sure the entry is not currently streaming to an on-hold call.
Use the show rtp-cache command output to find the required file name or event ID. Delete based on either:
file: Enter the file name of the WAV file to delete.
event: Enter the event ID for the entry, and optionally, the volume. DTMF events display as ”Event=event_id/volume” in the show rtp-cache output.
rtp-cache-delete file filename [codec] [packetTime] rtp-cache-delete event eventID [volume] [codec] [packetTime]
NNOS-E>rtp-cache-delete file announce1.wav Success! NNOS-E>show rtp-cache Type Cache Codec PacketTime Current-Streams Pkts-Cached Pkts-Sent ---- ----- ----- --------- --------------- ----------- --------- event 0/10 g723 30 0 33 0 g728 20 0 50 0 g729 20 0 50 0 iLBC 30 0 33 0 pcma 20 0 50 0 NNOS-E>rtp-cache-delete event 0 10 Success! NNOS-E> show rtp-cache Type Cache Codec PacketTime Current-Streams Pkts-Cached Pkts-Sent ---- ----- ----- ---------- --------------- ----------- --------- event 1/10 gsm 20 0 50 0 g723 30 0 33 0 g728 20 0 50 0
Decodes binary RTP packets (the output of the srtp action). The action results in output that prints out the fields of the header, as defined in RFC 1889, RTP: A Transport Protocol for Real-Time Applications. To execute, enter the hexadecimal value of the binary RTP header. The action returns
the version and any additional flags
RFC-defined payload type
The sequence number, used to detect missing or out-of-order packets
The timestamp, a sample count used to synchronize RTP sequences
The source synchronization ID.
Displays the packets that make up a recording. The options allow you to control the detail level of the display and also to create an XML file from a WAV file.
Select either:
details: Displays a full or compressed list of all packets in the RTP stream that made up the recording. Enter a file name that contains the recording. You can also select to display timestamps. Select delta to display the time passed since the last packet. Select relative to display timestamps relative to the beginning of the call. Select absolute to display the complete date/time string. By default (none) the output displays no time stamps.
The first true/false boolean controls display of an interpretive line highlighting potential changes. If true, the default, the output includes the line. The second true/false boolean controls compression. If true (the default), the output only displays a summary of packets as long as the sequence is as expected (no change to SSRC). Each unexpected line is displayed. If set to false, the output lists all packets.
summary: Displays high-level (header) information that summarizes the packets in the RTP stream.
stats: Displays MOS and other information for recorded files, including the CODEC in use, packet counts, jitter and others.
create: Creates and encodes an XML file from a WAV file. Optionally you can set the packetization rate.
rtp-stream details xmlSource {none | delta | relative | absolute} [true | false] [true | false] rtp-stream summary xmlSource rtp-stream stats xmlSource rtp-stream create wavSource xmlDest codec [packetTime]
NNOS-E> rtp-stream summary /cxc_common/recorded/sess-04c2a2312f70ca7a-0-1.xml Filename: /cxc_common/recorded/sess-04c2a2312f70ca7a-0-1.xml Start Time: 15:01:56.458930 Fri 2007-07-13 Packet-time: 20 2 rtpmaps: PCMU payload-type=0, sample-rate=8000, channels=1 telephone-event payload-type=101, sample-rate=8000, channels=1 Success! NNOS-E> rtp-stream details /cxc_common/recorded/sess-04c2a2312f70ca7a-0-1.xml relative 1 34 RTP Invalid: RTP version is invalid ***** SSRC changed from 0 to 1067843479 ****** 2 134 Payload type=PCMU, SSRC=1067843479, Seq=43432, Time=1373220824, Mark, payload bytes=160 3-162 Payload type=PCMU, SSRC=1067843479 163 3352 Payload type=PCMU, SSRC=1067843479, Seq=43593, Time=1373246584, payload bytes=160 ***** Missed 1 sequence numbers ****** 164 6679 Payload type=PCMU, SSRC=1067843479, Seq=43595, Time=1373273064, payload bytes=160 165 6700 Payload type=PCMU, SSRC=1067843479, Seq=43596, Time=1373273380, payload bytes=160 ***** Timestamp discontinuity (possible silence): old(1373273380) + expected(316) != new(1373273540) ****** 166 6721 Payload type=PCMU, SSRC=1067843479, Seq=43597, Time=1373273540, payload bytes=160 167-389 Payload type=PCMU, SSRC=1067843479 390 11197 Payload type=PCMU, SSRC=1067843479, Seq=43821, Time=1373309380, payload bytes=160 NNOS-E>rtp-stream stats /cxc_common/rtp_recorded/04c30cd29/sess-04c30cd2909dcc70-0-1.xml Codec : PCMU (pt=0) SSRC : 2691206733 (0x4d8e68a0) Duration : 8.74 seconds Packet interval : 20 msecs Jitter (sum) : 116.0 msecs Received : 437 Lost : 0 MOS : 4.39
Deletes an individual entry from or flushes the rule failover database. This database contains rules that are internally created by the third-party call control process to do advanced call control operations. You can list current rules with the show automatic-rules command. This action is for Technical Support use only.
Manages the ME passwords and tags. The ME uses this two-part password mechanism for passwords shared with other devices (also known as shared secrets). See Understanding Passwords and Tags for a complete explanation of this mechanism.
You can also set password/tag associations from various points within the configuration. This password mechanism applies does not apply to passwords created for users under the access object. Use the show secrets command to view configured password tags.
Enter one of the following:
set: Creates a password/tag association. If you re-execute this action, and supply a different password, the ME overwrites the password that was associated with the tag with the new password. When you set an association, you supply a tag. The system then prompts you for the secret (password). The tag is what users enter, the secret is the password known to the other device. Tags cannot contain the pound symbol (#). If you do not specify a tag, the system saves the password without an associated tag.
Note:
You must manually enter passwords on each ME device. Because passwords are maintained in a separate store, simply copying the configuration file between devices does not copy the password store.delete: Removes a secret so that the association between tag and secret no longer exists.
root: Resets the Linux root password. When prompted, specify and confirm the new root password. The root secret must be at least four characters long.
ssh: Sets the SSH account password. When prompted, specify and confirm the new password.
synchronize: Copies passwords to other devices in the cluster. Passwords are maintained in a separate store; simply copying the configuration file between devices does not copy the password store. Use this action on the master device to copy your passwords the other devices in the cluster.
verify: Confirms a secret that is associated with the specified tag. Enter the tag, and the system prompts you for the secret. If you did not associate a secret with a tag, you get a secret mismatch message.
Sends an event within the body of a NOTIFY message to the phone at the specified URL. If you select one of the preconfigured events (reboot, resync, restart, or report), the ME sends the event expected by a Sipura phone. To send an event to any other type of phone, enter the appropriate string. Note that some phones and event types require credentials, so username and password may be required. Also, optionally you can specify which interface the NOTIFY message goes out. In the tag field, enter a configured classification-tag from the ip object.
Use this action, for example, to send an event that will reboot the phone, check for configuration changes, and/or download a configuration.
send-notify-event {string | reboot | resync | restart | report} URL [from] [tag] [any | UDP | TCP | TLS] [username] [password]
NNOS-E>send-notify-event check-sync sip:2125551212@voip.acmepacket.com
--- End of Data ---
SIP Tx: [09:58:23.193602] 457 bytes to 66.10.143.110:22324 on vx1 (UDP socket 69 - 82.134.77.12:5060):
--- Start of Data ---
NOTIFY sip:2125551212@66.10.143.110;transport=UDP SIP/2.0
From: <sip:2125551212@66.10.143.110:22324>;tag=af4da8c0-13c4-469f6dfd-3f1eefb-2ac0a04f;rinstance=b6620d67f3884ca8
To: <sip:2125551212@66.10.143.110:22324>;rinstance=b6620d67f3884c
Call-ID: NNOS-E-1-af4da8c0-13c4-469f6dfd-3f1eefb-5f0726f5
CSeq: 1 NOTIFY
Via: SIP/2.0/UDP 82.134.77.12:5060;branch=z9hG4bK-678d-469f6dfd-3f1eefb-d68961
Event: check-sync
Subscription State: Active
Content-Length: 0
Manipulates elements of the sensor management system. Enter one of the following:
delete-events: Clears the sensor event log. Use the show sensor-events command to view the contents of the log prior to deleting. The sensor event log maintains information pertaining to such events as temperature, voltage, and others.
identify: Activates a blue light on the front of the system that can be used to identify the system you are working with. By executing the sensor identify action, the light will begin to blink and will continue for the number of seconds specified. Enter a value from 1 to 127. The default is 60 seconds.
reset-processors: Clears any error or disabled sensor states from all processors in the system. At boot time, the system performs a diagnostic test of its processors. If a processor fails, it is automatically disabled. (The system generates a log event if this happens; also show sensors and show sensor-events indicates the problem. use this action to begin recovery, followed by the restart cold action, causing the processor to be retested during the cold start.
Clears counters and configurations related to the configured servers. Enter one of the following:
routing-clear: Clears dial plan and registration plan statistics counters. These are the counters that are visible using the show dial-plan and show dial-plan commands.
purge-dynamic: For use with configured dns-group servers, purges the server-pool configuration. A dns-group server learns its server-pool configuration dynamically through DNS. If the data is not synchronized, for example the DNS server may have gone down and then come back up, you can execute this action to delete the server-pool configuration and rebuild it through incoming SIP traffic.
age-dynamic: For use with configured dns-group servers. When initiated, the ME purges the server IP address, port, and transport protocol information (but maintains the rest of the server configuration). This forces a DNS query the next time the server is used.
Performs a lookup in the specified service route table. The output of the action returns the best route to the destination, given the filtering parameters applied. It also displays other aspects of the route such as the gateway, physical interface, geolocation, and metrics. The metrics are the resulting values of the services-routing metric assignments. For example, if you had assigned user-metric, the ME displays the cost of the route (configured with the ip metric property). If you had assigned intf-throughput, the ME displays the most recent calculation of interface throughput for the route.
You must enter the following arguments:
service table name: Selects the specific routing table to search for the best route to the destination. Enter either sip, media, or stun.
destination: Specifies the host address of the destination. Enter in IP address format.
transport protocol: For a STUN service routing table lookup, specifies the transport protocol that the route must use to reach the specified destination. Each stun-server in the cluster is configured to support a particular protocol (UDP, TCP, or TLS) with the port property. The ME then returns the best route using that protocol.
Optionally you can enter:
partner IP address: Specifies the address of a peer in a cluster network. If you use this argument, the output will return the best route from the specified peer. By default, the ME finds the best route from any box (255.255.255.255). Use 0.0.0.0 as the partnerIP address to return results from the local box.
load-balance: Selects whether to load balance the results (choose true or false). If set to true, the ME uses a round robin algorithm to return results. Each time you execute the command, the next entry is returned. If set to false, the ME returns the first entry in the table (the default behavior).
geolocation: Filters results based on the geolocation. This value is assigned to an interface with the ip object, and is stored with the route. When you specify a geolocation, the ME returns the best route to the destination that has the specified geolocation.
Sets the ME to forward any calls intended for the specified address-of-record to a specified URI. Once configured, you can then use the enable and disable arguments to activate the forwarding.
Sets the system partition from which the ME boots. Use this, for example, to revert to an old system image after having installed and run off of a new one. In that case, set this to the alternate partition and reboot the system. You can use the on-board-rescue option to reboot using a limited functionality that provides access to USB stick rescue utilities without using the stick itself. Use the show chassis-config command to display the current partition assignment.
Configures the endpoint to which the ME directs console output the next time that it boots. To display output to the screen, set this to the port used for your management console. Use the show chassis-config command to display the current management console assignment.
Enables and disables IPMI functionality. By default, IPMI functionality is enabled, and allows system reports such as those returned by the show sensors command. Disable this only in cases where the IPMI functionality causes a problem with your specific platform. Use the show chassis-config command to view the current IPMI setting.
Sets the ME to return a busy response to any call directed to the specified address of record. The phone registered to that AOR will respond according to its configuration (busy, voice mail, etc.). Once configured, you can then use the enable and disable arguments to activate and deactivate the setting.
Performs actions on SIP transport connections. Each action, and its specific syntax, is described below.
ping: Pings the specified server, using the SIP OPTION message (instead of ICMP), to validate a SIP node. Enter a transport protocol and a port, if desired. The default protocol is UDP; the default port is 5060.
ping-aor: Pings the specified address of record, using the SIP OPTION message (instead of ICMP), to validate a SIP node.
traceroute: Sends SIP OPTION message trace packets to determine a routing path. The default protocol is UDP; the default port is 5060.
server-monitor: Adds the specified server to the monitor pool. The ME periodically pings the servers in this pool to check availability. Use the show sip-server-availability command to view the results for all monitor pool entries. Enter a server hostname or IP address, and optionally, a transport protocol and port. The default protocol is UDP; the default port is 5060.
server-unload: Removes the specified server from the monitor pool (see server-monitor, above). Enter a server hostname or IP address, and optionally, a transport protocol and port. The default protocol is UDP; the default port is 5060.
lookup-connection: Does a lookup in the SIP connection table. Specify the endpoint IP address. The ME returns an entry if there is a connection between that endpoint and the ME. Optionally, you can set the transport protocol and/or a local IP address to perform the lookup from, rather than from the ME.
delete-connection: Deletes the connection between the ME and the specified endpoint. Optionally, you can set the transport protocol and/or a local IP address to perform the lookup from, rather than from the ME.
purge-connection: Disconnects and deletes all entries in the connection table. (This is all active calls on the ME.)
reset-connection: Tears down and then resets all entries in the connection table.
clear-statistics: Clears all counters associated with the connection table.
ping-resume: Resumes sending SIP OPTION message ping packets to entries in the monitor pool. These packets would have been stopped with the ping-suspend option, below.
ping-suspend: Temporarily halts sending SIP OPTION message ping packets to entries in the monitor pool. The ME uses the last known state for each server as its current state data. Use the ping-resume option, above, to restart sending packets.
udp-log-on: Starts logging a partial header from each SIP UDP message to the UDP buffer. The UDP buffer is a FIFO buffer, the size of which is set with the vsp object max-udp-outbound-log property.
udp-log-off: Turns off logging of SIP UDP messages to the UDP buffer. See the udp-log-on option, above.
sip ping server [any | udp | tcp | tls] [port] sip ping-aor aor sip traceroute server [any | udp | tcp | tls] [port] sip server-monitor server [any | udp | tcp | tls] [port] sip server-unload server [any | udp | tcp | tls] [port] sip lookup-connection remoteIP [any | udp | tcp | tls] [localIP] sip delete-connection remoteIP [any | udp | tcp | tls] [localIP] sip purge-connection sip reset-connection sip clear-statistics sip ping-resume sip ping-suspend sip udp-log-on sip udp-log-off
The sip-send-info action sends out-of-dialog SIP INFO requests.
Valid arguments for this action are:
<AOR>: The Address of Record in the form of a URI.
[id]: The Unique ID that identifies the registration binding (returned in RegisterEvent).
[session-config]: The session-config used for formatting INFO headers and bodies.
The sip-send-message action sends out-of-dialog SIP MESSAGE requests.
Valid arguments for this action are:
<AOR>: The Address of Record in the form of a URI.
[id]: The Unique ID that identifies the registration binding (returned in RegisterEvent).
[session-config]: The session-config used for formatting MESSAGE headers and bodies.
The sip-send-notify command sends out-of-dialog SIP NOTIFY requests.
Valid arguments for this action are:
<AOR>: The Address of Record in the form of a URI.
[id]: The Unique ID that identifies the subscription binding (returned in SubscribeEvent).
[session-config]: The session-config used for formatting NOTIFY headers and bodies.
The sip-send-options action sends an out-of-dialog SIP OPTIONS request.
Valid arguments for this action are:
<AOR>: The Address of Record in the form of a URI.
[id]: The Unique ID that identifies the registration binding (returned in RegisterEvent).
[session-config]: The session-config used for formatting OPTIONS headers and bodies.
The sip-send-other action sends out-of-dialog requests for all other SIP methods which do not have a specific action.
Valid arguments for this action are:
<method>: The SIP method to use in the request.
<AOR>: The Address of Record in the form of a URI.
[id]: The Unique ID that identifies the registration binding (returned in RegisterEvent).
[session-config]: The session-config used for formatting the request headers and bodies.
The sip-send-subscribe action sends an out-of-dialog SIP SUBSCRIBE request.
When an application either sends a SUBSCRIBE request and receives a 200 OK or accepts a SUBSCRIBE request by responding with a 200 OK, the ME creates a subscription binding. This binding contains the supported events and a unique ID. The application can use this ID to distinguish between subscriptions that it created and other subscriptions created for the same AOR but a different application.
Subscription bindings are arranged in a vector under the AOR and have an expiration time that can be specified in the sip-send-subscribe and call-control-send-subscribe actions. If you do not specify an expiration time, the default is 3600 seconds.
Valid arguments for this action are:
<AOR>: The Address of Record in the form of a URI.
[event]: The name of the event type to subscribe to.
[accept]: The acceptable event data to include.
[id]: The unique ID that identifies the subscription binding (returned in SubscribeEvent).
[session-config]: The session-config used for formatting SUBSCRIBE headers and bodies.
[expiration]: The expiration time of the binding, in seconds. If this value is not specified, the registration-plan expiration is used.
The snmp-trap-test command allows you to generate any trap on the ME manually in order to test it without having to set up conditions to actually trigger the trap. After configuring your traps, filters, and logs, use this command to ensure they show up when triggered.
Provides a diagnostic tool for testing SRTP encryption/decryption of packets. When you select to decrypt a packet, use the same key and encryption suite that was used to originally encrypt the packet. When viewing the decrypt action output, if input and output are the same, the encryption is likely broken.
Select an action. The following fields are available for the start action.
action: Specify whether to start, send, or stop the testing.
start: Sets up the context for the testing session.
send: Begins sending packets for testing.
stop: Tears down the testing session.
operation: Specify whether to encrypt or decrypt the specified packet.
packetType: Select whether to send RTP or RTCP packets, as defined in RFC 3550, ”RTP: A Transport Protocol for Real-Time Applications.”
suite: Enter the SRTP protection suite consisting of encryption and authentication algorithms. Enter either:
None (no encryption or authentication)
AES-128 Countermode encryption, SHA-1 authentication (80 bit)
AES-128 Countermode encryption, SHA-1 authentication (32 bit)
F8-128 encryption, SHA-1 authentication
AES-128 Countermode encryption, MD5 authentication (Sipura)
DES Cipher Block Chaining per RFC-1889
key: Enter the hexadecimal value of the master key/salt (it must include the ”0x”) that is derived from the client or through the ME tracing. This is the value typically passed in the SDP message, or the decrypted value of the key passed in Linksys INFO messages.
mkiLen: Enter a value, in bytes, that sets the number of bytes in the master key identifier (MKI). Enter a value between 0 and 4. A value of 0 disables the MKI.
mkiID: Enter the MKI identifier that should be included in each packet.
roc: Enter value for the rollover counter. If it is a non-zero value, set the ssrc and sequence fields. This is state information used for testing.
ssrc: Enter a value for the synchronization source. This is state information used for testing.
sequence: Enter a sequence number. This is state information used for testing.
flags: enter a number, which will be used by the ME, to complete the encryption/decryption testing.
The send action requires the packet field:
packet: Enter the hexadecimal representation of the UDP payload of the packets (it must include the ”0x”). You would typically obtain this with an Ethereal capture.
The stop action takes no parameters.
srtp start {encrypt | decrypt} {rtp | rtcp} suite key [mki-len] [mki-id] [roc] [ssrc] [sequence] [flags]
srtp send packet
srtp stop
The following example shows a successful SRTP decrypt:
NNOS-E>srtp start encrypt rtp AES_CM_128_HMAC_SHA1_80 0x4b8730843d222bdc3ab023fb49b43b987e5611ccf4f4320db6bfa16eafc Success! NNOS-E>srtp send 0x8008000000123bad0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 SRTP encrypted packet (182 bytes): 0x8008a60c00123bad000000000e183fbfb896e28b1848302c265db177a376deaacade96d56dab52bc370f0ddff7bf9ec23d61d5bc9ecda0d781bafd62bcc61bab070bf954829b8d02bddad2d75970d906b69cf764a98275fcd12968af8a4c43a1db3d985c3c5ba4b772079922315eac75efbf586a75e4f0e7eed615d549a034c6890dae3b5dbdf1fd3cef518891a9c7cdb5f0ed8cf0f119e137406e337838dfe17ce3c2cdeb340b4fb4a9764493b75e3056754e706d97 NNOS-E>srtp stop AES_CM_128_HMAC_SHA1_80 Stats: Pass : 1 Encrypt : 1 Decrypt : 0 Drop: Crypto : 0 Drop: Auth : 0 Drop: Replay : 0 Drop: Force : 0 Drop: Internal : 0
Provides tools to manage SSH public keys. When installing a public key on to the system, make sure to select the OpenSSH format. You can make sure
regenerate-host-key: Regenerates the host keys used by SSH. Use this if you feel your SSH authentication system has been compromised. Note that the ME shuts down and restarts when you execute this action.
import-public-key: Imports a public key into the ME key store. Use this option if the key already resides on the system as file.
add-public-key: Adds a public key to the key store. Use this option when you can paste or enter the key content in to the command line.
remove-public-key: Removes a public key from the key store. Use the show ssh-public-keys command to determine the number that corresponds with the key.
password: Assigns the SSH account password. use this option if you have set the account property of the ssh object to ssh.
ssh regenerate-host-keys ssh import-public-key fileName ssh add-public-key key ssh remove-public-key integer ssh password password
NNOS-E>ssh regenerate-host-keys Are you sure (y or n)?y Acme Packet Net-Net OS-E is restarting... NNOS-E>ssh add-public-key "1023 37 89289440280818173424027287852513686914751511296457651625136488201298953681515786011904008499350263062785798665633269023599158353107785665907700933443924410358027349765766969317515908220381678683658869849422920314420373480212058574602902298344355656272707294228412581920740438101310247843081310190326690376069 rsa-1" Are you sure (y or n)?y Success!
This action tests the connectifity of a newly configured multimedia-streaming-server object. You can test either:
stream publish: Tests audio or video stream published to a specified server.
stream subscribe: Tests a subscription to an audio or video stream on a specified server.
The subscribe-delete action removes either a single subscription binding or all of the bindings for a single AOR.
Valid arguments for this action are:
<AOR>: The Address of Record in the form of a URI.
[id]: The Unique ID that identifies the subscription binding (if not specified, all bindings are removed).
The subscribe-flush action removes all subscription bindings from the entire cluster.
Manages the database containing the active terminals known to the ME. The database contains phone numbers and their associated devices, and is persistent across reboots. Select either:
merge: Merges the specified file into the active terminal list. Specify a file path; by default the system merges the file /cxc/terminal.xml.
replace: Replaces the active terminal list with the specified file. By default, the system replaces the list with the file /cxc/terminal.xml.
save: Saves the active terminal list cache to the database. By default, the system saves the cache to the file /cxc/terminal.xml. Optionally, you can specify a different file name.
delete: Deletes a specific entry from the from the active terminal list. Use the show active-terminals command to list entries.
flush: Removes all entries from the active terminal cache.
Immediately disconnects the call associated with the specified session ID. This action is intended to be used only as a last resort when the endpoints are no longer reachable. It does not make any attempt to cancel the call at the endpoints (the UAs still believe that the call is in progress). Instead, it does an internal cleanup to remove the session from the ME and free up any used resources. Use the show active-call command to view a list of currently active calls and their associated session IDs. Use the disconnect-call action to immediately terminate a call that has not been answered or that has been cancelled.
Manages the database containing the active terminals known to the ME. The database contains phone numbers and their associated devices, and is persistent across reboots. Select one of the following:
call: Places a call
hold: Places an existing call on hold
retrieve: Retrieve an existing call from hold
transfer: Transfer an existing call to another endpoint
disconnect: Disconnect an existing call
join: Given two calls, remove the originator from both calls and join the two terminators into a new call
loop: Place a loopback call
annotate: Attach an annotation on an existing call
get-annotation: Display any annotation on an existing call
park: Place a call to an endpoint, immediately placing it on hold
connect: Place a call to an endpoint, and connect it to a parked call
terminate: Disconnect one end of a call, leaving the other end on hold
memo-begin: Start recording voice memo to a .wav file
memo-end: Stop recording voice memo to a .wav file
play: Play a .wav file on an existing call
drop-file: Play a .wav file on an existing call, parking the originator
notify: Send a NOTIFY event
message: Connect to an endpoint, play a file, and terminate the call
third-party-call-control call to from [requestId] [enabled | disabled] [enabled | disabled] [any | UDP | TCP | TLS] [sessionConfigReference] third-party-call-control hold handle [serverConfigReference] third-party-call-control retrieve handle [serverConfigReference] third-party-call-control transfer handle to [serverConfigReference] third-party-call-control disconnect handle [serverConfigReference] third-party-call-control join handle1 handle2 [serverConfigReference] third-party-call-control loop handle [sessionConfigReference] third-party-call-control annotate handle text [sessionConfigReference] third-party-call-control get-annotation handle [sessionConfigReference] third-party-call-control park endpoint [from] [requestId] [enabled | disabled] [sessionConfigReference] [serverConfigReference] third-party-call-control connect handle endpoint [enabled | disabled] [requestId] [sessionConfigReference] [serverConfigReference] third-party-call-control terminate handle [serverConfigReference] third-party-call-control memo-begin handle filename [greeting] [enabled | disabled] third-party-call-control memo-end handle [serverConfigReference] third-party-call-control play handle filename [enabled | disabled] [serverConfigReference] third-party-call-control drop-file handle filename [serverConfigReference] third-party-call-control notify handle event [serverConfigReference] third-party-call-control message filename endpoint [from] [requestId] [enabled | disabled] [sessionConfigReference] [serverConfigReference]
Tests outgoing TLS connectivity to a remote device. Specify the destination IP address and port of the target device. Optionally, you can specify a reference to a configured certificate. If you do not specify the certificate, the ME uses the default outgoing TLS certificate entry.
NNOS-E>tls test 10.1.80.2:5061 ”vsp\tls\certificate Client” Attempting TLS test connection. Destination: 10.1.80.2:5061 Certificate: Record 129 TLS connection established; waiting for validation by remote TLS server... TLS connection still up; connection must have passed validation. Success.! If you do not specify a certificate and the remote peer required one, you would see this type of output: NNOS-E>tls test 10.1.80.2:5061 Attempting TLS test connection. Destination: 10.1.80.2:5061 Certificate: <Default Outgoing> TLS connection lost: TLS handshake failure. Connection attempt failed If you specify the wrong certificate, you would see this type of output: NNOS-E>tls test 10.1.80.2:5061 ”vsp\tls\certificate Client” Attempting TLS test connection. Destination: 10.1.80.2:5061 Certificate: Record 129 TLS connection established; waiting for validation by remote TLS server... TLS connection lost: Received TLS shutdown from peer. Connection attempt failed
Sends an acknowledgement to the SNMP agent to discontinue retransmission of SNMP traps. Use this action if you have enabled this feature with the trap-retransmit property of the snmp object. When you execute this action, all traps being retransmitted will be stopped. However, any subsequent traps will be retransmitted until you either re-execute this action or disable the trap-retransmit feature.
This action behaves as if the trickle-ice-media-specification has been received via a SIP INFO request.
Enter the following arguments:
<call-leg-handle>—The handle identifying the holding call-leg providing the trickle-ice update.
<media-type>—The mime type of media specification (initial-answer-SDP).
<trickle-ice-media-specification>—The offer media specification forwarded to the peer call-leg (incremental- SDP).
This action allows you to manually remove TURN Allocations. Per RFC5766, TURN clients that no longer want to use an Allocation are encouraged to delete the Allocation via a TURN Refresh request with a requested lifetime of 0. However, some TURN clients currently do not remove Allocations and these remain in the ME until they expire.
Note:
Ensure you remove only unused Allocations. Removing valid and in-use Allocations disrupts a WebRTC call using the ME's TURN server.Removes the specified device from the ME usable devices. In essence, this destroys a logical disconnection of the device, and you can no longer read or write to it. The effect of this is that any directories contained on the device become unavailable.
Disconnects an ME call using ME's REST APIs.
Syntax
Enter the following arguments:
<URI>: The URI tied to this binding.
<binding-identifier>: The identifier that uniquely identifies this binding.
Manages the alias table, an indexed table into the location database. This table maintains all the alias information for any known address of record. Select one of the following:
lookup: Returns all known aliases found in the alias table for the specified address of record.
reset: Deletes all alias mappings from the alias table and then recreates them by synchronizing with the enterprise directory. The ME repopulates the table with any alias associated with a known AOR.
flush: Deletes all alias mappings from the alias table and repopulates the alias table as it relearns them. Optionally you can specify whether to flush the cache immediately or as the entries time out. By default, the system flushes entries immediately.
seek: Returns all known aliases found in the directory service for the specified address of record.
delete: Deletes the specified entry from the location alias table.
change-state: Changes the state of the location cache entry in the alias table. Enter the AOR and the new state.
You can also schedule this action as part of routine maintenance using the task object.
Returns the normalized URI and the address of record and binding for the specified URI. The URI can be a SIP URI (e.g., sip:joe@abc.com) or a TEL URI (e.g., tel:19788236666).
NNOS-E>uri-resolve tel:+16667770001 URI tel:+16667770001 normalized to sip:6667770001@best.com AOR sip:6667770001@best.com has a binding at 192.168.215.95 at 5060 via UDP NNOS-E>uri-resolve sip:6667770001@best.com URI sip:6667770001@best.com normalized to sip:6667770001@best.com AOR sip:6667770001@best.com has a binding at 192.168.215.95 at 5060 via UDP
Performs a lookup in the ME user database for the requested AOR. The result returns the AOR with the associated UID and tag. You can use the show user-cache command to display all users in the cache. The ME directory process stores all entries for all configured enterprise directories in a database file. That file, which is read in to the SIP processing side or operations, creates a cache of all directory (user) information.
Resets all sessions on the VSP, disconnecting any active sessions. This action is primarily a debugging tool and should only be used if Technical Supports instructs you to do so. However, it is also required to activate any changes to the properties in the static-stack-settings object.
Sets the status/availability of a previously configured external location, policy, or event service server. Configure the services using the external-services group and service objects. Use the show web-services-callout-details command with the availability field to verify the status. Set the server status to one of the following:
disabled: Puts the server out of service until it is manually set to available using this action.
available: Returns a server to service with the ME, whether it was manually set or detected as unavailable.
unavailable: Marks a server as temporarily unavailable. If a heartbeat-url is configured for the server, the ME will attempt to bring it back into service.
Note that when the ME detects that a server is unavailable, it automatically changes that web service server status to unavailable.If the status is unavailable, you must set it to available (once it is) with this action before the ME can use that server again.
web-services set-location server {disabled | available | unavailable} web-services set-policy server {disabled | available | unavailable} web-services set-event server {disabled | available | unavailable}
NNOS-E>web-services set-policy ”external-services policy-group pol1 policy-service polSrvc1” available No service for server reference NNOS-E>config external-services policy-group pol1 policy-service polSrvc1 Creating ’policy-group pol1' Creating ’policy-service polSrvc1' config policy-service polSrvc1>exit Do you want to commit your changes before you exit (y or n)?y NNOS-E>web-services set-policy ”external-services policy-group pol1 policy-service polSrvc1” available Success!>
Provides tools to manage XML files on the ME. You must be running web services (enabled with the web object) on the system for this action to be available.
parse: Checks the specified file for well formedness.
transform: Translates the source file into the named destination file, using the specified style sheet. Enter a style sheet (.xsl file) to be used for the transformation. This can be a Oracle-supplied style sheet, for example, to convert configuration files for upgrade. Or, you can create your own to make modifications that you can then apply on each system. Optionally, you can use the parameters argument to alter the output transformed with the specified xsl style sheet.
validate: Verifies that the content of the of the source file conforms to the default or specified schema. If you do not enter a schema, the system uses the configuration file as the default.
xml parse file xml transform stylesheet source destination [parameters] xml validate fileName [schema]
NNOS-E>xml parse /cxc/backup/cfg1106.xml The XML file is not valid NNOS-E>xml parse /cxc/install/install.xml Success! NNOS-E>xml transform serverUpdate.xsl /cxc/cxc.cfg /cxc/server.cfg The XSL template appears invalid NNOS-E>xml transform 2.1-to-3.0.xsl /cxc/backup/cxc.cfg /cxc/cxc.cfg red=blue Success! NNOS-E>xml validate /cxc/install.xml Success!