Hi Klaus,
Yes, it is quite necessary. The P-CSCF's main functionality is to firewall the home domains. As such, it has to maintain a registrar for those users and that has to be a reversed one - it is not resolving identities to contacts but contacts to identities. This registrar is kept in sync with the one on the S-CSCF by P-CSCF subscribing to the "reg" event at the S-CSCF (see RFC3680).
Also it is responsible for the securing the communication with each individual client and of course for making sure that all UEs play nice by following Service-Routes and Record-Routes and by not injecting any attack traffic into the IMS core network.
The path extension is there already. On the P-CSCF it's a matter of adding it to REGISTER. Then the S-CSCF uses it when routing any requests towards the P-CSCF and the P-CSCF uses it to identify the session case. The processing of requests is quite twisted and my config files are already quite long.
Also adding more things to the Path is possible, like a Topology Hiding node, used to hide the information from the visited network.
-Dragos
Klaus Darilion wrote:
Dragos Vingarzan wrote:
On this topic, some parts of other modules are pasted in. For example the pcscf includes some nathelper functionality. I know that the best thing would have been to just use the nathelper module, but the pcscf has its own reversed-registrar, as usrloc is not suitable.
Hi Dragos!
Is it really necessary for the PCSCF to have a location table? I thought the Path: extension will take care of routing incoming calls to the clients and stateless proxies can be used as PCSCF.
btw: do you have added support for the Path extension?
regards klaus