[asterisk-bugs] [JIRA] (ASTERISK-20899) Dundi Lookup for Other Channel Drivers returng OTHER/[Mapping]

[Diederik de Groot (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-20899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Diederik de Groot closed ASTERISK-20899.
----------------------------------------

    Resolution: Workaround Available

Mappings only have to include trunk channel types

> Dundi Lookup for Other Channel Drivers returng OTHER/[Mapping]
> --------------------------------------------------------------
>
>                 Key: ASTERISK-20899
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20899
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: PBX/pbx_dundi
>    Affects Versions: 1.8.19.1, 10.11.1, 11.1.2
>            Reporter: Diederik de Groot
>            Severity: Minor
>         Attachments: pbx_dundi_(trunk-378644).diff
>
>
> When using a channel driver besides IAX2/SIP/H323 the result from DUNDILOOKUP contains OTHER/[mapping], instead of just the mapping. 
> For example when using the chan-sccp-b channel driver, which does the appropriate regcontext setting for dundi to be able to lookup the extension. And having a mapping like:
> local => sccpregistration,0,NONE,SCCP/${NUMBER},nopartial
> local => sipregistration,0,SIP,${NUMBER},nopartial
> in dundi.conf
> Instead of DUNDILOOKUP(1234), returning OTHER/SCCP/1234 when it is able to find the record. It would be nicer to return SCCP/1234 instead. So that the returned string can be used a dial command directly. Instead of having to examine the returned string to see if it returned OTHER and cut that part of.
> Changing Dundi to make it possible to register new channel tech for this purpose would/might be to difficult. Using the mapping above the needed result is returned and would even be usable in a Switch if only for the "OTHER" string at the start. 
> A simple change in pbx_dundi.c would make this possible.



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