[Home]

Summary:ASTERISK-16418: [patch] When matching peers check invite from domain against domain list
Reporter:rsw686 (rsw686)Labels:
Date Opened:2010-07-24 21:29:39Date Closed:2011-06-07 14:05:23
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-1.6.2.11-invite-domain-check.patch
Description:In trying to get the Exchange UM play on phone feature to work I developed this patch. Exchange UM is sending the below SIP invite. Asterisk ignores the domain when finding a matching SIP peer based on username. Since the invite from field matches a device in sip.conf with a secret Asterisk is responding with unauthorized. What I needed was for Asterisk to IP match my sip peer with insecure=port,invite.

INVITE sip:2001@voip.mydomain.net;user=phone SIP/2.0
FROM: ""<sip:2001@exch.testdev.local;user=phone>;epid=079E8F8013;tag=849256682
TO: <sip:2001@voip.mydomain.net;user=phone>

The debug output looks like

Using INVITE request as basis request - 5c97e0f0-5456-4b82-a7f4-e7f2adeba338
Found peer '2001' for '2001' from 10.10.1.31:19219

The patch address the issue by checking the from domain when domain support is enabled. In my configuration I just needed to enable autodomain=yes in sip.conf.

Now the debug output looks like

Using INVITE request as basis request - 54d10d2e-01d1-451e-b21a-ef4bba987a0f
Unknown peer from domain exch.testdev.local
Found peer 'exchange-vm' for '2001' from 10.10.1.31:37810

For those not utilizing domain support this will have no effect. In my testing with Polycom and Linksys phones all setup the invite with From: userid@registrationserver.

****** ADDITIONAL INFORMATION ******

More information available on the mailing list archive
http://lists.digium.com/pipermail/asterisk-users/2010-July/251529.html
Comments:By: rsw686 (rsw686) 2010-07-25 22:03:06

My issue description was based on problem/resolution with Exchange UM and doesn't explain how this improves domain functionality with Asterisk in mind. In sip.conf it states "REGISTER to non-local domains will be automatically denied if a domain list is configured." The REGISTER To field is deviceid@registrationserver so the INVITE From field should always be deviceid@registrationserver. If the INVITE From field domain doesn't match the domain list the device couldn't have been registered. Therefore there is no need to try and find a matching peer for unknown domains.
By: Olle Johansson (oej) 2010-07-27 01:38:14

The From: header is not related to local domains. You register to an AOR in a domain, which is given in the To: header. The r-uri can be the registrar server or the domain you are registering in.

This patch is basically wrong, as it is against the RFC 3261 standard.
By: rsw686 (rsw686) 2010-07-27 12:13:48

How can I change it to address the issue of Asterisk matching peers without checking the domain? Or is this against RFC standard? I can't change the Exchange UM INVITE and I want softphone users to be able to user their extension for the sip device username. Maybe I add the capability for domain to be set for each device? For example with the below the INVITE would only match peer 2000 for voip.mydomain.net?

[2000]
secret=
type=friend
domain=voip.mydomain.net
By: Olle Johansson (oej) 2010-07-27 13:34:22

Asterisk doesn't bother with domains today, more than for REGISTER messages, the rest is something you add to the dialplan. I would like to see a REGISTER from your server to understand what your problem really is and why we don't match the list of configured domains, which we should.

We need to add the domain like you write, but that would change the peer matching totally, something I plan to do now after 1.8. If you look into the code there are already hooks for being able to set domain-specific settings instead of having only one [general] setting.

Asterisk currently has only one name space for type=users, where we match on the username part and not the domain part. For peers, we don't match on name at all on INVITES, only on IP if there's no type=user for that name. There are several documents on the web that explains our matching scheme.

I do agree with you that the long term solution is to skip user/peer/friend and move to full matching on AORs. But that's a lot of work and won't be backwards compatible.
By: rsw686 (rsw686) 2010-07-27 15:34:05

I understand the matching scheme. Matching on only the username part is the problem since the INVITE looks to be from user, but should be matched to a peer. Exchange UM can't be changed and it is building the INIVTE to look like it is a call from the user to the user. Let me briefly go over my configuration.

