[SR-Users] Kamailio IMS_QOS

Sun Apr 24 23:30:09 CEST 2016

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 <ivailod at 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 <ivailod at 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 < <ivailod at telera.eu>
>> ivailod at 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-bounces at lists.sip-router.org>
>>> mailto:sr-users-bounces at lists.sip-router.org
>>> <sr-users-bounces at 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 at lists.sip-router.org><sr-users at lists.sip-router.org>
>>> <sr-users at 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-users at 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 at 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-users at 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 at 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.surname at smilecoms.com>jason.penton at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>

-- 
Cumprimentos
José Seabra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160424/450bb50e/attachment.html>