Registration status management for endpoint devices

A registration status manager may poll a user device, such as a session initiation protocol (SIP) endpoint device, for a registration state value indicative of its registration state. The registration status manager may receive the registration state value and determine that it indicates a registration state error such as an out-of-service no dial tone (NDT) condition. The registration status manager may determine a possible cause for failure associated with the registration state error. Subsequently, the registration status manager may determine a possible solution associated with the possible cause for failure.

BACKGROUND

System operators and content providers typically provide high-speed Internet services and Voice over Internet Protocol (VoIP) telephony services through a single transmission system. Accordingly, telephony devices such as embedded digital voice adapters (eDVAs) must complete and pass various stages of registration to achieve dial tone. However, devices may lose dial tone for various reasons at any given point in time.

One solution is to have a human service agent troubleshoot and fix an out-of-service device once a user calls in and reports a problem. However, this approach may result in a long downtime for the user and, in some instances, an unacceptably high Mean Time to Repair (MTTR). As a result, the user's experience may be negatively impacted while he or she waits for the human service agent to restore dial tone to the device.

SUMMARY

Some features described herein relate generally to a system that implements a registration status management automation technique for determining whether a telephony device has a dial tone when using Session Initiation Protocol (SIP) and, if a device does not have a dial tone, fixing or otherwise setting up the device so that it may have a dial tone.

In some embodiments, a computing device may poll a user device, such as an SIP endpoint device on an IP Multimedia Subsystem (IMS) network, for its registration state value. The registration state value may be a numeric value indicative of the current registration state of the device. In some instances, the computing device may poll the user device by transmitting a request for the registration state value, such as, for example, an SNMPWALK request and an SNMPGET request.

In some embodiments, the computing device may determine that the received registration state value indicates a registration state error, such as an out-of-service no dial tone (NDT) condition. The computing device may determine a possible cause for failure associated with the registration state error. For example, the computing device may determine that there is a one-to-one correlation between the registration state value and a particular registration state error value. The computing device may determine the possible cause for failure based on a registration state error category associated with the registration state error value. In some arrangements, registration error values may be stored in association with respective registration state error categories in a storage device such as a library of registration state errors.

In some embodiments, the computing device may then determine a possible solution associated with the possible cause for failure. For example, the computing device may access a storage device, such as a library of registration state error solutions, to identify a possible solution stored in association with the possible cause for failure, the registration state error category, or the registration state error value.

In some embodiments, the computing device may execute instructions associated with the possible solution to attempt to correct the registration state error. In some instances, if the executed instructions are successful in correcting the registration state error and bringing the user device to an in-service dial tone condition, the computing device may update the library of registration state error solutions to indicate that the determined possible solution is successful in correcting the determined possible cause for failure. In some instances, the computing device may transmit a message (e.g., text data, image data, audio data, video data) indicative of the possible solution to a user such as a fix agent for use in correcting the registration state error.

This summary is not intended to identify critical or essential features of the disclosures herein, but instead merely summarizes certain features and variations thereof. Other details and features will also be described in the sections that follow.

DETAILED DESCRIPTION

FIG. 1illustrates an example information distribution network100in which many of the various features described herein may be implemented. The illustrated information distribution network is only one example of a network and is not intended to suggest any limitation as to the scope of use or functionality of the disclosure. The illustrated network should not be interpreted as having any dependency or requirement relating to any component or combination of components in an information distribution network.

Network100may be a telecommunications network, a multi-service operator (MSO) network, a cable television (CATV) network, a cellular network, a wireless network, an optical fiber network, a coaxial cable network, a hybrid fiber-coaxial (HFC) network, or any other type of data access or distribution network or combination of networks. In one example, network100may be a digital voice network communicating with multiple session initiation protocol (SIP) endpoint devices, such as SIP endpoint device116in example premise102a(e.g., a home, a business, an institution, etc.). In another example, network100may be a cellular broadband network communicating with multiple communications access points, such as wireless communications tower130, to provide communication signals to devices such as wireless device118(e.g., a mobile phone, a wireless laptop, a tablet computer, a portable gaming device). In another example, network100may be a coaxial system comprising a modem termination system (e.g., a cable mode termination system (CMTS)) communicating with numerous gateway interface devices (e.g., gateway interface device111in example premise102a). In another example, the network100may be a fiber-optic system comprising optical fibers extending from an optical line terminal (OLT) to numerous optical network terminals (ONTs) communicatively coupled with various gateway interface devices. In another example, the network100may be a digital subscriber line (DSL) system that includes local office103communicating with numerous gateway interface devices. In another example, network100may be an HFC network in which Internet traffic is routed over both optical and coaxial communication paths to a gateway interface device in or near a user's premise. Various aspects of the disclosure may operate on one or more of the networks described herein or any other network architectures now known or later developed.

