[asterisk-users] Geo location 18.14.0-rc1 question

[George Joseph]

The email was getting too long for the mailing list so I've truncated it.
Anyway...

Dan, Have you tried using the GEOLOC_PROFILE dialplan function to create a
profile on the fly?  I'm not sure how this would fit into your use of
Originate but...

Create a dummy geoloc profile.
[<passthrough>]
type=profile
profile_precedence=discard_config

In pjsip.conf, set
geoloc_outgoing_call_profile = <passthrough>
on the outgoing channel.

Either in the dialplan or via the Originate (I forget how) call
GEOLOC_PROFILE.  Here's what it'd look like in the dialplan...

[geoloc_callee]
exten = s,1,NoOp(); CID: ${CALLERID(all)}  CL: ${CONNECTEDLINE(all)})
same  = n,Set(GEOLOC_PROFILE(format)=civicAddress)
same  = n,Set(GEOLOC_PROFILE(location_info)=country=US,A1=Colorado)
same  = n,Set(GEOLOC_PROFILE(pidf_element)=device)
same  = n,Return()

[default]
exten  = 911,Dial(PJSIP/upstream-carrier,20,b(geoloc_callee^s^1))

Not sure if this helps.  I am working on the other suggestions though.


On Mon, Aug 15, 2022 at 3:46 AM George Joseph <gjoseph at sangoma.com> wrote:

>
>
> On Sat, Aug 13, 2022 at 3:55 PM Dan Cropp <dan at amtelco.com> wrote:
>
>> Thank you George.
>>
>>
>>
>> rc2 did fix the issue.
>>
>
> Whew.
>
>
>>
>>
>> I am now able to program the variables in the location_info and pass
>> values via the AMI Originate variables.
>>
>>
>>
>> Is there a way to make the location_info optional?
>>
>
> I _believe_ I can allow you to specify "location" parameters directly on a
> profile which would be mutually exclusive with the location_reference
> parameter.  Let me look at it.
>
>
>>
>>
>> On the same PJSIP Endpoint, we may need to originate calls with different
>> requirements for the fields passed.
>>
>> For example
>>
>> Dialing a number for customer A, need to pass country, A1, A3, HNO, RD,
>> STS, PC, FLR and ROOM.
>>
>> Dialing a number for customer B, need to pass country, A1, A2, and A3.
>>
>>
>>
>> Is it possible to program the Profile/Location to support values for all
>> the settings, but have Asterisk ignore any settings where the value is
>> blank?
>>
>
> A good idea.  I can't think of any element that would need to be sent
> empty but I'm wondering if I'll need to add a config option like
> "suppress_empty_elements".  Let me investigate.
>
>
>>
>>
>> Right now, if I have HNO=${MYGEO_FLR} but the variable MYGEO_FLR is not
>> set, it still passes the FLR in the sip as <ca:FLR/>
>>
>>
>>
>> I believe it’s perfectly fine to send the <ca:FLR/>
>>
>> My fear is some system may interpret a blank FLR differently than the FLR
>> not being present at all.
>>
>>
>>
>> Dan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20220815/457f39ee/attachment.html>