[Home]

Summary:ASTERISK-12573: "From" shouldn't be matched against "users" if INVITE arrives from a "peer" IP
Reporter:Iñaki Baz Castillo (ibc)Labels:
Date Opened:2008-08-13 04:30:27Date Closed:2011-06-07 14:08:08
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Hi, I've realized that Asterisk matches "From" header even if the call arrives via a defined "peer" IP, so Asterisk asks it for authentication (that is not possible coming from a provider).

Example:

sip.conf:
----------
[200]
type=friend
host=dynamic
secret=*****

[provider]
type=peer
host=1.2.3.4
----------

If the following INVITE arrives from IP 1.2.3.4 then Asterisk will reject it with "403 Forbidden" since it matches the "From: sip:200@sip_provider.com" against user 200:

---------------
INVITE sip:999888777@asterisk_ip.org SIP/2.0
From: <sip:200@sip_provider.com>
---------------

IMHO Asterisk must not try to match a user ("From") if the INVITE arrives from a peer IP.
The only way to solve it is by ensuring that any INVITE arriving from the peer has a "From" different than any Asterisk user, that is impossible (imagine the case in which Asterisk receives a call from an external SIP provider with peering relation with "sip_provider.com", something like:

---------------
INVITE sip:999888777@asterisk_ip.org SIP/2.0
From: <sip:200@sip_provider.com>
P-Asserted-Identity: <sip:999888777@sip_provider.com>
---------------

PD: I know Asterisk doesn't handle PAI header, imagine then it's RPID.
Comments:By: Olle Johansson (oej) 2008-08-13 04:35:19

This is an effect of the architecture, not a bug. This is how it works. We always first match users on From user name, then look for peers on incoming calls. It's well documented in books and trainings, as well as in several mails on asterisk-users mailing list.
By: Iñaki Baz Castillo (ibc) 2008-08-13 07:43:03

Yep, I already know this is the "expected" behaviour. But what I wonder is if it's should be.

Note the example above in which Asterisk receives, via a peer, a call with a "From" matching a user (but it's just casuality, also the domains are differents).

Do you mean that this can't be handled in chan_sip and involves architecture changes?
By: Olle Johansson (oej) 2008-08-13 08:14:11

yes, thus the recommendation that you should not use user names that correspond to extension names at all. use random strings or MAC addresses. Anything else may cause namespace conflicts.

The device names and extensions are two different worlds.
By: Iñaki Baz Castillo (ibc) 2008-08-13 08:33:38

I think that recomendation (using different usernames and extensions) is wrong. Many phones show their extension (the username in fact) to the user (as Linksys, Thomon...) so it's not cool if you see in the phone screen "Your extension: oej" cuando to receive a call other user must dial 215.
By: Iñaki Baz Castillo (ibc) 2008-08-13 08:38:24

> ****cuando**** to receive a call other user must dial 215.

Sorry, it seems I was using Spanglish... I mean "when". XD
By: Jared Smith (jsmith) 2008-08-13 11:01:08

I concur with oej.  Asterisk has no way of magically knowing that this call came from a peer.  As he explained, Asterisk first checks the list of users (on the From: name), and then if *and only if* it doesn't find a match there does it match the peers (based on the IP address and port), and I don't see any overriding reason to change this behavior in the short term.

I also second oej's recommendation not to mix extension names with device names.  It'll only cause you heartache and trouble.
By: Iñaki Baz Castillo (ibc) 2008-08-13 11:31:33

@jsmith:
AFAIK Asterisk does can know if the call came from a peer (by looking the source IP:port before mathing the "From"). I understand it's not implemented in this way, that's way I **suggest** it.


You said:
> I also second oej's recommendation not to mix extension names with device
> names. It'll only cause you heartache and trouble.

Maybe I must improve my REAL example (it has occured to me today):

The world is more than ISUP/SS7 calls and VoIP is each time more extended. For example I admin a small SIP provider and of course I allow direct SIP_2_SIP calls between users. Also any SIP provider with peering relationship with others does the same.

- From my phone (sip:211 in my local Asterisk) I called a PSTN number (999888777).

- Asterisk added "P-Asserted-Identity: 999000111" before send the INVITE to the SIP provider.

- The SIP provider (my SIP provider in fact) checks the PAI number (it's allowed this one for this user) and since the destination 999888777 is also other local user (identified with "sip:client2@sip_provider.com") then my proxy forwards the INVITE to the location of "sip:client2@sip_provider.com" (another Asterisk).

- So the INVITE arriving to the second Asterisk is like:
---------------
INVITE sip:999888777@asterisk2_IP SIP/2.0
From: <sip:211@asterisk1_domain.com>
P-Asserted-Identity: <sip:999000111@asterisk1_domain.com>
---------------

- Now the problem occurs because 211 is **also** a local user of Asterisk 2, so Asterisk 2 rejects the call (because it matches the INVITE as coming from an user instead of coming fro mthe peer).


As you can imagine, I **cannot** control that ANY local extension in any other Asterisk doesn't match other local extension in any other Asterisk. It's impossible at all!

So I hope you understand that an Asterisk administrator can do NOTHING to avoid this problem in case it uses a SIP provider to receive calls.

So, in my opinion:
- Asterisk should first check if the call comes from a peer (IP:port).
- If not chech if it's a local user.

If not, IMHO Asterisk is not ready for a SIP world :(
By: Iñaki Baz Castillo (ibc) 2008-08-13 11:44:47

Also, using different usernames and extensions just to avoid those issues is too much IMHO.
By: Iñaki Baz Castillo (ibc) 2008-08-13 11:46:18

And also, many Asterisk GUI's as VoiceOne (and I think AsteriskGUI too) force the username to be the same as its extension.
By: Olle Johansson (oej) 2008-08-13 12:00:53

Well, regardless of what we think, this is the way it is and it's in the deep inside of chan_sip and can't easily be changed without a massive rewrite. If others haven't listened to all the advice on mailing lists, in the Asterisk book and other places, then it's up to them really.

I've proposed a different design in chan_sip3, see http://www.codename-pineapple.org - and there's a reason for that proposal.

This is a feature request and we don't tend to keep them in the bug tracker.
By: pj (pj) 2008-08-14 15:46:24

ibc, did you try to look at 'match_auth_username' sip.conf option?
maybe it can solve your issue.
By: Iñaki Baz Castillo (ibc) 2008-08-19 02:39:09

Thankt pj, I didn't try it. But I cannot understand how it can work, I mean: if you don't ask a request for authentication it will no send you a (Proxy-)Authorization header so there will not be auth "username" in the request. ¿?¿?
By: pj (pj) 2008-08-19 02:50:06

if it can't match 'username' due lack of autorizaton header, asterisk places this incomming call into context specified in [general] sip.conf section (you also should enable 'allowguest=yes')
By: Leif Madsen (lmadsen) 2008-12-05 10:57:30.000-0600

I'm closing this issue as it is quite clear the way this currently works is a bug, and the request to change the way this is handled is a feature request. Thanks!