››

Configuring Softswitch Voice

Introduction

The purpose of this document is to define how to configure Softswitch based voice on the Tellabs 1150 OLT and ONTs.

Applies To

This Application Note applies to analog voice ports on Tellabs ONTs for Tellabs 1131, 1134, 1150 and all analog voice ONTs. This application note only applies to Softswitch voice and does not apply to Voice Gateway(VGW) applications.

Overview of Steps to Setup Softswitch Voice

This section will define high level flow of steps to setup Softswitch voice:

Enable TConfig: TConfig must be enabled.
Config Address: Tconfig address must be configured
Config Voice VLAN: Voice VLAN must be configured
Create Profile: ONT Voice Profiles must be created.
Assign Profiles: Voice Profiles must be assigned to lines, and lines enabled.

Enabling TConfig and Configuring TConfig Address

You must have enabled Tconfig as a part of the EMS installation to use Tconfig’s services.

If you did this on install, you can ignore this section as it will prompt you for this information.

TconfigSubsystem.properties file

You can verify that it is set up by checking the content of a couple of files. The first file is the

TconfigSubsystem.properties file. This defines the IP address of the servlet that implements Tconfig.

This file can be found in: C:TellabsbbmgrserverdataTconfigSubsystem

The TconfigHost property will define the IP address Tconfig will listen on.

