Summary:	ASTERISK-01070: chan_local cannot be used for making SIP SRV based calls.
Reporter:	ktsaou (ktsaou)	Labels:
Date Opened:	2004-02-21 08:15:38.000-0600	Date Closed:	2011-06-07 14:04:57
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	We have a variable (e.g. tocall=user@domain) and we want this to be dialed on behalf of the user we have on the channel and bridged to him. The user did not dial this. The call should be done with the rules defined at the users context (e.g. phones). The phones context has several rules based on SIPDOMAIN and decides how to route the call based on them. I have created this macro: [macro-recursive-call] ; ${ARG1} - The context to send the call ; ${ARG2} - SIP address to parse ; ${ARG3} - Dial timeout ; ${ARG4} - Dial flags exten => s,1,Cut(SIPDOMAIN=ARG2|@|2) exten => s,2,Cut(ext=ARG2|@|1) exten => s,3,Dial(Local/${ext}@${ARG1}/n,${ARG3},${ARG4}) exten => s,4,SetVar(MACRO_OFFSET=0) exten => s,104,SetVar(MACRO_OFFSET=100) However, it seems that SIPDOMAIN is unset in the target context (${ARG1} of the macro). Normally, the Local channel should accept a format like this: Local/context/extension/options Example: Dial(Local/phones/costa@tsaousis.gr/n,20,Tr) Extension should accept user@domain, in which case it should be translated to extension "user" with SIPDOMAIN="domain", pretty much the same * does when a user is calling user@domain.
Comments:	By: Olle Johansson (oej) 2004-02-21 16:37:56.000-0600 The local channel is a multiprotocol channel. You refer to extensions in contexts. I see your problem, but for me it is unclear what you propose. Could you be more specific in regards to what your proposal for a change is? Catch the SIPDOMAIN on inbound call, copy it to a global variable and it should stay there. SIPDOMAIN is local to the inbound call. When you create another call, it's cleared. Does or does not the local channel accept a @ construct in extension? By: ktsaou (ktsaou) 2004-02-21 17:38:06.000-0600 A simple example is this: You want to have a callback extension for your local phones. So, suppose that user@domain.com calls you, you get this and store in astdb as LASTCALLER/yourcallerid. Then, you want your local user to dial *** to callback the last caller. The *** extension does a DBGet and receives user@domain.com. Now you have to call this and suddenly you face the following problem: 1. If the value you got from the database is a local phone you should call it with Local/value@context. 2. If the value you got belongs to one of the SIP domains that are served localy, you have to strip the domain and forward it to the relative extension. 3. If the value you got is from an external, unknown domain (that came with SRV), you cannot do Local/... but SIP/... In all cases you have to respect the context of the local user, meaning that if this context has some special rules to treat certain calls differently (like least cost routing) you have to follow these rules. So the main idea, is to have Local/... behave EXACTLY like the local user agent. If it can call whatever the user agent can call with whatever rules exist at the local user's context, you can dial something on behalf of the user agent without worrying about anything. Just Dial Local/... using the same context the local user agent uses. By: ktsaou (ktsaou) 2004-02-21 18:29:46.000-0600 This feature is usefull in cases like: a. IVR based directories of calls (missed, recieved, phonebook, etc). c. quickly call-last-caller (like the one I described above) d. PBX based redial and generally in all places that the PBX has to dial something on behalf of a local user. My proposition is to make chan_local "dial the same way the user agent does". This is true today for local extensions, but for external SIP addresses you cannot use Local/... and there is no way to use a user's context for deciding how to route them. The only way to call them, is Dial(SIP/...) which will directly place the call indepedently of what the user's context says. By: Brian West (bkw918) 2004-02-21 20:27:41.000-0600 chan_local is a proxy channel driver that dials things in the local dialplan and isn't aware of things outside of that.  You MUST use chan_sip to make calls if you want SRV based calls. By: ktsaou (ktsaou) 2004-02-21 21:32:45.000-0600 It was not my intention to bombard you with bugs today. You have my apologies :) By not implementing this, I believe you are pushing dial plan information to components that should not be aware of it. SIP was just an example. Think of it as an AGI application, a phonebook for example, completely independent and unaware of the dial plan. It only has a destination address (number, sip address or whatever). How this application will know if the destination is served by this * or another, if the local user has the right to call it or not, or if it is an external address that is mapped to a local user and should be handled internally? It should forward the call to the LOCAL dial plan for it to make the decision. Afterall this is the reason the dial plan is there. Without this improvement of chan_local, all applications and scripts that need to place a call will have to be aware of the dial plan, which I believe increases their complexity and potentialy makes every such application a backdoor to the dial plan. I kindly request you to reconsider. By: Tilghman Lesher (tilghman) 2004-02-22 00:08:09.000-0600 So you're saying that chan_local should be aware of other channels, but chan_sip should not be aware of the dialplan? This sounds like a hack.  We need to find the "right way", or if there's a bug here, fix it, not kludge around it. By: Brian West (bkw918) 2004-02-22 00:10:20.000-0600 Accually what you are wanting is related to forwarding via SIP.  A patch does exist on the bug tracker to let you do what you want.  Chan Local wouldn't even be needed or used in that case.  Bug number 879 I think covers this... in any case anything sip related should be taken care of in chan_sip and NOT chan_local as they have diffrent functions.  Also try not to use Macros and see if it works.  Something may be quirky with app_macro and chan_local interaction.  At any rate chan_local is for local proxy calls ONLY and isn't aware of technology.   Also SIPDOMAIN isn't going to be set unless you are dealing with an in or outbound sip call.  If you are originating a call via chan_local its ONLY going to know about your local dialplan. edited on: 02-21-04 22:58 edited on: 02-21-04 23:04 By: Olle Johansson (oej) 2004-02-22 02:30:10.000-0600 Possible workaround: Save SIP addresses as sip:user@domain in the database and catch that when you dbget and dial SIP/user@domain directly. This way you can save any tech in the database (like iax:sdfsdf@server) and dial into the right channel. By: ktsaou (ktsaou) 2004-02-22 09:00:11.000-0600 Guys, I don't ask that chan_local should be aware of other technologies or the dialplan. I ask for it to be able to handle all destination addresses. Today, it cannot handle extensions of the form user@domain because the @ character seperates extension from context. A simple change in its parsing (or just another expression): Local/context/extension/options will allow it to PASS ALL THE INFORMATION to the dialplan. Then, it is a matter of writing the dialplan properly. Today, chan_local assumes that an extension cannot have the @ character and this is a wrong assumption and a bug. It is so simple I think. Anyway, if this cannot be done, a possible workaround for me now, is to get user@domain from the database, convert it to user%domain and call: Dial(Local/user%domain@context/n) And then have the dialplan split and rebuild the address to take the decision. This is a hack however. By: Tilghman Lesher (tilghman) 2004-02-22 10:03:18.000-0600 You misunderstand extensions.  An extension is SPECIFICALLY an extension in the dialplan and is NOT a technology extension.  An extension can NOT have an @ symbol in it. This is a misunderstanding on your part and not a bug. By: ktsaou (ktsaou) 2004-02-22 10:53:56.000-0600 I will only make one final note. An extension: exten => _18XXXXXXXX,1,... defines an extension for a REMOTE destination. This is valid, it is well documented and it actually allows us to have extensions for taking routing decisions about DESTINATIONS OUTSIDE THE PBX. If you think now SIP or IAX, the domain part of the address defines DESTINATIONS OUTSIDE THE PBX. For SIP you have chosen to do it with the variable SIPDOMAIN rather than: exten => _.@domain\.com,1,... This is an implementation detail which I accept. It seems strange however that the dialplan should be able to handle REMOTE DESTINATIONS and TAKE ROUTING DECISIONS for the switched world, but should not define such destinations and should not handle routing for other technologies. In all cases, I see the dialplan as a "routing tool" not as a local extensions definition mechanism, which is a subset of routing. Anyway, the hack I gave before works, so my problem is solved. It is on your hands now to decide if asterisk is a switched world PBX or a <place your technology here> PBX. By: Brian West (bkw918) 2004-02-22 11:10:39.000-0600 No the dial plan is not a routing tool in the sense of the word.  You link extensions or pattern matches to technology.  Asterisk is just that a PBX not a sip proxy or what not.  Its a PBX that can speak multi protocol.