Network100may use a series of interconnected communication links101(e.g., coaxial cables, optical fibers, wireless links, etc.) to connect premises such as premises102or other user environments to local office103. Communication links101may include any wired communication links, wireless communication links, communications networks, or combinations thereof. For example, portions of communication links101may be implemented with fiber-optic cable, while other portions of communication links101may be implemented with coaxial cable. Communication links101may also include various communications components such as splitters, filters, amplifiers, wireless components, and other components for communicating data. Data may include, for example, internet data, voice data, weather data, media content, and any other information. Media content may include, for example, video content, audio content, media on demand, video on demand, streaming video, television programs, text listings, graphics, advertisements, and other content.

Local office103may transmit downstream information signals onto communication links101, and premises such as premises102may receive and process those signals. In certain implementations, communication links101may originate from local office103as a single communications path, and may be split into any number of communication links to distribute data to premises102and various other destinations. Although the term premise is used by way of example, premises102may include any type of user environment, such as single family homes, apartment complexes, businesses, schools, hospitals, parks, and other environments and combinations of environments.

Local office103may include interface104, which may be a computing device configured to manage communications between devices on the network of communication links101and backend devices, such as server105, server106, and server107. For example, interface104may be a cable modem termination system (CMTS). The termination system may be as specified in a standard, such as, in an example of an HFC-type network, the Data Over Cable Service Interface Specification (DOCSIS) standard, published by Cable Television Laboratories, Inc. The termination system may be configured to transmit data over one or more downstream channels or frequencies to be received by various devices, such as modems in premises102(e.g., homes, businesses, institutions, etc.), and to receive upstream communications from those modems on one or more upstream frequencies.

Local office103may include one or more network interfaces108for communicating with one or more external networks109. One or more external networks109may include, for example, one or more telecommunications networks, Internet Protocol networks, cellular communications networks (e.g., Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), and any other 2nd, 3rd, 4th and higher generation cellular communications networks), cellular broadband networks, radio access networks, fiber-optic networks, local wireless networks (e.g., Wi-Fi, WiMAX), satellite networks, and any other networks or combinations of networks.

Local office103may include a variety of servers that may be configured to perform various functions. Local office103may include one or more push servers105for generating push notifications to deliver data, instructions, or both to devices that are configured to detect such notifications. Local office103may include one or more content servers106configured to provide content (e.g., media content) to devices. Local office103may include one or more application servers107.

Premises102such as premise102amay include an interface120, which may include modem device110, for communicating on communication links101with local office103, one or more external networks109, or both. For example, modem device110may be a coaxial cable modem (for coaxial cable links101), a broadband modem (for DSL links101), a fiber interface node (for fiber-optic links101), or any other device or combination of devices. In another example, modem device110may be an embedded multimedia terminal adapter (eMTA) comprising a cable modem and a multimedia adapter (MTA), such as a Voice over IP (VoIP) adapter. In certain implementations, modem device110may be a part of, or communicatively coupled to, gateway interface device111. Gateway111may be, for example, a wireless router, a set-top box, a computer server, or any other computing device or combination.

Gateway interface device111may be any computing device for communicating with modem device110to allow one or more other devices in example premise102ato communicate with local office103, one or more external networks109, or other devices communicatively coupled thereto. Gateway111may include local network interfaces to provide communication signals to client devices in or near example premise102a, such as television112, set-top box113, personal computer114, laptop computer115, SIP endpoint device116, wireless device117(e.g., a wireless laptop, a tablet computer, a mobile phone, a portable gaming device), a vehicular computing system (e.g., a mobile computing system, navigation system, or entertainment system in an automobile, marine vessel, or aircraft) and any other device.

FIG. 2illustrates general hardware elements and software elements that can be used to implement any of the various computing devices and/or software discussed herein. Device200may include one or more processors201, which may execute instructions of a computer program to perform any of the functions and steps described herein. The instructions may be stored in any type of computer-readable medium or memory to configure the operation of the processor201. For example, instructions may be stored in a read-only memory (ROM)202, random access memory (RAM)203, removable media204, such as a Universal Serial Bus (USB) drive, compact disk (CD) or digital versatile disk (DVD), hard drive, floppy disk drive, or any other desired electronic storage medium. Instructions may also be stored in hard drive205, which may be an internal or external hard drive.

