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

[Odicha]

Tzafrir Cohen escribió:
> On Thu, Nov 19, 2009 at 12:28:18PM +0000, Jose A. Deniz wrote:
>> Hi!
>>
>> I am doing some job on GSM support at asterisk level, and I'd like make
>> some propossals and listen to your ideas.
>>
>> The requeriments I see for GSM support.
>> three layers. voice, sms & network
>> Voice support. Simple
>> Sms support. Send & Receive capabilities.
>> Network. Info of net status (coverage, provider...)
>>
>> Paths to accomplish these requeriments.
>>
>> A) New struct at chan_dahdi level (as pri or ss7) + new library (similar
>> to libpri)
>>
>> B) Use pri existent struct and add a new layer at libpri library.
> 
> Is there a good mapping between GSM networking and ISDN? If not, I guess
> (A) would be preffered to (B).
> 
> Are there such existing libraries?
> 
Not really. A sample. (from _receive after pri_check_event at libpri)

case SEBI_STATE_PRE_ANSWER:
    if (!strncmp(h, "OK", 2)) {
        if (!strncmp(pri->sent, "ATA", 3)) {
            pri_transmit(pri, "AT^DDSETEX=2\r"); /* Enable Audio */
		} else if (!strncmp(pri->sent, "AT^DDSETEX=2", 12)) {
			pri->state = SEBI_STATE_CALL_ACTIVE;
			pri->ev.e = PRI_EVENT_ANSWER;
			pri->ev.answer.progress = 0;
			pri->ev.answer.channel = c->channelno;
			pri->ev.answer.cref = c->cr;
			pri->ev.answer.call = c;
			c->alive = 1;
			return &pri->ev;
		}
	}

Mixing at commands and pri events could be a nightmare...

I think A will be the path.


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.

I think it'll be more clear. Perhaps at driver level it implies a
different way of do things but AT and PRI signalling differs a lot.