TEXT   24

april28 notes

Guest on 24th May 2022 02:29:42 PM

  1. PSAP Boundary DB discussion
  3. ESQK Use and allocation discussion
  5. Use of multiple keys to support routing and ALI query was discussed and
  6. is generally supportable.
  9. Signaling flow based on above discussions
  11. Client-ID discussion
  13. Call Server to ESGW, related to routing key discussion.
  15. Call Server to LGS/LGW
  17. Default call routing
  19. Migration steps to i3
  21. Location information on day one (with LIS) may not be MSAG valid unless
  22. there is a local process in place
  24. This would not be an i2 solution. Maybe i1.5
  26. If the address isn't MSAG validated, send geodetic coordinates for those
  27. PSAP's that can accept that type of information.
  30. Terminology
  32. Based on slide 8 in Martin's chart deck
  34. Location Information Server = LIS
  36. VoIP Positioning Center = VPC
  38. Emergency Services Gateway = ESGW
  40. User Agent to Proxy  = V1
  42. Proxy to VPC = V2
  44. LIS to VPC = V3
  46. Proxy to ESGW V4
  48. LIS to UA = V0
  52. Work Items:
  54. MSAG Validation methods and process
  56. Discussion ensued regarding validation of information down to the room
  57. level. Brian explained his theory.
  59. The new MSAG should support room, floor information from day one. It may
  60. not be implemented although it depends on the operational issues.
  62. When changes occur, there needs to be a process that provides a method
  63. for the MSAG data changes to be changed in the LIS.
  65. MSAG access and database changes shouldn't be a problem if the number of
  66. VPC and LIS is low (Ric Atkins)
  68. Should (does) i2 support VoIP users worldwide
  70. MSAG copy to limited number of authorities is OK (Ric Atkins) There were
  71. no specific objections to this however, it requires a service provider
  72. model. Ric also stated that his costs would increase if he allowed the
  73. MSAG data to be published.
  75. If the consolidation of a central MSAG database began 1/1/2005, is was
  76. speculated that a good portion of the US could be covered in a 12 month
  77. period of time.
  79. Public database for the purposes of MSAG validation and Private db for
  80. routing. Brian's idea. Generally acceptable principle.
  82. How are validation errors handled?
  83. How are errors corrected in the LIS?
  84. Who is responsible for making corrections?
  87. Brian/Intrado/Telcordia/Marc, Harris County/Roger, TCS will deal with
  88. MSAG issue. Document the public/private MSAG access method and process.
  89. Database creation.
  91. Location will be delivered via DHCP when there is no other method for
  92. location determination. DHCP server will query the LIS to populate the
  93. location fields.
  95. Location may be determined by multiple sources so, we need to document
  96. the process for dealing with these sources.
  98. Henning/Brian/Intrado/Telcordia, document the architecture as far as
  99. interfaces and protocols. Nadine can identify and document the
  100. definitions for the overall solution in the VoIP world.
  102. Martin Dawson/Martin Dolly, ATT will identify protocol related issues.
  103. Detailed parameters for procols.
  105. Need a timeline for various deliverables (Mark Lewis)
  107. Location object discussion. Can i2 make use (or move to) the PIDF-LO
  108. location object?
  110. Client ID discussion - uses of a specific Client ID, Call reporting,
  111. trace, etc.
  113. Unique, unstructured, key may require structure
  115. V4 interface typically SIP based
  117. V2 interface Martin/Patti/Carl/Roger There can be implementations where
  118. the VPC has SIP functionality and models
  120. V3 interface https/xml? Martin Dawson, Patti
  122. Intrado/Brian/Henning/Telcordia/TCS/ATT working on the V interfaces
  123. defining the signaling.
  125. April 29th notes
  127. -------------
  130. "   Structure and interdependencies of documents
  131. o   Documentation map.
  132. o   Assign to Mark Lewis
  133. "   ESQK allocation and formatting, Congestion control and default conventions
  134. o   Focus group and prime to be allocated
  135. "   Callback numbers
  136. o   How to deal with callbacks for "non-dialable" devices?
  137. o   An issue for i2?
  138. o   If callback always provided over E2 - PSAP auto callback interface
  139. "button" doesn't function. OK or not?
  140. o   Out of area callback numbers not always deliverable over CAMA anyway.
  141. "   SS7 signaling NENA alignment
  142. o   Further discussion on need for focus group
  143. "   Expected feature interactions for SIP clients
  144. o   Further discussion on need for focus group
  145. "   Requirements document => coverage
  146. o   Plan a dedicated session to review the requirements document as a team.
  147. "   Next meeting time?
  148. o   Suggestion to use conference room at NENA nat'l conference in June.
  149. Action: Mark L to request facility and schedule.
  152. ----------
  154. MSAG validation discussion
  155. - Could have the street level data be MSAG validated but not floor and
  156. room information. Would PSAPs allow for non validated MSAG data be
  157. presented at the PSAPs?
  159. - Brian is talking about having a new MSAG database which has level of
  160. data that goes deeper than what is happening today. Wants to provide
  161. more details such as floor and room in the MSAG.
  163. - If you store anything in the LIS which has routing information (e.g.,
  164. PSAP boundary), then you need to make sure that data is correct.
  166. - Debate on whether routing information should be pushed all the way
  167. down to the LIS.
  168. - If there is one VPC in the country, the VPC will have to PSAP routing
  169. data for the whole country.
  170. - Big discussion is about the MSAG being available publicly to any one
  171. that wants it. One proposal was having a clearing house that would have
  172. all the MSAG. Maybe all the MSAGs would be provided to a provider and
  173. the provider maintains this data for any VoIP provider.
  175. - Big discussion happening on whether routing information is available
  176. in the LIS or the VPC?
  177. - Brian is proposing a DNS solution, LIS sends its LO to DNS server and
  178. if address is present in the DNS it is considered to be validated.
  180. - PSAPs seem to be OK with publishing their MSAG data as long as it does
  181. not include routing data.
  182. - So they are thinking about one provider who would responsible for
  183. getting MSAG data from the different PSAPs and make this data available
  184. publicly in a DNS database.
  186. - Brian will lead a sub group on MSAG
  187. Agreement -
  188. - V0 is DHCP. Use DHCP to send LO to UA. How DHCP server does this is
  189. implementation dependent.
  190. - V3 would be needed if LO was provided when call server queried the VPC.
  191. - There might be multiple Los present in a call. Wireless triangulation
  192. provided one position and DHCP provided another static position, which
  193. one is used and how is that decided?
  195. - Telcordia has been nominated to work on the architecture document that
  196. talks about the various "V" interfaces, and talk about what the
  197. different location objects and elements that need to be sent look like.
  198. Nadine will work on defining the objects. What are the different
  199. objects. Look at Martin diagram 8. She will be responsible for the final architecture.
  201. - LO - will it be pidf-lo?
  202. - Client ID is still not defined in terms of what it looks like. Client
  203. iD is unique, unstructured, - more than one way to do it. It needs to do
  204. tracking and will need to do keying. The key has to be structured, the
  205. tracking component need not be structured.
  207. - Will XML be used as the query interface for V2 traveling over https?
  208. - Martin and Patti will work on V2 and v3.
  209. - V4 will be SIP

Raw Paste

Login or Register to edit or fork this paste. It's free.