Abstract: A container having a lid includes a cavity defined by a bottom wall and a first plurality of upstanding sidewalls. A first flange is formed integrally with the first plurality of upstanding sidewalls at their respective uppermost ends and extends outwardly with respect to the cavity. A second plurality of upstanding sidewalls is mounted about the outer periphery of the first flange. A second flange is formed integrally with the second plurality of upstanding sidewalls at their respective uppermost ends and extends outwardly with respect to the cavity. The second flange has a tear tab adapted to be gripped by a user. The tear tab is corner-mounted in a first embodiment and is formed on a leading end of the second flange in a second embodiment. In both embodiments, the tear tab is bordered by perforation lines and clear cut lines and is easily seen if it has been torn.

Abstract: A system operator provisions, or loads, a user's communication device, such as a cable modem, with multiple sets of loopback mode parameters that each facilitate a loopback test, and associates each set with multiple loopback numbers, or variable values. The loopback variables may be MIBs assigned to the device's manufacturer for use in initiating a loopback test of a user device. An operator may initiate a loopback test from a central computer device located remotely from the user device. The initiating device may be coupled to an operator's private IP network, or to a network coupled to the user device. The initiating device sends one of the loopback values in a SIP Invite message to the user device, without the use of SIP extensions, in a call. The user device recognizes the loopback value, auto-answers the call, and performs actions according to the provisioned parameters corresponding to the loopback value.

Abstract: A communication protocol specification is divided into subsets of parameters based on patterns established by equipment vendors. A combination of subsets is selected based on parameters and features supported by particular network devices installed in a network. A user interface facilitates convenient creation or modification of a configuration file, which instructs a network device how to format a communication message and what information is to be contained therein. After the configuration file is loaded into a device, it controls software switches in the device such that features and parameters corresponding to the parameters selected with the user interface and controlled by the switches are either enabled or disable based on the parameters selected. Supported parameter combinations for popular equipment may be prestored so that selection with the interface of a particular piece of equipment automatically edits the configuration file according to the features and parameters supported by said equipment.

Abstract: An induced loss value is retrieved from a configuration file of an MTA device. The loss value is provided to a signal generator that generates call progress/alerting signals and FSK signals in the MTA telephony device. To mitigate the imbalance between incoming voice signal levels and call progress/alerting signals that may occur because the call progress/alerting signals are not generated at a level equal to that of the incoming voice signals, the loss/attenuation amount from the configuration file is used to adjust the levels of the generated call progress/alerting and FSK signals by a corresponding amount before they are attenuated along with the incoming voice signals.

Abstract: Methods for collection of device reset history from a network communication device comprising: (a) determining whether a reset condition is triggered by software or hardware, (b) for a software triggered reset: (i) upon a software exception, retrieving related reset information, (ii) upon an operator initiation, retrieving related reset information, (iii) allocating space in non-volatile memory, (iv) storing retrieved current reset information together with a corresponding reset time, and (v) adding the current reset information to historical reset information, (c) proceeding with the reset, (d) executing startup code during reboot, (e) upon a hardware triggered reset; (i) retrieving hardware registry and other residual hardware information still present, (ii) allocating space in non-volatile memory, (iii) storing the current retrieved reset information together with a current time that corresponds approximately to the reset and (iv) adding the reset information to historical reset information, and (f) contin

Abstract: Methods, systems, and apparatus can be used to decouple software loads on customer premise equipment devices. In various examples, simple network management protocol (SNMP) messages, configuration files or other types of notifications can be used to notify customer premise devices of software updates for non-data over cable service interface specification (DOCSIS) modules. The version of the software load included in a notification can be compared to existing software loads to determine whether the software load identified by the notification should be loaded to the device.

Abstract: A method adds a MAC address per line for a multiline EMTA. After the EMTA initializes, the method creates “Virtual MTA” instances corresponding to each analog line/MAC address. The method facilitates MTA emulation of each of the Virtual MTA instances. For each virtual EMTA line, the emulation method includes acquiring an IP address via DHCP and acquiring a configuration file via TFTP for each virtual MTA instance.

Abstract: Methods for collection of device reset history from a network communication device comprising: (a) determining whether a reset condition is triggered by software or hardware, (b) for a software triggered reset: (i) upon a software exception, retrieving related reset information, (ii) upon an operator initiation, retrieving related reset information, (iii) allocating space in non-volatile memory, (iv) storing retrieved current reset information together with a corresponding reset time, and (v) adding the current reset information to historical reset information, (c) proceeding with the reset, (d) executing startup code during reboot, (e) upon a hardware triggered reset; (i) retrieving hardware registry and other residual hardware information still present, (ii) allocating space in non-volatile memory, (iii) storing the current retrieved reset information together with a current time that corresponds approximately to the reset and (iv) adding the reset information to historical reset information, and (f) contin

