27 Apr
2016
27 Apr
'16
12:52 p.m.
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(a)smilecoms.com>om>:
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(a)gmail.com>
wrote:
--
Cumprimentos
José Seabra
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(a)telera.eu>eu>:
--
*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(a)smilecoms.com <name.surname(a)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(a)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(a)telera.eu>
wrote:
--
Cumprimentos
José Seabra
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)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(a)telera.eu>
ivailod(a)telera.eu>gt;:
> 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(a)lists.sip-router.org>
> mailto:sr-users-bounces@lists.sip-router.org
> <sr-users-bounces(a)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>
> <sr-users(a)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(a)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(a)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.com>jason.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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users