[SR-Users] P-CSCF

[Fred Schulz]

Hi Jason,

thank you for your answer. But could you please explain how the UE is identified?
Is it the contact header? Or some other stuff .. I wasn’t able to find any information.

And yes, we plan to use the Rx as well. I am can make some traces and logs at Monday.


Thank you
Fred



Am 28.01.2016 um 20:49 schrieb Jason Penton <jason.penton at smilecoms.com<mailto:jason.penton at smilecoms.com>>:

Hi Fred,

I can answer the 1st question only as I am not too clued up with mediaproxy module and server.

The pcscf_is_registered function is used to confirm that the UE you are sending the request from is actually registered to the IMS. If this is true, then the P-CSCF will assert the identity and forward the request to I-CSCF or S-CSCF, depending on state and request type. Normally the interface between UE and P-CSCF is via ipsec so it's almost a given that any traffic coming in on the ipsec pipe can be asserted. In the case without IPSEC however, there are various methods used to make sure the UE that is sending the request is actually registered to the IMS. There are a few algorithms that can be configured to check - ie you can check the contact host and port (this is only works for invites as MESSAGEs don't have contact headers generally), then you can check the received IP and port to make sure it's coming from a currently registered contact that used the same IP:PORT combination, etc, etc.

Alternatively you could remove the check and pass the request onto the S-CSCF without asserting (not per std though) and then challenge all "cost incurring" requests with a 407 on the S-CSCF.... One limitatoin of not getting this working correctly is that you will not be able to use the Rx interface unless you can match a contact on the P-CSCF (ims_qos module).... but perhaps you are not interested in Rx interface at the moment?

If you send me a trace (pcap) and logfile I'll take a look as soon as I get a chance and let you know what the problem is.

Cheers
Jason

On Thu, Jan 28, 2016 at 9:24 PM, Fred Schulz <FSchulz at blackned.de<mailto:FSchulz at blackned.de>> wrote:
Hi all,

we’re just playing around with an IMS setup bases on kamailio. Therefore the kamailio is used as P-,I- and S-CSCF.
We where able to register two clients through all components.
As we wan to start a call session, the P-CSCF answers with „403 - Forbidden. You must register with an S-CSCF“…

I found this snippet in kamailio.cfg:

if (!pcscf_is_registered("location")) { send_reply("403","Forbidden - You must register first with a S-CSCF“); break; }

Can one tell me what exactly the kamailio is checking there? As I figured out it is looking in database location table.

The table contains the registered users registered towards the IMS.

Another „problem“ we faced with is the rtpproxy. As the ngcp-mediaproxy-ng is no longer available and replaced with rtpproxy we’re trying to use it. But kamailio said that the proxy isn’t answering the way expected.

ERROR: rtpengine [rtpengine.c:1622]: rtpp_test(): proxy responded with invalid response

Any advise would be nice.

Thank you
Fred


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org<mailto: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)
Mobile: +27 (0) 83 283 7000
Skype:  jason.barry.penton

jason.penton at smilecoms.com<mailto:name.surname at smilecoms.com>
www.smilecoms.com<http://www.smilecoms.com/>
[http://196.33.227.129/~smlcoms/sigs/pty/images/smile_signature_07_09.jpg]




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 at lists.sip-router.org<mailto:sr-users at lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160130/fb9001c6/attachment.html>