Re: [GnomeMeeting-devel-list] IAX2 In Ekiga

[Julien PUYDT <jpuydt free fr>]

Damien Sandras a écrit :
> I would say that the main part will be to write / finish the IAX2 code
> in OPAL, either new code, or reusing the current code so that all
> features that you see in SIP and H.323 are also available for IAX2.
>
> Your first project will be to look the limitations of the current code
> and write a document showing what features you have tested, what work is
> required to complete them, and what new work is required for new
> features (Call Hold, Call Transfer, Registering, Call Forward, ...).
>
> Writing the endpoint in Ekiga is the last part of the project once the
> code in OPAL is full functional. Ekiga only contains high-level code.

I don't fully agree with you: writing low-level code all summer long 
then finally writing the upper-level code, will lead to a non-working 
feature :-/

Having a least minimal functionality in ekiga would be nice to test the 
low-level regularly, and see it improving.

> > One key problem I have identified is the accounts code.  The protocols
> > are tightly integrated with how it works.  I could either refactor this
> > code to loosen the integration or hack iax2 support in there and
> > refactor it later ;).  The advantage of this refactored will be when
> > someone wants to add Xmpp/libjingle support, or some other protocol down
> > the track.
>
> I would concentrate first on IAX2 in OPAL, then on IAX2 in Ekiga, and
> finally perhaps to a refactoring of the accounts code as it is not the
> primary purpose of the Google SoC :)

Indeed, the purpose is the IAX2 support, not refactoring the code. I 
would say that hardcoding the IAX2 account setup in the code would be 
enough for the SoC.

Making it work in the ui in the accounts would be bonus if you had the 
time, or would be a work to do afterwards.

Snark