“geo:” and SIP Location Conveyance

August 6th, 2010 by alex Leave a reply »

“geo:” is getting more attention in other areas of the Internet Engineering Task Force. After the VCARDDAV working group has included “geo:” URIs in their revision of the vCard scheme, the SIPCORE working group is now discussing the use of “geo:” in their “Location Conveyance” draft.

SIP is the IETF’s protocol for establishing Realtime Application Sessions, and is very commonly used for Voice over IP. It has gained massive popularity in recent years, and is not just be used in VoIP-Software, but also in Public Branch Exchanges from various vendors, open source products such as Asterisk, Kamailio and a wide range of carrier products. SIP is the base for telephoney in the upcoming Next Generation networks such as LTE, and a major component of IMS systems. A good percentage of phone calls being routed between carriers as of today already uses SIP.

For those reasons, the IETF is looking into ways to embed location information into SIP messages. This is important for services such as Emergency Services, but can of course be used for any other realtime application that needs to transmit location information in its session setup. An example of that could be location conveyance between contacts in a social network, or applications for “checking in”, such as Gowalla and Foursquare.

The current version of the SIP Location Conveyance Specification uses “Content ID” URIs (besides “sip”/”sips”/”pres”) to refer from the new “Geolocation:” header to a MIME body part, which then contains the location embedded in a PIDF-LO Presence/Location document. Such a geolocation header (and respective body part) would look like this:

Geolocation: <cid:target123@atlanta.example.com>
     ;inserted-by="alice@atlanta.example.com"

   --boundary1

   <?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:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:gml="http://www.opengis.net/gml"
          entity="pres:alice@atlanta.example.com">
        <dm:device id="point2d">
         <timestamp>2007-12-02T14:00:00Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>33.001111 -96.68142</gml:pos>
                </gml:Point>
               </gml:location>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2007-12-07T18:00:00Z</gp:retention-
                            expiry>
            </gp:usage-rules>
            <gp:method>DHCP</gp:method>
            <gp:provided-by>www.example.com</gp:provided-by>
          </gp:geopriv>
         </status>
        </dm:device>
      </presence>
   --boundary1--

PIDF-LO allows for great flexibility of location types, can contain civic addresses, and extensive privacy rules. However, conveyance of a simple “point” type location could also be achieved by using the “geo:” URI in the Geolocation header directly as follows:

Geolocation: <geo:33.001111,-96.68142>

Which, obviously, would be much more compact, probably easier to parse, and not in the need of a seperate MIME body part.

However, the “geo:” URI specifically lacks privacy rules, because an URI itself does not identify a Target, but rather reflects just a physical location in space. In SIP Location Conveyance as a “GEOPRIV Using Protocol”, privacy is required.

There is currently a discussion going on the SIPCORE mailing list, and the proposal is that a “geo:” URI (when used in an “Geolocation” SIP header) would come with implicit default rules (currently under discussion whether those default rules would be GEOPRIV’s general default rules, or defaults specific to the use of “geo:” in the context of the “Geolocation:” header).

We’ll keep watching the discussion.

Advertisement

1 comment

  1. As per James M. Polk, from Cisco, in the public-geolocation@w3.org mailing list, the scheme hasn’t been considered for the upcoming “-06” draft.

Leave a Reply