Hi Kamal,

Yes there are changes. For example, there is no such module called pcscf anymore ;). We have effectively broken IMS functionality into smaller building blocks, like:

diameter_rx (this is the PCRF Policy control interface to the PCC) - used to be in pcscf.so
diameter_cxdx (module which would be used by an I/SCSCF - for talking to HSS) - used to be in pcscf.so/scscf.so/icscf.so
diameter_rx (online charging module for realtime billing)

These modules can then be loaded and used from withing the config file, so based on your config you can make your kamailio into a P/S/I CSCF depending on what you want to do.

The old pcscf stores dialog, contacts, registrar, pcc sessions, etc. These are now instead using existing functionality in std kamailio modules like registrar, usrloc, dialog, etc

So to answer you question, yes it will look very different!

We hope that this will help us better integrate IMS extensions into standard kamailio without duplicating functionality already there.

Cheers
Jason

On Fri, Oct 14, 2011 at 10:13 AM, kamal koubaa <kamal.koubaa@gmail.com> wrote:
Hi Jason,

Will the P-CSCF module and its config file be changed a lot from the
actual one ?
Can you tell us the main changes?

Thanks,
With regards
 Kamal


On Fri, Oct 14, 2011 at 7:42 AM, Jason Penton <jason.penton@gmail.com> wrote:
> Hi guys,
>
> To fix the std IMS extenstions, simply remove the Client_Ro module from
> Carsten's. This is a module we wrote which we gave to Carsten a while back.
> It requires some internals of the dialog module to be exposed via the API,
> like get_dlg, un/ref, etc. We are busy re-writing the Ro module based on a
> new dialog module that we have written. We are planning to start pushing all
> of our changes to a separate branch early next week.
>
> However, in the meantime, it would probably be best to simply remove
> Client_Ro from Carsten's branch and use his branch. Our branch will be
> *very* different from the std. openimscore code. We set out to re-use
> existing functionality of the Kamailio platform, for example, dialog,
> usrloc, registrar, etc. So effectively, our branch will not be what you are
> used to, but would welcome testers and developers alike to jump into the
> branch once we push it, and hopefully we can get everything in before 3.3.0
> :D
>
> I don't think there will be much use for people to use our Client_Ro just
> yet anyway as you will need an OCS (online charging server), which is not
> part of the openimscore, so removing it from Carsten's branch to compile
> wont cost you any openimscore-specific functionality.
>
> Hope this helps
> Cheers
> Jason
>
> On Thu, Oct 13, 2011 at 11:54 PM, kamal koubaa <kamal.koubaa@gmail.com>
> wrote:
>>
>> Hello all,
>>
>> Alexis, in an other topic in the mailing list : subject "IMS branch",
>> Jason said they'll release their last work in the few coming days, so
>> we keep waiting.
>>
>> me too had the same errors when trying to compile kamailio with ims
>> modules, these are the errors :
>> CC (gcc) [M Client_Ro.so]               ccr.o
>> CC (gcc) [M Client_Ro.so]               diameter_ro.o
>> CC (gcc) [M Client_Ro.so]               ims_ro.o
>> ims_ro.c: In function ‘send_ccr_interim’:
>> ims_ro.c:594:42: error: ‘AVP_EPC_User_Equipment_Info_Type_MAC’
>> undeclared (first use in this function)
>> ims_ro.c:594:42: note: each undeclared identifier is reported only
>> once for each function it appears in
>> ims_ro.c: In function ‘send_ccr_stop’:
>> ims_ro.c:749:42: error: ‘AVP_EPC_User_Equipment_Info_Type_MAC’
>> undeclared (first use in this function)
>> ims_ro.c: In function ‘Ro_Send_CCR’:
>> ims_ro.c:831:17: error: ‘struct dlg_binds’ has no member named ‘get_dlg’
>> ims_ro.c:835:15: error: ‘struct dlg_binds’ has no member named ‘unref_dlg’
>> ims_ro.c:886:42: error: ‘AVP_EPC_User_Equipment_Info_Type_MAC’
>> undeclared (first use in this function)
>> make[1]: *** [ims_ro.o] Error 1
>> make: *** [modules] Error 1
>>
>>
>>
>>
>> From now till getting the new release, I'll try to remove the parts
>> that generate such errors and see if i can compile it. If you have any
>> other suggestion, it would help a lot.
>>
>> Thank you guys.
>> Kamal
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev