Hi Jyoti, I give you in this email a hint of what you can try and most probably it works but I can't be 100% sure. The reason for this is I haven't been involved in the current implementation of the Kamailio P-CSCF Rx interface. That Rx AAR which happens during registration is called in the standards "subscription to notification of IMS signaling path status", "subscription to notification of Change of IP-CAN Type", "Provisioning of SIP signaling flow information" and "subscription to notification of change of PLMN id" they are all optional features.  There doesn't seem to be a straightforward way to deactivate them in the current Kamailio P-CSCF (would be easy to implement a parameter for that) so I am going to suggest you the hard way and I expect that there is no dependency later when the other Rx functions are called (when Provisioning of Session Information during the INVITE etc.).  There shouldn't be any consequence of doing this that I suggest here, but I don't know in the current implementation, it probably takes less time if you try it out and see if there is any problem. In the config file that has the routing logic of the REGISTER just comment out the logic associated with the Rx interface. If you are using the default one like in https://github.com/kamailio/kamailio/blob/master/misc/examples/ims/pcscf/ro… its the lines 27 until 65. You see that there is a ifdef WITH_RX there but you want to have WITH_RX set because later in the processing of the INVITE is this same define the one that controls the provisioning of session information to the PCRF. An interesting note if there is any mantainer of these features, the AAR creates a session in the PCRF, if the AAR is sent when receiving the REGISTER instead of when receiving the 200 OK to the REGISTER, the session needs to be removed (by sending an STR) if the REGISTER is not successful. There is no such logic in the current Kamailio P-CSCF.  In TS 29213 Annex B.1 3GPP shows some of these flows (subscription to notification to signaling path status, provisioning of signaling flow information) ocurring when receiving a 200 OK to a REGISTER instead of when receiving the REGISTER itself. That would be in my opinion more appropriate (generates less signaling), although 3GPP does depict subscription to notiifcation of IP-CAN change and subscription to notification of PLMN id change as happening upon receipt of REGISTER instead of the 200 OK. That seems to me just 3GPP trying to make everyone crazy Best regards alberto El 10/01/2022 a las 17:15, Jyoti Bansal escribió: