60 likes | 186 Views
Additional Data related to an Emergency Call. draft-ietf-ecrit-additional-data-00.txt Hannes Tschofenig Brian Rosen. Fundamental Idea. Devices and services providers have data useful to PSAPs
E N D
Additional Data related to an Emergency Call draft-ietf-ecrit-additional-data-00.txt HannesTschofenig Brian Rosen
Fundamental Idea • Devices and services providers have data useful to PSAPs • Examples of data include identification & contact data of SP, subscriber data, “class of service” provided by SP to subscriber • Draft seeks to standardize the form of this data, and how it’s transported; • Re-uses the work done in the NENA additional data working group!
Transport • HTTPS GET of an XML structure defined by this document • URI to the XML carried in a SIP Call-Info header • Device or any/all SPs in the path could add such a header • Questions: • Security protection: signing data? • Do we need to bind the data to the SIP session?
Data itself • Draft lists several kinds of data and the fields for each as if it was a completely new XML schema • List discussion suggests using mime/multipart with a mime description of each “kind” • As an example, SP and subscriber “contact” data is in vcard form, so use mime/vcard • New mime types would be required for some of the data where there is no existing mime type
Problem: Multiple MIME Type Instances • How do we deal with, e.g. multiple vcards? • SP has a 24/7 contact which is a vcard • Subscriber name and address is a vcard • Emergency contacts are vcards • What is the mechanism used to identify which of these is which?
What does the HTTP GET return? • What does the outer envelope look like, within which the mime/multipart exists • Related to the first problem – which vcard is which