Abstract: An emergency call handling system can route an emergency call received from a caller to an appropriate public safety answering point (PSAP) and provide the PSAP with an emergency response location (ERL) of the caller. The ERL of the caller can include, in addition to a civic address, floor, wing, sector, room, etc., information associated with the caller. The system can include a location information server (LIS) for obtaining and storing the ERLs associated with the callers. A network element, to which the caller's phone is connected, can be configured to store the location information of the caller's phone. The LIS can be configured to store a validated civic address of the network element and obtain the location information of the phone dynamically from the network element. The LIS can then combine the civic address of the network element with the location information of the network element to determine a complete ERL of the caller.

Abstract: An emergency call handling system can provide emergency call routing and processing that compliments or modifies the routing and processing provided by conventional enhanced 911 (E-911) and next generation 911 (NG-911) systems. Both the routing and processing can be based on rule sets detailed in emergency call handling profiles (ECHPs). Any entity (e.g., SIP servers, switches, terminals, etc.) within the system can process and route the emergency call by executing the rule sets within the ECHPs associated with the call. The ECHPs are delivered to the entities within the system by value or by reference. A SIP server, e.g., may execute all or a subset of the rule set, and may communicate with an application server to execute other subsets of the rule set.

Abstract: In a VoIP system, a method and apparatus for tracking emergency callers is provided. A VoIP service provider network includes a plurality of VoIP phones and is connected to an emergency service provider system. The emergency service provider system includes a call server connected to the VoIP service provider network; a subscriber database; a VPC SBC; and a media gateway for connection to a PSTN. The call server is adapted to receive an emergency call from a VoIP telephone in the VoIP network; verify if the SIP URI has a DID bound to the SIP URI; if the SIP URI does not have a DID bound to the SIP URI, obtain a temporary DID from a DID pool and temporarily bind the temporary DID to the SIP URI; and forward the call to an appropriate PSAP in the PSTN. Should the emergency call be dropped, a person at the PSAP can call back the emergency caller without unnecessary delays.

Abstract: An emergency call handling system can provide emergency call routing and processing that compliments or modifies the routing and processing provided by conventional enhanced 911 (E-911) and next generation 911 (NG-911) systems. Both the routing and processing can be based on rule sets detailed in emergency call handling profiles (ECHPs). Any entity (e.g., SIP servers, switches, terminals, etc.) within the system can process and route the emergency call by executing the rule sets within the ECHPs associated with the call. The ECHPs are delivered to the entities within the system by value or by reference. A SIP server, e.g., may execute all or a subset of the rule set, and may communicate with an application server to execute other subsets of the rule set.

Abstract: An emergency call handling system can provide emergency call routing and processing that compliments or modifies the routing and processing provided by conventional enhanced 911 (E-911) and next generation 911 (NG-911) systems. Both the routing and processing can be based on rule sets detailed in emergency call handling profiles (ECHPs). Any entity (e.g., SIP servers, switches, terminals, etc.) within the system can process and route the emergency call by executing the rule sets within the ECHPs associated with the call. The ECHPs are delivered to the entities within the system by value or by reference. A SIP server, e.g., may execute all or a subset of the rule set, and may communicate with an application server to execute other subsets of the rule set.

Abstract: In a VoIP system, a method and apparatus for tracking emergency callers is provided. A VoIP service provider network includes a plurality of VoIP phones and is connected to an emergency service provider system. The emergency service provider system includes a call server connected to the VoIP service provider network; a subscriber database; a VPC SBC; and a media gateway for connection to a PSTN. The call server is adapted to receive an emergency call from a VoIP telephone in the VoIP network; verify if the SIP URI has a DID bound to the SIP URI; if the SIP URI does not have a DID bound to the SIP URI, obtain a temporary DID from a DID pool and temporarily bind the temporary DID to the SIP URI; and forward the call to an appropriate PSAP in the PSTN. Should the emergency call be dropped, a person at the PSAP can call back the emergency caller without unnecessary delays.

Abstract: The invention is a method for performing a soft handoff of a mobile terminal (MT) from a source (BSC) to a target BSC in a telecommunication network. The method further detects a failure at one of the target BSC and the source BSC that handle a call for the MT. Responsive to the detection, the method sends a reset message from one of the target BSC and the source BSC to one of the source BSC and the target BSC. The reset message includes a Source ID for identifying the failed source process if the failure is detected at the source BSC and a Target ID for identifying the failed target process if the failure is detected at the source BSC. Afterwards, the method uses one of the Source ID or the Target ID for tearing down the call at one of the target BSC and the source BSC.

Abstract: A GPRS Support Node (GGSN) has a plurality of user plane (data session) processing units (GTP-Us) for handling data sessions for Mobile Stations (MSs), a plurality of controlling units (GTP-C/s) for controlling the data sessions payloads, and a master data session control unit (GTP-C/m) dispatching data sessions requests to GTP-C/s. When a GTP-U goes down, the GTP-C/m detects the failure. If no spare GTP-U is available, the GTP-C/m removes internal connections related to the failed data sessions, and instructs all the GTP-C/s that controlled data sessions lost on the failed GTP-U to delete the PDP contexts of those sessions, and requests a Route update from the Routing Engine (RE). If a spare GTP-U is available, the GTP-C/m activates the spare GTP-U, and requests every GTP-C/s that controlled data sessions on the failed GTP-U to rebuild these sessions on the spare GTP-U unit. Following completion of the rebuild, it requests a Route update from the RE.

Abstract: A GPRS Support Node (GGSN) has a plurality of slave data session control units (GTP-C/s) for controlling data sessions for Mobile Stations (MSs), a plurality of data sessions payload units (GTP-Us) for supporting routing of data sessions payloads, and a master data session control unit (GTP-C/m) dispatching data sessions requests to GTP-C/s. When a GTP-C/s goes down, the GTP-C/m detects the failure, closes data sessions of the failed GTP-C/s and their corresponding accounting sessions. If a spare control unit is available, the GTP-C/m detects and activates the spare unit with the role and IP address of the failed GTP-C/s. When the GTP-C/m goes down, all the control units are notified, and the least loaded unit is elected for replacing the GTP-C/m. The elected unit is a spare, non-utilized, GTP-C, or one of the slave GTP-C/s, which is activated as the GTP-C/m by rebuilding a GTP-C/m database with information received from remaining GTP-C/s.