[SR-Users] Kamailio IMS_QOS

Ivailo Dobrev ivailod at telera.eu
Sat Apr 23 00:46:25 CEST 2016


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 
> <mailto: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
>>     <mailto: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
>>>         [mailto: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>
>>>         <mailto: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 list
>>>         sr-users at lists.sip-router.org
>>>         <mailto:sr-users at 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 at lists.sip-router.org
>>         <mailto: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 list
>>     sr-users at lists.sip-router.org <mailto:sr-users at 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 at lists.sip-router.org <mailto: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 <mailto:name.surname at smilecoms.com>
> www.smilecoms.com <http://www.smilecoms.com/>
>
>
>
> This email is subject to the disclaimer of Smile Communications athttp://www.smilecoms.com/home/email-disclaimer/ 
> <http://www.smilecoms.com/home/email-disclaimer/>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160423/434c3ebe/attachment.html>


More information about the sr-users mailing list