[asterisk-bugs] [JIRA] (DAHLIN-338) dynamic SPAN

[Shaun Ruffell (JIRA)]

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

Shaun Ruffell updated DAHLIN-338:
---------------------------------

    Target Release Version/s: 2.10.0

> dynamic SPAN
> ------------
>
>                 Key: DAHLIN-338
>                 URL: https://issues.asterisk.org/jira/browse/DAHLIN-338
>             Project: DAHDI-Linux
>          Issue Type: New Feature
>      Security Level: None
>          Components: dahdi (the module), dahdi_dynamic
>    Affects Versions: 2.9.1.1
>            Reporter: Pavel Selivanov
>            Assignee: Russ Meyerriecks
>      Target Release: 2.10.0
>
>         Attachments: dahdi-linux_tdmox.patch, dahdi-linux_tdmox_v1.patch, dahdi_tdmox.r799.tar.gz, dahdi_tdmox_r818.tar.gz, dahdi-tools_tdmox.patch
>
>
> Dear all,
> I am looking how to support dynamic SPANs in dahdi_genconf & FreePBX dahdiconfig module (Elastix, Trixbox, AsteriskNow,...).
> Seems like I will have to code a lot, produce a lot of patches with low chance for submitting them in trunks.
> The main problem - is the way dynamic was designed.
> dynamic SPAN's are allocated in system.conf. That's the file, dahdi_genconf should generate.
> Moreover, all other devices (SPANs) are absolutely the same for DAHDI, but not the dynamic SPAN.
> It is even initialized with a separate code in dahdi_cfg (DAHDI_DYNAMIC_CREATE, DAHDI_DYNAMIC_DESTROY).
> I'd like to implement an alternative dynamic SPAN implementation, similar to Xorcom's XPP implementation.
> dynamic.conf - configuration file, used to register SPAN.
> dynamic=eth,eth0/00:02:b3:35:43:9c,24,0
> I can extend functionality and describe SPAN & channels:
> SPAN signalling (CAS/CCS)
> supported signalling on channels (LoopStart, ...)
> e.t.c.
> After loading configuration, /proc/dahdi/N will present enought information, to make dahdi_scan, dahdi_genconf & FreePBX happy.
> As happy, like they have local card with local SPAN.
> The question is - do I have a chance to submit that alternative "dynamic" implementation to the trunk ?
> In other words, should I take about your coding style ?
> Thank you.



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