Hi Ivo, That answers to my doubts.
Thank you Regards José 2016-04-27 23:22 GMT+01:00 Ivailo Dobrev <ivai...@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 <joseseab...@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.pen...@smilecoms.com> >> jason.pen...@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 < <joseseab...@gmail.com> >>> joseseab...@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 < <ivai...@telera.eu> >>>> ivai...@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 < <ivai...@telera.eu> >>>>> ivai...@telera.eu> wrote: >>>>> >>>>>> Yes you send both direction media information to the PCRF but when >>>>>> reply is received in precondition state. >>>>>> >>>>>> >>>>>> On 04/23/2016 12:03 AM, José Seabra wrote: >>>>>> >>>>>> Hello Ivailo and Franz, >>>>>> >>>>>> Thank you for your clarifications. >>>>>> >>>>>> Well sending an AAR when receive a reply makes all sense, but ims_qos >>>>>> must send the SDP information from the Initial Invite and also from 183 >>>>>> ringing or 200Ok, Am I correct? >>>>>> >>>>>> Because PCRF needs to know the session parameters from Initial >>>>>> Initial INVITE and the reply to it. >>>>>> >>>>>> The PCRF is a proprietary solution. >>>>>> >>>>>> Thank you >>>>>> BR >>>>>> José Seabra >>>>>> >>>>>> >>>>>> 2016-04-22 21:54 GMT+01:00 Ivailo Dobrev < <ivai...@telera.eu> >>>>>> ivai...@telera.eu>: >>>>>> >>>>>>> Hi Franz, >>>>>>> >>>>>>> There no real OS PCRF. Yota/Telexir use to had some free VM image >>>>>>> that is OK for test. You can search about FreePCRF. It is a little >>>>>>> tricky >>>>>>> to configure it but ... I made for my tests a really dummy one based on >>>>>>> FreeDIAMETER. Generally speaking PCRF is the "brain" of the network and >>>>>>> you >>>>>>> should understand and design things well there. I have experience also >>>>>>> w/ >>>>>>> commercial PCRFs and there is no real answer yes this is a right way of >>>>>>> making something. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Ivo >>>>>>> >>>>>>> >>>>>>> On 04/22/2016 11:09 PM, Franz Edler wrote: >>>>>>> >>>>>>> Hi José, >>>>>>> >>>>>>> >>>>>>> >>>>>>> in principle it is possible to send an AAR after receiving the >>>>>>> request. In this case the Service-Info-Status AVP is set to PRELIMINARY >>>>>>> SERVICE INFORMATION. >>>>>>> >>>>>>> More efficient is it to wait until SDP answer is received and then >>>>>>> the Service-Info-Status AVP is set to FINAL_SERVICE_INFORMATION. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I don’t know if both methods are covered in ims_qos module. >>>>>>> >>>>>>> >>>>>>> >>>>>>> BTW: which PCRF are you using? Is there some open source PCRF >>>>>>> available? >>>>>>> >>>>>>> >>>>>>> >>>>>>> BR >>>>>>> >>>>>>> Franz >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* sr-users [ <sr-users-boun...@lists.sip-router.org> >>>>>>> mailto:sr-users-boun...@lists.sip-router.org >>>>>>> <sr-users-boun...@lists.sip-router.org>] *On Behalf Of *José Seabra >>>>>>> *Sent:* Friday, April 22, 2016 3:58 PM >>>>>>> *To:* Kamailio (SER) - Users Mailing List >>>>>>> <sr-users@lists.sip-router.org><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-us...@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>sr-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-us...@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>sr-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.pen...@smilecoms.com>jason.pen...@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-us...@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.surn...@smilecoms.com>jason.pen...@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-us...@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
