[SR-Users] Kamailio IMS_QOS
José Seabra
joseseabra4 at gmail.com
Thu Apr 28 11:14:49 CEST 2016
Hi Ivo,
That answers to my doubts.
Thank you
Regards
José
2016-04-27 23:22 GMT+01:00 Ivailo Dobrev <ivailod at 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 at 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 at smilecoms.com>
>> jason.penton at 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 at gmail.com>
>>> joseseabra4 at 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 at telera.eu>
>>>> ivailod at 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 at telera.eu>
>>>>> ivailod at telera.eu> wrote:
>>>>>
>>>>>> Yes you send both direction media information to the PCRF but when
>>>>>> reply is received in precondition state.
>>>>>>
>>>>>>
>>>>>> On 04/23/2016 12:03 AM, José Seabra wrote:
>>>>>>
>>>>>> Hello Ivailo and Franz,
>>>>>>
>>>>>> Thank you for your clarifications.
>>>>>>
>>>>>> Well sending an AAR when receive a reply makes all sense, but ims_qos
>>>>>> must send the SDP information from the Initial Invite and also from 183
>>>>>> ringing or 200Ok, Am I correct?
>>>>>>
>>>>>> Because PCRF needs to know the session parameters from Initial
>>>>>> Initial INVITE and the reply to it.
>>>>>>
>>>>>> The PCRF is a proprietary solution.
>>>>>>
>>>>>> Thank you
>>>>>> BR
>>>>>> José Seabra
>>>>>>
>>>>>>
>>>>>> 2016-04-22 21:54 GMT+01:00 Ivailo Dobrev < <ivailod at telera.eu>
>>>>>> ivailod at telera.eu>:
>>>>>>
>>>>>>> Hi Franz,
>>>>>>>
>>>>>>> There no real OS PCRF. Yota/Telexir use to had some free VM image
>>>>>>> that is OK for test. You can search about FreePCRF. It is a little tricky
>>>>>>> to configure it but ... I made for my tests a really dummy one based on
>>>>>>> FreeDIAMETER. Generally speaking PCRF is the "brain" of the network and you
>>>>>>> should understand and design things well there. I have experience also w/
>>>>>>> commercial PCRFs and there is no real answer yes this is a right way of
>>>>>>> making something.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Ivo
>>>>>>>
>>>>>>>
>>>>>>> On 04/22/2016 11:09 PM, Franz Edler wrote:
>>>>>>>
>>>>>>> Hi José,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> in principle it is possible to send an AAR after receiving the
>>>>>>> request. In this case the Service-Info-Status AVP is set to PRELIMINARY
>>>>>>> SERVICE INFORMATION.
>>>>>>>
>>>>>>> More efficient is it to wait until SDP answer is received and then
>>>>>>> the Service-Info-Status AVP is set to FINAL_SERVICE_INFORMATION.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I don’t know if both methods are covered in ims_qos module.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> BTW: which PCRF are you using? Is there some open source PCRF
>>>>>>> available?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> BR
>>>>>>>
>>>>>>> Franz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* sr-users [ <sr-users-bounces at lists.sip-router.org>
>>>>>>> mailto:sr-users-bounces at lists.sip-router.org
>>>>>>> <sr-users-bounces at lists.sip-router.org>] *On Behalf Of *José Seabra
>>>>>>> *Sent:* Friday, April 22, 2016 3:58 PM
>>>>>>> *To:* Kamailio (SER) - Users Mailing List
>>>>>>> <sr-users at lists.sip-router.org><sr-users at lists.sip-router.org>
>>>>>>> <sr-users at lists.sip-router.org>
>>>>>>> *Subject:* [SR-Users] Kamailio IMS_QOS
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hello There,
>>>>>>>
>>>>>>> I'm trying using the ims_qos module with PCRF for QOS, but I'm
>>>>>>> facing some issues.
>>>>>>>
>>>>>>> When kamailio receives an initial invite (originator), it will
>>>>>>> execute the function - "Rx_AAR("ORIG_SESSION_AAR","orig","",-1)", but the
>>>>>>> PCRF is not contacted and i see the following messages:
>>>>>>>
>>>>>>> 5(12153) DEBUG: <script>: Diameter: Orig authorizing media via Rx
>>>>>>> 5(12153) DEBUG: ims_qos [mod.c:609]: w_rx_aar(): Looking for route
>>>>>>> block [ORIG_SESSION_AAR]
>>>>>>> 5(12153) DEBUG: ims_qos [mod.c:621]: w_rx_aar(): Rx AAR called
>>>>>>> 5(12153) DEBUG: ims_qos [mod.c:1345]: create_return_code():
>>>>>>> Creating return code of [-2] for aar_return_code
>>>>>>> 5(12153) DEBUG: ims_qos [mod.c:1354]: create_return_code(): created
>>>>>>> AVP successfully : [aar_return_code]
>>>>>>> 5(12153) DEBUG: ims_qos [mod.c:627]: w_rx_aar(): Can't do AAR for
>>>>>>> call session in request.
>>>>>>>
>>>>>>> Why kamailio says that I Can't do AAR for call session in
>>>>>>> request? I have looked into source code and I found that the condition
>>>>>>> that is blocking the communication with PCRF is:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> //We don't ever do AAR on request for calling scenario...
>>>>>>> if (msg->first_line.type != SIP_REPLY) {
>>>>>>> LM_DBG("Can't do AAR for call session in request\n");
>>>>>>> return result;
>>>>>>> }
>>>>>>>
>>>>>>> Anyone can help me understand why it is happening? why it can't
>>>>>>> proceed if isn't a reply?
>>>>>>>
>>>>>>> Thank you for your support
>>>>>>>
>>>>>>> BR
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> José Seabra
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at 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 at lists.sip-router.org>sr-users at 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 at 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 at lists.sip-router.org>sr-users at 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 at smilecoms.com>jason.penton at 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 at 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 at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cumprimentos
>>>> José Seabra
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> 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 at smilecoms.com>jason.penton at 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 at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
--
Cumprimentos
José Seabra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160428/106e2977/attachment.html>
More information about the sr-users
mailing list