Device200may include one or more output devices, such as a display206(e.g., external monitor, television), and may include one or more output device controllers207, such as a video processor. In some embodiments, device200may include one or more user input devices208, such as a remote control, keyboard, mouse, touch screen, microphone, or any other input device.

Device200may also include one or more network interfaces, such as network input/output (I/O) interface210to communicate with an external network209. The network interface may be a wired interface, wireless interface, or a combination of the two. In some embodiments, network I/O interface210may include a cable modem, and network209may include the communication links101, one or more external networks109, an in-premise network, a provider's wireless, coaxial, fiber, or hybrid fiber/coaxial distribution system (e.g., a DOCSIS network), or any other desired network.

FIG. 3illustrates an example system300for providing registration status management automation. In one aspect, system300may be used to correct out-of-service no dial tone (NDT) conditions on session initiation protocol (SIP) endpoint devices, such as embedded digital voice adapter (eDVA) devices (e.g., “phones” on an IMS network). The various features shown inFIG. 3may be implemented using hardware, software, or both, such as device200, and may be communicatively coupled through one or more communications networks, such as one or more external networks109, via a respective router using any communications links, such as communications links101. For example, IP Multimedia Subsystem (IMS)310and registration status manager320may be communicatively coupled to one or more external networks109, and endpoint devices302a-nmay each be an SIP endpoint device such as device116located in premise102aand communicatively coupled to one or more external networks109through local office103.

In one or more arrangements, system300may support a digital voice network by digitizing voice communications and transmitting data over network109. A digital voice network may be supported by, for example, network100, and may be accessible by users such as subscribers to a service provider or non-subscribing users. In some instances, the components in system300may be communicatively coupled to a Domain Name System (DNS) server, a Dynamic Host Configuration Protocol (DHCP) server, a Trivial File Transfer Protocol (TFTP) server, or any other server or combination of servers through network109for providing one or more of the features described herein.

System300may include one or more endpoint devices302a-n, IP Multimedia Subsystem (IMS)310, and registration status manager320. Endpoint devices302a-nmay include any SIP endpoint devices or eDVA devices (e.g., device116), and may be coupled to network109through a termination system (e.g., interface104). For example, each of endpoint devices302a-nmay be may be an SIP phone capable of transmitting and receiving voice and video communications data, such as phone calls and video chats. In an illustrative example, endpoint devices302a-nmay include devices associated with users of a digital voice service provided by a service provider.

Endpoint devices302a-nmay be configured to store respective registration state values304a-n. Registration state values304a-nmay be, for example, numerical or other values respectively indicative of each of endpoint devices302's registration status (e.g., dial tone, no dial tone). In one example, registration state values may include a series of integer values ranging from “1” to “10” mapped to a particular protocol, such as to DOCSIS and telephony registration states, where values of “1” through “6” correspond to DOCSIS registration states and values of “7” through “10” correspond to telephony registration states. In certain implementations, registration state values304a-nmay be programmed into an SIP protocol stack of an eDVA code stored in endpoint devices302a-n. Registration state information (e.g., registration states and registration state values) will be discussed in further detail with reference toFIG. 4.

Internet Protocol (IP) Multimedia Subsystem (IMS)310may be configured to manage the operations of and services offered by a service provider over a digital voice network supported by network109. IMS310may provide various services and features to endpoint devices302, such as voice communications, voicemail, call forwarding, call waiting, caller identification (ID) and video chat. In one example, IMS310or another server or system may direct voice mail messages to a voice mail server if a device called by one of endpoint devices302is not currently available (e.g., line is busy, no answer, etc.). In another example, IMS310may interact with an IMS feature server to control connection services, select processes or services that may be applied to a call, and provide routing within a network such as network109. In some instances, IMS310may interface with a public switched telephone network (PSTN) for communicating with public switched telephone devices.

