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