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:[email protected] which gets
translated by CPL into sip:[email protected] -- 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:[email protected] and wanted to forward
it to sip:[email protected] 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

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to