Registration status manager320may be a computing device that includes hardware and/or software for identifying and correcting registration state errors (e.g., out-of-service NDT conditions) on endpoint devices302, thereby providing service (e.g., dial tone) to users or subscribers respectively associated with those devices. Registration status manager320may be implemented using, for example, one or more computing devices such as application servers, database servers, or other devices or combinations of devices. In one example, registration status manager320may be partially or wholly included in an application point of presence (APOP) data center. In some embodiments, registration status manager320may include one or more processors and memory that includes computer executable instructions (e.g., coded in the Ruby programming language) and other information that, when executed by the one or more processors, perform the features of the present disclosure.

Registration status manager320may include, for example, registration status management information base (MIB)322, library of registration state errors324, library of registration state error solutions326, and other computing devices for providing registration status management automation. For example, if it is determined that device302ais stuck in an out-of-service NDT condition based on its registration state value, registration status manager320may process information associated with device302a's registration status value304abased on a series of techniques implemented using registration status MIB322, errors library324and solutions library326for use in bringing device302ato an in-service dial tone condition.

Registration status MIB322may be, for example, a storage device or database for managing the registration statuses of endpoint devices302. Registration status MIB322may include, for example, user information, address information and registration status information. User information may include, for example, billing information, account numbers, (PSTN) telephone numbers, e-mail addresses, subscription information, subscription levels, subscription statuses, user preferences, and other information respectively associated with the users or subscribers of endpoint devices302. Address information may include, for example, unique identifiers (UIDs) such as internet protocol (IP) addresses, media access control (MAC) addresses, fully qualified domain names (FQDNs), international mobile subscriber identity (IMSI) numbers, and other information respectively associated with endpoint devices302. Registration status information may include, for example, information associated with the registration states of endpoint devices302, such as respective registration state values and the dates and times at which they were stored, transmitted, or received. Registration status MIB322and examples of information stored therein will be described in further detail with reference toFIG. 5.

Library of registration state errors324may be, for example, a storage device or database for use in identifying registration state errors associated with the registration state values304received from endpoint devices302. Errors library324may include, for example, registration state error information such as registration state error values, registration state error categories, possible causes for failure, and other information respectively associated with various registration state errors. Errors library324and examples of information stored therein will be described in further detail with reference toFIG. 6.

Library of registration state error solutions326may be, for example, a storage device or database for use in determining solutions to particular registration state errors or error categories stored in errors library324. Solutions library326may include, for example, registration state error solution information such as possible solutions to the possible causes for failure associated with various registration state errors. For example, each registration state error category may be associated with a specific set of computer executable instructions for use by registration status manager320and, in some instances, other instructions (e.g., text, images, audio, videos) for use by users such as fix agents. Solutions library326and examples of information stored therein will be described in further detail with reference toFIG. 7.

In some embodiments, registration status manager320may perform registration status management automation by monitoring the registration states and availabilities of each of endpoint devices302. For example, registration status manager320may poll endpoint devices302for their registration state values304by transmitting, using Simple Mail Transfer Protocol (SNMP), an SNMPWALK request and an SNMPGET request to each of endpoint devices302requesting that they perform a SNMPWALK/SNMPGET procedure against their respective registration state values304. In certain implementations, registration status manager320may poll endpoint devices302using Hypertext Transfer Protocol (HTTP) commands or data transmissions associated with any other protocol. In response to the transmission, each of endpoint devices302may transmit their respective registration state value304to registration status manager320or an intermediate computing device communicatively coupled to registration status manager320. Registration status manager320may receive the registration state values304and store them in a storage device such as registration status MIB322.

In some embodiments, registration status manager320may determine registration state errors for devices in an out-of-service NDT condition based on the received registration state values. For example, registration status manager320may determine that one or more of the received registration state values are associated with a registration state error by, for example, determining that the one or more received registration state values are not indicative of an in-service dial tone condition. In an example of DOCSIS and PacketCable telephony registration states with values ranging from “1” to “10,” where the value of “10” corresponds to an in-service dial tone condition, endpoint devices with registration state values of “1” through “9” may be identified as having registration state errors because, in some instances, they may be stuck in an out-of-service NDT condition.

In some embodiments, registration status manager320may identify registration state error categories and determine possible causes for failure associated with the identified registration state errors. In an example, registration status manager320may determine whether a registration state value is associated with a registration state error value indicative of a particular registration state error category stored in errors library324based on, for example, a one-to-one correlation or mapping. For example, registration status manager320may determine that registration state values of “7,” “8,” and “9” correlate to registration state error values of “7,” “8,” and “9,” respectively, which may be respectively associated with the error categories of “telephony-DHCP,” “telephony-TFTP,” and “telephony-RegWithCallServer.”

