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
Hi Jose,
AAR is made no the reply. Reply is the place in that both media streams in SDP are available and known. Default IMS config should be changed a little Rx to start work. This also reminds me that you will probably face another problem if your PCRF does not have integration w/ HSS.
P.S. Good luck w/ PCRF battle. It is a great fun to make it work ;)
Cheers,
Ivo
On 04/22/2016 04:58 PM, José Seabra wrote:
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 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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 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
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@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 *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 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@lists.sip-router.org sr-users-bounces@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 *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@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
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@telera.eu mailto:ivailod@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@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 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@lists.sip-router.org mailto:sr-users-bounces@lists.sip-router.org sr-users-bounces@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 *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@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-users@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
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@telera.eu mailto:ivailod@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@telera.eu <mailto:ivailod@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@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.penton@smilecoms.com mailto:name.surname@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
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@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@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@telera.eu ivailod@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@lists.sip-router.org mailto:sr-users-bounces@lists.sip-router.org sr-users-bounces@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.orgsr-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-users@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-users@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.surname@smilecoms.comjason.penton@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@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
Hi José,
Unfortunately you have to use the ims_usrloc_pcscf as there are extra extra data fields that are required in the case of IMS registrations. Perhaps what you can do is run with both usrloc backends. I know that we made the restriction that you could only use one but I as soon as I get a chance I will see if it's possible for ims modules to bind specifically to the ims_usrloc_* module as well as allow you to run "other" code that bind to other usrloc backends.
Cheers Jason
On Sun, Apr 24, 2016 at 11:30 PM, José Seabra joseseabra4@gmail.com wrote:
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@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@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@telera.eu ivailod@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@lists.sip-router.org mailto:sr-users-bounces@lists.sip-router.org sr-users-bounces@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.orgsr-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-users@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-users@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.surname@smilecoms.comjason.penton@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@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
Hi Jason, What could be the impact of using both modules (usrloc and ims_usrloc_pcscf)?
One of the impacts that I can see is the Shared memory, it will consume more shared memory because will save the AOR twice in memory, one in usrloc and the other in ims_usrloc_pcscf, is that right?
Another Doubt that I have:
At this moment I'm only using the function rx_aar, (I'm not using ims_qos with register sip messages), and when kamailio sends an AAR to PCRF, the AVP "Flow-Description" contains the IP address of received host, that is a kamailio server acting as loadbalancer, not the Terminal IP address.
So I'm obliged to use RX on registrar messages in order to have the AOR of the SIP Terminal on the AVP "Flow-Description"? Or can I manipulate it in an easy way?
Anyway I'm facing an issue when PCRF is sending an Abort-Session Request after the call is established, Kamailio stops working with the following Log messages:
36(21757) DEBUG: cdp [receiver.c:1083]: receive_message(): receive_message(): [alb-pcrf.rx.example.com] Recv msg 274 36(21757) DEBUG: cdp [peerstatemachine.c:92]: sm_process(): sm_process(): Peer alb-pcrf.rx.example.com State I_Open Event I_Rcv_Message 36(21757) DEBUG: cdp [session.c:305]: cdp_get_session(): called get session with id proxy1.sw.example.com;2463925226;1 and hash 39 36(21757) DEBUG: cdp [session.c:308]: cdp_get_session(): looking for | proxy1.sw.example.com;2463925226;1| in |proxy1.sw.example.com;2463925226;1| 36(21757) DEBUG: ims_qos [mod.c:301]: callback_for_cdp_session(): callback_for_cdp session(): called with event 5 and session id [ proxy1.sw.example.com;2463925226;1] 36(21757) DEBUG: ims_qos [cdpeventprocessor.c:113]: new_cdp_cb_event(): Creating new event for rx session [proxy1.sw.example.com;2463925226;1] 36(21757) INFO: cdp [authstatemachine.c:271]: auth_client_statefull_sm_process(): after callback of event 5 36(21757) INFO: cdp [authstatemachine.c:733]: Send_ASA(): Send_ASA(): sending ASA 36(21757) INFO: cdp [authstatemachine.c:758]: Send_ASA(): sending ASA to peer alb-pcrf 36(21757) DEBUG: cdp [diameter_msg.c:83]: AAABuildMsgBuffer(): AAABuildMsgBuffer(): len=172 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:209]: cdp_cb_event_process(): processing event [5] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:221]: cdp_cb_event_process(): Received notification of ASR from transport plane or CDP timeout for CDP session with Rx session ID: [proxy1.sw.example.com;2463925226;1] and associated contact [] and domain [] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:228]: cdp_cb_event_process(): This is a media bearer session session39(21770) DEBUG: ims_qos [cdpeventprocessor.c:316]: free_cdp_cb_event(): Freeing cdpb CB event structure 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:318]: free_cdp_cb_event(): about to free string from cdp CB event [proxy1.sw.example.com;2463925226;1] 0(21693) ALERT: <core> [main.c:739]: handle_sigs(): child process 21757 exited by a signal 11 0(21693) ALERT: <core> [main.c:742]: handle_sigs(): core was not generated 0(21693) INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD 0(21693) DEBUG: <core> [main.c:756]: handle_sigs(): terminating due to SIGCHLD 69(21816) INFO: <core> [main.c:809]: sig_usr(): signal 15 received . . .
Thank you
Best Regards José Seabra
2016-04-25 13:27 GMT+01:00 Jason Penton jason.penton@smilecoms.com:
Hi José,
Unfortunately you have to use the ims_usrloc_pcscf as there are extra extra data fields that are required in the case of IMS registrations. Perhaps what you can do is run with both usrloc backends. I know that we made the restriction that you could only use one but I as soon as I get a chance I will see if it's possible for ims modules to bind specifically to the ims_usrloc_* module as well as allow you to run "other" code that bind to other usrloc backends.
Cheers Jason
On Sun, Apr 24, 2016 at 11:30 PM, José Seabra joseseabra4@gmail.com wrote:
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@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@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@telera.eu ivailod@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@lists.sip-router.org mailto:sr-users-bounces@lists.sip-router.org sr-users-bounces@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.orgsr-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-users@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-users@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.surname@smilecoms.comjason.penton@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@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
--
*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@smilecoms.com name.surname@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
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
Hi, Updating my last email, I noticed that the AVP framed_ip_address is also containing the IP address of SDP C field, so in my case that I have a SBC in front of my Kamailio doing NAT, the SDP address will be the IP of the SBC, in order that PCRF will try reserve bandwidth in the SBC.
What we can do in these cases?
Thank you for your support BR
2016-04-27 10:52 GMT+01:00 José Seabra joseseabra4@gmail.com:
Hi Jason, What could be the impact of using both modules (usrloc and ims_usrloc_pcscf)?
One of the impacts that I can see is the Shared memory, it will consume more shared memory because will save the AOR twice in memory, one in usrloc and the other in ims_usrloc_pcscf, is that right?
Another Doubt that I have:
At this moment I'm only using the function rx_aar, (I'm not using ims_qos with register sip messages), and when kamailio sends an AAR to PCRF, the AVP "Flow-Description" contains the IP address of received host, that is a kamailio server acting as loadbalancer, not the Terminal IP address.
So I'm obliged to use RX on registrar messages in order to have the AOR of the SIP Terminal on the AVP "Flow-Description"? Or can I manipulate it in an easy way?
Anyway I'm facing an issue when PCRF is sending an Abort-Session Request after the call is established, Kamailio stops working with the following Log messages:
36(21757) DEBUG: cdp [receiver.c:1083]: receive_message(): receive_message(): [alb-pcrf.rx.example.com] Recv msg 274 36(21757) DEBUG: cdp [peerstatemachine.c:92]: sm_process(): sm_process(): Peer alb-pcrf.rx.example.com State I_Open Event I_Rcv_Message 36(21757) DEBUG: cdp [session.c:305]: cdp_get_session(): called get session with id proxy1.sw.example.com;2463925226;1 and hash 39 36(21757) DEBUG: cdp [session.c:308]: cdp_get_session(): looking for | proxy1.sw.example.com;2463925226;1| in |proxy1.sw.example.com ;2463925226;1| 36(21757) DEBUG: ims_qos [mod.c:301]: callback_for_cdp_session(): callback_for_cdp session(): called with event 5 and session id [ proxy1.sw.example.com;2463925226;1] 36(21757) DEBUG: ims_qos [cdpeventprocessor.c:113]: new_cdp_cb_event(): Creating new event for rx session [proxy1.sw.example.com;2463925226;1] 36(21757) INFO: cdp [authstatemachine.c:271]: auth_client_statefull_sm_process(): after callback of event 5 36(21757) INFO: cdp [authstatemachine.c:733]: Send_ASA(): Send_ASA(): sending ASA 36(21757) INFO: cdp [authstatemachine.c:758]: Send_ASA(): sending ASA to peer alb-pcrf 36(21757) DEBUG: cdp [diameter_msg.c:83]: AAABuildMsgBuffer(): AAABuildMsgBuffer(): len=172 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:209]: cdp_cb_event_process(): processing event [5] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:221]: cdp_cb_event_process(): Received notification of ASR from transport plane or CDP timeout for CDP session with Rx session ID: [proxy1.sw.example.com;2463925226;1] and associated contact [] and domain [] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:228]: cdp_cb_event_process(): This is a media bearer session session39(21770) DEBUG: ims_qos [cdpeventprocessor.c:316]: free_cdp_cb_event(): Freeing cdpb CB event structure 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:318]: free_cdp_cb_event(): about to free string from cdp CB event [proxy1.sw.example.com ;2463925226;1] 0(21693) ALERT: <core> [main.c:739]: handle_sigs(): child process 21757 exited by a signal 11 0(21693) ALERT: <core> [main.c:742]: handle_sigs(): core was not generated 0(21693) INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD 0(21693) DEBUG: <core> [main.c:756]: handle_sigs(): terminating due to SIGCHLD 69(21816) INFO: <core> [main.c:809]: sig_usr(): signal 15 received . . .
Thank you
Best Regards José Seabra
2016-04-25 13:27 GMT+01:00 Jason Penton jason.penton@smilecoms.com:
Hi José,
Unfortunately you have to use the ims_usrloc_pcscf as there are extra extra data fields that are required in the case of IMS registrations. Perhaps what you can do is run with both usrloc backends. I know that we made the restriction that you could only use one but I as soon as I get a chance I will see if it's possible for ims modules to bind specifically to the ims_usrloc_* module as well as allow you to run "other" code that bind to other usrloc backends.
Cheers Jason
On Sun, Apr 24, 2016 at 11:30 PM, José Seabra joseseabra4@gmail.com wrote:
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@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@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@telera.eu ivailod@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@lists.sip-router.org mailto:sr-users-bounces@lists.sip-router.org sr-users-bounces@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.orgsr-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-users@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-users@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.surname@smilecoms.comjason.penton@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@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
--
*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@smilecoms.com name.surname@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
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
Hi Jose,
Framed IP or some king of hashing over IP/identitiy/APN... is used from PCRF for session binding. If I understand question right the short answer is that reservation from PCRF is made by Media-Component-Description not by framed IP address. In your architecture if Kamailio instance that serves Rx do not have real UE IP address (and real SDP media addresses) it cannot send proper info to PCRF. You should put Kamailio in front of SBC...
BR, Ivo
On 04/28/2016 12:28 AM, José Seabra wrote:
Hi, Updating my last email, I noticed that the AVP framed_ip_address is also containing the IP address of SDP C field, so in my case that I have a SBC in front of my Kamailio doing NAT, the SDP address will be the IP of the SBC, in order that PCRF will try reserve bandwidth in the SBC.
What we can do in these cases?
Thank you for your support BR
2016-04-27 10:52 GMT+01:00 José Seabra <joseseabra4@gmail.com mailto:joseseabra4@gmail.com>:
Hi Jason, What could be the impact of using both modules (usrloc and ims_usrloc_pcscf)? One of the impacts that I can see is the Shared memory, it will consume more shared memory because will save the AOR twice in memory, one in usrloc and the other in ims_usrloc_pcscf, is that right? Another Doubt that I have: At this moment I'm only using the function rx_aar, (I'm not using ims_qos with register sip messages), and when kamailio sends an AAR to PCRF, the AVP "Flow-Description" contains the IP address of received host, that is a kamailio server acting as loadbalancer, not the Terminal IP address. So I'm obliged to use RX on registrar messages in order to have the AOR of the SIP Terminal on the AVP "Flow-Description"? Or can I manipulate it in an easy way? Anyway I'm facing an issue when PCRF is sending an Abort-Session Request after the call is established, Kamailio stops working with the following Log messages: 36(21757) DEBUG: cdp [receiver.c:1083]: receive_message(): receive_message(): [alb-pcrf.rx.example.com <http://alb-pcrf.rx.example.com>] Recv msg 274 36(21757) DEBUG: cdp [peerstatemachine.c:92]: sm_process(): sm_process(): Peer alb-pcrf.rx.example.com <http://alb-pcrf.rx.example.com> State I_Open Event I_Rcv_Message 36(21757) DEBUG: cdp [session.c:305]: cdp_get_session(): called get session with id proxy1.sw.example.com <http://proxy1.sw.example.com>;2463925226;1 and hash 39 36(21757) DEBUG: cdp [session.c:308]: cdp_get_session(): looking for |proxy1.sw.example.com <http://proxy1.sw.example.com>;2463925226;1| in |proxy1.sw.example.com <http://proxy1.sw.example.com>;2463925226;1| 36(21757) DEBUG: ims_qos [mod.c:301]: callback_for_cdp_session(): callback_for_cdp session(): called with event 5 and session id [proxy1.sw.example.com <http://proxy1.sw.example.com>;2463925226;1] 36(21757) DEBUG: ims_qos [cdpeventprocessor.c:113]: new_cdp_cb_event(): Creating new event for rx session [proxy1.sw.example.com <http://proxy1.sw.example.com>;2463925226;1] 36(21757) INFO: cdp [authstatemachine.c:271]: auth_client_statefull_sm_process(): after callback of event 5 36(21757) INFO: cdp [authstatemachine.c:733]: Send_ASA(): Send_ASA(): sending ASA 36(21757) INFO: cdp [authstatemachine.c:758]: Send_ASA(): sending ASA to peer alb-pcrf 36(21757) DEBUG: cdp [diameter_msg.c:83]: AAABuildMsgBuffer(): AAABuildMsgBuffer(): len=172 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:209]: cdp_cb_event_process(): processing event [5] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:221]: cdp_cb_event_process(): Received notification of ASR from transport plane or CDP timeout for CDP session with Rx session ID: [proxy1.sw.example.com <http://proxy1.sw.example.com>;2463925226;1] and associated contact [] and domain [] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:228]: cdp_cb_event_process(): This is a media bearer session session39(21770) DEBUG: ims_qos [cdpeventprocessor.c:316]: free_cdp_cb_event(): Freeing cdpb CB event structure 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:318]: free_cdp_cb_event(): about to free string from cdp CB event [proxy1.sw.example.com <http://proxy1.sw.example.com>;2463925226;1] 0(21693) ALERT: <core> [main.c:739]: handle_sigs(): child process 21757 exited by a signal 11 0(21693) ALERT: <core> [main.c:742]: handle_sigs(): core was not generated 0(21693) INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD 0(21693) DEBUG: <core> [main.c:756]: handle_sigs(): terminating due to SIGCHLD 69(21816) INFO: <core> [main.c:809]: sig_usr(): signal 15 received . . . Thank you Best Regards José Seabra 2016-04-25 13:27 GMT+01:00 Jason Penton <jason.penton@smilecoms.com <mailto:jason.penton@smilecoms.com>>: Hi José, Unfortunately you have to use the ims_usrloc_pcscf as there are extra extra data fields that are required in the case of IMS registrations. Perhaps what you can do is run with both usrloc backends. I know that we made the restriction that you could only use one but I as soon as I get a chance I will see if it's possible for ims modules to bind specifically to the ims_usrloc_* module as well as allow you to run "other" code that bind to other usrloc backends. Cheers Jason On Sun, Apr 24, 2016 at 11:30 PM, José Seabra <joseseabra4@gmail.com <mailto:joseseabra4@gmail.com>> wrote: 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@telera.eu <mailto:ivailod@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@telera.eu <mailto:ivailod@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@telera.eu <mailto:ivailod@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@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 <tel:%2B27%20%280%29%2083%20283%207000> *Skype:* jason.barry.penton jason.penton@smilecoms.com <mailto:jason.penton@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/ _______________________________________________ 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 -- *Jason Penton* *Senior Manager: Applications and Services* *Smile Communications Pty (Ltd)* *Voice: Mobile:* +234 (0) 702 000 000 7 +27 (0) 83 283 7000 <tel:%2B27%20%280%29%2083%20283%207000> *Skype:* jason.barry.penton jason.penton@smilecoms.com <mailto:name.surname@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/ _______________________________________________ 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-- 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
Hi Ivo,
That answers to my doubts.
Thank you Regards José
2016-04-27 23:22 GMT+01:00 Ivailo Dobrev ivailod@telera.eu:
Hi Jose,
Framed IP or some king of hashing over IP/identitiy/APN... is used from PCRF for session binding. If I understand question right the short answer is that reservation from PCRF is made by Media-Component-Description not by framed IP address. In your architecture if Kamailio instance that serves Rx do not have real UE IP address (and real SDP media addresses) it cannot send proper info to PCRF. You should put Kamailio in front of SBC...
BR, Ivo
On 04/28/2016 12:28 AM, José Seabra wrote:
Hi, Updating my last email, I noticed that the AVP framed_ip_address is also containing the IP address of SDP C field, so in my case that I have a SBC in front of my Kamailio doing NAT, the SDP address will be the IP of the SBC, in order that PCRF will try reserve bandwidth in the SBC.
What we can do in these cases?
Thank you for your support BR
2016-04-27 10:52 GMT+01:00 José Seabra joseseabra4@gmail.com:
Hi Jason, What could be the impact of using both modules (usrloc and ims_usrloc_pcscf)?
One of the impacts that I can see is the Shared memory, it will consume more shared memory because will save the AOR twice in memory, one in usrloc and the other in ims_usrloc_pcscf, is that right?
Another Doubt that I have:
At this moment I'm only using the function rx_aar, (I'm not using ims_qos with register sip messages), and when kamailio sends an AAR to PCRF, the AVP "Flow-Description" contains the IP address of received host, that is a kamailio server acting as loadbalancer, not the Terminal IP address.
So I'm obliged to use RX on registrar messages in order to have the AOR of the SIP Terminal on the AVP "Flow-Description"? Or can I manipulate it in an easy way?
Anyway I'm facing an issue when PCRF is sending an Abort-Session Request after the call is established, Kamailio stops working with the following Log messages:
36(21757) DEBUG: cdp [receiver.c:1083]: receive_message(): receive_message(): [alb-pcrf.rx.example.com] Recv msg 274 36(21757) DEBUG: cdp [peerstatemachine.c:92]: sm_process(): sm_process(): Peer alb-pcrf.rx.example.com State I_Open Event I_Rcv_Message 36(21757) DEBUG: cdp [session.c:305]: cdp_get_session(): called get session with id proxy1.sw.example.com;2463925226;1 and hash 39 36(21757) DEBUG: cdp [session.c:308]: cdp_get_session(): looking for | proxy1.sw.example.com;2463925226;1| in |proxy1.sw.example.com ;2463925226;1| 36(21757) DEBUG: ims_qos [mod.c:301]: callback_for_cdp_session(): callback_for_cdp session(): called with event 5 and session id [ proxy1.sw.example.com;2463925226;1] 36(21757) DEBUG: ims_qos [cdpeventprocessor.c:113]: new_cdp_cb_event(): Creating new event for rx session [proxy1.sw.example.com;2463925226;1] 36(21757) INFO: cdp [authstatemachine.c:271]: auth_client_statefull_sm_process(): after callback of event 5 36(21757) INFO: cdp [authstatemachine.c:733]: Send_ASA(): Send_ASA(): sending ASA 36(21757) INFO: cdp [authstatemachine.c:758]: Send_ASA(): sending ASA to peer alb-pcrf 36(21757) DEBUG: cdp [diameter_msg.c:83]: AAABuildMsgBuffer(): AAABuildMsgBuffer(): len=172 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:209]: cdp_cb_event_process(): processing event [5] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:221]: cdp_cb_event_process(): Received notification of ASR from transport plane or CDP timeout for CDP session with Rx session ID: [proxy1.sw.example.com;2463925226;1] and associated contact [] and domain [] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:228]: cdp_cb_event_process(): This is a media bearer session session39(21770) DEBUG: ims_qos [cdpeventprocessor.c:316]: free_cdp_cb_event(): Freeing cdpb CB event structure 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:318]: free_cdp_cb_event(): about to free string from cdp CB event [proxy1.sw.example.com ;2463925226;1] 0(21693) ALERT: <core> [main.c:739]: handle_sigs(): child process 21757 exited by a signal 11 0(21693) ALERT: <core> [main.c:742]: handle_sigs(): core was not generated 0(21693) INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD 0(21693) DEBUG: <core> [main.c:756]: handle_sigs(): terminating due to SIGCHLD 69(21816) INFO: <core> [main.c:809]: sig_usr(): signal 15 received . . .
Thank you
Best Regards José Seabra
2016-04-25 13:27 GMT+01:00 Jason Penton < jason.penton@smilecoms.com jason.penton@smilecoms.com>:
Hi José,
Unfortunately you have to use the ims_usrloc_pcscf as there are extra extra data fields that are required in the case of IMS registrations. Perhaps what you can do is run with both usrloc backends. I know that we made the restriction that you could only use one but I as soon as I get a chance I will see if it's possible for ims modules to bind specifically to the ims_usrloc_* module as well as allow you to run "other" code that bind to other usrloc backends.
Cheers Jason
On Sun, Apr 24, 2016 at 11:30 PM, José Seabra < joseseabra4@gmail.com joseseabra4@gmail.com> wrote:
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@telera.eu ivailod@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@telera.eu ivailod@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@telera.eu ivailod@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@lists.sip-router.org > mailto:sr-users-bounces@lists.sip-router.org > sr-users-bounces@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.orgsr-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-users@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.orgsr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > 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@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.orgsr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 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 <%2B27%20%280%29%2083%20283%207000> *Skype:* jason.barry.penton jason.penton@smilecoms.comjason.penton@smilecoms.com http://www.smilecoms.comwww.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@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
--
*Jason Penton* *Senior Manager: Applications and Services* *Smile Communications Pty (Ltd)*
*Voice: Mobile:* +234 (0) 702 000 000 7
+27 (0) 83 283 7000 <%2B27%20%280%29%2083%20283%207000> *Skype:* jason.barry.penton name.surname@smilecoms.comjason.penton@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 list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Cumprimentos José Seabra
-- Cumprimentos José Seabra
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@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
Hi José
Ivailo is correct here, you need to have p-cscf *be* the SBC or at least sit in front of one if it is not the SBC. If not you will effectively be sending "junk" to the PCRF and it will be impossible for it to signal the correct setup of bearers between UE and P-CSCF/SBC.
Then, re. youre questions around usrloc. The current pre-requisites of binding to usrloc and dialog are for the following reasons:
1. if signalling bearer is removed by network, typically QCI 5 bearer (for whatever reason) viz ASR - then: a) tear down all active calls related to contact (requires dialog_ng binding) b) unregister contact (network initiated) (requires usrloc binding)
2. if media bearer is removed by network (typically QCI 1 and / or 2) - then: a) terminate active call (requires dialog_ng binding)
So, for ims_qos to correctly do what it is meant to do, it *has* to bind to the ims_usrloc... I hope this helps make sense of it all a little more
Cheers Jason
On Thu, Apr 28, 2016 at 12:22 AM, Ivailo Dobrev ivailod@telera.eu wrote:
Hi Jose,
Framed IP or some king of hashing over IP/identitiy/APN... is used from PCRF for session binding. If I understand question right the short answer is that reservation from PCRF is made by Media-Component-Description not by framed IP address. In your architecture if Kamailio instance that serves Rx do not have real UE IP address (and real SDP media addresses) it cannot send proper info to PCRF. You should put Kamailio in front of SBC...
BR, Ivo
On 04/28/2016 12:28 AM, José Seabra wrote:
Hi, Updating my last email, I noticed that the AVP framed_ip_address is also containing the IP address of SDP C field, so in my case that I have a SBC in front of my Kamailio doing NAT, the SDP address will be the IP of the SBC, in order that PCRF will try reserve bandwidth in the SBC.
What we can do in these cases?
Thank you for your support BR
2016-04-27 10:52 GMT+01:00 José Seabra joseseabra4@gmail.com:
Hi Jason, What could be the impact of using both modules (usrloc and ims_usrloc_pcscf)?
One of the impacts that I can see is the Shared memory, it will consume more shared memory because will save the AOR twice in memory, one in usrloc and the other in ims_usrloc_pcscf, is that right?
Another Doubt that I have:
At this moment I'm only using the function rx_aar, (I'm not using ims_qos with register sip messages), and when kamailio sends an AAR to PCRF, the AVP "Flow-Description" contains the IP address of received host, that is a kamailio server acting as loadbalancer, not the Terminal IP address.
So I'm obliged to use RX on registrar messages in order to have the AOR of the SIP Terminal on the AVP "Flow-Description"? Or can I manipulate it in an easy way?
Anyway I'm facing an issue when PCRF is sending an Abort-Session Request after the call is established, Kamailio stops working with the following Log messages:
36(21757) DEBUG: cdp [receiver.c:1083]: receive_message(): receive_message(): [alb-pcrf.rx.example.com] Recv msg 274 36(21757) DEBUG: cdp [peerstatemachine.c:92]: sm_process(): sm_process(): Peer alb-pcrf.rx.example.com State I_Open Event I_Rcv_Message 36(21757) DEBUG: cdp [session.c:305]: cdp_get_session(): called get session with id proxy1.sw.example.com;2463925226;1 and hash 39 36(21757) DEBUG: cdp [session.c:308]: cdp_get_session(): looking for | proxy1.sw.example.com;2463925226;1| in |proxy1.sw.example.com ;2463925226;1| 36(21757) DEBUG: ims_qos [mod.c:301]: callback_for_cdp_session(): callback_for_cdp session(): called with event 5 and session id [ proxy1.sw.example.com;2463925226;1] 36(21757) DEBUG: ims_qos [cdpeventprocessor.c:113]: new_cdp_cb_event(): Creating new event for rx session [proxy1.sw.example.com;2463925226;1] 36(21757) INFO: cdp [authstatemachine.c:271]: auth_client_statefull_sm_process(): after callback of event 5 36(21757) INFO: cdp [authstatemachine.c:733]: Send_ASA(): Send_ASA(): sending ASA 36(21757) INFO: cdp [authstatemachine.c:758]: Send_ASA(): sending ASA to peer alb-pcrf 36(21757) DEBUG: cdp [diameter_msg.c:83]: AAABuildMsgBuffer(): AAABuildMsgBuffer(): len=172 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:209]: cdp_cb_event_process(): processing event [5] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:221]: cdp_cb_event_process(): Received notification of ASR from transport plane or CDP timeout for CDP session with Rx session ID: [proxy1.sw.example.com;2463925226;1] and associated contact [] and domain [] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:228]: cdp_cb_event_process(): This is a media bearer session session39(21770) DEBUG: ims_qos [cdpeventprocessor.c:316]: free_cdp_cb_event(): Freeing cdpb CB event structure 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:318]: free_cdp_cb_event(): about to free string from cdp CB event [proxy1.sw.example.com ;2463925226;1] 0(21693) ALERT: <core> [main.c:739]: handle_sigs(): child process 21757 exited by a signal 11 0(21693) ALERT: <core> [main.c:742]: handle_sigs(): core was not generated 0(21693) INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD 0(21693) DEBUG: <core> [main.c:756]: handle_sigs(): terminating due to SIGCHLD 69(21816) INFO: <core> [main.c:809]: sig_usr(): signal 15 received . . .
Thank you
Best Regards José Seabra
2016-04-25 13:27 GMT+01:00 Jason Penton < jason.penton@smilecoms.com jason.penton@smilecoms.com>:
Hi José,
Unfortunately you have to use the ims_usrloc_pcscf as there are extra extra data fields that are required in the case of IMS registrations. Perhaps what you can do is run with both usrloc backends. I know that we made the restriction that you could only use one but I as soon as I get a chance I will see if it's possible for ims modules to bind specifically to the ims_usrloc_* module as well as allow you to run "other" code that bind to other usrloc backends.
Cheers Jason
On Sun, Apr 24, 2016 at 11:30 PM, José Seabra < joseseabra4@gmail.com joseseabra4@gmail.com> wrote:
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@telera.eu ivailod@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@telera.eu ivailod@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@telera.eu ivailod@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@lists.sip-router.org > mailto:sr-users-bounces@lists.sip-router.org > sr-users-bounces@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.orgsr-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-users@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.orgsr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > 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@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.orgsr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 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 <%2B27%20%280%29%2083%20283%207000> *Skype:* jason.barry.penton jason.penton@smilecoms.comjason.penton@smilecoms.com http://www.smilecoms.comwww.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@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
--
*Jason Penton* *Senior Manager: Applications and Services* *Smile Communications Pty (Ltd)*
*Voice: Mobile:* +234 (0) 702 000 000 7
+27 (0) 83 283 7000 <%2B27%20%280%29%2083%20283%207000> *Skype:* jason.barry.penton name.surname@smilecoms.comjason.penton@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 list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Cumprimentos José Seabra
-- Cumprimentos José Seabra
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@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
Hi Jason, I understood it, the issue here is that i was trying to use ims_qos module in a non IMS network and my frontend component isn't the Kamailio server.
But now I understood that the requirement is having this component in the frontend of network in order to have the correct information from UE.
Once again, thank you all to make it more clear to me.
BR José
2016-04-28 10:16 GMT+01:00 Jason Penton jason.penton@smilecoms.com:
Hi José
Ivailo is correct here, you need to have p-cscf *be* the SBC or at least sit in front of one if it is not the SBC. If not you will effectively be sending "junk" to the PCRF and it will be impossible for it to signal the correct setup of bearers between UE and P-CSCF/SBC.
Then, re. youre questions around usrloc. The current pre-requisites of binding to usrloc and dialog are for the following reasons:
- if signalling bearer is removed by network, typically QCI 5 bearer (for
whatever reason) viz ASR - then: a) tear down all active calls related to contact (requires dialog_ng binding) b) unregister contact (network initiated) (requires usrloc binding)
- if media bearer is removed by network (typically QCI 1 and / or 2) -
then: a) terminate active call (requires dialog_ng binding)
So, for ims_qos to correctly do what it is meant to do, it *has* to bind to the ims_usrloc... I hope this helps make sense of it all a little more
Cheers Jason
On Thu, Apr 28, 2016 at 12:22 AM, Ivailo Dobrev ivailod@telera.eu wrote:
Hi Jose,
Framed IP or some king of hashing over IP/identitiy/APN... is used from PCRF for session binding. If I understand question right the short answer is that reservation from PCRF is made by Media-Component-Description not by framed IP address. In your architecture if Kamailio instance that serves Rx do not have real UE IP address (and real SDP media addresses) it cannot send proper info to PCRF. You should put Kamailio in front of SBC...
BR, Ivo
On 04/28/2016 12:28 AM, José Seabra wrote:
Hi, Updating my last email, I noticed that the AVP framed_ip_address is also containing the IP address of SDP C field, so in my case that I have a SBC in front of my Kamailio doing NAT, the SDP address will be the IP of the SBC, in order that PCRF will try reserve bandwidth in the SBC.
What we can do in these cases?
Thank you for your support BR
2016-04-27 10:52 GMT+01:00 José Seabra joseseabra4@gmail.com:
Hi Jason, What could be the impact of using both modules (usrloc and ims_usrloc_pcscf)?
One of the impacts that I can see is the Shared memory, it will consume more shared memory because will save the AOR twice in memory, one in usrloc and the other in ims_usrloc_pcscf, is that right?
Another Doubt that I have:
At this moment I'm only using the function rx_aar, (I'm not using ims_qos with register sip messages), and when kamailio sends an AAR to PCRF, the AVP "Flow-Description" contains the IP address of received host, that is a kamailio server acting as loadbalancer, not the Terminal IP address.
So I'm obliged to use RX on registrar messages in order to have the AOR of the SIP Terminal on the AVP "Flow-Description"? Or can I manipulate it in an easy way?
Anyway I'm facing an issue when PCRF is sending an Abort-Session Request after the call is established, Kamailio stops working with the following Log messages:
36(21757) DEBUG: cdp [receiver.c:1083]: receive_message(): receive_message(): [alb-pcrf.rx.example.com] Recv msg 274 36(21757) DEBUG: cdp [peerstatemachine.c:92]: sm_process(): sm_process(): Peer alb-pcrf.rx.example.com State I_Open Event I_Rcv_Message 36(21757) DEBUG: cdp [session.c:305]: cdp_get_session(): called get session with id proxy1.sw.example.com;2463925226;1 and hash 39 36(21757) DEBUG: cdp [session.c:308]: cdp_get_session(): looking for | proxy1.sw.example.com;2463925226;1| in |proxy1.sw.example.com ;2463925226;1| 36(21757) DEBUG: ims_qos [mod.c:301]: callback_for_cdp_session(): callback_for_cdp session(): called with event 5 and session id [ proxy1.sw.example.com;2463925226;1] 36(21757) DEBUG: ims_qos [cdpeventprocessor.c:113]: new_cdp_cb_event(): Creating new event for rx session [proxy1.sw.example.com;2463925226;1] 36(21757) INFO: cdp [authstatemachine.c:271]: auth_client_statefull_sm_process(): after callback of event 5 36(21757) INFO: cdp [authstatemachine.c:733]: Send_ASA(): Send_ASA(): sending ASA 36(21757) INFO: cdp [authstatemachine.c:758]: Send_ASA(): sending ASA to peer alb-pcrf 36(21757) DEBUG: cdp [diameter_msg.c:83]: AAABuildMsgBuffer(): AAABuildMsgBuffer(): len=172 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:209]: cdp_cb_event_process(): processing event [5] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:221]: cdp_cb_event_process(): Received notification of ASR from transport plane or CDP timeout for CDP session with Rx session ID: [ proxy1.sw.example.com;2463925226;1] and associated contact [] and domain [] 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:228]: cdp_cb_event_process(): This is a media bearer session session39(21770) DEBUG: ims_qos [cdpeventprocessor.c:316]: free_cdp_cb_event(): Freeing cdpb CB event structure 39(21770) DEBUG: ims_qos [cdpeventprocessor.c:318]: free_cdp_cb_event(): about to free string from cdp CB event [proxy1.sw.example.com ;2463925226;1] 0(21693) ALERT: <core> [main.c:739]: handle_sigs(): child process 21757 exited by a signal 11 0(21693) ALERT: <core> [main.c:742]: handle_sigs(): core was not generated 0(21693) INFO: <core> [main.c:754]: handle_sigs(): terminating due to SIGCHLD 0(21693) DEBUG: <core> [main.c:756]: handle_sigs(): terminating due to SIGCHLD 69(21816) INFO: <core> [main.c:809]: sig_usr(): signal 15 received . . .
Thank you
Best Regards José Seabra
2016-04-25 13:27 GMT+01:00 Jason Penton < jason.penton@smilecoms.com jason.penton@smilecoms.com>:
Hi José,
Unfortunately you have to use the ims_usrloc_pcscf as there are extra extra data fields that are required in the case of IMS registrations. Perhaps what you can do is run with both usrloc backends. I know that we made the restriction that you could only use one but I as soon as I get a chance I will see if it's possible for ims modules to bind specifically to the ims_usrloc_* module as well as allow you to run "other" code that bind to other usrloc backends.
Cheers Jason
On Sun, Apr 24, 2016 at 11:30 PM, José Seabra < joseseabra4@gmail.com joseseabra4@gmail.com> wrote:
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@telera.eu ivailod@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@telera.eu ivailod@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@telera.eu > ivailod@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@lists.sip-router.org >> mailto:sr-users-bounces@lists.sip-router.org >> sr-users-bounces@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.orgsr-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-users@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.orgsr-users@lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> 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@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.orgsr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > 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 <%2B27%20%280%29%2083%20283%207000> *Skype:* jason.barry.penton jason.penton@smilecoms.comjason.penton@smilecoms.com http://www.smilecoms.comwww.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@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
--
*Jason Penton* *Senior Manager: Applications and Services* *Smile Communications Pty (Ltd)*
*Voice: Mobile:* +234 (0) 702 000 000 7
+27 (0) 83 283 7000 <%2B27%20%280%29%2083%20283%207000> *Skype:* jason.barry.penton name.surname@smilecoms.comjason.penton@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 list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Cumprimentos José Seabra
-- Cumprimentos José Seabra
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@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 jason.penton@smilecoms.com name.surname@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
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
-
Franz Edler -
Ivailo Dobrev -
Jason Penton -
José Seabra