[asterisk-dev] chan_sip SIP Authentication

[asterisk at ntplx.net]

I know this is a can of worms and I'm just getting into a hornet's nest
with this. I understand that it's a bad idea to mix phone numbers
and device names. But I'm looking for some answers to internal asterisk
programming questions.... It is not my intent to drag everyone into this,
but this is the DEV list...

On my PRI gateway I an using RPID to transfer the CID info and I
force the "from" to just be "asterisk" to avoid auth issues. But this
is causing some issues when RPID does not work correctly.

But I am looking to solve this for my self. I am looking at two
ways to "solve" this issue. One is to match the peer first, the second
is to match the peer after an auth fail. If I match the peer first
then it seems to match a known "friend" as a peer...I guess because
a "friend" is a peer when it's known.

Correct? Known friends are IP peers in the too?????

> If you set type=peer it won't. type=friend will. But a friend
> is still a peer in memory. I have not changed configuration ...yet.

So if I match peers first, before user names, what problem am
am I going to cause when I match friends as peers?


   Andrew




Quoting Johansson Olle E <oej at edvina.net>:

>
> 28 jan 2009 kl. 15.41 skrev Klaus Darilion:
>
>>
>>
>> Johansson Olle E schrieb:
>>> Well,
>>>
>>> The problem arises since you use phone numbers as identifiers for the
>>> users. This is not a good thing (TM) and should be avoided. The
>>> dialplan is where you route phone numbers. Devices should have device
>>> names that you address in the dialplan on the extension that is
>>> supposed to connect to one or several devices.
>>
>> That's the more elegant version, but then you need a mapping from
>> number
>> to user. Thats why I use name=number to avoid this mapping
> That is why you have hints, Klaus.
>
>>
>>>
>>> I guess we have no make this need of namespace separation clear in
>>> the
>>> documentation.
>>>
>>> If we go ahead and change matching order, I'm afraid it will break
>>> backwards compatibility and stop many systems from working properly.
>>> We don't want that.
>>>
>>> The real solution to this users/peers/friends thing is to create a
>>> better solution and implement it. The first big step towards it was
>>> to
>>> kill the sip_user structure,
>>> and thus the need for users at all in 1.6.1. We now also match peers
>>> by name before we match IP.
>>
>> Does this mean that my setups do not work anymore in 1.6.1. Does all
>> peers use this name checking or is this an configuration option?
> If you set type=peer it won't. type=friend will. But a friend is still
> a peer
> in memory. I have not changed configuration ...yet.
>
>>
>>> This implements a way to
>>> - register with SIp services
>>> - get the call back
>>> - match the proper peer, even if you have five accounts, we will
>>> match
>>> the proper peer
>>> - send the call to the called number (to: header), not using a
>>> pseudo-
>>> exten that overrides.
>>
>> ahh. It took us many yours to tell vendors that To-based routing is
>> wrong.
> Oh yes, it is. In theory you should never do that, but...
>
> But if you register for a service, the request URI is whatever
> you register with and can't really be used for any routing decisions
> in a b2bua.
> For a simple phone, it doesnt matter. Registration for a trunk service
> doesn't really work,
> which might be a design flaw in SIP.
>
> How on earth do you get the requested number without checking To: or
> RPID?
>
> /O
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>