In some embodiments, registration status manager320may determine a possible cause for failure from among multiple possible causes for failure. In an example, registration status manager320may determine that registration state value304acorrelates to multiple possible causes for failure and determine a particular possible cause for failure based on account information (e.g., service levels, software, firmware, etc.) associated with endpoint device302a. For example, registration status manager320may receive account information associated with device302aand reset device302aor perform a predetermined action that might help initiate a fix based on, for example, a service level associated with device302a, such as a subscription to a high or low bandwidth service. In another example, registration status manager320may perform a predetermined action that might help initiate a fix based on the particular software or firmware stored in device302a. For example, a firmware version stored in device302amay have a known possible cause for failure and may be associated with a known solution for fixing registration state errors that may result from the known possible cause for failure.

In some embodiments, registration status manager320may determine possible solutions associated with the determined possible causes for failure for use in correcting the registration state errors. For example, registration status manager320may determine whether a determined registration state error value or category correlates with a possible solution stored in solutions library326based on, for example, a one-to-one correlation or mapping. For example, registration status manager320may determine that registration state error values of “7,” “8,” and “9” correlate to the possible solutions “re-provision and reset the device,” “correct bootfile, routing or check file on the TFTP server,” and “activate correctly in billing and reset the device,” respectively.

In some embodiments, registration status manager320may process the determined possible solutions for use in correcting the registration state errors. For example, registration status manager320may execute instructions associated with a possible solution (e.g., “re-provision and reset the device”) to attempt to correct one or more devices associated with a common registration state error category. If the possible solution is successful in transitioning a device to an in-service dial tone condition, registration status manager320may update solutions library326to indicate that the solution was successful. If the possible solution is not successful in correcting the registration state error, registration status manager320may transmit a message including instructions (e.g., text, images, audio, video) to a fix agent for further remediation or troubleshooting. In certain implementations, if the fix agent identifies a possible solution or determines a solution that is successful in correcting the registration state error, the fix agent may update solutions library326with computer executable instructions corresponding to the possible solution or the successful solution using an input device such as input device208.

In some embodiments, registration status manager320may provide the ability to monitor for trends and root causes of registration state errors. Registration status manager320may also build a report for future use so that the root cause of the registration state errors can be addressed. For example, after identifying the specific registration state errors associated with each of endpoint devices302, registration status manager320may generate a report, such as a comma-separated values (csv) file or a spreadsheet file, that groups the devices into defined registration state error categories. Registration status manager320may store the report in registration status MIB322for use in applying common solutions to devices stuck in common registration state errors or for use in identifying larger systemic problems. In certain implementations, registration status manager320may update the report by performing the registration status management automation at a predetermined or regularly scheduled interval (e.g., once a day, every two seconds, etc.), or on-demand for as-needed fixes. In some instances, the report may be used in a root cause analysis for determining the possible causes for failure associated with the registration state errors.

FIG. 4illustrates example registration state information400that may be stored in an SIP endpoint device (e.g., endpoint device302) as it transitions through various stages of registration to achieve dial tone. As shown inFIG. 4, each registration state may be respectively associated with a registration state description in field401and a registration state value in field402.

Registration states, which, in one embodiment, are DOCSIS registration states411(e.g., “docsis-DownstreamScanning” having a registration state value of “1”),412(e.g., “docsis-DownstreamRanging” having a registration state value of “2”),413(e.g., “docsis-UpstreamRanging” having a registration state value of “3”),414(e.g., “docsis-DHCP” having a registration state value of “4”),415(e.g., “docsis-TFTP” having a registration state value of “5”) and416(e.g., “doscis-DataRegComplete” having a registration state value of “6”) may correspond to DOCSIS registration states. An SIP endpoint device302may progress through registration states411,412,413,414,415and416after connecting to the radio frequency (RF) interface of the cable modem termination system (e.g., interface104).

Registration states417(e.g., “telephony-DHCP” having a registration state value of “7”),418(e.g., “telephony-TFTP” having a registration state value of “8”),419(e.g., “telephony-RegWithCallServer” having a registration state value of “9”) and420(e.g., “telephony-RegComplete” having a registration state value of “10”) may correspond to telephony registration states. The endpoint device may progress through registration states417,418,419, and420as it registers with an IMS core (e.g., IMS301) to achieve dial tone. For example, after completing DOCSIS registration in registration state416, the endpoint device may complete registration with the DHCP server in registration state417, receive files from the TFTP server in registration state418, and register with the IMS core in registration states419and420to achieve dial tone.

