[OpenSIPS-Users] Authenticating CPL locations

[Bogdan-Andrei Iancu]

Hi Rick,

You hit the biggest problem with CPL - encapsulation ; so, it is really 
difficult in integrate with any other functionalities.

So, regarding issue 2), you need at script level to remember who you run 
the script for and, in case of fwd, use branch_route to check if you 
need to do auth (if going to a foreign domain) and load the appropriate 
credentials (for calling user to the chosen destination).

About the SDP filtering - the CPL RFC does not has such a switch, as it 
mainly focus on the signaling part. So there is no official extension. 
If you want to develop something like that, we can add it to the module 
(and also if you need help with the module, use the devel mailing list).

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 12/04/2012 09:36 PM, Rick van Rein wrote:
> Hi Bogdan,
>
>>> Yes indeed.  I want to filter and forward domain-bound SIP services
>>> and forward that.  I'd like to keep it as general as possible, so
>>> others can use it too.
>> Not following you - location node can only look in the registered
>> contacts (in the cpl module). So the outcome of a location node is
>> loading contacts and forwarding to the devices.
>> Maybe you can detail a bit here.
> Sure -- someone would try to access sip:rick at example.com which gets
> translated by CPL into sip:12345 at provider.nep -- now if provider.nep
> needed authentication for the call to get through, CPL on its own is
> not going to get through.  As you stated, the uac_auth module can help.
>
> Now if someone else setup sip:john at example.com and wanted to forward
> it to sip:7896 at elsewhere.nep they might also have to authenticate,
> using their own secret.
>
> 1. uac_auth did not seem to allow for such setups -- but below you are
>     explaining that it actually does;
>
> 2. uac_auth cannot separate forwarding on behalf of john from rick,
>     so john could actually employ rick's forwarding route with client
>     authentication and thereby abuse any credits on that account.  This
>     is a problem if CPL filters cannot mutually trust one another.
>
> This actually is turning into a practical case over here -- we are
> experimenting with a new mobile provider who unleashes the GSM link to
> mobile phones as a SIP-address, but protected with a per-account password
> so as to keep access limited to one's own setup.
>
>> you can use as many secrets you want :) - the uac module has as
>> params 3 avps for dynamically passing to the uac_auth() function the
>> username, realm and passwd to be used for auth - and you can load
>> these values from DB or whatever.
> Ah!  Couldn't infer that from the README!  That solves issue 1. above;
> but issue 2. seems to remain.  I can probably trick around that in some
> way or another.  I'll have a go :)
>
>>> Do stop me if I'm saying something stupid :)
>> see above :)
> I can be really stupid if I'm deprived of documentation ;-) so thanks
> for compensating for that!
>
>>> It may be due to the use of an XML Schema in the RFC and a DTD in
>>> OpenSIPS...?
>> It may be - i remember some hard times making DTD validation working
>> with libxml2 while using namespaces... Simply skip that for the
>> moment :).
> Haha, ok.  Chances are I'll be poking around in the module at some point,
> so I might then give it a try too -- I'd love to have an extension that
> can filter on SDP...
>
>   - is there a line "c=IN IP4" and/or a line "c=IN IP6" for each "m=" line?
>   - is there an "m=video" and/or "m=text" in the SDP portion?
>   - is there a blacklisted IP address in any of the "c=" lines?
>   - is support for ZRTP actively offered for all media streams?
>
> ...and I totally understand if I'll have to do this myself.  Shouldn't be
> a problem to donate back if I find the time for doing this.
>
>
> Thanks a lot for explaining how to authenticate with CPL!
>
>
> Cheers,
>   -Rick