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
<mailto: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
<mailto: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
[mailto: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>
<mailto: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 list
sr-users@lists.sip-router.org
<mailto:sr-users@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@lists.sip-router.org
<mailto: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 <mailto:sr-users@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@lists.sip-router.org <mailto: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
jason.pen...@smilecoms.com <mailto:name.surn...@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@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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
