[asterisk-dev] GSM trunks & Dahdi - New funcionality Request for discussion

[Odicha]

Kai Hoerner escribió:
> Hi Odicha/Jose,
> 
> i like A), because i think it's more clean to have an implementation 
> uncoupled from libpri. Did you already take a look at "libgsmat"? Maybe 
> it's possible to use this one. (i didn't check that, just a suggestion)
> 
> B) would mix up GSM/AT with PRI/ISDN implementation. It's cleaner design 
> to have different implementations for different protocols.
> Considering what you wrote, conditional code would have to be inserted 
> in libpri to handle GSM/AT specifics, which could complicate debugging 
> of ISDN/PRI  related problems.
> 
> I also prefer 1) over 2) because i think it's less confusing and easier 
> to debug if you do the mapping between "standard AT" and "vendor AT" 
> directly in the hardware driver module. The device driver module would 
> then be a single point for vendor specific implementation.
> (dont forget: the longer your chain, the more stations you will have to 
> debug if there are problems)
> 
> That way anyone could write device drivers and would not have to add 
> vendor specific code to the AT library.
> New drivers can be installed without updating and recompiling the AT 
> library.
> 
> Also, this would allow for closed source drivers, since no 
> implementation would have to be done in the open source AT library.
> Everything vendor specific should be done in the device driver.
> 
> just my 2 cents.
> 
> Regards,
> Kaii
> 

Ok. Thinking...

I have seen now a case where this struct could fail.
I have a card branded X with a "cool & sexy" feature.
How do we enable it?
For example a card with multisim support. how could we do this?

I answer myself. New version of library...

Well, nor cool & sexy things yet.

What would we need?

make & receive calls (basic) call waiting perhaps... or three way call
Enable a card via pin
Reset span or full card
look at network registers (coverage provider...) This could be something
like "sebi show span n", instead of timers values, we show all GSM net
values we can get.
& sms nightmare... at library level... receive sms and send sms. But
what do we do with the sms? store it, make a warning?
I think this only is useful on small pbxs. If I want to send 500 sms per
hour, there're another softs for it. (thinking... only thinking...)


> 
> Odicha wrote:
>> Tzafrir Cohen escribió:
>>   
>>> On Thu, Nov 19, 2009 at 02:03:38PM +0100, Kai Hoerner wrote:
>>>     
>>>> Hi Jose,
>>>>
>>>> there are already great efforts made by "Odicha" to integrate support 
>>>> for GSM cards and modems into DAHDI. Please have a look at the mail-archive.
>>>>
>>>> This is already working with a few devices, but is still alpha quality.
>>>> If you intend to make own efforts in GSM support, i suggest you jump 
>>>> into that project.
>>>>
>>>> You may write an eMail to Odicha and ask for SVN/CVS access (if he has 
>>>> source control):
>>>>
>>>> odi at odicha.net
>>>>       
>>> Right, that indeed should be done ASAP.
>>>
>>> Odicha, would you mind granting such access to "Jose A. Deniz"
>>> <odi at odicha.net>? ;-)
>>>
>>>     
>> BTW. What do you think about this, Tafrir? A) B) or more ideas?
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>   
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev