Inboundmapping API

50 views
Skip to first unread message

Michael Suiter

unread,
Sep 16, 2021, 9:25:47 AM9/16/21
to dSIPRouter
This may be a feature request, I read through the API python code and didn't see how to do it but I don't know python.
  1. Is there a way to send an inboundmapping PUT json with multiple requests, so we can bulk add DIDs with one API Call? Any "duplicate" error messages would need to include the DID that was found to be duplicated, or we can construct the json just like the inboundmapping GET response with numeric array keys.
  2. Is there a way we can make a request that does an UPSERT, where it updates a record if a matching record already exists but creates it if it doesn't already exist? Currently I would have to PUT, and on error send a separate POST

Michael Suiter

unread,
Sep 16, 2021, 9:29:12 AM9/16/21
to dSIPRouter
I meant to add a blurb about what I am doing, I am creating an app in fusionpbx that will inject all of the DIDs into dsiprouter. I have a setup with multiple fusionpbx servers with a shared database, but I need to define which DIDs go which server as their primary and be able to update them on the fly. The app also integrates into Amazon Route53 API to update the DNS for customers so the endpoints connect to the correct node, that part is already fully functional just adding in the DID mapping component as well so the calls hit the same node as the customer.

Mack Hendricks

unread,
Sep 16, 2021, 9:38:14 AM9/16/21
to Michael Suiter, dSIPRouter
Let me look at this and let you know how we can prioritize this.

--
You received this message because you are subscribed to the Google Groups "dSIPRouter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dSIPRouter+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dSIPRouter/490107a9-0188-4abd-9892-d1acc8edf752n%40googlegroups.com.

Michael Suiter

unread,
Sep 16, 2021, 4:15:59 PM9/16/21
to dSIPRouter
I've been working with your API all day, and I think the single biggest issue is that you are using "PUT" as if is an UPDATE action, when its true intention is when you have to PUT something like a file to a server somewhere, that's what PHP's CURL library is assuming based on its docs.

Ideally our "Action" would be defined in the JSON of the POST request, like {"action": "update", "data": [ "did":"1313","servers"["#16"],"name":"1313 DID"]}, or some deeper array structure to have more entries that can be updated/added/upserted in the same request.

Mack Hendricks

unread,
Sep 16, 2021, 5:40:05 PM9/16/21
to Michael Suiter, dSIPRouter
Hey Michael,

We following this mapping of HTTP verbs to CRUD (Create, Read, Update and Delete) mappings: https://www.restapitutorial.com/lessons/httpmethods.html

I'm looking into the inboundmapping API right now


Michael Suiter

unread,
Sep 16, 2021, 5:50:10 PM9/16/21
to dSIPRouter
Ah, makes sense. I'm still new to the whole API thing, just basing my knowledge on what I have used so far which has been fairly limited. My most extensive API usage isn't even directly with the API, it's through Amazon's AWS SDK. I think I have a working version of the app I'm trying to create that will Push all Destinations from fusionpbx into dsiprouter via the API, and to get the status of a domain I just get the entire inboundmapping from dsiprouter and handle it in PHP code checking it against each domain's DIDs to see if they are mapped yet.
Do you think I will run into any limits as we get more and more DIDs into this setup, such as performance issues in dsiprouter or with the API? I could probably pretty quickly convert to making a separate API call for each DID on each domain as I am refreshing the sync status if you think there are going to be any limitations.

I'll probably have my code up to publishing an initial version on github tomorrow, right now there are too many constants in the code, gotta get all the variables/default settings going. It's a fairly narrow focus, because it relies upon a user of it to both be using Route53 DNS and dsiprouter as their SBC and just has a single button to update dns and update dsiprouter inboundmappings on a per-domain basis.

Michael Suiter

unread,
Sep 17, 2021, 2:51:56 PM9/17/21
to dSIPRouter
I've got the initial rough version of my code, it works with Route53 and dsiprouter.

Michael Suiter

unread,
Sep 17, 2021, 2:52:57 PM9/17/21
to dSIPRouter
https://github.com/demonspork/fusionpbx-app-cluster_manager forgot to post the link. It's very rough and doesn't handle errors well, in fact if you try to click update without checking anything it just errors out, but it's a start.

Mack Hendricks

unread,
Sep 17, 2021, 7:05:02 PM9/17/21
to Michael Suiter, dSIPRouter
Good stuff - I will check this out.  I’m putting in a feature request for multi update API for the inbound mapping API

Mack Hendricks
Chief Flyball
dOpenSource / DetroitPBX, Flyball Companies 
Direct: 313-789-1313 (SMS Enabled)

On Sep 17, 2021, at 2:52 PM, Michael Suiter <demon...@gmail.com> wrote:

https://github.com/demonspork/fusionpbx-app-cluster_manager forgot to post the link. It's very rough and doesn't handle errors well, in fact if you try to click update without checking anything it just errors out, but it's a start.

Michael Suiter

unread,
Sep 23, 2021, 8:54:39 PM9/23/21
to dSIPRouter
The inboundmapping API doesn't return information about or have a method to modify a hard forward. If I update a mapping via the API, the hard forward is unaffected which is good until we have the ability to check for it/modify it via the API.

In the process of testing that out I discovered a bug with using VI and Hard Forwards.

If an INVITE comes from one of the IPs in the VI Inbound Only carrier group, dsiprouter complains that there is no rule found for it if it is configured to Hard Forward using the VI Outbound only carrier group. This seems to be because a hard forward requires the incoming call to be in the same carrier group as the outgoing call? I can't seem to select any carrier group but the group that the call is going to be received from, and since VI has very little overlap between servers that allow termination and servers that originate calls, this causes problems.
Reply all
Reply to author
Forward
0 new messages