As shown inFIG. 4, registration state values beyond a threshold value, such as threshold value430, may correspond to registration state errors. For example, registration states411,412,413,414,415,416,417,418and419having registration state values less than or equal to a predetermined threshold value430of “9” may correspond to SIP endpoint devices having out-of-service NDT conditions. Registration state420having a registration state value greater than the predetermined threshold value430of “9” may correspond to SIP endpoint devices having an in-service dial tone condition (e.g., the device may be fully registered and may have dial tone).

FIG. 5illustrates example information500for a plurality of SIP endpoint devices (e.g., endpoint devices302). Information500may be stored in, for example, a registration status MIB (e.g., MIB322). In some arrangements, information500may be included in a user interface displayed on device200using, for example, display206.

Information500may include user information, address information and registration status information for respective devices in, for example, rows511-520or in any other suitable field, grouping, data structure, or combination thereof. Information500may include, for example, user information in fields501(e.g., “Account Number”),502(e.g., “Telephone Number (TN)”),503(e.g., “Billing Account Status”) and504(e.g., “Billing TN Status”).

Information500may include, for example, address information in fields505(e.g., “Cable Modem IP address”),506(e.g., “Cable Modem MAC Address”) and507(e.g., “Device MAC Address”). It will be understood that the term “Cable Modem” is used by way of illustration and not of limitation and may correspond to any device communicatively coupled between the device and a termination system (e.g., interface104), such as interface120or device.

Information500may include, for example, registration status information in fields508(e.g., “Device Registration State”) and509(e.g., “Device Registration State Value”), which may include the features described with reference to fields401and402, respectively.

In one illustrative example, the registration status manager may receive the user information in fields501,502,503and504in response to accessing a billing database maintained by a service provider. The registration status manager may compare information associated with all devices on the IMS network against the user information and, in some instances, only poll those devices having “Active” billing TN statuses in field504(e.g., rows511-519) for their respective registration status values. The registration status manager may perform no action for devices having “Inactive” billing TN statuses in field504(e.g., row520). The registration status manager may then filter information500to identify any devices having registration status values in field509not equal to “10” (e.g., rows513-518) and apply the corresponding solution codes (e.g., instructions stored in solutions library326) to attempt to fix the devices' out-of-service NDT conditions.

FIG. 6illustrates example information600for use in identifying registration state errors associated with registration state information (e.g., information in fields508and509) received from an SIP endpoint device. Information600may be stored in, for example, a library of registration state errors (e.g., errors library324). In some arrangements, information600may be included in a user interface displayed on device200using, for example, display206. In some arrangements, the one or more possible causes for failure may be determined by the registration status manager, input by a user using an input device such as input device208, or both.

As shown inFIG. 6, each registration state error may be respectively associated with a registration state error category in field601, a registration state error value in field602, and one or more possible causes for failure in field603. For purposes of illustration and not of limitation, the disclosure will focus on out-of-service NDT conditions corresponding to telephony registration states417,418and419.

In some embodiments, an SIP endpoint device may fail the telephony registration process (e.g., registration states417-420) due to a variety of factors, such as incorrect bootfile, incorrect provisioning, incorrect activation method, routing issues do to the TFTP servers, DNS issues, DHCP pool exhaustion (e.g., running out of IP addresses causing the device to be stuck in DHCP), unavailability of a network path (e.g., failure of a communications link), or IMS core issues. For example, as shown in rows611and612, the registration state error category “telephony-DHCP” having the registration state error value “7” may be associated with two possible causes for failure, “PacketCable side not provisioned” and “Does not receive DHCP option122,” respectively. In another example, as shown in rows613,614,615and616, the registration state error category “telephony-TFTP” having the registration state error value “8” may be associated with four possible causes for failure, “Incorrect cable modem or PacketCable bootfile due to mis-provisioning,” “DNS issue with trying to resolve the TFTP server FDQN,” “Routing issue to the TFTP server” and “Absence of file on TFTP server,” respectively. In another example, as shown in row617, the registration state error category “telephony-RegWithCallServer” having the registration state error value “9” may be associated with the possible causes for failure “Billing services not activated correctly for the subscriber.”

