[asterisk-dev] Channel driver API question

[Lorenzo Miniero]

Hi Kevin,

we talked some time ago on the developers' mailing list about a 
conferencing project I'm involved in (Confiance), which envisages 
enhancements upon the MeetMe application.
I write you because we encountered some obstacles in our development, 
which are mainly related to how the Asterisk channel driver API actually 
works, and so I'm really interested in your opinion about the subject.
I'm putting the mailing list in copy to this mail since I think it can 
be of interest to other developers too, whose opinion is welcome as well.

Our conferencing framework envisages the use of other protocols besides 
the CSP (call signaling protocol) used to join the conferences. In fact 
we added support for the BFCP (Binary Floor Control Protocol) and MSRP 
(Message Session Relay Protocol). The problem is that both these 
protocols require some mechanisms in order to let the joining 
conferencing client know how to contact the server and exploit them. In 
the IETF there's a standard way to handle this by means of what is 
called a COMEDIA negotiation: the new protocol connection is basically 
negotiated as if it were a media in a SIP/SDP re-INVITE.
This of course gave us some problems, since with the channel API 
abstraction:

	1) we couldn't choose what had to appear in the SDP of messages;
	2) we couldn't force a re-INVITE.

It is, obviously, normal we couldn't do this, since the ast_channel API 
is conceived in order to allow maximum indipendence from the underlying, 
private, channel technology behind. This forced us to do some kinds of 
*hack*, by basically improperly exploiting the ast_indicate_data method 
in app_meetme to pass our "indications" to a modified chan_sip (e.g. the 
BFCP identifiers to give to the client), and thus have chan_sip take 
note of the indication and set the SIP_NEEDREINVITE flag to build a 
custom re-INVITE. All this actually works, bus as I told it's quite a 
hack and probably all but the best solution to handle this.

Is itt currently possible in Asterisk to have more freedom/power/control 
upon the underlying private signaling technology in any other way? if 
not, are there any plans to do it, by for example extending the 
currently available API stack regarding channel drivers? I'm aware of 
the fact that Asterisk is pretty much a phone-based application, and 
that the channel API is conceived to ease the work of developers in 
order to allow them to just attach two channels and masquerade all the 
gatewaying functionality behind; however, I actually think that a bit 
more control about when and what to send according to a specific channel 
technology could be useful to many people, since I'm sure we're not the 
only ones who have come in need of such a feature.

Thanks in advance, hope to hear you soon,
Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: lorenzo.miniero at unina.it