3 Nov
2011
3 Nov
'11
12:57 p.m.
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(a)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(a)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(a)gmail.com>
wrote:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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(a)gmail.com>
wrote:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev