[quote=“david55”]The problem isn’t in the extensions.conf processing (“the PABX”) it is in the SIP channel processing. When you phone dials a number what it actually sends is number@asterisk.box.domain.example.com.
To allow raw SIP addresses to be sent from the phone, one would need to modify chan_sip.c so that it didn’t strip the domain name.[/quote]
Perhaps I fail to understand something here. Using AsteriskNOW 1.4 as is, I can invoke the Dial() function in extensions.conf with a URI as its argument. For example:
Because if ${EXTEN} is something like “98005551212”, then there’s no domain name to strip out. It doesn’t get changed by that code. If ${EXTEN} is something like “joe@somecompany.com”, then it is stripped to “joe”.
What we need to do is be able to configure it so when a user “dials” an address like “joe@somecompany.com”, it can do a regexp match to see that there is an address with an @ and then dial that and connect the channels.
I’m not an Asterisk hacker but it seems like it would be very easy to either a) add a configuration option to tell it not to chop the address or b) create another variable, like ${RAW_EXTEN} or something, that preserves the unmodified extension. There’s no harm in having a variable which preserves it, right? It’s similar to what happens in web server software: your app can access parsed request variables, and it can access raw header values if it needs to for some reason. Both are useful in different situations.
All those detractors who think this is a really bad idea are welcome to not use it, meanwhile I’ll set it up and use as a routine thing.
We are perfectly willing to accept alpha addresses for email, chat and even voice calls on Skype. If we can use alpha addresses for all those things, why not chat, voice and video calls through SIP? Why is it reasonable to want to make voice calls to an alpha address on Skype but not SIP?
This makes no sense. It’s no different from the problems that happens with Bob’s email address when he leaves. In fact routing these calls through Asterisk makes it really easy to solve. All the calls that went to bob@company can easily go to a voice response that says, “Bob no longer works here. For HR, call … etc”. With email addresses, we set up addresses like sales@, customerservice@, and so on. In fact you could be cool and make it play that message, and then connect through to Alex (Bob’s replacement). There’s no difference in how voice calls would be handled. As it is now, we have to use Skype for communications with our partners, so we already face whatever issue there is, with the added problem that Skype gives us no control over routing, and is otherwise not a good solution this. Using SIP addresses improves the situation over what we are currently doing (Skype).
If we’re willing to accept alpha addresses for voice calls in Skype and on chat systems, what’s so frightening about using them in SIP? I quoted part of the Asterisk manual that talks about the great new world of being able to use non-numeric identifiers for call routing. I agree with that! I’m ready to start!
[quote]Perhaps I fail to understand something here. Using AsteriskNOW 1.4 as is, I can invoke the Dial() function in extensions.conf with a URI as its argument. For example:
What you are failing to understand is that the problem is not in Asterisk originating calls to arbitrary SIP addresses, but in its accepting requests to do so from incoming callers.
The dialplan is matched against only the part of the requested address before the @.
One other factor to consider here is that Digium’s business model seems to be based on selling hardware to support PSTN accesss.
One other factor is that if dialplans can look at the full address, Asterisk starts functioning as not just a PBX but as a switch. Perhaps Digium is worried that at that point, Asterisk is communication equipment being used to provide telecommunications services and so CALEA (the wiretapping act) would then apply to Asterisk users. That would be bad because CALEA is a pain to comply with.
It does seem very artificial that somehow the dialed address isn’t available within the dialplan.
However, a converse point is that email protocols where designed to work point to point, but, with some notable exceptions, when the internet hit the mass market, almost everyone started using pull type split client mailbox protocols, for the final hop, rather than the natural email delivery protocol, SMTP. POP3 rapidly got abused to allow it to deliver to multiple user names.
Nowadays, if you are an individual user, it can be a pain to use direct SMTP to destination, even though broadband has eliminated some of the technical problems that initially encouraged the abuse of POP3. You are likely to find yourself black listed by the inbound mailserver of any of the big consumer ISPs.
I set up Ekiga to use Asterisk as both my registrar, and my proxy. If I don’t use * as my proxy, then of course when I dial george@widgetcorp.com, Ekiga will try to connect directly to the IP address of widgetcorp.com. Telling it “Asterisk is my proxy” makes it connect to Asterisk.
Indeed, the domain name is stripped out of the ${EXTEN} variable within the dialplan, but the domain is preserved carefully in the ${SIPDOMAIN} variable. So I can use both the ${EXTEN} and ${SIPDOMAIN} together to reconstruct the full SIP address. Haven’t looked into support for port numbers, and don’t care especially about that.
Now the next problem: specifying the pattern for dialing. It would be nice to just say, “If he dials an extension that looks like a SIP address, call it”, but unfortunately, the exten matching is very limited: it only looks at the ${EXTEN} variable and it has very limited matching capabilities.
I may play around with starting my context with a match-everything extension, have it look to see the user did enter a full SIP address, and then call based on that.
In any case, I think I’m making progress on being able to dial a SIP address through Asterisk, even if this is a use that (strangely) wasn’t envisioned by the * developers, and which many here seem to think is a bizarre thing to want (even as they use similar addresses for email, chat and Skype voice calls).