Open Source Training Seminar FreePBX Paid Support

Ticket #2838 (new Bugs)

Opened 3 months ago

Last modified 1 month ago

If a local extension matches the extension dialed in a call to a SIP URI, the local extension will be dialed instead.

Reported by: drmessano Assigned to: p_lindheimer
Priority: minor Milestone: 3.0
Component: Core Version: 2.4.0
Keywords: SIP URI Dial Local Extension Remote Cc:
Confirmation: Need Feedback SVN Revision (if applicable):
Backend Engine: All Backend Engine Version:

Description (Last modified by p_lindheimer)

If a local extension matches the extension dialed in a call to a SIP URI, the local extension will be dialed instead.

Example: 

1. Define extension 102 on your system.
2. Create a custom extension to dial SIP/102@someoneelsesdomain.com or use a client capable of dialing SIP URIs to dial the same.
3. The call will be placed to the local 102 extension.

This behavior seems to come and go.. and may be based on DNS lookups. Was reported to devs directly and told unable to reproduce. Reporting anyway.

Change History

06/06/08 01:51:43 changed by ryppn

Agreed, reproducible.

06/06/08 09:23:06 changed by p_lindheimer

  • priority changed from major to minor.
  • confirmation changed from Unreviewed to Confirmed.

drmessano, it's been about a week since I tested this and reviewed together with Jared Smith at Digium, there does appear to be a problem but not quite as you described. The issue appears to be the following IIRC:

  • Both systems have extension 102, each with a different sip sercret
  • Both systems have extension 700
  • System A's extension 102 dials System's B extension 700 (using a custom extension that dials SIP/700@System-B
  • The call properly dials System B
  • System-B 'sees' the caller as 102 on System-B and the request for caller 102 to authenticate fails when System-A can't properly authenticate (normally there would be no request to authenticate because it should be an anonymous call)
  • This results in the call failing, because System-B had a mistaken identity getting confused about extension 102

That's how I recall it anyhow, Jared was looking into it a bit more. It's not clear if it is a configuration issue that we can control, or an issue with Asterisk, or some combination.

I also may be mistaken, but think if extension 102 on both systems have the same secret, the call may be successful. This may be a cause for some of the intermittent testing behavior since in lab environments we tend to use the same secret, or the extension number as the secret resulting in the same behavior. I also seem to recall that changing the domain to be unique (from it being 'asterisk') may effect this, but I have not tested this recently.

I've tested this between Asterisk 1.2 and 1.4 systems and it seems to be consistent in both directions.

06/06/08 17:39:52 changed by drmessano

Considering that I am the one that reported it, and had the condition existing on my systems, I would think I would know what it is I was experiencing and what is was that I reported. The issue is just as I reported, and has nothing to do with the originating extension. If I dial SIP/102@box2 from box1, and 102 exists locally, 102 will be dialed on box1 and the call will not be passed out to box2. It's very simple, and I don't think requires continued reiteration.

06/06/08 18:08:51 changed by p_lindheimer

drmessano, it's a difficult bug as a few of us both on the Asterisk side and FreePBX side have spent a substantial amount of time looking at it, at the SIP traces, etc. (after we talked on the IRC the other day) I also just ran through a few more tests and realized that I was off a bit. The issue that I have setup to reproduce is similar but not quite what you described and I was mistaken in my description above. If 102 tries to call the remote 102 the call does fail in the scenario that we reproduced. But it does not go to the local system. The SIP invite is sent to the remote system and a response is returned indicating that authentication is required which there is no authentication available. However, extension 222 has no problem calling extension 102 on the remote system through the same custom extension...

The issue needs more digging into - if you are seeing the call not even attempting to go to the remote system in you example, it would be really useful to see those SIP traces since that is a scenario that we have not seen.

06/06/08 21:36:32 changed by drmessano

I haven't even tried using 102 to dial 102 on the remote system. My issue was with 104 dialing 102 on the remote system and the call being directed to the local 102. If 102 can't dial 102 on the remote system, then it sounds like there is a major issue here. This priority on this should be much higher than "minor" as well, since it sounds like there is a major bug in the internal routing here.

06/07/08 08:21:19 changed by p_lindheimer

  • description changed.

drmessano,

you are describing something different then I can reproduce. Can you please provide a trace with sip debugging turned on, of the attempted call so we can see what is happening. I have changed the priority because of the expected percentage of systems that are impacted by this issue as well as the ambiguity and what appears to be spottiness of reproducing the same things on different setups.

Also - in my scenario, it is not a routing issue, it is routing fine. It is the remote system getting confused and asking for authentication (thinking that the incoming call is from it's local version of the extension), although the authentication request still goes back to the originating system. This may be a configuration issue that we can find a way to address in FreePBX, or it may be Asterisk, or it may be both. That is why I'm talking to the Asterisk team about it as well.

Thanks in advance for the traces.

p.s. by any chance, do you happen to have a sip section (trunk or custom) that is named exactly 'someoneelsesdomain.com' on the system making the call.

06/12/08 09:11:24 changed by p_lindheimer

  • confirmation changed from Confirmed to Need Feedback.

drmessano, ping - any chance of getting the trace. It would be really helpful to see if there are two different issues going on here and without being able to reproduce your failure scenario it is not possible to hone in any more on that aspect. These may be two different issues that are related or not related but we lack the informational or repro ability to determine at this time.

07/31/08 08:15:21 changed by p_lindheimer

  • milestone changed from 2.5 to 3.0.

from further investigations and discussions with the Asterisk team, there appears to be one know and one potential solution to address this:

  • don't use the same device number
  • potentially the use of fromuser in conjunction with sendrpid/trustrpid

The first case is already possible when using deviceanduser mode. Having an option in FreePBX to automatically prepend what is hopefully a unique id in conjunction with the extension number for an extension would be a good thing to implement but won't happen in this release.
The second option needs someone to test in a lab environment and see if they can get it to work. If it were done in conjunction with global settings on the receiving end and a generated context for the custom extension on the sending end, then we could consider ways of autogenerating the context or making a simplified 'custom-sip' extension type that had the minimal parameters needed to set up that environment or do it in dialplan somehow by inserting SIP headers.

In either case, this is a grey area between a bug and feature request in FreePBX (closer to a feature request given the capabilities of Asterisk) so in the interim it is being moved out of the 2.5 milestone. We will track this and would really like someone to breasboard up an environment with the second option to determine if that provides a viable solution. (since there are many third part applications as well as applications like FOP and others that would break for the majority of users who expect the extension number = device number.

Donate



Support
Download
Develop
Forums
News
Documentation
Paid Support
About

Paid Ads