Location Conveyance in SIP

1. Location Conveyance in SIP draft-ietf-sip-location-conveyance-01 James M. Polk Brian Rosen 2nd Aug 05

2. Location Conveyance • Goal is to define SIP as a Geopriv “Using Protocol”, per RFC 3693 • Incorporate the Geopriv LO into SIP by • adhering to all requirements of 3693 • add necessary requirements unique to SIP for location conveyance • SIP Element behaviors depend on intent of Location Conveyance

3. New to Document I • Moved to SIP WG since last meeting • Cleaned up layout of doc • Added Reqs requested • Brought proposed 4XX Response codes earlier in doc • Moved complete message flows to appendixes • Give examples of 2 formats of PIDF-LO of same position on earth

4. Location scenarios to Resolve • UA doesn't know its location, and doesn't understand how to participate in providing its location. • UA doesn't know its location, but understands to process of providing location. Wants to get a location to provide. Once it gets that, will turn into one of the three following: • UA knows its location, doesn’t need proxy for loc • UA knows its location, proxy is satisfied with that • UA knows its location, proxy doesn't trust that, wants to provide another location in addition or instead • UAC could merely want to request Loc of another UA

5. New to Document II • Insert location indication when UA supports “location” • Conclude a UA doesn’t understand “Location” if header or option-tag not present • Helps with Responses • Indication is a new “Location” Header • Header Fields: option-tag, CID or URI

6. Location Header Option-tags • loc-body identifies location is present in the message body of this message, but gives no indication which format it is in, or even if it is visible to the SIP element viewing the message. • civic-loc identifies the format of location included, or desired. • geo-locidentifies the format of location included, or desired. • convey-uac identifies in a message for the receiver of this message to forward the sender's location information to another UA. • convey-uas identifies to a UAS within a transaction to convey its location to the UAC of that transaction, or to a third party UA • unknown indicates the UAC understands the concept of location, but does not have knowledge of where it is to include in the message. Used with 425 (Retry Loc Body) • Forgot location even though I use it in the examples

7. What Location Header solves • Support for “location” awareness (#1) • Option-tag for Require, Proxy-Requires, Supported and Unsupported headers • UAC requesting Loc from SIP intermediary (#2) • CID for location message body (#3 and 4) • Loc format included or requested (#4 or #6) • By-Reference URI (#2 and #5) • By-value accomplished with 425 (Retry Loc Body) • UAC requesting Loc of UAS (side effect of #6)

8. Benefits of location by-reference • UA may not know where it is, but some server may • UA isn’t upgraded yet for location • UA doesn’t have the capacity to know • Can be placed in a header, meaning SIP intermediaries can insert location for the UA

9. Issues with by-reference approach • Session establishment (call) may fail because of failure to dereference • Especially bad for emergency calls requiring UAC location to route message at all • Emergency calling uses location for dispatch as well, meaning second dereference needed • Forcing a dereference each time creates a chargeable transaction (i.e. creates a business model) • “Location” will be about users telling other users where they are, scaling this means servers always knowing where UAs are 100% of time

10. Added to list of Methods Using Location The list of applicable Methods for UA-to-UA location conveyance is: • INVITE OPTIONS (new) • UPDATE SUBSCRIBE/NOTIFY • MESSAGE PUBLISH. • REFER (was omitted by accident, but included in the text section) • REGISTER (has since been requested) The list of applicable Methods for UA-to-Proxy location conveyance is: • INVITE • UPDATE • MESSAGE • (NEW) Each Method has its own section with accepted and rejection message examples focusing on element behaviors to headers

11. Open Issues • Dean doesn’t like using OPTIONS to fetch UAC’s location • General Location Request (SUB) Event package should go here

12. What’s next? • Need to complete ABNF of Location header • Solve open issues through discussion and Chair/AD guidance • Need to create SUB/NOT Event package • Figure out if Rohan’s event package belongs in this ID or separate • Need to complete appendixes • NOTE: This doc is normative to all(?) of ECRIT WG docs

13. PIDF-LO in coordinate/geo Format <tuple id="sg89ae"> <timestamp>2005-08-01T10:00:00Z</timestamp> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point96" srsName="epsg:4326"> <gml:coordinates>33.001111N 96.68142W</gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <method>dhcp</method> <provided-by><nena>www.cisco.com</nena></provided-by/> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention- expiry> </gp:usage-rules> </gp:geopriv> </status> </tuple>

14. PIDF-LO in coordinate/geo Format <tuple id="sg89ae"> <timestamp>2005-08-01T10:00:00Z</timestamp> <status> <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>US</cl:country> <cl:A1>Texas</cl:A1> <cl:A3>Colleyville</cl:A3> <cl:HNO>3913</cl:HNO> <cl:A6>Treemont</cl:A6> <cl:STS>Circle</cl:STS> <cl:PC>76034</cl:PC> <cl:FLR>1</cl:FLR> <cl:civilAddress> </gp:location-info> <method>dhcp</method> <provided-by><nena>www.cisco.com</nena></provided-by/> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2005-08-05T01:00:00Z</gp:retention- expiry> </gp:usage-rules> </gp:geopriv> </status> </tuple>