[SR-Users] Kamailio IMS_QOS

Sat Apr 23 00:35:47 CEST 2016

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>:
>
>> 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>
>> *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
jason.penton at smilecoms.com <name.surname at smilecoms.com>
www.smilecoms.com

-- 

This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160423/7f3b603c/attachment.html>