FIG. 7illustrates example information700for use in determining possible registration state error solutions associated with registration state error information (e.g., information in fields601,602and603). Information700may be stored in, for example, a library of registration state error solutions (e.g., solutions library326). In some embodiments, fields701,702and703may include the features described with reference to fields601,602, and603, respectively. In some arrangements, information700may be included in a user interface displayed on device200using, for example, display206. In some arrangements, the one or more possible solutions may be determined by the registration status manager, input by a user using an input device such as input device208, or both.

As shown inFIG. 7, each registration state error category may be respectively associated with one or more possible solutions in field704. For example, as shown in rows711and712, the registration state error category “telephony-DHCP” having the registration state error value “7” may be associated with computer executable instructions and other instructions (e.g., text data, image data, audio data, video data for use by fix agents) for performing the possible solution “Re-provision and reset the device.” In another example, as shown in rows713,714,715and716, the registration state error category “telephony-TFTP” having the registration state error value “8” may be associated with computer executable instructions and other instructions for performing the possible solution “Correct bootfile, routing or check file on the TFTP server.” In another example, as shown in row717, the registration state error category “telephony-RegWithCallServer” having the registration state error value “9” may be associated with computer executable instructions and other instructions for performing the possible solution “Activate correctly in billing and reset the device.”

FIG. 8illustrates an example process flow for providing registration status management automation.

At step802, a registration status manager (e.g., registration status manager320) polls one or more SIP endpoint devices (e.g., endpoint devices302a-n) for their registration state values (e.g., values304a-n). For example, the registration status manager may transmit an SNMPWALK request and an SNMPGET request to each of the one or more endpoint devices requesting that they perform a SNMPWALK/SNMPGET procedure against their respective registration state values. Each device's registration state value may be, for example, a numerical value indicative of its current state, e.g., its DOCSIS or telephony registration state as discussed with reference toFIG. 4.

At step804, the registration status manager receives the one or more registration state values associated with the one or more polled devices. In certain implementations, the registration status manager may store the received one or more registration state values in a registration status MIB (e.g., MIB322).

At step806, the registration status manager determines one or more registration state errors based on the one or more registration state values. For example, the registration status manager may determine that one or more of the received registration state values are indicative of a registration state error if they are not indicative of an in-service dial tone condition as discussed with reference toFIG. 3andFIG. 4.

At step808, the registration status manager determines one or more possible causes for failure respectively associated with the one or more registration state errors. For example, the registration status manager may determine that one or more of the received registration state values are associated with one or more registration state error categories and possible causes for failure stored in a storage device (e.g., errors library324) as discussed with reference toFIG. 3andFIG. 6.

At step810, the registration status manager determines one or more possible solutions respectively associated with the one or more possible causes for failure. For example, the registration status manager may determine that the one or more of the possible causes for failure, or error categories associated with the possible causes for failure, are associated with one or more possible solutions stored in a storage device (e.g., solutions library326) as discussed with reference toFIG. 3andFIG. 7.

At step812, the registration status manager executes instructions respectively associated with the one or more possible solutions to attempt to correct the registration state error. For example, the registration status manager may execute instructions stored in a storage device (e.g., solutions library326) and associated with a possible solution to attempt correct one or more devices associated with a common possible cause for failure or registration state error category as discussed with reference toFIG. 3andFIG. 7.

At step814, the registration status manager determines whether the executed instructions are successful in correcting the one or more registration state errors. For example, the registration status manager may determine that the executed instructions are successful in correcting a registration state error if the executed instructions are successful in transitioning a device stuck in an out-of-service NDT condition to an in-service dial tone condition as discussed with reference toFIG. 3. If the executed instructions are successful in correcting the one or more registration state errors, the process may end because the one or more registration state errors have been corrected. If the executed instructions are not successful in correcting the one or more registration state errors, the process may return to step802and repeat because there is at least one registration state error to correct.

With the features described above, various advantages may be achieved. One advantage that may be achieved with the present technique is that the amount of customer service calls from subscribers may decrease as a result of polling for and correcting out-of-service devices before they are noticed by the subscribers. Accordingly, operational costs to the service provider may decrease and, in some instances, subscriber satisfaction and positive user experience may increase.

The various features described above are merely non-limiting examples, and can be rearranged, combined, subdivided, omitted, and/or altered in any desired manner. For example, features of the servers can be subdivided among multiple processors and computing devices. The true scope of this patent should only be defined by the claims that follow.