1 / 13

draft-ietf-sipping-location-requirements-00

draft-ietf-sipping-location-requirements-00. James M. Polk Brian Rosen March 3 rd , 2004 IETF 59 [Seoul]. Review of effort. ID is for Location Conveyance in SIP 2 scenarios are presented: User to User Location Conveyance no known open issues Emergency Calls

tonymartinez
Download Presentation

draft-ietf-sipping-location-requirements-00

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-ietf-sipping-location-requirements-00 James M. Polk Brian Rosen March 3rd, 2004 IETF 59 [Seoul]

  2. Review of effort • ID is for Location Conveyance in SIP • 2 scenarios are presented: • User to User Location Conveyance • no known open issues • Emergency Calls • Where location of UAC determines routing of the call set-up

  3. Solved issues since last meeting [1] • Location SHOULD always be transmitted, even if not considered reliable.

  4. Solved issues since last meeting [2] • UACs SHOULD be able to inform the ERC if it considers the location info "probably wrong". • should a flag saying this LI is probably wrong be included? (This could be a listed open item)

  5. Solved issues since last meeting [3] • In the situation of a VPN, the UA SHOULD keep the first DHCP Location Reply, and not the one sent in the VPN set-up

  6. Solved issues since last meeting [4] • Requirement to indicate in the INVITE where the LI came from (GPS, Cell Tower Triangulation, WiFi, DHCP, manual entry as examples). And possibly include all LI that is available/known

  7. Solved issues since last meeting [5] • Use TLS in emergency calls (eliminates the issue of self signed certs and S/MIME for the LI), and use S/MIME in non-emergency location conveyance between UAs • Addresses the discussion on “header vs. body” • Proxies are for routing messages, and it’s not known which Proxy does this routing

  8. Not solved issues since last meeting [1] • Requirement to allow ERCs to do "after the fact" investigation on why a location was provided (that ended up being wrong).

  9. Not solved issues since last meeting [2] • MUST be able to validate a civil loc against an MSAG entry (MSAG = Master Street Address Guide used in North America) • The catch: North American PSAPs will accept the call even without this verification • Perhaps making this requirement moot

  10. Not solved issues since last meeting [3] • Proxies SHOULD be able to insert Location into an emergency call in a multipart body or return an LO in a Redirect Response • Inserting message body parts is an open SIP debate • Alternate could be to use a Redirect model only

  11. New Open Issues from list [1] • surprised a requirement doesn't exist for a self signed cert for S/MIME? Current status - Not sure if this Requirement should be MUST, SHOULD or MAY (or even mentioned, but not disallowed)

  12. New Open Issues from list [2] • there needs to be a "confidence value" included with the LI in a SIP message. Currently Cell tower triangulation provides this, and aren't sure how many other technologies do

  13. What’s coming with this effort • Rev ID based on comments here and the list [4/04] • Morph ID to include a solution [maybe in the 4/04 rev, definitely before SD] • Goal to have effort ready for WGLC post San Diego [~9/04]

More Related