Skip to content
Snippets Groups Projects
Commit 30d7a212 authored by George Joseph's avatar George Joseph
Browse files

Geolocation: Wiki Documentation 

Change-Id: I68ba22db0a69d9e2eabcc2141b48a2395f7f1a23
parent f4a020a4
No related branches found
No related tags found
3 merge requests!138Merge branch asterisk-20.3.0 into devel properly,!123Merge asterisk '20.3.0' into devel,!118Draft: manager: AOC-S support for AOCMessage
Hide whitespace changes
Inline Side-by-side
res/res_geolocation/wiki/AsteriskImplementation.md 0 → 100644
+ 177
− 0
View file @ 30d7a212
{section:border=false}
{column:width=70%}
h1. Introduction
The Geolocation capabilities are implemented in Asterisk with the res_geolocation and res_pjsip_geolocation modules and the geolocation.conf configuration file. There are also dialplan functions which allow you to manipulate location information as it's passed through the dialplan.
h1. Location Information Flow
Location information can be supplied to Asterisk from several sources during the call flow...
* Sent by a caller in a SIP INVITE message.
* Provided by a geolocation profile attached to the caller's endpoint.
* Provided by the dialplan via the Geolocation apps and functions.
* Provided by a geolocation profile attached to the callee's endpoint.
These sources aren't mutually exclusive and may, in fact, provide conflicting information or present the same information in multiple formats. Given that, there's no way for Asterisk to merge information nor is there a way for Asterisk to automatically determine which source should take precedence. However, you can use the geolocation profiles and the dialplan functions to tell Asterisk what to do with the location information received from the previous step in the call flow.
h1. Core Configuration
The bulk of the geolocation support is implemented in the res_geolocation module and configured in the geolocation.conf file. The file contains two main objects, Location and Profile.
h2. Common Behavior
h3. Sub-parameters
Some of the parameters in each object are actually lists of comma-separated name-value "sub-parameters". For example, the {{location_info}} parameter in the Location object contains a list of sub-parameters that are specific to the location type.
{code}
location_info = shape=Circle, pos="39.12345 -105.98766", radius=100
{code}
Spaces around the equals signs and commas are ignored so you must double quote sub-parameter values with spaces or commas in them.
For readability, parameters that use sub-parameters can be split over more than one line. For example:
{code}
location_info = country=US,A1="New York"
location_info = house_number=1633,PRD=W,street=46th
{code}
would be equivalent to:
{code}
location_info = country=US,A1="New York",house_number=1633,PRD=W,street=46th
{code}
h3. Variable substitution
Some of the parameters can contain references to channel variables and dialplan functions. For example, you might have a URI location object that contains a reference to the {{EXTEN}} channel variable:
{code}
location_info = URI=http://some.example.com?key=${EXTEN}
{code}
When a call is processed that uses this location object, {{$\{EXTEN\}}} would be replaced with the channel's extension and would result in a URI such as {{http://some.example.com?key=1000}}. You'd set up your web server to return a location document based on the value of "key".
You can also use dialplan functions such as {{CURL}} and {{ODBC_SQL}} to supply values just as you would in extensions.conf.
h2. Location
The Location object defines a discrete location or defines a template that can be used to define a discrete location on a per-call basis.
||Parameter||Required?||Uses Channel\\Variables?||Uses Sub\\Parameters?||Usage||
|type|yes|no|no|Must be "location"|
|format|yes|no|no|"civicAddress", "GML" or "URI" to indicate how the location is expressed.|
|method|no|no|no|If provided, it MUST be one of "GPS", "A-GPS", "Manual", "DHCP", "Triangulation", "Cell", "802.11"|
|location_source|no|no|no|If provided, it MUST be a fully qualified domain name. IP addresses are specifically not allowed.
See [RFC8787|Geolocation Reference Information#rfc8787] for the exact definition of this parameter.|
|location_info|yes|yes|yes|The sub-parameters of location_info are dependent on the location's format:
* URI: A single {{URI}} sub-parameter with the URI.
Example: {{location_info = URI=http://some.example.com}}
See the [URI] page for more info.
* civicAddress: A set of sub-parameters that describe the location.
Example:
{code}
location_info = country=US,A1="New York",A3="New York"
location_info = house_number=1633,PRD=W,street=46th
location_info = street_suffix = Street,postal_code=10222
{code}
See the [Civic Address] page for more info.
* GML: A set of sub-parameters that describe the location.
Example: {{location_info = shape=Circle, pos="39.12345 -105.98766", radius=100}}
See the [GML] page for more info.|
h2. Profile
The Profile object defines how a location is used and is referenced by channel drivers.
||Parameter||Required?||Uses Channel\\Variables?||Uses Sub\\Parameters?||Usage||
|type|yes|no|no|Must be "profile"|
|location_reference|no|no|no|Specifies the id of a Location object to use.|
|pidf_element|no|no|no|For Civic Address and GML location formats, this parameter specifies the PIDF element that will carry the location description on outgoing SIP requests. Must be one of "tuple", "device" or "person". The default is "device".|
|allow_use_for_routing|no|no|no|This value controls the value of the {{Geolocation-Routing}} header sent on SIP requests, Must be "yes" or "no". The default is "no".
See [RFC6442|Geolocation Reference Information#rfc6442] for more information.|
|action|no|no|no|Specifies what should be done with any incoming location descriptions received by a channel referencing this profile.\\
* {{discard}}: Discard any incoming location descriptions and use only the location description specified by {{location_reference}} (if any).\\
* {{append}}: Append any incoming location descriptions to the one specified by {{location_reference}} (if any).\\
* {{prepend}}: Prepend any incoming location descriptions to the one specified by {{location_reference}} (if any).\\
* {{replace}}: Replace the location description specified by {{location_reference}} (if any) with the ones received.\\
*WARNING*: Using the {{append}} or {{prepend}} options can cause _multiple_ location objects to be sent to a recipient. [RFC5491|Geolocation Reference Information#rfc5491] discourages the use of multiple location objects but has rules that should be followed if it's necessary. Unfortunately, as is typical for RFCs, there are many "SHOULD"s and very few "MUST"s in the rules so you should read that RFC carefully before you allow multiple locations.|
|usage_rules|no|yes|yes|For Civic Address and GML location formats, this parameter specifies the contents of the {{usage-rules}} PIDF-LO element.\\
* {{retransmission-allowed}}: Must be "yes" or "no". The default is "no".\\
* {{retention-expires}}: An ISO-format timestamp after which the recipient MUST discard and location information associated with this request. The default is 24 hours after the request was sent. You can use dialplan functions to create a timestamp yourself if needed. For example, to set the timestamp to 1 hour after the request is sent, use:
{{retention-expires="$\{STRFTIME($[$\{EPOCH\}+3600],UTC,%FT%TZ)\}"}}\\
See [RFC4119|Geolocation Reference Information#rfc4119] for the exact definition of this parameter.
|
|location_info_refinement|no|yes|yes|This parameter can be used to refine referenced location by adding these sub-parameters to the {{location_info}} parameter of the referenced location object. For example, you could have Civic Address referenced object describe a building, then have this profile refine it by adding floor, room, etc. Another profile could then also reference the same location object and refine it by adding a different floor, room, etc.
|location_variables|no|yes|yes|Any parameter than can use channel variables can also use the arbitrary variables defined in this parameter. For example {{location_variables = MYVAR1=something, MYVAR2="something else"}} would allow you to use {{$\{MYVAR1\}}} and {{$\{MYVAR2\}}} in any other parameter that can accept channel variables|
|notes|no|no|no|The specifications allow a free-form "note-well" element to be added to the location description. Any text entered here will be present on all outgoing Civic Address and GML requests.|
h1. chan_pjsip Configuration
Two new parameters have been added to pjsip endpoints:
||Parameter||Usage||
|geoloc_incoming_call_profile|Should be set to the name of a geolocation profile to use for calls coming into Asterisk from this remote endpoint. If not set, no geolocation processing will occur and any location descriptions present on the incoming request will be silently dropped.|
|geoloc_outgoing_call_profile|Should be set to the name of a geolocation profile to use for calls Asterisk sends to this remote endpoint. If not set, no geolocation processing will occur and any location descriptions coming from the associated incoming channel or the dialplan will be silently dropped and not conveyed to the endpoint.|
h1. Dialplan Applications and Functions
Two new dialplan applications and one dialplan function have been added to allow a dialplan author to manipulate geolocation information.
h2. GeolocProfileCreate
This application creates a new Geolocation profile on the channel in addition to any others that may already exist. It tasks a profile name and an index as its arguments. Callers must use the {{GEOLOC_PROFILE}} function to set its actual location description.
h2. GeolocProfileDelete
This application deletes the existing Geolocation profile at the specified index from the channel's list of profiles.
h2. GEOLOC_PROFILE
This function can get or set any of the fields in a specific profile. The available fields are those in _both_ the Location and Profile configuration objects.
h1. Example Call Flows
h2. Simple Example 1
Alice and Bob work in the same building so in geolocation.conf, we can define a location that describes the building and profiles for Bob and Alice that add floor and room. We're assuming here that Bob's and Alice's phones don't send any location information themselves.
{code}
[building1]
type = location
format = civicAddress
location_info = country=US, A1="New York", A3="New York",
location_info = HNO=1633, PRD=W, RD=46th, STS=Street, PC=10222
method = Manual
[alice]
type = profile
location_reference = building1
location_refinement = FLR=4, ROOM=4B20
[bob]
type = profile
location_reference = building1
location_refinement = FLR=32, ROOM=32A6
{code}
In pjsip.conf, we can now associate those profiles to endpoints.
{code}
[bob]
type = endpoint
geoloc_incoming_call_profile = bob
[alice]
type = endpoint
geoloc_incoming_call_profile = alice
{code}
You'll notice that neither bob nor alice set {{geoloc_outgoing_call_profile}} because we never want to send location information _to_ them.
Now when Alice makes a call, Asterisk will construct an effective profile (including any defaults and variable substitutions) that looks like this...
{code}
format = civicAddress
location_info = country=US, A1="New York", A3="New York",
location_info = HNO=1633, RD=46th, STS=Street, PC=10222, FLR=4, ROOM=4B20
method = Manual
usage_rules = retransmission-allowed=no
usage_rules = retention-expires="${STRFTIME($[${EPOCH}+86400],UTC,%FT%TZ)}"
allow_routing = no
pidf_element = device
{code}
Bob's effective profile would be exactly the same except for {{FLR}} and {{ROOM}}
This effective profile will then be forwarded to the dialplan. The dialplan application can then use GEOLOC_PROFILE to make changes before the effective profile is forwarded to the outgoing channel. It can also use GeolocProfileDelete to just delete the effective profile and pass nothing.
{column}
{column:width=30%}
Table of Contents:
{toc}
Geolocation:
{pagetree:root=Geolocation|expandCollapseAll=true}
{column}
{section}
res/res_geolocation/wiki/CivicAddress.md 0 → 100644
+ 167
− 0
View file @ 30d7a212
{section:border=false}
{column:width=70%}
h1. Introduction
For static locations, using Civic Address location descriptions would be the easiest method. As stated earlier though, you and your partners must agree on which description formats are acceptable.
The following tables list the IANA registered element names that are currently accepted. The complete list of codes is defined in:
[https://www.iana.org/assignments/civic-address-types-registry/civic-address-types-registry.xhtml]
These codes were originally defined in [RFC4119|Geolocation Reference Information#rfc4119] and [RFC4776|Geolocation Reference Information#rfc4776]
|| Label || Description || Example |
| country | The country is identified by the two-letter ISO 3166 code.|US|
| A1 | national subdivisions (state, region, province, prefecture)|New York|
| A2 | county, parish, gun (JP), district (IN)|King's County|
| A3 | city, township, shi (JP)|New York|
| A4 | city division, borough, city, district, ward, chou (JP)|Manhattan|
| A5 | neighborhood, block | Morningside Heights |
| A6 | street\\NOTE: This code has been deprecated in favor of {{RD}}, defined below. | Broadway |
| PRD | Leading street direction| N, W |
| POD | Trailing street direction| SW |
| STS | Street suffix | Avenue, Platz, Street|
| HNO | House number, numeric part only|123|
| HNS | House number suffix | A, 1/2 |
| LMK | Landmark or vanity address|Low Library |
| LOC | Additional location information\\NOTE: {{ROOM}} was added below.| Room 543 |
| FLR | Floor | 5 |
| NAM | Name (residence, business or office occupant)|Joe's Barbershop |
| PC | Postal code | 10027-0401 |
These codes were added in [RFC5139|Geolocation Reference Information#rfc5139]
|| Label || Description || Example |
| BLD | Building (structure) | Hope Theatre |
| UNIT | Unit (apartment, suite) | 12a |
| ROOM | Room | 450F |
| PLC | Place-type | office |
| PCN | Postal community name | Leonia |
| POBOX | Post office box (P.O. box) | U40 |
| ADDCODE | Additional Code | 13203000003 |
| SEAT | Seat (desk, cubicle, workstation) | WS 181 |
| RD | Primary road or street | Broadway |
| RDSEC | Road section | 14 |
| RDBR | Road branch | Lane 7 |
| RDSUBBR | Road sub-branch | Alley 8 |
| PRM | Road pre-modifier | Old |
| POM | Road post-modifier | Service |
These codes were added in [RFC6848|Geolocation Reference Information#rfc6848]
|| Label || Description || Example |
|PN|Post number that is attributed to a lamp post or utility pole.|21344567|
|MP|Milepost: a marker indicating distance to or from a place (often a town)
May actually be expressed in "miles" or "kilometers".|237.4|
|STP|Street Type Prefix.|Boulevard|
|HNP|House Number Prefix.|Z|
h1. Example Configurations
h2. Simple Example 1
In geolocation.conf, we can define a location that describes a building and profiles for Bob and Alice that add floor and room. We're assuming here that Bob's and Alice's phones don't send any location information themselves.
{code}
[building1]
type = location
format = civicAddress
location_info = country=US, A1="New York", A3="New York",
location_info = HNO=1633, PRD=W, RD=46th, STS=Street, PC=10222
method = Manual
[alice]
type = profile
location_reference = building1
location_refinement = FLR=4, ROOM=4B20
[bob]
type = profile
location_reference = building1
location_refinement = FLR=32, ROOM=32A6
{code}
h1. PIDF-LO XML Examples
Here's what Alice's PIDF-LO would look like:
{code}
<?xml version="1.0" encoding="UTF-8"?>
<presence entity="pres:alice@example.com"
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<dm:device>
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>US</ca:country>
<ca:A1>New York</ca:A1>
<ca:A3>New York</ca:A3>
<ca:HNO>1633</ca:HNO>
<ca:PRD>W</ca:PRD>
<ca:RD>46th</ca:RD>
<ca:STS>Street</ca:STS>
<ca:PC>10222</ca:PC>
<ca:FLR>4</ca:FLR>
<ca:ROOM>4B20</ca:ROOM>
</ca:civicAddress>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
<gp:method>manual</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2022-04-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
{code}
Here's what Bob's PIDF-LO would look like:
{code}
<?xml version="1.0" encoding="UTF-8"?>
<presence entity="pres:bob@example.com"
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<dm:device>
<gp:geopriv>
<gp:location-info>
<ca:civicAddress xml:lang="en-AU">
<ca:country>US</ca:country>
<ca:A1>New York</ca:A1>
<ca:A3>New York</ca:A3>
<ca:HNO>1633</ca:HNO>
<ca:PRD>W</ca:PRD>
<ca:RD>46th</ca:RD>
<ca:STS>Street</ca:STS>
<ca:PC>10222</ca:PC>
<ca:FLR>32</ca:FLR>
<ca:ROOM>32A6</ca:ROOM>
</ca:civicAddress>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
<gp:method>manual</gp:method>
</gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2022-04-22T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
{code}
Note that the only civicAddress difference between the two are the {{FLR}} and {{ROOM}}.
{column}
{column:width=30%}
Table of Contents:
{toc}
Geolocation:
{pagetree:root=Geolocation|expandCollapseAll=true}
{column}
{section}
res/res_geolocation/wiki/GML.md 0 → 100644
+ 60
− 0
View file @ 30d7a212
{section:border=false}
{column:width=70%}
h1. Introduction
All compliant participants are required to support GML as the description language but it's really only suitable for mobile devices. As stated earlier though, you and your partners must agree on which description formats are acceptable.
The language itself is fairly simple. There are 8 shapes that can be used to describe a location and they share a common set of attributes described below. Determining the actual values for those attributes though can be quite complex and is not covered here.
h2. References:
* [Open Geospatial Consortium Geography Markup Language|gml]
* [GML 3.1.1 PIDF-LO Shape Application Schema|geoshape]
* [Universal Geographical Area Description (GAD)|gad] (for background)
h2. Coordinate Reference Systems
The coordinate reference system (crs) for a shape specifies whether the points that define a shape express a two dimensional or three dimensional point in space. It does NOT specify whether the shape itself is 2D or 3D. For instance, a Point is a one dimensional "shape" but it can be specified with just a latitude and longitude (2d) or latitude, longitude and altitude (3d). The `crs` is specified for each shape with the `crs` attribute whose value can be either `2d` or `3d`.
h2. Units of Measure
h3. Position
Positions are always specified in decimal degrees latitude and longitude. A 3d position adds the altitude in meters. `pos` and `posList` are the two attributes that specify position.
h3. Distance
Distance is _always_ specified in meters. `height`, `radius` and the altitude component of `pos` are some of the distance attributes.
*A special note about altitude:* As of the date of this writing (May 2022) we couldn't find any mention in the RFCs concerning the altitude reference. Is it above:
# Ground Level (AGL)
# Mean Sea Level (MSL)
# A Geoid reference (which one?)
h3. Angle
Angle may be specified in either degrees or radians by specifying the `degrees` or `radians` suffix to the angle value. The default it `degrees` if no suffix is provided. `orientation`, `startAngle` and `openingAngle` are some of the angle attributes.
h2. Shapes
h3. Point
A Point isn't really a "shape" because it's a one dimensional construct but we'll ignore that. It's simply a point in space specified with either two or three dimensions.
|| Shape || Attributes || Description ||
| Point | pos or pos3d | A single point |
| Circle | pos or pos3d, radius | A two dimensional circle around a point |
| Sphere | pos3d, radius | A 3 dimensional sphere around a point |
|| Attribute || Description || Units || Example ||
| pos | A two dimensional point | Decimal degrees | pos="39.12345 -105.98766" |
| pos3d | A three dimensional point | Decimal degrees + altitude in meters | pos="39.12345 -105.98766 1690" |
| radius | Distance | Meters | radius="20" |
| height | Distance | Meters | height="45" |
| orientation | Angle | Degrees (default) or Radians | orientation="90", orientation="25 radians" |
{column}
{column:width=30%}
Table of Contents:
{toc}
Geolocation:
{pagetree:root=Geolocation|expandCollapseAll=true}
{column}
{section}
res/res_geolocation/wiki/Geolocation.md 0 → 100644
+ 74
− 0
View file @ 30d7a212
{section:border=false}
{column:width=70%}
{warning:title=Please Read!}
Before you go off on a geolocation configuration spree, you'll need to understand a few things about Geolocation itself.
* It's not a single specification.
While a good part of the implementation is covered in RFCs, some of it is documented in the Geography Markup Language Specification, the 3GPP Technical Specifications, national organizations like the FCC and National Emergency Number Association in the US, and probably your interfacing carriers. The last is the most important as you don't want emergency calls dropped or routed to incorrect emergency service centers because of a configuration incompatibility.
* It's been around a while.
The first references I could find date back to 2002. Since then there have been innumerable changes including IETF drafts that expired 15 years ago that are still being returned by Google searches.
With that in mind, please do your own research and coordinate closely with your partners to validate your configuration.
{warning}
h1. Introduction
As it applies to Asterisk, Geolocation is the process of...
* A channel driver accepting location information in an incoming SIP INVITE, either by reference or by value, then using a geolocation profile to determine the disposition of that information and/or possibly add or delete information.
* Passing the resulting information (if any) to the dialplan which can also determine the disposition of that information and/or possibly add or delete information.
* Passing the information from the dialplan to the outgoing channel driver which can also use a geolocation profile to determine the disposition of that information and/or possibly add or delete information.
* Finally sending the information to another party, either by reference or by value.
h1. What's a "location"?
h2. Describing a Location
There are currently two ways to describe a location.
h3. Geography Markup Language (GML)
GML allows you to express a location in terms of shapes, coordinates, lengths, angles, etc. For example, a Point with a latitude, longitude and altitude, or a Sphere with a latitude, longitude, altitude and radius. Other shapes include, Circle, Polygon, Ellipse, Ellipsoid, and Prism. See [GeoShape|Geolocation Reference Information#geoshape].
GML would most often be used by mobile systems where the originator's location is determined dynamically such as base station, sector antenna, distance, etc. According to [RFC4119|Geolocation Reference Information#rfc4119] GML is considered to be the "baseline" format and MUST be supported by all implementations. The _level_ of support is not well defined however. For instance, a specific implementation may only support a subset of shapes.
h3. Civic Address
For fixed locations, Civic Address is probably the most used location description method. It's described with terms like Country, State/Province, City, Neighborhood, Street, House Number, Floor, Room, etc. Oddly enough, support for Civic Address is NOT required by [RFC4119|Geolocation Reference Information#rfc4119].
Both methods are expressed in XML but which location description method you use is entirely between you and your partners.
h3. Encapsulation
The IETF chose the "Presence Information Data Format" (PIDF) as the wrapper document for location information which can be placed in {{<tuple>}}, {{<device>}}, or {{<person>}} sub-elements. BTW, this is the same PIDF used to convey SIP subscription information but Asterisk is only supporting PIDF-LO in INVITE requests at this time.
The specification allows multiple locations in each element, multiple elements in a single PIDF-LO document, _and_ multiple PIDF-LO documents in a single request. Dealing with multiple locations however is such an extraordinarily complex process that it's not support by Asterisk at this time. Please read the reference information for the applicable rules. [RFC5491|Geolocation Reference Information#rfc5491] is a good starting point.
h2. Conveying a Location via SIP
There are currently two ways to convey a location description regardless of which description method you use. Both use the {{Geolocation}} SIP message header to indicate where to get the location description document.
h3. By Reference
This one's simple. The "reference" is actually URI that the recipient can access that will return an XML document containing the description. "http" and "https" are the most common URI schemes but there are others. See [RFC6442|Geolocation Reference Information#rfc6442] above. An example {{Geolocation}} header might look like: {{Geolocation: <https://geoloc.example.com?location=some_location_reference>}}.
With this method, you are entirely responsible for retrieving location descriptions from URIs you receive and for serving location descriptions for URIs you send. Asterisk does not attempt to retrieve any information from those URIs.
When sending information to an upstream carrier, it's possible they may give _you_ special URIs to place in Geolocation headers you send them.
h3. By Value
This method involves sending or receiving a PIDF-LO document attached to a SIP message. For details on how this works generally, See [RFC6442|Geolocation Reference Information#rfc6442] and [RFC5491|Geolocation Reference Information#rfc5491]. An example {{Geolocation}} header might look like: {{Geolocation: <cid:gyytfr@your.pbx.com>}}. The {{cid}} scheme indicates that the recipient should look in the SIP message body (or bodies since there could also be an SDP for example) for the location document.
h3. Multiple URIs
The {{Geolocation}} header can contain multiple URIs and they can be a mix of "by-reference" and "by-value". As mentioned above though, the process of dealing with multiple location references is pretty complex and should be avoided.
h3. Geolocation-Routing
[RFC6442|Geolocation Reference Information#rfc6442] also defines the {{Geolocation-Routing}} header which indicates to a recipient that the location information may or may not be used for call routing purposes. If set to "no" (the default if absent), the recipient MUST NOT use the location information for routing purposes. If set to "yes", the recipient MAY use the location information for routing purposes and may also reset the value to "no" to prevent downstream systems from using the location information for routing.
Some carriers ignore this header altogether.
{column}
{column:width=30%}
Table of Contents:
{toc}
Geolocation:
{pagetree:root=Geolocation|expandCollapseAll=true}
{column}
{section}
res/res_geolocation/wiki/ReferenceInformation.md 0 → 100644
+ 33
− 0
View file @ 30d7a212
{section:border=false}
{column:width=70%}
There is no single document that has the complete, current specification so please follow and read any "updated by" references in these documents.
|| RFC || Title ||
|[RFC3693|https://www.rfc-editor.org/rfc/rfc3693]|Geopriv Requirements|
|[RFC4119|https://www.rfc-editor.org/rfc/rfc4119]|A Presence-based GEOPRIV Location Object Format|
|[RFC5139|https://www.rfc-editor.org/rfc/rfc5139]|Revised Civic Location Format for\\Presence Information Data Format Location Object (PIDF-LO)|
|{anchor:rfc5491} [RFC5491|https://www.rfc-editor.org/rfc/rfc5491]|GEOPRIV Presence Information Data Format\\Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations|
|[RFC5808|https://www.rfc-editor.org/rfc/rfc5808]|Requirements for a Location-by-Reference Mechanism|
|[RFC6280|https://www.rfc-editor.org/rfc/rfc6280]|An Architecture for Location and Location\\Privacy in Internet Applications|
|{anchor:rfc6442} [RFC6442|https://www.rfc-editor.org/rfc/rfc6442]|Location Conveyance for the Session Initiation Protocol|
|[RFC6848|https://www.rfc-editor.org/rfc/rfc6848]|Specifying Civic Address Extensions in the\\Presence Information Data Format Location Object (PIDF-LO)|
|[RFC7459|https://www.rfc-editor.org/rfc/rfc7459]|Representation of Uncertainty and Confidence\\in the Presence Information Data Format Location Object (PIDF-LO)|
|[RFC8787|https://www.rfc-editor.org/rfc/rfc8787]|Location Source Parameter for the SIP Geolocation Header Field|
|{anchor:gml} [OGC GML|https://www.ogc.org/standards/gml]|Open Geospatial Consortium Geography Markup Language|
|{anchor:geoshape} [GeoShape|https://portal.ogc.org/files/?artifact_id=21630#:~:text=This%20GML%203.1.,uses%20the%20separately%20specified%20geoshape]|GML 3.1.1 PIDF-LO Shape Application Schema\\for use by the Internet Engineering Task Force (IETF)|
|{anchor:gad} [3GPP TS 23.032|https://www.3gpp.org/ftp/Specs/archive/23_series/23.032/]|3GPP Technical Specification: Universal Geographical Area Description (GAD)\\Use version [23.032-h20|https://www.3gpp.org/ftp/Specs/archive/23_series/23.032/23032-h20.zip]\\This document is NOT specific to Geopriv so use with caution|
{column}
{column:width=30%}
Table of Contents:
{toc}
Geolocation:
{pagetree:root=Geolocation|expandCollapseAll=true}
{column}
{section}
res/res_geolocation/wiki/URI.md 0 → 100644
+ 86
− 0
View file @ 30d7a212
{section:border=false}
{column:width=70%}
h1. Introduction
As mentioned in other pages, Geolocation descriptions can be passed "by-value" using a GML or Civic Address XML document, or "by-reference" using a URI. This page discusses the latter.
h1. Concepts
h2. Outgoing Calls
Passing location descriptions using URIs is fairly simple from an Asterisk perspective. It does however, require the implementer to establish and maintain infrastructure to handle the serving of those URIs. Given the critical nature of the information, setting up such infrastructure is not trivial and is beyond the scope of Asterisk and this documentation.
h2. Incoming calls
On incoming calls, Asterisk will make any "pass-by-reference" URIs available to the dialplan via the {{GEOLOC_PROFILE}} function but will NOT attempt to retrieve any documents from that URI. It's the dialplan author's responsibility to retrieve, interpret and process such documents.
h1. Example 1
Let's say that every extension in your organization has a public DID associated with it, you have a database that cross references DIDs and office locations, and you have a web server that can be queried with a "GET" request and an "DID" query parameter ({{https://my.company.com/location_query?DID=<did>}}) to get the DID's location. When someone in your organization dials 911, you want a link sent in the outgoing SIP INVITE that the recipient can call to get the caller's location.
In geolocation.conf, you'd create Location and Profile objects as follows:
{code}
[did-xref]
type = location
format = URI
location = URI='https://my.company.com/location_query?DID=${CALLERID(num)}'
[employees-outbound]
type = profile
location_reference = did-xref
{code}
In pjsip.conf, you'd add a {{geoloc_outgoing_call_profile}} parameter to your _outgoing_ endpoint definition:
{code}
[my-provider]
type = endpoint
...
geoloc_outgoing_call_profile = employees-outbound
{code}
Now let's say that Bob has DID {{12125551212}} assigned to him and he makes an outgoing call which is routed to "my-provider". Asterisk would automatically add the following header to the INVITE:
{code}
Geolocation: <https://my.company.com/location_query?DID=12125551212>
{code}
The recipient could then make a simply query using that URI and get Bob's location in whatever format was agreed upon with you and them.
Of course, this is a _very_ simple example that would add the Geolocation header to _all_ calls made via "my-provider". If you only routed emergency calls to "my-provider" this would work fine but you probably don't want to leak location information on non-emergency calls.
h1. Example 2
In this example, we'll use the dialplan apps and functions to decide if we want to send location information to the recipient or not. In fact, we're not going to use geolocation.conf at all.
In extensions.conf:
{code}
; The pre dial handler adds a new profile with a URI location to
; the outgoing channel when 911 is dialed and does nothing if another number is dialed.
[pre-dial-handler]
exten = 911,1,NoOp(Entering PDH for Outgoing Channel)
same = n,GeolocProfileCreate(geoloc.example@myserver.com)
same = n,Set(GEOLOC_PROFILE(format,0)=URI)
same = n,Set(GEOLOC_PROFILE(location_info,0)=URI=https://my.company.com/location_query?DID=${CALLERID(num)})
same = n,Return(0)
exten = _X.,1,Return(0)
[default]
exten = _X.,1,NoOp(Outgoing call)
; 'b' will run the pre-dial-handler on the outgoing channel.
same = n,Dial(PJSIP/${EXTEN},5,b(pre-dial-handler))
{code}
{column}
{column:width=30%}
Table of Contents:
{toc}
Geolocation:
{pagetree:root=Geolocation|expandCollapseAll=true}
{column}
{section}
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment