White Paper - Emergency Call Handling in VoIP Networks
Locating the Caller (continued)
Many subscribers in a fixed network VoIP solution will use DSL technology. The best time to record the data for VoIP users is when they get authenticated for IP services, typically with their ISP.
The subscriber uses a port on the DSL DSLAM to gain access. If the name of the DSLAM and the physical port number can be recorded, then by a series of database look-ups the location of the caller can be determined.
There are two potential mechanisms to allow the ISP to discover this information. When the DSLAM has IP connectivity then the "Option 82" in the DHCP exchange can be used to convey the information about DSLAM and the physical port being used to connect to the subscriber back to the ISP. The ISP would record this data in an "open" database so that the ECH service could determine caller location.
For ATM based DSLAMs, which have no real visibility of the IP world, another mechanism can be used, Extended Authentication Protocol (EAP). Here the DSLAM uses a Radius or Diameter interface to pre-authenticate the subscriber, and at this point the data can be captured.
The location information that this provides can be combined with subscriber registration records. This combination will allow the call handling centre to immediately distinguish a roaming call from one made from the registered location.
There are some developments from the IETF in the form of ECRIT - Emergency Context Resolution with Internet Technologies - which outlines various functional requirements, including identification of the emergency caller's location, the use of an emergency identifier to declare a call to be an emergency call, and the mapping function required to route the call to the appropriate Public Safety Answering Point (PSAP).
These mechanisms allow the indirect derivation of user location, but how would it be sent to the ECH centre? The call processing system would ideally append a cross reference in the SIP Invite message that establishes the call, perhaps in the P-Network-Access-Info field, already defined in the IMS specifications from 3GPP and ETSI.
Emergency Call Traffic Management
The first requirement is to support emergency calls at all times, if necessary at the expense of other traffic. In the access layer this is relatively straight forward since there is a limited list of emergency call numbers, so with adequate traffic management capability, emergency calls will always get through. Access session border controllers are already used to enforce traffic policies and can identify ECH as a special case.
An additional challenge is the requirement to prioritise key worker and facility traffic below that of than emergency calls but higher than other calls.
|
IPsec and VoIP
