Re: [SR-Users] Kamailio IMS_QOS

Hi all, Once again, thank you all for the Help. I have one last question, can I use the function Rx_AAR_Register without save the usr location information on ims_usrloc_pcscf? that is because I'm already using the usrloc module with dmq_usrloc. I know that ims_usrloc_pcscf is a dependency of ims_qos, but the doubt here is if I don't use the ims_registrar_pcscf, the usrloc_pcscf won't be used to store usr location? And the ims_qos will works correctly? BR José Seabra 2016-04-22 23:46 GMT+01:00 Ivailo Dobrev < &lt;ivailod(a)telera.eu&gt; ivailod(a)telera.eu&gt;gt;: > Hi Jason, > > It is always better when code "guru" shares his opinion :) > > Cheers gents ! > > > > On 04/23/2016 01:35 AM, Jason Penton wrote: > > Hi gents, > > we do not support the preliminary service information. So for now you > can only call Rx_AAR when you have SDP in the replies. So for VoLTE > (preconditions), for example you can call on 183 SP whilst using plain SIP > you will have to call on the first reply you get that has SDP (either 183SP > or 200OK). > > HTH > > Cheers > Jason > > On Fri, Apr 22, 2016 at 11:11 PM, Ivailo Dobrev < &lt;ivailod(a)telera.eu&gt; > ivailod(a)telera.eu&gt; wrote: > >> Yes you send both direction media information to the PCRF but when >> reply is received in precondition state. >> >> >> On 04/23/2016 12:03 AM, José Seabra wrote: >> >> 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 < &lt;ivailod(a)telera.eu&gt; >> ivailod(a)telera.eu&gt;gt;: >> >>> 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 [ &lt;sr-users-bounces(a)lists.sip-router.org&gt; >>> mailto:sr-users-bounces@lists.sip-router.org >>> &lt;sr-users-bounces(a)lists.sip-router.org&gt;] *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><sr-users@lists.sip-router.org> >>> &lt;sr-users(a)lists.sip-router.org&gt; >>> *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 listsr-users@lists.sip-router.orghttp://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>sr-users@lists.sip-router.org >>> <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >> >> >> -- >> Cumprimentos >> José Seabra >> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://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>sr-users@lists.sip-router.org >> <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> > > > -- > > *Jason Penton* > *Senior Manager: Applications and Services* > *Smile Communications Pty (Ltd)* > > > *Voice: Mobile:* +234 (0) 702 000 000 7 > > +27 (0) 83 283 7000 <%2B27%20%280%29%2083%20283%207000> > *Skype:* jason.barry.penton > <jason.penton@smilecoms.com>jason.penton@smilecoms.com > <http://www.smilecoms.com>www.smilecoms.com > > > > This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- Cumprimentos José Seabra _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users