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

[Odicha]

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...

BTW Another question, could be possible enable slin for chan_dahdi? Most
of usb gsm devices work at slin with 20 ms frames so I have to read one
frame from device, convert audio, send and receive audio chunks from
dahdi and then write a frame to modem. Perhaps it's seen better at code...
...
memcpy (cast_rx, modem->b_rx_buf,  MODEM_AUDIO_FRAME);
modem->b_tx_buf_idx = 0;

loops = MODEM_AUDIO_FRAME / DAHDI_CHUNKSIZE / 2 ;
for (i=0; i < loops; i++) {
	for (j=0; j < DAHDI_CHUNKSIZE; j++) {
		k = (i * DAHDI_CHUNKSIZE) + j;
		modem->dahdi_b_rxbuf[j] = DAHDI_LIN2A(cast_rx[k]);
	}
	dahdi_receive(&modem->span.span);

	dahdi_transmit(&modem->span.span);
	for (j=0; j < DAHDI_CHUNKSIZE; j++) {
		k = (i * DAHDI_CHUNKSIZE) + j;
		cast_tx[k] = (DAHDI_ALAW(modem->dahdi_b_txbuf[j]));
	}
}
memcpy (modem->b_tx_buf, cast_tx, MODEM_AUDIO_FRAME);
modem_write(modem->port[IFACE_E169_VOICE], modem->b_tx_buf,
MODEM_AUDIO_FRAME);
modem->b_rx_buf_idx = 0;
...

It's a waste of cpu cycles making the audio conv. But chan_dahdi allows
a-law or u-law. Other channels allow slin audio instead.