asterisk users - Jul 2022 - Question about the Geo Location support being added

Looking at the Asterisk wiki
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Geolocation+Implementation

I see the dial plan support the GeolocProfileCreate and there is support for
GEOLOC_PROFILE settings to be set on the dial plan.

We currently use AMI Originate support.  We may have dozens/hundreds of calls in
the system and external to Asterisk, someone executes a behavior where we
perform the Originate, if the party answers, we ConfBridge the necessary calls
together.  It can be multiple calls and we never know when the total calls
bridged together will need to be increased.  Because of the random increase in
calls, we can't use the Dial to bridge the parties together.

The GEO Location information for the original caller can vary significantly
because they could be WebRTC.  We are planning to require the setup of the Geo
Location for each call to be provided to us (either via the incoming call or it
may be provided from third party software).  Either way, we will know what the
GEO Location to use for the Originate.  Trying to wrap my head around the best
way to achieve this.

Using AMI Originate, is it possible to set the GEOLOC_PROFILE settings via the
Variable header?

My thought would be to configure an outgoing Geo Location profile for the PJSIP
endpoint, but it would have the minimum settings.
When sending the AMI Originate, provide all the adjustments to the
GEOLOC_PROFILE settings via the Variable.

Is this possible or might there be a better way to achieve this?


Alternatively, I could generate an internal local channel, configure the
GeoLocProfile on it, configure all GEOLOC_PROFILE adjustments on it, then have
it perform the Dial.  If the other end answers or not, treat it exactly as we
currently do using the Originate.


Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20220727/7439697b/attachment.html>

On Wed, Jul 27, 2022 at 11:02 AM Dan Cropp <dan at amtelco.com> wrote:
> Looking at the Asterisk wiki
>
>
>
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Geolocation+Implementation
>
Just FYI, I'm in the process of clarifying and adding more info.  Should be
done Friday.
>
>
> I see the dial plan support the GeolocProfileCreate and there is support
> for GEOLOC_PROFILE settings to be set on the dial plan.
>
>
>
> We currently use AMI Originate support.  We may have dozens/hundreds of
> calls in the system and external to Asterisk, someone executes a behavior
> where we perform the Originate, if the party answers, we ConfBridge the
> necessary calls together.  It can be multiple calls and we never know when
> the total calls bridged together will need to be increased.  Because of the
> random increase in calls, we can’t use the Dial to bridge the parties
> together.
>
>
>
> The GEO Location information for the original caller can vary
> significantly because they could be WebRTC.  We are planning to require the
> setup of the Geo Location for each call to be provided to us (either via
> the incoming call or it may be provided from third party software).  Either
> way, we will know what the GEO Location to use for the Originate.  Trying
> to wrap my head around the best way to achieve this.
>
A real scenario to test!!!  Thanks!
>
>
> Using AMI Originate, is it possible to set the GEOLOC_PROFILE settings via
> the Variable header?
>
I've not tested this but you don't need to do it at all...
>
>
> My thought would be to configure an outgoing Geo Location profile for the
> PJSIP endpoint, but it would have the minimum settings.
>
Actually it would have a template specifying replacement channel variables.

When sending the AMI Originate, provide all the adjustments to
the
> GEOLOC_PROFILE settings via the Variable.
>
>
>
> Is this possible or might there be a better way to achieve this?
>
>
>
It's possible but probably not needed.  Let's say you're using Civic
Address and a direct originate to the remote party via Dial.   In the
originate, you can specify regular, inherited channel variables with the
official Civic Address parameters preceded by '_'.  Let's use HNO
(house
number) as an example.   You'd set _HNO=1633 in the originate and since it
has the '_' prefix it's going to be inherited by the outgoing
channel.   In
the outgoing channel's profile/location, you'd set 'location_info
HNO=${_HNO}.  Of course there'd be more than just the HNO parameter set but
it's the same technique.  The outgoing channel has a very generic location
template populated with values received from the incoming channel.

Now, this isn't going to work if you're originating both calls and
adding
them to a bridge yourself but in this case, you have both channels at the
same time so you can just add the incoming channel's location info
directly to the outgoing channel's variables as you originate the outgoing
call.  Youdon';t need to create a new GEOLOC_PROFILE for the outgoing
channel.

All of this assumes that I actually understood your situation correctly. :)

How are you getting the caller's info in the first place?
>
>
> Alternatively, I could generate an internal local channel, configure the
> GeoLocProfile on it, configure all GEOLOC_PROFILE adjustments on it, then
> have it perform the Dial.  If the other end answers or not, treat it
> exactly as we currently do using the Originate.
>
Sounds more complicated than it needs to be.
>
>
>
>
> Dan
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>       https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20220727/03de4e8c/attachment.html>