Posted: Thu Dec 06, 2007 7:23 pm Post subject: [asterisk-dev] Kill the user, kill the user!
Friends,
For many years, I've been working to remove the "type=user" and
"type=friend" from chan_sip. In 1.4 you can in fact
do everything you can do with a user with a peer. The only difference
is the way we match incoming calls.
* For users, we match the user object name with the From: username
(without the domain).
* For peers, we match on IP for incoming calls.
I've created a branch called "kill_the_user" that has no type=friend
or type=user, only peers.
Incoming calls are handled this way
* First, we match on peer object name with the From username
* Then we try to match on IP/Port
* If we can't match, we send to the context defined in the "general"
section in sip.conf or to "default".
If you can find any way this may give you problems, please inform me
now. Otherwise, I'm going
to test this branch with all of you. I don't foresee any problems
going ahead with this in trunk.
For backwards compatibility, we will accept "type=friend" and
"type=user" with a warning in 1.6,
then remove it totally. Old configurations will still work.
For realtime, realtime users will not be used any more.
I hope this will make chan_sip easier to understand and use.
Feedback is appreciated!
/Olle
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Dec 06, 2007 8:01 pm Post subject: [asterisk-dev] Kill the user, kill the user!
-----Original Message-----
From: asterisk-dev-bounces@lists.digium.com [mailto:asterisk-dev-bounces@lists.digium.com] On Behalf Of Johansson Olle E
Subject: [asterisk-dev] Kill the user, kill the user!
[skip]
Quote:
For realtime, realtime users will not be used any more.
What does it mean?
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Dec 06, 2007 8:11 pm Post subject: [asterisk-dev] Kill the user, kill the user!
Dmitry Andrianov wrote:
Quote:
-----Original Message-----
From: asterisk-dev-bounces@lists.digium.com [mailto:asterisk-dev-bounces@lists.digium.com] On Behalf Of Johansson Olle E
Subject: [asterisk-dev] Kill the user, kill the user!
[skip]
> For realtime, realtime users will not be used any more.
What does it mean?
I interpret this to mean that instead of having realtime users and realtime
peers, there will only be realtime peers.
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Dec 06, 2007 9:28 pm Post subject: [asterisk-dev] Kill the user, kill the user!
On Thursday 06 December 2007 14:00:19 Mark Michelson wrote:
Quote:
Dmitry Andrianov wrote:
> -----Original Message-----
> From: asterisk-dev-bounces@lists.digium.com
> [mailto:asterisk-dev-bounces@lists.digium.com] On Behalf Of Johansson
> Olle E Subject: [asterisk-dev] Kill the user, kill the user!
>
>
> [skip]
>
>> For realtime, realtime users will not be used any more.
>
> What does it mean?
I interpret this to mean that instead of having realtime users and realtime
peers, there will only be realtime peers.
More specifically, sippeers will be used, sipusers will not. Note that
iaxpeers and iaxusers are unaffected.
--
Tilghman
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
For many years, I've been working to remove the "type=user" and
"type=friend" from chan_sip. In 1.4 you can in fact
do everything you can do with a user with a peer. The only difference
is the way we match incoming calls.
* For users, we match the user object name with the From: username
(without the domain).
* For peers, we match on IP for incoming calls.
I've created a branch called "kill_the_user" that has no type=friend
or type=user, only peers.
Incoming calls are handled this way
* First, we match on peer object name with the From username
* Then we try to match on IP/Port
* If we can't match, we send to the context defined in the "general"
section in sip.conf or to "default".
If you can find any way this may give you problems, please inform me
now. Otherwise, I'm going
to test this branch with all of you. I don't foresee any problems
going ahead with this in trunk.
For backwards compatibility, we will accept "type=friend" and
"type=user" with a warning in 1.6,
then remove it totally. Old configurations will still work.
For realtime, realtime users will not be used any more.
I hope this will make chan_sip easier to understand and use.
Feedback is appreciated!
/Olle
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
I've created a branch called "kill_the_user" that has no
type=friend or type=user, only peers.
Incoming calls are handled this way
* First, we match on peer object name with the From username
* Then we try to match on IP/Port
* If we can't match, we send to the context defined in the "general"
section in sip.conf or to "default".
Will this mechanism be able to distinguish between calls from the
following?
From: <sip:1234@example1.net>
From: <sip:1234@example2.net>
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
> I've created a branch called "kill_the_user" that has no
> type=friend or type=user, only peers.
>
> Incoming calls are handled this way
>
> * First, we match on peer object name with the From username
> * Then we try to match on IP/Port
> * If we can't match, we send to the context defined in the "general"
> section in sip.conf or to "default".
Will this mechanism be able to distinguish between calls from the
following?
From: <sip:1234@example1.net>
From: <sip:1234@example2.net>
call <-> section matching was discussed in a thread some time ago.
I think it is correct to say that there is no single method that satisfies
everyone, so the type and order of matching needs to be configurable.
trunk already has this section in chan_sip.c, and i hope it has
Not disappeared (or at least, I certainly want it reintroduced, as
it is off by default):
if (global_match_auth_username) {
/*
* XXX This is experimental code to grab the search key from the
* Auth header's username instead of the 'From' name, if available.
* Do not enable this block unless you understand the side effects (if any!)
* Note, the search for "username" should be done in a more robust way.
* Note2, at the moment we chech both fields, though maybe we should
* pick one or another depending on the request ? XXX
*/
Matching on IP/port may be ok in some cases (i.e. if you trust the IP/port!)
I think matching on the From username is completely bogus because there is
no check whatsoever on that field - clients may generate a random value
and it is not authenticated in any way.
In any case, when the 'user' is gone i will be glad to add in some hooks
so you can define the order and type of checks as you like.
cheers
luigi
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Fri Dec 07, 2007 5:20 pm Post subject: [asterisk-dev] Kill the user, kill the user!
On Thursday 06 December 2007 16:48:43 Patrick wrote:
Quote:
On Thu, 2007-12-06 at 14:04 -0800, Ryan Mitchell wrote:
> To raise an issue that's come up a few times before, instead of
> checking user then ip/port, why not check ip/port first then user?
How about making it configurable per peer?
That doesn't make any sense. The whole purpose of this code is to FIND
the peer. By the time you know which peer, it's too late.
--
Tilghman
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Fri Dec 07, 2007 5:58 pm Post subject: [asterisk-dev] Kill the user, kill the user!
Hi!
Johansson Olle E wrote:
Quote:
Incoming calls are handled this way
* First, we match on peer object name with the From username
* Then we try to match on IP/Port
* If we can't match, we send to the context defined in the "general"
section in sip.conf or to "default".
If you can find any way this may give you problems, please inform me
now. Otherwise, I'm going
to test this branch with all of you. I don't foresee any problems
going ahead with this in trunk.
Feedback is appreciated!
Should it solve my problems with incoming calls from my telco. I have
registered many lines on single SBC then incoming call have the same IP
and port. Difference only in To: user name. Incoming INVITE have not
auth, but when we send final BYE we have problem with auth name, because
it is wrong selected on initial INVITE. Can also peer search able by To
field?
--
Best regards,
Igor A. Goncharovsky
________________________________
ICQ: 648337
mailto: igi-go@ya.ru
________________________________
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Fri Dec 07, 2007 6:47 pm Post subject: [asterisk-dev] Kill the user, kill the user!
On Fri, Dec 07, 2007 at 11:05:57AM -0600, Tilghman Lesher wrote:
Quote:
On Thursday 06 December 2007 16:48:43 Patrick wrote:
> On Thu, 2007-12-06 at 14:04 -0800, Ryan Mitchell wrote:
> > To raise an issue that's come up a few times before, instead of
> > checking user then ip/port, why not check ip/port first then user?
>
> How about making it configurable per peer?
That doesn't make any sense. The whole purpose of this code is to FIND
the peer. By the time you know which peer, it's too late.
i was about to make the same comment in my previous email,
however there is perhaps a partially related per-peer setting,
namely allow/disallow/assign different weights to each
match criteria on a per-peer basis.
E.g. for certain peers who have little privilege (e.g.
cannot place external calls or cannot use toll services)
you might decide to allow IP/port matching even if not
authenticated; for other peers you could allow a match only
basing on some more reliable credential. And so on.
This requires a bit of thought but it is probably doable.
cheers
luigi
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Fri Dec 07, 2007 7:44 pm Post subject: [asterisk-dev] Kill the user, kill the user!
At 10:31 AM -0800 2007/12/7, Luigi Rizzo wrote:
Quote:
On Fri, Dec 07, 2007 at 11:05:57AM -0600, Tilghman Lesher wrote:
> On Thursday 06 December 2007 16:48:43 Patrick wrote:
> > On Thu, 2007-12-06 at 14:04 -0800, Ryan Mitchell wrote:
> > > To raise an issue that's come up a few times before, instead of
> > > checking user then ip/port, why not check ip/port first then user?
> >
> > How about making it configurable per peer?
>
> That doesn't make any sense. The whole purpose of this code is to FIND
> the peer. By the time you know which peer, it's too late.
i was about to make the same comment in my previous email,
however there is perhaps a partially related per-peer setting,
namely allow/disallow/assign different weights to each
match criteria on a per-peer basis.
E.g. for certain peers who have little privilege (e.g.
cannot place external calls or cannot use toll services)
you might decide to allow IP/port matching even if not
authenticated; for other peers you could allow a match only
basing on some more reliable credential. And so on.
This requires a bit of thought but it is probably doable.
cheers
luigi
I will concur with Luigi's comments.
I frequently have situations where I need to match based _only_ on IP
address/port (or IP address range, even more of a headache) and I
also need to match on user credentials for any hosts not in those
ranges. Think of this situation, which for me is quite common:
1) I have a VoIP provider who sends me calls, but doesn't understand
authentication. They have a /24 from which INVITEs originate to
ranges of DIDs on my Asterisk system.
2) I have a dumb VoIP device that sits at the house of the CEO that
doesn't understand authentication. I know the /24 of his
DHCP-allocated network range, but can't anticipate what address the
INVITEs will come from.
3) I have a set of users who roam with their smartphones and can
appear anywhere on the Internet. These users require passwords for
authentication to my system to receive/make calls on their discreet
extensions.
Is this easily possible with the new methodology? Because it's been
a constant headache in the past with getting the configuration right
for situations like this.
JT
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Fri Dec 07, 2007 8:08 pm Post subject: [asterisk-dev] Kill the user, kill the user!
Hi all,
On Fri, 2007-12-07 at 11:25 -0800, John Todd wrote:
Quote:
I frequently have situations where I need to match based _only_ on IP
address/port (or IP address range, even more of a headache) and I
also need to match on user credentials for any hosts not in those
ranges. Think of this situation, which for me is quite common:
1) I have a VoIP provider who sends me calls, but doesn't understand
authentication. They have a /24 from which INVITEs originate to
ranges of DIDs on my Asterisk system.
I can confirm this scenario... that's pretty common when you do traffic
exchange between providers or send/receive traffic using sip "trunks".
The auth is based only on the ip address, nothing more.
jm2c
matteo.
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Fri Dec 07, 2007 9:35 pm Post subject: [asterisk-dev] Kill the user, kill the user!
On Fri, Dec 07, 2007 at 11:25:54AM -0800, John Todd wrote:
...
Quote:
I will concur with Luigi's comments.
I frequently have situations where I need to match based _only_ on IP
address/port (or IP address range, even more of a headache) and I
also need to match on user credentials for any hosts not in those
ranges. Think of this situation, which for me is quite common:
1) I have a VoIP provider who sends me calls, but doesn't understand
authentication. They have a /24 from which INVITEs originate to
ranges of DIDs on my Asterisk system.
2) I have a dumb VoIP device that sits at the house of the CEO that
doesn't understand authentication. I know the /24 of his
DHCP-allocated network range, but can't anticipate what address the
INVITEs will come from.
3) I have a set of users who roam with their smartphones and can
appear anywhere on the Internet. These users require passwords for
authentication to my system to receive/make calls on their discreet
extensions.
Is this easily possible with the new methodology? Because it's been
a constant headache in the past with getting the configuration right
for situations like this.
"easily" has two aspects.
one is the amount of code needed to implement this flexibility,
the other one is the processing cost.
The code complexity is very limited: it suffices to have a library
of 'match' functions, and define for each peer which one(s) to
invoke to check for a match, and the corresponding return values
in case of success. E.g.
[ceo_phone]
match = match_by_ip(1.2.3/24) -> 100
[user_foo]
match = match_by_auth(foobar) -> 100
match = match_by_from(foobar) -> 1
then after a full scan of peers you can make a selection.
While trivial to implement, this is expensive at runtime (though
basically the same as the current method, which has O(n) cost too).
If you limit the set of match functions, you can in principle organize
the peers in such a way that lookup is efficient, e.g. using some additional
indexing data structures specifically designed for the lookup, e.g.
hash tables to support lookup on the From/Auth, tries to support
lookups on the IP/port, and so on.
This all can be done transparently i.e. pay the extra cost only for
those peers who request matching on some 'unoptimized' criterion.
I think the above is the complete design for an efficient and flexible
peer matching scheme. I am not sure i or someone else are willnig to
implement this in our spare time - most of the fun is in the design,
and i already had my share :)
cheers
luigi
I suspect this is not the kind of code one writes 'for fun' - it is
really a pure
Quote:
JT
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Mon Dec 10, 2007 7:03 am Post subject: [asterisk-dev] Kill the user, kill the user!
7 dec 2007 kl. 17.45 skrev Igor A. Goncharovsky:
Quote:
Hi!
Johansson Olle E wrote:
> Incoming calls are handled this way
>
> * First, we match on peer object name with the From username
> * Then we try to match on IP/Port
> * If we can't match, we send to the context defined in the "general"
> section in sip.conf or to "default".
>
> If you can find any way this may give you problems, please inform me
> now. Otherwise, I'm going
> to test this branch with all of you. I don't foresee any problems
> going ahead with this in trunk.
>
> Feedback is appreciated!
>
Should it solve my problems with incoming calls from my telco. I have
registered many lines on single SBC then incoming call have the same
IP
and port. Difference only in To: user name. Incoming INVITE have not
auth, but when we send final BYE we have problem with auth name,
because
it is wrong selected on initial INVITE. Can also peer search able by
To
field?
Well, that is a different thing. After I've removed the user, my plan
was to add "service" and "trunk".
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
