[Home]

Summary:ASTERISK-28233: pbx_dundi: PJSIP is not a supported technology
Reporter:Kirsty Tyerman (ktyerman)Labels:pjsip
Date Opened:2019-01-06 19:32:42.000-0600Date Closed:2023-04-10 14:38:23
Priority:MinorRegression?
Status:Closed/CompleteComponents:PBX/pbx_dundi
Versions:15.3.0 Frequency of
Occurrence
Related
Issues:
duplicatesASTERISK-28109 pbx_dundi: Does not support chan_pjsip
Environment:Attachments:
Description:PJSIP is not supported as a technology for a DUNDILOOKUP, it is reported as UNKNOWN.

I want to configure "dundi.conf" with a mapping that uses PJSIP.
{noformat}
[mappings]
test => test,0,PJSIP,${NUMBER}@192.168.1.1,nopartial
{noformat}

When I query the mappings on the CLI it displays as an unknown technology.
{noformat}
*CLI> dundi show mappings
DUNDi Cntxt  Weight  Local Cntxt  Options    Tech  Destination              
test         0       test         NONE       Unkno ${NUMBER}@192.168.1.1
{noformat}

PJSIP should be a valid technology and should be able to be called via a returned DUNDILOOKUP.
Comments:By: Asterisk Team (asteriskteam) 2019-01-06 19:32:43.818-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Kirsty Tyerman (ktyerman) 2019-01-06 22:42:18.224-0600

Added patch: https://gerrit.asterisk.org/#/c/asterisk/+/10855/
By: Kirsty Tyerman (ktyerman) 2019-01-08 19:43:17.190-0600

As PJSIP cannot dial a target at an IP address, the proposed solution would require a configuration of a PJSIP endpoint to be dialed.
The "dundi.conf" on Asterisk Server A could be configured as such:
{noformat}
[mappings]
test => test,0,PJSIP,${NUMBER}@ServerA,nopartial
{noformat}

The "pjsip.conf" on Asterisk Server B would need a PJSIP endpoint configured with the name "ServerA" to point to a PJSIP endpoint configured on Server A to accept calls from Server B.

When a lookup is done from Server B, if there is a result the DUNDILOOKUP will respond with a PJSIP dial response. This will dial the target at the PJSIP endpoint that Server A has responded with in the mapping. Since ServerB has ServerA configured in "pjsip.conf" it will be able to call Server A. Any other servers would need a "ServerA" configuration in their "pjsip.conf" configuration, otherwise the DIAL will fail with the following result "Unable to create PJSIP channel - endpoint 'ServerA' was not found".
By: Rhys Hanrahan (rhys) 2019-03-18 22:40:03.998-0500

Hi Everyone,

I have been looking at this bug and in particular the code review page: https://gerrit.asterisk.org/c/asterisk/+/10865

We're in the process of moving to Asterisk 16 and while I got DUNDi working the way Kirsty described, it would be good to see it properly supported. I can see the point Joshua is making, and I will most likely take a stab at doing this internally - but a question. Is there a standard parser built into Asterisk that I could use to "extract" the number from a dial string? Or would I need to write a basic self-contained one to try and cover the main use cases, just for this purpose?

I suppose that each channel driver probably has it's own internal parser, and the problem would be that, to leverage those parsers, you would add a dependency on all these channel drivers, which is not ideal. So I was hoping there is something that's part of core Asterisk that can be re-used? I'm not familiar enough with the codebase to figure this out!

