* 3d positions were being rendered without an enclosing `<gml:pos>`
element resulting in invalid XML.
* There was no way to set the `id` attribute on the enclosing `tuple`, `device`
and `person` elements.
* There was no way to set the value of the `deviceID` element.
* Parsing of degree and radian UOMs was broken resulting in them appearing
outside an XML element.
* The UOM schemas for degrees and radians were reversed.
* The Ellipsoid shape was missing and the Ellipse shape was defined multiple
times.
* The `crs` location_info parameter, although documented, didn't work.
* The `pos3d` location_info parameter appears in some documentation but
wasn't being parsed correctly.
* The retransmission-allowed and retention-expiry sub-elements of usage-rules
were using the `gp` namespace instead of the `gbp` namespace.
In addition to fixing the above, several other code refactorings were
performed and the unit test enhanced to include a round trip
XML -> eprofile -> XML validation.
Resolves: #1667
UserNote: Geolocation: Two new optional profile parameters have been added.
* `pidf_element_id` which sets the value of the `id` attribute on the top-level
PIDF-LO `device`, `person` or `tuple` elements.
* `device_id` which sets the content of the `<deviceID>` element.
Both parameters can include channel variables.
UpgradeNote: Geolocation: In order to correct bugs in both code and
documentation, the following changes to the parameters for GML geolocation
locations are now in effect:
* The documented but unimplemented `crs` (coordinate reference system) element
has been added to the location_info parameter that indicates whether the `2d`
or `3d` reference system is to be used. If the crs isn't valid for the shape
specified, an error will be generated. The default depends on the shape
specified.
* The Circle, Ellipse and ArcBand shapes MUST use a `2d` crs. If crs isn't
specified, it will default to `2d` for these shapes.
The Sphere, Ellipsoid and Prism shapes MUST use a `3d` crs. If crs isn't
specified, it will default to `3d` for these shapes.
The Point and Polygon shapes may use either crs. The default crs is `2d`
however so if `3d` positions are used, the crs must be explicitly set to `3d`.
* The `geoloc show gml_shape_defs` CLI command has been updated to show which
coordinate reference systems are valid for each shape.
* The `pos3d` element has been removed in favor of allowing the `pos` element
to include altitude if the crs is `3d`. The number of values in the `pos`
element MUST be 2 if the crs is `2d` and 3 if the crs is `3d`. An error
will be generated for any other combination.
* The angle unit-of-measure for shapes that use angles should now be included
in the respective parameter. The default is `degrees`. There were some
inconsistent references to `orientation_uom` in some documentation but that
parameter never worked and is now removed. See examples below.
Examples...
```
location_info = shape="Sphere", pos="39.0 -105.0 1620", radius="20"
location_info = shape="Point", crs="3d", pos="39.0 -105.0 1620"
location_info = shape="Point", pos="39.0 -105.0"
location_info = shape=Ellipsoid, pos="39.0 -105.0 1620", semiMajorAxis="20"
semiMinorAxis="10", verticalAxis="0", orientation="25 degrees"
pidf_element_id = ${CHANNEL(name)}-${EXTEN}
device_id = mac:001122334455
Set(GEOLOC_PROFILE(pidf_element_id)=${CHANNEL(name)}/${EXTEN})
```
This fixes a number of broken links throughout the
tree, mostly caused by wiki.asterisk.org being replaced
with docs.asterisk.org, which should eliminate the
need for sporadic fixes as in f28047db36.
Resolves: #430
Also added a note to the geolocation.conf.sample file
and added a README to the res/res_geolocation/wiki
directory.
Change-Id: I89c3c5db8c0701b33127993622d5e4f904bddfbc
You can now specify the location object's format, location_info,
method, location_source and confidence parameters directly on
a profile object for simple scenarios where the location
information isn't common with any other profiles. This is
mutually exclusive with setting location_reference on the
profile.
Updated appdocsxml.dtd to allow xi:include in a configObject
element. This makes it easier to link to complete configOptions
in another object. This is used to add the above fields to the
profile object without having to maintain the option descriptions
in two places.
ASTERISK-30185
Change-Id: Ifd5f05be0a76f0a6ad49fa28d17c394027677569
Added profile parameter "suppress_empty_ca_elements" that
will cause Civic Address elements that are empty to be
suppressed from the outgoing PIDF-LO document.
Fixed a possible SEGV if a sub-parameter value didn't have a
value.
ASTERISK-30177
Change-Id: I924ccc5aa2f45110a3155b22e53dfaf3ef2092dd
The trigger to perform outgoing geolocation processing is the
presence of a geoloc_outgoing_call_profile on an endpoint. This
is intentional so as to not leak location information to
destinations that shouldn't receive it. In a totally dynamic
configuration scenario however, there may not be any profiles
defined in geolocation.conf. This makes it impossible to do
outgoing processing without defining a "dummy" profile in the
config file.
This commit adds 4 built-in profiles:
"<prefer_config>"
"<discard_config>"
"<prefer_incoming>"
"<discard_incoming>"
The profiles are empty except for having their precedence
set and can be set on an endpoint to allow processing without
entries in geolocation.conf. "<discard_config>" is actually the
best one to use in this situation.
ASTERISK-30182
Change-Id: I1819ccfa404ce59802a3a07ad1cabed60fb9480a
* Added processing for the 'confidence' element.
* Added documentation to some APIs.
* removed a lot of complex code related to the very-off-nominal
case of needing to process multiple location info sources.
* Create a new 'ast_geoloc_eprofile_to_pidf' API that just takes
one eprofile instead of a datastore of multiples.
* Plugged a huge leak in XML processing that arose from
insufficient documentation by the libxml/libxslt authors.
* Refactored stylesheets to be more efficient.
* Renamed 'profile_action' to 'profile_precedence' to better
reflect it's purpose.
* Added the config option for 'allow_routing_use' which
sets the value of the 'Geolocation-Routing' header.
* Removed the GeolocProfileCreate and GeolocProfileDelete
dialplan apps.
* Changed the GEOLOC_PROFILE dialplan function as follows:
* Removed the 'profile' argument.
* Automatically create a profile if it doesn't exist.
* Delete a profile if 'inheritable' is set to no.
* Fixed various bugs and leaks
* Updated Asterisk WiKi documentation.
ASTERISK-30167
Change-Id: If38c23f26228e96165be161c2f5e849cb8e16fa0
This commit adds res_geolocation which creates the core capabilities
to manipulate Geolocation information on SIP INVITEs.
An upcoming commit will add res_pjsip_geolocation which will
allow the capabilities to be used with the pjsip channel driver.
This commit message is intentionally short because this isn't
a simple capability. See the documentation at
https://wiki.asterisk.org/wiki/display/AST/Geolocation
for more information.
THE CAPABILITIES IMPLEMENTED HERE MAY CHANGE BASED ON
USER FEEDBACK!
ASTERISK-30127
Change-Id: Ibfde963121b1ecf57fd98ee7060c4f0808416303