The TconfigIPv6Host property can be used to either define an Ipv6 address for Tconfig (you can have both a Ipv4 and Ipv6 Tconfig instance running at the same time. It can also be used to define a 2^nd Ipv4 Tconfig address on another NIC of the machine when you have two softswitches on different VLANs. While labeled Ipv6Host, it will just spawn a 2^nd instance at whatever address you specify whether it is Ipv4 or Ipv6. No other attribute should be modified.

Figure 1 Enabling Tconfig

The Tconfig processes must be enabled. This can be done at install via the installation script prompts. If it was not enabled at startup, then you will have to manually enable it in the startup.txt file which defines all processes that are started up.

ConfigMgr Startup.txt

Look in the startup.txt file which is found in the c:TellabsbbmgrserverdataConfigMgr subdirectory of the installation. The root of the path will vary based on installation and OS.

If there is a # sign at the beginning of a line, it is commented out and will not be started. There are two processes associated with Tconfig.

com.tellabs.ems.server.feature.tconfig.TconfigSS and
com.tellabs.ems.serverrmi.tconfigmanager.TconfigManagerSubsystem.

Remove any # signs at the beginning of these two lines in the startup.txt file.

Figure 2 Enabling Tconfig Part 2

Download Manager startup.txt file

Check to see if the Tconfig server is commented out in the download manager properties. Modify the C:TellabsPanoramaINMbbmgrserverdataDownloadManagerSubsystemstartup.txt (or solaris equivalent) as follows;

- Uncomment (remove the pound/number sign) the following line in the file.

#com.tellabs.ems.tconfig.TconfigSubsystem

so that it looks like this:
com.tellabs.ems.tconfig.TconfigSubsystem

If you change the IP address, you must stop and start the Tconfig server for it to take effect.

For Windows machines, you can do this by going to services finding the PanoramaHttpd service and stopping and starting it. To run Windows Services, push the start button. In the search bar, push type in services and the machine should find it.

On Solaris, you can do this by running the following two scripts:

Figure 3 Restarting Tconfig Server

For windows you can use the services method mentioned above, or use the batch files. For Windows, the files will be named stopHttpServer.bat and runHttpServer.bat.

If you change the startup.txt file, you must stop and restart the EMS server for the Tconfig processes to be properly started up. Go to the Tellabs Program group under the Start menu on Windows and find the Tellabs group and you should see the line items to Stop and Start the server.

Network Configuration requirements

You must configure the voice VLAN on the EMS. The system can be configured with a separate voice VLAN (recommended production environment) or with voice and management sharing the same VLAN. For security reasons in a production environment, it is best to configure the voice onto a separate VLAN to isolate your voice resources from all external access to prevent any attacks on the voice subsystem and to minimize the ability of people to snoop the contents of the voice VLAN.

Figure 4 Network Models for Tconfig Access

The voice VLAN must be placed into the VLAN Properties so the system knows that this VLAN exists.

Figure 5 Configuring Voice VLAN(s)

You must then map the traffic onto one or more uplink interfaces. In this example, the voice VLAN 13 has been mapped onto the NET1 Uplink interface.

Figure 6 Mapping Voice VLANs to an Uplink

The last step is to configure the Network Element Tconfig server address. Each NE supports a separate Tconfig server address, so that each NE can point to the appropriate NIC. The implication is that you can only have one Tconfig IP address per NE. The IP address should be set properly for your network. The port should never be changed.

Figure 7 Setting Tconfig IP Address

ONT Profile Configuration requirements

Equipment Settings profile for use with all ONTs. This profile is used for systems that are using UDP transport for the SIP.

Figure 8 Setting up UDP Equipment Settings Profile

See below.

If you need to encrypt the SIP interface, this is how you configure it. The switch you are using must support this and have port 5061 open for encrypted SIP traffic. Please note only the 729GP supports encrypted SIP.

Figure 9 Creating a TLS Equipment Settings Profile

The next step is to create the Service Profiles.

There will need to be separate profiles for the 729 versus the other ONTs. The 729 GP requires an outbound proxy for proper operation. The other ONTs cannot work with the outbound proxy specified. This leads to two profiles; one for the 729GP, one for the rest of the ONTs.

Profile for all ONTs except for the 729GP.

This is the Services Profile Settings for the ONT 702, 704, 705, and 142. MLPP must be off as these ONTs do not support MLPP, only the 729GP does. Please note that the Outbound Proxy Address is blank.

Figure 10 Standard ONT Services Profile

It may be necessary to edit some of the fields. Here are some of the most commonly edited fields.

Local Ports Min - This is the lowest port number that will be selected for voice RTP flows. It is often necessary to constrain the ports used so that they can have pinholes opened in the firewall. If you don’t need to pass through a firewall, just leave it blank.
Local Ports Max - This is the highest port number that will be selected for voice RTP flows.
Enable RFC2833 - This field controls whether the DTMF digits are sent via RFC2833 messages or whether they are sent inband in the PCM flow. Many PBXes want the DTMF digits sent as 2833 due to the codecs they allow or due to wanting to separately process the signaling from the RTP.
Registrar URI - This is the IP address or hostname of the switch. This is unique to your installation and must be entered.
Proxy Address - This is the IP ddress or hostname of the switch.
Timed Release - This says how long the phone has to be onhook before it will terminate the call, recommended setting is 3 seconds.

729GP Services Profile.
Only the Outbound proxy differs.

The format of the outbound proxy field for the 729GP is different than the other ONT types:

Note: The < = less than, the > = greater than, essentially shorthand for angled brackets.

<sip:hostname;lr> where the lr instructs the 729 to use loose routing.

Note: If MLPP is enabled on the 729GP, you typically need to configure it as follows:

Figure 11 Typical 729GP Services Profile

You also need to set up the outbound proxy differently if you are using tls transport for SIP. This is only supported by the 729GP.

This is because most switches violate the RFC and do not send the sips: scheme rather than the sip: scheme. The addition of a hint for the transport lets the transport layer know to always use TLS transport even though the sip: scheme is being used.

Figure 12 729GP Services Profile Part 2

Call Features Profile for all ONTs:

Dial plan is the only field that is complicated.

Standard North American Dial plan should be used for 7/10 digit standard dialing.

Lismore-Business : This is a good example dial plan for 3 digit PBX station to station dialing along with 9+ dialing to get out.

You can change it to 4 digit station to station dialing by changing the following line.

([^9]xx) ; Three digit extension dialing within the business, extensions can’t begin with 9 as that is outside line.

([^9]xxx) ; Four digit extension dialing within the business, extensions can’t begin with 9 as that is outside line.

Figure 13 Call Features Profile

Typically, you will need to Enable Transfer, Hold, 3wc (three way calling), Call Waiting (Enable CW) and Caller ID.

Message Event URI - Settings vary by switch. If you need to subscribe for the Message Waiting Light status, then you should put sip:<ip of switch> in the Message Event URI. This will cause the ONT to subscribe for the Message Waiting Indicator status.
Message Waiting Mode - Typical setup is Message Waiting Mode set to dial-tone, visual. This will give you the message waiting light, and the stutter dial tone when messages are waiting.

Call Features Profile 2^nd Half. All below Message Waiting is defaults

Figure 14 Call Features Profile Part 2

How to configure Hotline in the Call Features Profile.

Figure 15 Hotline Configuration

Hotline - Hotline is a feature where when you pick up the phone, it will automatically dial a pre-programmed number. Similar to the President’s hotline or something similar. This is also used for house phones.
Warmline - Warmline is similar to hotline although you get a pre-programmed delay before auto dialing begins. If dialing begins before the timeout, a normal call can be placed. This is also used on house phones where you can dial out but after a pre-programmed delay will auto dial the programmed number. This is also used for the elderly where if they dial out great, but if they can’t dial, after a while it will call a pre-programmed relative’s number.

ONT Configuration requirements

This section defines how to configure an ONT for Softswitch.

Figure 16 ONT Voice Configuration

ONX Voice Personality - Can be set for VGW or Softswitch. In this example is set to Softswitch.
IP Address - Typically set for Ipv4. The only method of IP address assignment in softswitch is via DHCP. You must have a DHCP server set up; it must hand out an IP address and a DNS entry. If after setting everything up, you don’t see an IP address here, then start looking at networking or DHCP setup.
VLAN ID - Defines the voice VLAN ID for this ONT.
Do not change any of the Tconfig specifications other than Equipment Settings.
Equipment Settings - This profile defines whether the SIP is encrypted or now and how often the XML config file will be downloaded to the ONT. You can typically use the default profile unless you are using TLS to encrypt the SIP path.

ONT Line Configuration requirements

This section defines how to configure an individual phone line. Example of Per Line Configuration:

Figure 17 ONT Voice Line Configuration

AOR URI - This field defines the SIP Address Of Record (AOR) and how to contact the line. The typical format is: sip:<phone number>@<switch IP address or hostname> Please note that the IP address is that of the softswitch not of the ONT. This basically says I am phone number 1234 registered at softswitch IP address.
Contact - This will be auto filled for you if you set the AOR correctly.
Softswitch User Name - This is the username used to log into the switch for authentication purposes. Most installations use this to authenticate the phone / user to the switch. If authentication is off, then just put in anything. These fields will only be used if the switch challenges a registration or a call attempt.
Softswitch Password - Password to log into the softswitch.
Services Profile - Defines the services profile for that line.
Call Features Profile - Defines the call features profile for the line.

You MUST activate the line before it will register.

Example of In service Line, Activate/Deactivate buttons used to put line into/out of service:

Figure 18 Voice Line Status

Call State shows line offhook state.

Registration State show whether line is registered and any problems with registration. A working line will show a Registration State of Registered.

Voice Line Debug

Debugging Voice Line Problems:

Figure 19 Voice Line Debug

IP Address - If you don’t have an IP address, then look at DHCP, Networking and the VLAN. Without an IP address, nothing will work. A DHCP server must be set up and should be handing out a DNS entry via DHCP. Static IPs are not supported for Softswitch Voice.
Show Tconfig Statistics - This will show you the latest Tconfig Statistics. This lets you know whether the ONT has its configuration data.
Successful Polls - If this is zero, then Tconfig has never communicated and you have a networking or Tconfig setup problem. Look at Tconfig properties files on the EMS and at the IP address configured in the properties file and the NE. Each time you press the Refresh Profile button the Successful Polls should increment.
Last Polled On - This tells you the time of the last successful poll. This can give you a clue as to when it last talked to the EMS. Default is to do this daily unless you reboot or push the Refresh VoIP Profile button.

Figure 20 Checking Registration and Offhook Status

The registration screen is also very helpful.

Registration State - Tells you the state of a line.
Initializing usually is a temporary state and if it persists then typically you have a problem with some configuration on the Voice Line or Voice Profiles.
Registered means that you are registered with the switch and you should have dial tone. If not, you often have a wiring problem.
Authentication Failure - This typically means the Softswitch login is wrong. Typically, one of three fields. Softswitch Username, Password, or the Realm. Real is defined in the service profile and defines the authentication realm for the switch. The most common setting on most switches for the realm is either the Switch’s IP address or the word Realm.
Call State - This can often help you diagnose wiring problems. If the line is registered and off hook but shows up on the dialog as idle, then you likely have a wiring problem.

Voice Alarms

Alarms give you a very rich way to pinpoint what is wrong with voice.

Here is the list of alarms supported by the system.

SIP DHCP server - No Response or Error Received - You are not getting an address from the server. Check (a) Network Status (b) VLAN configured on ONT for voice, (c) DHCP server status.
SIP DHCP Server - Incomplete Response - This alarm indicates that a DNS entry was not present in the DHCP options. This means that hostnames cannot be resolved on the ONT voice ports. Since it is valid for hostnames to be used this can pose a problem with call completion. It is recommended that you always have a DNS entry unless you are certain that all requests will only be IP based.
SIP Config Server Retrieving - Cannot Authenticate - Should not be possible with EMS Tconfig. This was a problem with external Tconfig.
SIP Config Server Retrieving - Malformed Configuration Document - This happens when there is a problem with the dial plan specification or the Outbound Proxy format. Correct it and the line will go into service. It can also happen if there is a typo in the Message Event URI for the line, but this is a less common error and is rarely used.
SIP UA Register - Cannot Authenticate - There is a problem with the softswitch credentials programmed on the Voice Line Config screen (Softswitch Username or Password) or the realm is incorrect in the services profile. A Wireshark capture can usually determine a mismatch in the realm as the switch will typically give it’s realm in the responses.
SIP UA Register - Cannot Resolve Domain Name - The services profile configuration or the Voice Line config included a hostname and either DNS is not set up, or the DNS server couldn’t resolve it. Look for typos, then go investigate the DNS server.
SIP UA Register - Timeout - The Voice Line attempted to register but no answer came back from the switch. Can also point to networking problems. Try pinging the ONT from the switch console.
SIP UA Register - Server Failure Response - The switch refused the registration attempt for reasons other than authentication.

Encrypted Voice

Encrypted SIP

The SIP path can be encrypted by setting the Transport protocol name to tls in the Equipment settings profile. This only applies to the 729GP at this time. No other ONT supports encrypted SIP. The Equipment profile is assigned on the Properties dialog of the ONT. An example TLS profile is shown below.

Figure 21 Encrypting SIP

Encrypted RTP/Voice

The voice path can be encrypted via the Media Encapsulation setting in the Services Profile of the Voice Line. The media encapsulation defines whether RTP, SRTP or both are used for transport of the voice. This only applies to the 729GP at this time.

RTP Only Selected - The ONT will only use unencrypted RTP packets for transport of voice.
SRTP Only Selected - Only encrypted calls are allowed and only SRTP will be used for transport of voice. Requests to the ONT that only offer RTP will be rejected.
RTP and SRTP - The ONT will offer both RTP and SRTP to the far end with the preference being SRTP (encrypted). If the far end cannot support SRTP, the ONT will accept an RTP call. If the other end can support SRTP, then SRTP will be used.

MLPP Configuration

The 729GP ONT is the only ONT that currently supports MLPP. MLPP or multi-level priority and pre-emption is a capability that allows higher priority calls to pre-empt lower priority calls in military and government environments.

MLPP is configured within the Services profile of the 729GP. You must enable MLPP. The dialing prefix is typically 9x where x is the priority of the call. All of the MLPP settings match the UCR and should not need modification. It may be necessary to modify the Network domain depending on whether it is a uc or dsn network.

The Max Precedence level should be set to the maximum level that the user should be allowed to initiate.

Dial Prefix	Default Precedence	Level Allowed
94	0	Routine Only
93	2	Priority and below.
92	4	Immediate and Below
91	6	Flash and Below.
90	8	Flash Override and below.

Voice Certificates Configuration

Using Stock Certificates

The 729GP ONT is shipped with a certificate on it that is generated by Tellabs. This certificate can be used in most instances to secure voice. In most instances where you are using certificates, you will want to load a site specific certificate onto the 729 to use in a secured voice installation.

The stock certificate is generated by the TellabsCA1 certificate authority and you can request this trust anchor certificate from Tellabs TAC. Essentially you will need to add the trust anchor to the list of trust anchors within the switch if you wish to trust the default certificates installed by Tellabs.

You will also need to add the trust anchor certificate of the CA(also known as CA certificate) that created the Softswitch certificate. This will allow the ONT to "trust" the certificate coming from the switch.

MLPP and Encrypted Voice

The 729GP is the only ONT which supports secure voice. The 729GP supports certificate authentication as part of SIP and MLPP. When utilizing voice secured by certificates, you must perform the following setup steps to properly use certificates and properly implement MLPP.

The following tasks must be performed for proper operation of MLPP and AS-SIP:

Add Device Certificates and Trust Anchor Certificates to the EMS.
Add Device Certificates and Trust Anchor Certificates to the OLT.
Add Device Certificates and Trust Anchor Certificates to the EMS.

Adding Device Certificates and Trust Anchor Certificates to the EMS

Tellabs provides a tool for managing EMS certificates. This tool can be invoked from the server directory of the EMS(C:TellabsPanoramaPonbbmgrserver). This tool allows for importing and exporting certificates.

Two types of EMS certificates can be managed:

Trust Anchor Certificates - These are public certificates of the CA (certificate authority). The system will trust any certificates that it receives that were created by certificate authorities in its trust anchor list.
Device Certificates - These are certificates that are presented by the ONT to the softswitches whenever they perform SIP registration.

The certificateMgr allows the user to load certificates and trust anchors for the ONTs. There is a batch file in windows and a script in in Solaris named certificateMgr in the server directory that performs this function.

Figure 22 Windows Certificate Manager Location

Figure 23 Solaris Certificate Manager

You will be required to log in as a user with the certificate administrator role prior to making changes. The user must be created via the EMS User menus and have the certificate administrator role associated with it.

You MUST perform a backup prior to modifying any certificates. This is to ensure that you can return the system to a known state prior to the addition of certificates. The Panorama PON Administration manual gives details on how to do this function. You can initiate the backup using the backupems.bat file in the server directory. You will be prevented from modifying certificates until this backup exists.

Adding EMS Trust Anchor(s)

The Trust Anchors for the EMS should first be updated using menu option 3 PON EMS device/anchor certificate menu from the main menu of certificateMgr.

Anchor certificates can be either appended to the existing trust anchor list, or can replace the existing list. A pem file is used to import the certificate(s).

Updating the EMS certificate will require shutting down the EMS server. This is non service affecting, but will prevent management of the OLTs via the EMS GUI for the duration of the certificate management activities.

After the certificate has been added, you will be prompted to restart the server.

Adding EMS Device Certificate

The EMS should also be loaded with a device certificate that is created by one of the CAs in the trust anchor list. Please note the OLTs will lose communication with the EMS until they are loaded with corresponding certificates created by a CA in the trust anchor list of the EMS. This is non-service affecting but the OLTs will not be manageable by the EMS until the OLT certificates have been loaded.

You will be prompted to restart the EMS Server.

Adding OLT Certificates

You must log into the OLT with a user account that has the Security Admin role. Certificates can only be managed by users with this role assigned.

When using the CLI to import the certificate into the OLT, it must be in PEM format to be able to paste into the CLI terminal. If your certificate file is in a p12 form, it can be converted using standard openSSL as follows:

Note: You must know the certificate password to convert a p12 to a pem.

The following command is used to add the certificate to the OLT:

ne security key edit pem terminal

The import function requires that the pem file be password protected and will prompt for the file password.

The certificate is then pasted into the terminal then <Ctrl-D> is used to tell the CLI that the import is complete.

The certificate if valid will be imported by the OLT and the result of the import is shown:

The accompanying trust anchor(s) can be loaded in a similar fashion using the command:

ne security pki-ca-trustpoint edit certificate pem terminal

The EMS and OLT should be now communicating using the newly installed certificates.

Managing ONT Device Certificates

The certificate manager supports the following ONT certificate menus:

Deploying an ONT Anchor Archive - loading a .tgz file (tar and gzipped) list of pem files used as trust anchors.

Add a Trust Anchor to the Archive - Add a new trust anchor to the existing anchor tgz file.

Delete a Trust Anchor from the Archive - Remote a trust anchor that has expired or you no longer want to trust.

Create an Archive from a directory - Take a directory full of trust anchor pem files and turn them into a trust anchor tgz file.

Replace an Archive with Directory’s contents - Same as create, but it will replace the tgz file that exists with the tgz file created from the directory’s contents.

Start the HTTP Server - Starts the HTTP server which serves up the certificates to the ONT. It is required that you restart the server if you change the IP address or the trust anchor archive.

Stop the HTTP Server - Stops the HTTP server. It is required that you restart the server if you change the IP address or the trust anchor archive.

Device certificates are used to authenticate the identity of an ONT to the soft switch. The system allows loading of Device Certificates to the ONT 729GP for the purposes of secure AS-SIP compliant transactions with the soft switch. If you manually load a device certificate on an ONT729GP, it will go into secured AS-SIP mode which is compliant with Fed Gov requirements laid out in the UCR. This will require the OLT and EMS to also be secured by a certificates that are created by a CA in the ONT’s trust anchor list.

The device certificate will enable a number of additional checks that must be met for proper TLS operation.

CN - The certificate name must either be a host name that equates to the ONT’s IP, or it must be the IP address of the ONT. The ONT will verify that received certificates CN name resolves to the IP address of the party trying to connect to the ONT. i.e. The softswitch certificate must have a CN name and it must resolve to the softswitch IP. The same is true of the ONT’s device certificate. This requires as per the UCR that each ONT 729GP must have its own unique certificate. If hostname based, the Device ID/Hostname in the ONT VoIP tab MUST agree with the one in the certificate.

OCSP - The system will do a certificate check to ensure that the switch’s certificate has not been revoked.

Note: Open Certificate Status Protocol (OCSP) must be included in the Device Certificate.

The device certificate must be in the p12 format to be loaded by the ONT and include the certificate, public key and private key and the private key must be secured by a password to ensure proper security.

From the certificateMgr script, you can bulk load certificates to the server directories using the item 8 option of the menu. This allows you to put the certificates onto the machine so they can be loaded to ONTs.

Figure 24 Managing Device Certificates

Each OLT has a directory, named by its IP address that the certificates are stored in prior to being loaded onto the ONT.

You can see the current certificate from the ONT Properties on the Certificate Status tab as shown below. The upper pane shows the device certificate loaded; the bottom pane allows the user to step through each of the loaded trust anchors and see what Cas the ONT will trust.

Figure 25 Certificate Status Screen

The certificate can be loaded from the Security tab of the ONT Properties dialog which can only be seen or modified by someone with the certificate admin role. All users can check the certificate status on the Certificate Status tab of the ONT Properties menu.

Figure 26 Security Tab

The Security menu allows loading of certificates. You can browse to the certificate to be loaded, enter the certificate password, and then push Execute Download.

This will trigger a download of the certificate and the trust anchors to the ONT. The results of the download can be seen on the certificate status. It takes 15-20 seconds for the certificate to be downloaded, decrypted and installed onto the system. The certificate is stored persistently on the ONT and the certificate is removed from the EMS. If you want a copy, you must keep a copy in some other location. There is no way to get a copy of the certificate out of the ONT.

Look at the Certificate Status tab fields Installation Date, Last Download Date and the Last Download Status to determine the result of the certificate install.

You can also reset the certificate back to the default stock certificate if you wish by pressing the Reset ONT Certificate button on the Certificate Status tab of the ONT.

Managing ONT Anchor Certificates

The ONT Anchor Certificates are used to verify the identity of certificates that are offered to the ONT. Typically, this is the Softswitch and the EMS. The EMS certificate must validate for the TConfig XML to download. The Softswitch certificate must validate for the Softswitch connection when in TLS mode.

Anchor certificates can be loaded into the Anchor Certificate repository using the CertificateMgr batch file on the EMS. The anchor certificates must be in the PEM file format. Multiple anchor certificates can be loaded. Every day when the ONTs check for configuration changes, they will note any anchor certificate changes and pick them up from the EMS.

All of the following certificateMgr features allow management of the anchor certificates archive.

Deploying an ONT Anchor Archive - loading a .tgz file (tar and gzipped) list of pem files used as trust anchors.
Add a Trust Anchor to the Archive - Add a new trust anchor to the existing anchor tgz file.
Delete a Trust Anchor from the Archive - Remove a trust anchor that has expired or you no longer want to trust.
Create an Archive from a directory - Take a directory full of trust anchor pem files and turn them into a trust anchor tgz file.
Replace an Archive with Directory’s contents - Same as create, but it will replace the tgz file that exists with the tgz file created from the directory’s contents.

Surveillance of Certificate Issues

A number of alarms and event reports exist to give current status of certificates, and issues with certificates offered to the ONT. The certificate events will only appear in the Security Events Tab of the Events View.

Certificate Expired - ONTs whose certificate have expired will raise this alarm. Details of the certificate can be seen in the Additional text field of the alarm.
Certificate Expiring - This is an event which will be issued when there is a certificate that will expire within the configured warning period. Certificate data and number of days left on the certificate are signaled within the Additional text field of the event.
Certificate Revoked - When the ONT or a device the ONT is communicating with has detected that OCSP has revoked a certificate this event will be posted. The Event will give information identifying the certificate, the IP address and FQDN if one exists.
Downloaded Certificate Invalid - The ONT will reject any invalid certificate and will not load it. The ONT will continue using the existing certificate and make no changes. If an attempt is made to download an invalid certificate the ONT will post this event. The Event will give information identifying the certificate.
Device Certificate Installed - A valid certificate was loaded by a user with Certificate Administrator rights. The certificate downloaded will be identified.
Certificate Download Failed - If a certificate download could not be completed, the ONT will signal this event. The existing certificate will be kept active and no changes will be made.
OCSP Responder Failed - If contact is lost with OCSP, the system will post this event. Calls will continue and certificates will be validated but revocation status cannot be checked.
Peer Certificate Validation Failed - If the ONT fails to validate a certificate of a device attempting to communicate with it (EMS, Softswitch) then it will post this event. This Event is sent when the device attempts to perform mutual authentication on a peer certificate and that certificate fails validation. Validation can fail due to an invalid certificate, an unknown CA, invalid certificate dates or unable to validate that the hostname stated in the certificate resolves to the IP address from which the message originates.

FEEDBACK: Are you happy with this material?

Thank you Your feedback helps us to continually improve our content.