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

[Odicha]

Artem Makhutov escribió:
> Hi,
> 
> On Thu, Nov 19, 2009 at 07:13:29PM +0000, Odicha wrote:
>> Artem Makhutov escribió:
>>> Hi,
>>>
>>> On Thu, Nov 19, 2009 at 06:16:05PM +0000, Odicha wrote:
>>>> Tzafrir Cohen escribió:
>>>>> On Thu, Nov 19, 2009 at 03:06:00PM +0000, Odicha wrote:
>>>>>
>>>>>> In a abstraction layer environment with an own library and AT
>>>>>> translation at dahdi driver it would be somethig like this:
>>>>>>
>>>>>> case SEBI_STATE_PRE_ANSWER
>>>>>> 	if (h == CALL_ANSWER_ACK)
>>>>>> 		sebi->ev.e = SEBI_EVENT_ANSWER_ACK
>>>>>> 		....
>>>>>>
>>>>>> and the "translation" between "AT^DDSETEX=2\r" and CALL_ANSWER_ACK would
>>>>>> be done at dahdi driver level. So in hdlc frames between library & dahdi
>>>>>> won't have AT commands but our own signalling abstraction layer events
>>>>>> and frames.
>>>>> Is there a good reason to do this translation in kernel space?
>>>>>
>>>>> One potential good reason: if the driver needs to allocate resources
>>>>> that may be used by different userspace processes and needs to
>>>>> understand the AT commands in order to do so.
>>>>>
>>>> Suppose we finished this. It's working fine into trunk. Brand X (better
>>>> Y... some brands starts with X here ;-) Brand Y wants make a GSM card
>>>> for asterisk. Their GSM module has an AT commands pool different from
>>>> those that are already into the library. They might make a new module
>>>> for AT library, be tested, added to svn and later into trunk.
>>>> If we put AT translation into kernel space and work with a standard AT
>>>> abstraction layer, they can make a driver that uses existent library.
>>>> John Todd told me that a good way could be via some .conf file, but for
>>>> make the same thing one module uses one AT command and another three, so
>>>> I don't see it...
>>> Don't put this into kernel space.
>>> All AT-Command translation and "normalization" should be done in user space.
>>>
>>> All the AT commands of the Huawei sticks are not documentated.
>>> You don't know for sure what could be happend. Something unpredictible
>>> could crash the whole server.
>>>
>>> Also the debugging, installation and so on would be more complicated.
>>> You will have to recompile the kernel modules on a kernel update and so on...
>>>
>>> I don't see any reasons to put this into kernel space.
>>>
>>> Regards, Artem
>>>
>> Ok. "A" model but with AT translation into library then?
> 
> Yes, at library level. I can also imagine an external daemon for this.
> 
> The daemon could also take care about assigning the Devices based on IMEI
> to different /dev/gsmdeviceXYZ or something like that and could also provide
> this functionality for other applications other then asterisk like ppp to
> create dialup backup routes or so...
> 

But, remember this is not only for huawei sticks. There are some pci gsm
cards over there... And of course usb sticks will need a dahdi driver
(not option serial-usb driver via tty ports). I've a skeleton driver for
 E169 sticks. It creates one span with one clear (b) channel and one
hardhdlc (d) channel. Mixing dahdi & tty ports doesn't seem to me a good
idea.



> Regards, Artem
> 
> _______________________________________________
> --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