I am using FreePBX in device and user mode. I have devices that match user extensions like 2001, 2002, 2003, 2004. These end up in sip.conf as

[2001]
type=friend
secret=xxxxxx
....

[2002]
type=friend
secret=xxxxxx
....

I have also a trunk to Exchange UM which looks like the below.

[exchange-vm]
type=peer
host=exch.testdev.local
transport=tcp
insecure=port,invite
context=from-internal

Exchange UM works with insecure TCP SIP. Sending calls to Exchange UM voicemail works great with Dial SIP/exchange-vm. When using the Exchange UM play on phone feature it creates an INVITE to asterisk.

INVITE sip:2001@voip.mydomain.net;user=phone SIP/2.0
FROM: ""<sip:2001@exch.testdev.local;user=phone>;epid=079E8F8013;tag=849256682
TO: <sip:2001@voip.mydomain.net;user=phone>

This is where the issue happens. Asterisk has the following code in check_auth_result

              /* First find devices based on username (avoid all type=peer's) */
               peer = find_peer(of, NULL, TRUE, FINDUSERS, FALSE, 0);

               /* Then find devices based on IP */
               if (!peer) {
                       peer = find_peer(NULL, &p->recv, TRUE, FINDPEERS, FALSE, p->socket.type);
               }

It you watch the debug output it looks like

Using INVITE request as basis request - 5c97e0f0-5456-4b82-a7f4-e7f2adeba338
Found peer '2001' for '2001' from 10.10.1.31:19219

Asterisk is matching user 2001 in sip.conf to the INVITE and then proceeds to send 401 Unauthorized to Exchange UM. If I remove the 2001 device from sip.conf Asterisk doesn't match the user, but matches the exchange-vm peer based on IP. This is what I want to happen as Exchange UM only works with insecure.

Using INVITE request as basis request - 413feda8-186c-4fe1-a82d-eb074be527e1
Found peer 'exchange-vm' for '2001' from 10.10.1.31:63436

So with the Asterisk code the way it is I would have to change all my softphone users to something like 12001, 12002, etc. This is confusing for them as X-Lite shows on the phone 12002 and they think that is their extension.

Otherwise I need the check_auth_result code to only match the peer based on the URI domain namespace. Since the Exchange UM domain (exch.testdev.local) and Asterisk domain (voip.mydomain.net) are different the 2001 peer would not be matched and play on phone would work.


By: Olle Johansson (oej) 2010-07-28 01:06:32

Oh, I see the problem. The broken exchange INVITE messes with FreePBX. If you define all your type=friend as type=peer to remove the matching on the From: username and only match on IP, I think you might have an easier path forward. Your problem is that you have type=user objects that block proper matching.
By: rsw686 (rsw686) 2010-07-28 09:00:39

If I only match on IP I potentially have problems if somebody has two phones at a remote location behind NAT. That is why I thought matching the INVITE From: username based on domain namespace could be beneficial. The domain support in Asterisk can restrict REGISTER and direct INIVTE's to a context based on the To domain. Does it not make sense to add this functionality?

My original patch was based on the thought of why would you want to match a type=user object for a domain not defined on the Asterisk box. If I changed it so that each type=user object could have a domain defined then you potentially could have a multi-tenant system with the same username for multiple domains.
By: Olle Johansson (oej) 2010-07-28 09:03:28

If you check, we match on both ip/port, unless you use the insecure port setting. Why don't you test a bit?

What you are proposing is the right way to go in the future, but it requires a lot of work to get done properly. Let's fix your problem first.

/O
By: Leif Madsen (lmadsen) 2010-07-29 15:15:31

I'd suggest we figure out what really needs to be done with this issue. Once that is defined then other developers will have a better idea as to how to help with this.
By: Olle Johansson (oej) 2010-07-29 15:24:34

Currently is a combination of a bad configuration and a feature request for the future.
By: Paul Belanger (pabelanger) 2010-08-18 08:03:06

Based on oej's comments, I'll suspend this issue.

---
Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.

Further information can be found at http://www.asterisk.org/developers/bug-guidelines