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 <ivai...@telera.eu>: > 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 <ivai...@telera.eu> 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 < <ivai...@telera.eu> >> ivai...@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 [ <sr-users-boun...@lists.sip-router.org> >>> mailto:sr-users-boun...@lists.sip-router.org >>> <sr-users-boun...@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><sr-users@lists.sip-router.org> >>> <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 >>> listsr-us...@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 >>> 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-us...@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 >> 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 > *Skype:* jason.barry.penton > <name.surn...@smilecoms.com>jason.pen...@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-us...@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 > 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
