Re: [Ekiga-devel-list] [info] Re: Ekiga INVITE requests are rejected by OpenIMS P-CSCF

[Damien Sandras <dsandras seconix com>]

Hello !

Le jeudi 10 mai 2007 �7:15 +0200, Dragos Vingarzan a �it :
> Great :).
> 
> So now that the introduction is done (sorry for the fuss), I think that
> there a few issues that prevents Ekiga from working as an IMS Client. I
> am reattaching the dump that Sergey Mikhanov has posted to both Ekiga
> and Open IMS Core lists.
> 
> 1. The SUBSCRIBE message in packet 2 is sent too early. In IMS you are
> supposed to complete first your registration. This is because a special
> "border" and outbound proxy called P-CSCF (Proxy-Call Session Control
> Functions) will keep track of all registration and will only allow users
> to use identities that have been authenticated. So nothing else then
> REGISTER requests will be accepted until the registration completes.

I am currently working on incorportating basic presence using SIMPLE in
the CVS HEAD of OPAL and Ekiga. This code only sends SUBSCRIBE requests
when the registration is successful. You can thus consider this problem
has fixed.

> 2. It seems that Ekiga switches ports... Or it seems so from the trace
> (haven't tried it myself). That would be OK, but you need to provide in
> the REGISTER all the contact addresses that you are going to use, as for
> security reasons (to prevent impersonation) the identities are linked to
> the contacts.
> 

We can not determine in advance what ports will be used in the future.
But in next release, the Contact header will not change from PDU to PDU.
In the future, Craig will be working on an enhancement allowing to reuse
the same port for all transactions. That "problem" is known, and will be
fixed as soon as possible.

> 3. It seems that there is no support for RFC3608 - Service-Route. This
> is not mandatory, but it would be nice to have. The Open IMS Core can
> deal with both compliant or non-compliant clients.
> 
> Oh and there is something else that you might want to implement in this
> direction is the AKA v1/2 MD5 authentication - we have contributed the
> client side in the SIPp project, so you could take it directly from
> there (RFC 3310/4169).

sipp is GPL, OPAL is MPL, we need to reimplement. Is that something you
could do ?

Thanks !
-- 
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   NOVACOM         : http://www.novacom.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras ekiga net