140 likes | 151 Views
This document discusses the requirements and implementation specifics of conveying location information in SIP. It covers user-agent-to-user-agent and user-agent-to-proxy-server scenarios, including emergency communications. Changes from the previous version, fields for location data, message flow examples, and listed SIP methods for location conveyance are detailed. It also identifies open and new issues for further consideration.
E N D
Location Conveyance in SIP draft-ietf-sipping-location-requirements-01 James M. Polk Brian Rosen 6th August 04
Location Conveyance • Goal is to define SIP as an RFC3693 “Using Protocol” • Incorporate the Geopriv LO into SIP by • adhering to all requirements of 3693 • add necessary requirements unique to SIP for location conveyance
Types of Location Conveyance in SIP • User Agent to User Agent • i.e. person to person • User Agent to Proxy Server • i.e. message routing based on location of User Agent Client (the initiator of a message) • this has one use-case identified: 911/112-type emergency communications
What changed since version -00 Several things changed in this version: • Removed requirements that were to be addressed by Geopriv • Removed requirements Geopriv did not address with the PIDF-LO that were not appropriate in SIP (ex. VPN existing, confidence factor) • Added 34 pages to ID (to 45 now), soooo... • Added a solution set to this effort for review with all “well-formed” SIP messages and message bodies
PIDF-LO as a body part of a SIP Message <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="pres:geotarget@example.com"> <tuple id="sg89ae"> <timestamp>2004-08-03T017:30:00Z</timestamp> <status> <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>US</cl:country> <cl:A1>California</cl:A1> <cl:A3>San Diego</cl:A3> <cl:A6>Harbor Island</cl:A6> <cl:STS>Drive</cl:STS> <cl:HNO>1380</cl:HNO> <cl:NAM>Sheraton San Diego Hotel</cl:NAM> <cl:PC>92101</cl:PC> <cl:civilAddress> <method>dhcp</method> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2004-08-05T17:50:00Z</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> </tuple> </presence> • Specifies up to 25+ fields for civil location • Provides how location was derived • Provides retention and distribution elements
UA-to-UA Location Conveyance in SIP • Identified which SIP Methods were appropriate with message flow examples of usage for each • this included examples of both civil and coordinate PIDF-LOs • and included many counter examples with and without encryption (for reference sake)
UA-to-UA Location Conveyance in SIP • The listed SIP Methods are: • INVITE • PIDF-LO is a multipart MIME body (with SDP when included) • and included how an LO can be in a 200 OK Response • MESSAGE • Some have groaned at another misuse of this Method • But I did include a Content-Disposition (render) in the examples • UPDATE • Might have understated its use • PUBLISH (this section was not completed by deadline) • will add SUBSCRIBE/NOTIFY in the next version based on guidance from SIPPING chair and AD
UA-to-Proxy Location Conveyance in SIP • Identified which SIP Methods were appropriate and gave examples of usage for each • this included examples of both civil and coordinate PIDF-LOs
UA-to-Proxy Location Conveyance in SIP • The listed SIP Methods are: • INVITE • PIDF-LO is a multipart MIME body (with SDP when included) • MESSAGE • Some have groaned at another misuse of this Method • But I did include a Content-Disposition (render) in the example • UPDATE • Might have understated its use • will add SUBSCRIBE/NOTIFY in the next version based on guidance from SIPPING chair and AD
Regarding Other Methods No issues with providing LO in these Methods, just don’t have a use-case yet: • CANCEL • OPTIONS • REFER • ACK • PRACK • BYE
Holdover Open Issues from -00 • Can a PIDF-LO can be inserted by a Proxy? • this one keeps lingering... • If a Proxy knows where the UA is, how can it inform the UA of this and have the UA include this in its next INVITE • a Redirect rule to include when received?
New Open Issues for -01 • How does a UAC request an LO from the UAS (and in a certain format)? • Current choice is through a Presence capability • Should there be a new 4XX for a “bad location” given? • Do we want to address Proxy Assertion of Location? • In the Proxy Routed model, how does a UA update its location prior to a final response, and how does this facilitate a new INVITE to a different endpoint (ERC)?
New Open Issues moving towards -02 • Is “location” by itself considered a dialog parameter? • this affects when to use UPDATE vs. reINVITE • How can a Proxy tell the UAC to add a body the Proxy included in its 4XX Response • This could be a semantic of the 4XX “Bad Location” Response Code if a body is included in that message • which might be also for the case where no location was given
Next Steps - Plans • Revise by end of the month • Solve open issues through discussion and Chair/AD guidance • Looking at WGLC in SIPPING ~ Dec 04 • But... If this effort needs to extend the protocol – it needs to move to SIP first and it will take more time