TR:
This was the "easy" part. I ended up making my own table in the database and I
wrote some code that essentially does the same as the permission module (with a
few minor enhancements). The initial issue was trying to determine which
authentication mechanism to apply to an INVITE packet when it comes in, which
"is_from_local()" solved.
Thx!
Brett Woollum
br...@woollum.com
----- Original Message -----
From: "T.R. Missner" <t...@voipjedi.com>
To: "OpenSIPS users mailling list" <users@lists.opensips.org>
Sent: Tuesday, September 14, 2010 2:00:12 PM GMT -08:00 US/Canada Pacific
Subject: Re: [OpenSIPS-Users] Help with Inbound PSTN, and Inbound SIP URI
Authentication Sub-Routine
I've used the permissions module for this in the past.
Essentially you can whitelist your carriers' IP addresses using permissions
module.
-tr
On Tue, Sep 14, 2010 at 4:52 PM, Brett Woollum < br...@woollum.com > wrote:
Hi Kennard,
I need to provide some level of authentication for incoming calls. This is
because I need to allow my PSTN gateways to bring any calls for my DIDs into
OpenSIPS, but I don't want to open the door and allow anybody from the internet
to call any of my DIDs using a direct URI. I have a database table that
contains incoming DIDs that I process calls from my gateway against, and a
sepearate database table which contains incoming SIP URI's that I process
completely unauthenticated calls against.
In this scenario, my PSTN gateway can bring calls into sip:
+13145551...@mysipdomain.com , but an Internet user cannot call that number. On
the other hand, an unauthenticated Internet user can call
sip:mycomp...@mysipdomain.com sucessfully.
Does this make sense?
Brett W
Sent from my iPhone
On Sep 14, 2010, at 8:44 AM, kennard_wh...@logitech.com wrote:
Hi Brett,
For what it is worth, I do it the other way around: I check the source IP, and
if from a PSTN provider process the telephone number as appropriate for them;
otherwise I do user auth.
A question: if you're allowing "outside" users to call in, why authenticate any
INVITE traffic? (Ok, you have to authenticate traffic going to PSTN from your
subscribers, but other than that...)?
Regards,
Kennard
<graycol.gif> Brett Woollum ---09/14/2010 02:26:33 AM---David, The
"is_from_local" function is just what I needed. It will allow me to decipher
whether or
From: Brett Woollum < br...@woollum.com >
To: OpenSIPS users mailling list < users@lists.opensips.org >
Date: 09/14/2010 02:26 AM
Subject: Re: [OpenSIPS-Users] Help with Inbound PSTN, and Inbound SIP URI
Authentication Sub-Routine
Sent by: users-boun...@lists.opensips.org
David,
The "is_from_local" function is just what I needed. It will allow me to
decipher whether or not the user appears local or not, and authenticate them if
so (ie: a subscriber), or check their IP if not (ie: from my gw).
Thanks!
Brett Woollum
br...@woollum.com
----- Original Message -----
From: "David J." < da...@styleflare.com >
To: "OpenSIPS users mailling list" < users@lists.opensips.org >
Sent: Tuesday, September 14, 2010 1:08:38 AM GMT -08:00 US/Canada Pacific
Subject: Re: [OpenSIPS-Users] Help with Inbound PSTN, and Inbound SIP URI
Authentication Sub-Routine
It depends on your configuration.
You can place it before or after.
Because you dont want to authenticate inbound calls, you can have a simple if
statement that checks if the user is not local and alias exists, then relay to
that alias.
Not real code:
if(not_from_local){
if(alias()){
relay;
}
}
On 9/14/10 3:32 AM, Brett Woollum wrote:
Hi David, As far as I can tell, the alias module is independent of how the call
is authenticated. My understanding is that it will look for a replacement URI
based on the current one, and replace if a new one is found. It appears as
though this "function" would go into the config file somewhere after the
section I'm working on now. Is my understanding correct? I'll need some way to
determine if this is an inbound call (i.e.; not originating from a subscriber's
phone) prior to mapping it to the alias module. Also, I'd like to determine if
the incoming call is from my PSTN gateway and give different aliases than if
the call was a SIP URI call. Brett Woollum br...@woollum.com ----- Original
Message ----- From: "David J." <da...@styleflare.com> To: "OpenSIPS users
mailling list" <users@lists.opensips.org> Sent: Tuesday, September 14, 2010
12:20:23 AM GMT -08:00 US/Canada Pacific Subject: Re: [OpenSIPS-Users] Help
with Inbound PSTN, and Inbound SIP URI Authentication Sub-Routine Hi Brett, The
common practice is to use the alias module for inbound routing. You can look at
the docs for its usage, but essentially you can map DID's to local users. On
9/14/10 3:18 AM, Brett Woollum wrote:
Hello! I have an OpenSIPS 1.6.3 installation that is working well. I have
subscribers registering to OpenSIPS, and they can dial between each other and
outside of my domain (to my media servers and to the PSTN). All is well. I am
now beginning to write the configuration that will process inbound calls -
meaning calls from non-subscribers. This will include calls from the PSTN
gateway, as well as direct SIP URI calls to the OpenSIPS subscribers. For
example, a person can call 515-555-1212 from a regular phone, and the call will
come to OpenSIPS as an un-authenticated call from my PSTN gateway. Also, I'd
like to accept SIP URI's for incoming calls. For example, calling
mycomp...@mysipdomain.com from a soft phone might route the call to subscriber
A's phone. The code I have that applies to this is: (This is currently
configured to authenticate all outbound calls from subscribers only.) #
authenticate if from local subscriber if (!(method=="REGISTER")) { if
(!proxy_authorize("", "subscriber")) { proxy_challenge("", "0"); exit; } if
(!db_check_from()) { send_reply("403","Forbidden auth ID"); exit; }
consume_credentials(); # caller authenticated } I am looking for direction on
how to expand this to determine if the call is A) from a subscriber calling
outbound, B) inbound from the PSTN, or C) inbound from any other user calling
my SIP URI's. Once I am able to determine this information, I'll be able to
route the call appropriately within the rest of my scripts. My problem is that
my SIP phones usually attempt to place calls without including authorization in
the header (because they are registered already), then OpenSIPS replies
requiring proxy authentication. The SIP phones will then try the call again
including the credentials in the header, which works. How can I re-write this
section of code to allow inbound SIP URI calls and calls from my PSTN gateway,
while still asking my subscribers to authenticate? Or, is there a method that
might work better? Notes: - Each of my PSTN gateway's has a static IP. - It's
safe to assume a single-domain setup ( mysipdomain.com ). Thanks in advance!
Brett Woollum br...@woollum.com _______________________________________________
Users mailing list Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