My rough idea  for implementing PJSIP support (based on Joshua's comments) would be:

* A user does a lookup against a peer for the number "61299998888"
* A DUNDi peer is advertising a mapping returns a dial string similar to: SIP/100.1.1.1/61299998888
* User doing the lookup adds "use_endpoint=SIP-SYD-01" to the DUNDi peer
* Nothing changes on the DUNDi peer advertising it's mapping, but on the lookup side we take the response "SIP/100.1.1.1/61299998888" and extract the number from the end.
* The lookup side then transparently converts the dial string before returning it, to: PJSIP/61299998888@SIP-SYD-01
* The side doing the lookup now has a dial string that contains the PJSIP endpoint they specified and can use this to dial out without any messing around with the lookup result, or coordinating with the DUNDi peer on the other side.
* Probably modify dundi lookup command output to show the returned string both before and after translation, if "use_endpoint" is configured, to help with debugging.

So hopefully it becomes clear that while I could implement a basic parser to try and grab the number out of most common scenarios, there's probably lots of edge cases with formatting, so just checking to see if there's a pre-existing parser that could take care of all of that.

To further clarify, I would also want to support PJSIP's format of: PJSIP/61299998888@100.1.1.1 and automatically swap the IP provided by the peer, with an endpoint. But I think it's important to support chan_sip format URLs to help ease the transition of PJSIP - as the vast majority of DUNDi peers (if you're peering publicly) will probably be using a dial string in the format first mentioned.

Thanks for your input.

Rhys.
By: Joshua C. Colp (jcolp) 2019-03-19 05:14:59.791-0500

[~rhys] There is nothing built in really for parsing Dial strings, as everyone does it differently and the meaning/layout of the Dial string is different between them. I think your approach is fine and covers what I was concerned with.
By: Rhys Hanrahan (rhys) 2019-03-19 09:44:52.176-0500

Hi Joshua,

Thanks for the feedback! Will have to find some time to put something forward.

Rhys.
By: Michael Newton (miken32) 2021-12-13 12:33:02.371-0600

[~rhys] I'm guessing this never got to the point of something you could present as a patch? If you got it working at all, is it something you'd be willing to make public? Was thinking about putting a bounty on this bug but asterisk-dev seems pretty quiet and mention of dundi is almost non-existent there.
By: Michael Newton (miken32) 2021-12-15 12:06:35.329-0600

BTW my thinking on endpoints is somewhat different, but that may be based on my use of dundi. We use it internally to route incoming calls to one of many PBXs, so having a single endpoint specified by a `use_endpoint` directive would not be helpful. The dundi response includes the PBX name or IP address, and that should be used. A better solution in my mind would be to have a `default_endpoint` directive in the config file. If the name/IP address provided by the peer can be mapped to a known endpoint, then it should be given priority but fall back to the default otherwise. So I would modify Rhys' list to look like this:


*   User doing the lookup adds "default_endpoint=SIP-SYD-01" to the DUNDi peer
*   A user does a lookup against a peer for the number "61299998888"
*   A DUNDi peer is advertising a mapping returns a dial string similar to: SIP/100.1.1.1/61299998888
*   Nothing changes on the DUNDi peer advertising it's mapping, but on the lookup side we take the response "SIP/100.1.1.1/61299998888" and extract the number from the end.
*   The lookup side then transparently converts the dial string before returning it, to: PJSIP/61299998888@100.1.1.1
*   The side doing the lookup now has a dial string that contains the PJSIP endpoint they specified and can use this to dial out without any messing around with the lookup result, or coordinating with the DUNDi peer on the other side.
*   If the dial string cannot be resolved, use the "default_endpoint" value to try a different endpoint: PJSIP/61299998888@SIP-SYD-01
*   Probably modify dundi lookup command output to show the returned string both before and after translation, if "use_endpoint" is configured, to help with debugging.


Maybe a mix of both approaches would be most flexible, so having a `force_endpoint` that's always used (if desired) or a `default_endpoint` that's a fallback.
By: Friendly Automation (friendly-automation) 2023-04-10 14:38:24.477-0500

Change 20056 merged by Friendly Automation:
pbx_dundi: Add PJSIP support.

[https://gerrit.asterisk.org/c/asterisk/+/20056|https://gerrit.asterisk.org/c/asterisk/+/20056]
By: Friendly Automation (friendly-automation) 2023-04-10 14:38:54.813-0500

Change 19702 merged by Friendly Automation:
pbx_dundi: Add PJSIP support.

[https://gerrit.asterisk.org/c/asterisk/+/19702|https://gerrit.asterisk.org/c/asterisk/+/19702]
By: Friendly Automation (friendly-automation) 2023-04-10 14:39:07.808-0500

Change 20057 merged by Friendly Automation:
pbx_dundi: Add PJSIP support.

[https://gerrit.asterisk.org/c/asterisk/+/20057|https://gerrit.asterisk.org/c/asterisk/+/20057]
By: Michael Newton (miken32) 2023-04-12 18:12:01.989-0500

Looking over the recent commits, I am having trouble understanding how a single fixed endpoint is in any way useful? The idea of dundi is to send out a request to many peers, any of which might respond with an offer to complete the call. Am I misunderstanding what an "endpoint" is in pjsip terminology?

In our network, we have incoming calls from our PSTN carrier sent to a single server. That server does a dundi query of 100 hosted PBXs, one of which responds with, e.g. "SIP/12345678@foobar_pbx" where "foobar_pbx" is configured as a dundi peer and a SIP peer with an IP address on the local network. How could this be replicated with this patch using a single fixed endpoint?

Also I am not a C programmer, but are both these things meant to be checking for an empty string? There are two opposite uses of {{ast_strlen_zero}} here.

{noformat}
if (!ast_strlen_zero(pjsip_outgoing_endpoint)) {
ast_log(LOG_WARNING, "PJSIP calls require an endpoint to be specified explicitly (use the pjsip_outgoing_endpoint option in dundi.conf)\n");
return -1;
}
/* Take IP/number and turn it into sip:number@IP */
if (ast_strlen_zero(ip)) {
ast_log(LOG_WARNING, "PJSIP destination is empty?\n");
return -1;
}
{noformat}
By: Joshua C. Colp (jcolp) 2023-04-13 03:56:52.769-0500

An endpoint in PJSIP defines the configuration to use when initiating a call to a destination. I don't believe your usage is covered currently for PJSIP, because you're using the SIP one in a way it wasn't originally made for and kind of just happens to work based on how things work in chan_sip (passing SIP peer names in returned DUNDi dial strings). Further work would need to be done to cover your specific use case.

[~InterLinked] Will you be fixing the string issue above?
By: Joshua C. Colp (jcolp) 2023-04-13 04:04:46.724-0500

I guess one way to support that use case is to indeed allow PJSIP over the wire and specify an endpoint which if you control everything does work, and with chan_sip already worked whether intentionally or not because there is no difference between dialing a SIP peer and an IP address due to the dial string being the same.
By: Joshua C. Colp (jcolp) 2023-04-13 04:11:23.063-0500

And looking at why your comments were missed, all the discussion happened on Gerrit itself. When we move to Github you'll be able to comment even without a signed license agreement so that should eliminate the chance of such comments being missed.
By: Joshua C. Colp (jcolp) 2023-04-13 04:36:42.297-0500

I went ahead and put a fix up for the empty check.
By: Michael Newton (miken32) 2023-04-13 14:51:16.050-0500

@jcolp thanks for the reply; I guess I'm thinking of an endpoint as the destination server itself, but that's really the contact or something. (PJSIP abstracts a lot of stuff which probably makes it a lot more flexible for you guys, but a lot more to learn for the rest of us.)

The same format dialstrings (tech/number@destination) are allowed for PJSIP as well, so it should work per my suggestions above. If I'm reading the code in the commit right, it would be a simple matter of allowing {{pjsip_outgoing_endpoint}} to be empty (or use a separate boolean setting like {{pjsip_use_provided_endpoint}}) and then in that case using
{noformat}
snprintf(req, sizeof(req), "%s/%s@%s,,%s", results[x].tech, S_OR(number, ""), ip, S_OR(dundiargs, ""));
{noformat}
By: Friendly Automation (friendly-automation) 2023-04-13 16:21:58.256-0500

Change 20082 merged by Friendly Automation:
pbx_dundi: Fix PJSIP endpoint configuration check.

[https://gerrit.asterisk.org/c/asterisk/+/20082|https://gerrit.asterisk.org/c/asterisk/+/20082]
By: Friendly Automation (friendly-automation) 2023-04-13 17:57:38.754-0500

Change 20067 merged by Joshua Colp:
pbx_dundi: Fix PJSIP endpoint configuration check.

[https://gerrit.asterisk.org/c/asterisk/+/20067|https://gerrit.asterisk.org/c/asterisk/+/20067]
By: Friendly Automation (friendly-automation) 2023-04-17 07:24:11.877-0500

Change 20066 merged by George Joseph:
pbx_dundi: Fix PJSIP endpoint configuration check.

[https://gerrit.asterisk.org/c/asterisk/+/20066|https://gerrit.asterisk.org/c/asterisk/+/20066]