[asterisk-bugs] [JIRA] (ASTERISK-28233) pbx_dundi: PJSIP is not a supported technology

[Rhys Hanrahan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246594#comment-246594 ] 

Rhys Hanrahan edited comment on ASTERISK-28233 at 3/18/19 10:42 PM:
--------------------------------------------------------------------

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 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: 61299998888 at 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.

Thanks for your input.

Rhys.


was (Author: rhys):
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 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: 61299998888 at 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.

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.

Thanks for your input.

Rhys.

> pbx_dundi: PJSIP is not a supported technology
> ----------------------------------------------
>
>                 Key: ASTERISK-28233
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28233
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: PBX/pbx_dundi
>    Affects Versions: 15.3.0
>            Reporter: Kirsty Tyerman
>            Assignee: Kirsty Tyerman
>            Severity: Minor
>              Labels: pjsip
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)