Abstract: Methods for collection of device reset history from a network communication device comprising: (a) determining whether a reset condition is triggered by software or hardware, (b) for a software triggered reset: (i) upon a software exception, retrieving related reset information, (ii) upon an operator initiation, retrieving related reset information, (iii) allocating space in non-volatile memory, (iv) storing retrieved current reset information together with a corresponding reset time, and (v) adding the current reset information to historical reset information, (c) proceeding with the reset, (d) executing startup code during reboot, (e) upon a hardware triggered reset; (i) retrieving hardware registry and other residual hardware information still present, (ii) allocating space in non-volatile memory, (iii) storing the current retrieved reset information together with a current time that corresponds approximately to the reset and (iv) adding the reset information to historical reset information, and (f) contin

Abstract: A system operator provisions, or loads, a user's communication device, such as a cable modem, with multiple sets of loopback mode parameters that each facilitate a loopback test, and associates each set with multiple loopback numbers, or variable values. The loopback variables may be MIBs assigned to the device's manufacturer for use in initiating a loopback test of a user device. An operator may initiate a loopback test from a central computer device located remotely from the user device. The initiating device may be coupled to an operator's private IP network, or to a network coupled to the user device. The initiating device sends one of the loopback values in a SIP Invite message to the user device, without the use of SIP extensions, in a call. The user device recognizes the loopback value, auto-answers the call, and performs actions according to the provisioned parameters corresponding to the loopback value.

Abstract: A method adds a MAC address per line for a multiline EMTA. After the EMTA initializes, the method creates “Virtual MTA” instances corresponding to each analog line/MAC address. The method facilitates MTA emulation of each of the Virtual MTA instances. For each virtual EMTA line, the emulation method includes acquiring an IP address via DHCP and acquiring a configuration file via TFTP for each virtual MTA instance.

Abstract: An integrated user device couples to a user's telephone network, and to multiple service provider networks. A local interface port couples to a local device. When service is transferred from an old provider to a new provider, a message is received at the integrated user device. Processing circuitry in the user device processes the message and causes switching components in the user device to decouple the telephone network from the old service provider's network and to couple to the new provider's network. The message may be received from the new provider's network or from the local interface port. The message may be an SNMP MIB, a ring signal or a command line interface message; delivery may be via DOCSIS, PacketCable, SIP, or other method. The switching processing components may include relay coils in an alternating arrangement coupled to a source node and to separate relay driver pins of a SLIC.

Abstract: A SIP proxy server embedded in a cable modem or other SIP user device coupled to a cable modem or similar network interface device processes SIP messages associated with SIP communication sessions. The SIP proxy server instructs a QoS manager client, typically also embedded in the cable modem, to communicate with a corresponding QoS manager client at the CMTS. In response to the instruction from the SIP proxy server, the QoS managers cooperate to establish a requested amount of bandwidth to the SIP session. The amount of bandwidth is typically requested in initial SIP set up messaging.

Abstract: An induced loss value is retrieved from a configuration file of an MTA device. The loss value is provided to a signal generator that generates call progress/alerting signals and FSK signals in the MTA telephony device. To mitigate the imbalance between incoming voice signal levels and call progress/alerting signals that may occur because the call progress/alerting signals are not generated at a level equal to that of the incoming voice signals, the loss/attenuation amount from the configuration file is used to adjust the levels of the generated call progress/alerting and FSK signals by a corresponding amount before they are attenuated along with the incoming voice signals.

Abstract: A communication protocol specification is divided into subsets of parameters based on patterns established by equipment vendors. A combination of subsets is selected based on parameters and features supported by particular network devices installed in a network. A user interface facilitates convenient creation or modification of a configuration file, which instructs a network device how to format a communication message and what information is to be contained therein. After the configuration file is loaded into a device, it controls software switches in the device such that features and parameters corresponding to the parameters selected with the user interface and controlled by the switches are either enabled or disable based on the parameters selected. Supported parameter combinations for popular equipment may be prestored so that selection with the interface of a particular piece of equipment automatically edits the configuration file according to the features and parameters supported by said equipment.

Abstract: A device examines a configuration file having type, length variables that contain a plurality of file names referring to a corresponding plurality of software images to determine a vendor table having only TLV records containing information related to the device's vendor. Predetermined matching criteria, including device model/revision number, and/or software revision number, for example, are used to determine which record from the vendor table corresponds to the device. A device-MIB referring to the model/revision number is compared to the vendor table TLV. When a matching record having a TLV value equal to the model/revision MIB is found, the filename contained in the record is sent in a request to a file server which downloads to the requesting device the file corresponding to the filename. The device installs the downloaded filename and reboots, loading the new software.

Abstract: A user interface accesses a storage device and allows a user to change telephony features in a system that provides telephony service over IP. A user logs in to an MTA of a telephony terminal and chooses which features to change and which options associated with the chosen feature(s) is to be selected. The features may apply to incoming call features, such as ring cadence, and outgoing features, such as call blocking.