Hello Ivailo and Franz,

Thank you for your clarifications.

Well sending an AAR when receive a reply makes all sense, but ims_qos must send the SDP information from the Initial Invite and also from 183 ringing or 200Ok,  Am I correct?

Because PCRF needs to know the session parameters from Initial Initial INVITE and the reply to it.

The PCRF is a proprietary solution. 

Thank you
BR
José Seabra


2016-04-22 21:54 GMT+01:00 Ivailo Dobrev <ivailod@telera.eu>:
Hi Franz,

There no real OS PCRF. Yota/Telexir use to had some free VM image that is OK for test. You can search about FreePCRF. It is a little tricky to configure it but ... I made for my tests a really dummy one based on FreeDIAMETER. Generally speaking PCRF is the "brain" of the network and you should understand and design things well there. I have experience also w/ commercial PCRFs and there is no real answer yes this is a right way of making something.

Cheers,

Ivo


On 04/22/2016 11:09 PM, Franz Edler wrote:

Hi José,

 

in principle it is possible to send an AAR after receiving the request. In this case the Service-Info-Status AVP is set to PRELIMINARY SERVICE INFORMATION.

More efficient is it to wait until SDP answer is received and then the Service-Info-Status AVP is set to FINAL_SERVICE_INFORMATION.

 

I don’t know if both methods are covered in ims_qos module.

 

BTW: which PCRF are you using? Is there some open source PCRF available?

 

BR

Franz

 

From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of José Seabra
Sent: Friday, April 22, 2016 3:58 PM
To: Kamailio (SER) - Users Mailing List <sr-users@lists.sip-router.org>
Subject: [SR-Users] Kamailio IMS_QOS

 

Hello There,

I'm trying using the ims_qos module with PCRF for QOS, but I'm facing some issues.

When kamailio receives an initial invite (originator), it will execute the function - "Rx_AAR("ORIG_SESSION_AAR","orig","",-1)", but the PCRF is not contacted and i see the following messages:

 5(12153) DEBUG: <script>: Diameter: Orig authorizing media via Rx
 5(12153) DEBUG: ims_qos [mod.c:609]: w_rx_aar(): Looking for route block [ORIG_SESSION_AAR]
 5(12153) DEBUG: ims_qos [mod.c:621]: w_rx_aar(): Rx AAR called
 5(12153) DEBUG: ims_qos [mod.c:1345]: create_return_code(): Creating return code of [-2] for aar_return_code
 5(12153) DEBUG: ims_qos [mod.c:1354]: create_return_code(): created AVP successfully : [aar_return_code]
 5(12153) DEBUG: ims_qos [mod.c:627]: w_rx_aar(): Can't do AAR for call session in request.

Why kamailio says  that I  Can't do AAR for call session in request?  I have looked into source code and I found that the condition that is blocking the communication with PCRF is:





//We don't ever do AAR on request for calling scenario...
    if (msg->first_line.type != SIP_REPLY) {
        LM_DBG("Can't do AAR for call session in request\n");
        return result;
    }

Anyone can help me understand why it is happening? why it can't proceed if isn't a reply?

Thank you for your support

BR

--

José Seabra



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




--
Cumprimentos
José Seabra