PSAP Boundary DB discussion ESQK Use and allocation discussion Use of multiple keys to support routing and ALI query was discussed and is generally supportable. Signaling flow based on above discussions Client-ID discussion Call Server to ESGW, related to routing key discussion. Call Server to LGS/LGW Default call routing Migration steps to i3 Location information on day one (with LIS) may not be MSAG valid unless there is a local process in place This would not be an i2 solution. Maybe i1.5 If the address isn't MSAG validated, send geodetic coordinates for those PSAP's that can accept that type of information. Terminology Based on slide 8 in Martin's chart deck Location Information Server = LIS VoIP Positioning Center = VPC Emergency Services Gateway = ESGW User Agent to Proxy = V1 Proxy to VPC = V2 LIS to VPC = V3 Proxy to ESGW V4 LIS to UA = V0 Work Items: MSAG Validation methods and process Discussion ensued regarding validation of information down to the room level. Brian explained his theory. The new MSAG should support room, floor information from day one. It may not be implemented although it depends on the operational issues. When changes occur, there needs to be a process that provides a method for the MSAG data changes to be changed in the LIS. MSAG access and database changes shouldn't be a problem if the number of VPC and LIS is low (Ric Atkins) Should (does) i2 support VoIP users worldwide MSAG copy to limited number of authorities is OK (Ric Atkins) There were no specific objections to this however, it requires a service provider model. Ric also stated that his costs would increase if he allowed the MSAG data to be published. If the consolidation of a central MSAG database began 1/1/2005, is was speculated that a good portion of the US could be covered in a 12 month period of time. Public database for the purposes of MSAG validation and Private db for routing. Brian's idea. Generally acceptable principle. How are validation errors handled? How are errors corrected in the LIS? Who is responsible for making corrections? Brian/Intrado/Telcordia/Marc, Harris County/Roger, TCS will deal with MSAG issue. Document the public/private MSAG access method and process. Database creation. Location will be delivered via DHCP when there is no other method for location determination. DHCP server will query the LIS to populate the location fields. Location may be determined by multiple sources so, we need to document the process for dealing with these sources. Henning/Brian/Intrado/Telcordia, document the architecture as far as interfaces and protocols. Nadine can identify and document the definitions for the overall solution in the VoIP world. Martin Dawson/Martin Dolly, ATT will identify protocol related issues. Detailed parameters for procols. Need a timeline for various deliverables (Mark Lewis) Location object discussion. Can i2 make use (or move to) the PIDF-LO location object? Client ID discussion - uses of a specific Client ID, Call reporting, trace, etc. Unique, unstructured, key may require structure V4 interface typically SIP based V2 interface Martin/Patti/Carl/Roger There can be implementations where the VPC has SIP functionality and models V3 interface https/xml? Martin Dawson, Patti Intrado/Brian/Henning/Telcordia/TCS/ATT working on the V interfaces defining the signaling. April 29th notes ------------- " Structure and interdependencies of documents o Documentation map. o Assign to Mark Lewis " ESQK allocation and formatting, Congestion control and default conventions o Focus group and prime to be allocated " Callback numbers o How to deal with callbacks for "non-dialable" devices? o An issue for i2? o If callback always provided over E2 - PSAP auto callback interface "button" doesn't function. OK or not? o Out of area callback numbers not always deliverable over CAMA anyway. " SS7 signaling NENA alignment o Further discussion on need for focus group " Expected feature interactions for SIP clients o Further discussion on need for focus group " Requirements document => coverage o Plan a dedicated session to review the requirements document as a team. " Next meeting time? o Suggestion to use conference room at NENA nat'l conference in June. Action: Mark L to request facility and schedule. ---------- MSAG validation discussion - Could have the street level data be MSAG validated but not floor and room information. Would PSAPs allow for non validated MSAG data be presented at the PSAPs? - Brian is talking about having a new MSAG database which has level of data that goes deeper than what is happening today. Wants to provide more details such as floor and room in the MSAG. - If you store anything in the LIS which has routing information (e.g., PSAP boundary), then you need to make sure that data is correct. - Debate on whether routing information should be pushed all the way down to the LIS. - If there is one VPC in the country, the VPC will have to PSAP routing data for the whole country. - Big discussion is about the MSAG being available publicly to any one that wants it. One proposal was having a clearing house that would have all the MSAG. Maybe all the MSAGs would be provided to a provider and the provider maintains this data for any VoIP provider. - Big discussion happening on whether routing information is available in the LIS or the VPC? - Brian is proposing a DNS solution, LIS sends its LO to DNS server and if address is present in the DNS it is considered to be validated. - PSAPs seem to be OK with publishing their MSAG data as long as it does not include routing data. - So they are thinking about one provider who would responsible for getting MSAG data from the different PSAPs and make this data available publicly in a DNS database. - Brian will lead a sub group on MSAG Agreement - - V0 is DHCP. Use DHCP to send LO to UA. How DHCP server does this is implementation dependent. - V3 would be needed if LO was provided when call server queried the VPC. - There might be multiple Los present in a call. Wireless triangulation provided one position and DHCP provided another static position, which one is used and how is that decided? - Telcordia has been nominated to work on the architecture document that talks about the various "V" interfaces, and talk about what the different location objects and elements that need to be sent look like. Nadine will work on defining the objects. What are the different objects. Look at Martin diagram 8. She will be responsible for the final architecture. - LO - will it be pidf-lo? - Client ID is still not defined in terms of what it looks like. Client iD is unique, unstructured, - more than one way to do it. It needs to do tracking and will need to do keying. The key has to be structured, the tracking component need not be structured. - Will XML be used as the query interface for V2 traveling over https? - Martin and Patti will work on V2 and v3. - V4 will be SIP