Hey Jason, Thanks for these valuable information, I've got the point, and it's indeed interesting. But I suppose that, in this case you'll need to provide users with documentations that shows what are the building blocks and how to configure them to get to a specific CSCF. For my case this is quite interesting and challenging at the same time. Interesting because am going to need to build some special IMS agents that interact directly with I-S-CSCF through the Mw interface, they act like a P-CSCF but they are not really P-CSCF. Challenging because I'll have to do that inside a module that I may call AGCF, so that I have to call some P-CSCF function from that module, and that won't be done through a config file. the IMS agents that are part of the AGCF module would do registration of H.248 users on behalf of the MGC. If I manage to do that, it would become possible to do PSTN/ISDN emulation, as describe in :
www.etsi.org/deliver/etsi_ts/182000.../ts_182012v020104p.pdf
page 11.
Chears, Kamal
On Thu, Nov 3, 2011 at 11:08 AM, Jason Penton jason.penton@gmail.com wrote:
Hey Kamal, The idea behind the new design is that there will not be 1 module for PCSCF, 1 for SCSF, 1 for ICSCF, etc. Instead the individual logical components that make up functionality of a PCSCF is released as a module. So effectively, you can build a P/S/I CSCF based purely on config file and the appropriate functions/modules you require. For example, if you want a PCSCF to do PCC, you will load the diameter_rx module and call Rx_AAR before you setup a call (on_reply route block getting RTP). The diameter_rx module we have released will apply for QoS from PCRF and monitor the dialog (using dialog2) and tear it down should QoS disappear, etc, etc. This will allow us to re-use functionality where necessary across the modules, as opposed to the way it is now where functionality is replicated in all 3 modules. It also makes it a heck of a lot easier to manage the bite-size chunks of functionality in their individual modules. Hope that makes sense. p.s. this will most likely be quite a long task and we are def. still in alpha stage so don't expect thing to be rock solid just yet. maybe another few iterations on the code released so far, but with help from you and others we could progress quite quickly Cheers Jason
On Thu, Nov 3, 2011 at 11:59 AM, kamal koubaa kamal.koubaa@gmail.com wrote:
Hi, Great !!!, I'll wait for that, is the built P-CSCF will be of the new design or the old one, because I see no pcscf module in your branch?
Thanks a lot, Kamal
On Thu, Nov 3, 2011 at 10:54 AM, Jason Penton jason.penton@gmail.com wrote:
Hi Kamal, Yes it should work. I am just busy with something else at the moment, but I will attach a pcscf example cfg file before the end of the day (GMT+2) ;) It will be great to get your feedback on your testing! ;) Cheers Jason On Thu, Nov 3, 2011 at 11:37 AM, kamal koubaa kamal.koubaa@gmail.com wrote:
Hi Jason,
Is it possible at this point to build a working P-CSCF using the source on your branche ?. If so you have a working config file for that, I would like to use it to access an I/S-CSCF in an existing IMS core. If the actual code could do that, it would help a lot.
Regards, 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev