draft ietf sipping location requirements 00 n.
Skip this Video
Loading SlideShow in 5 Seconds..
draft-ietf-sipping-location-requirements-00 PowerPoint Presentation
Download Presentation


3 Views Download Presentation
Download Presentation


- - - - - - - - - - - - - - - - - - - - - - - - - - - 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]