Re: [asterisk-dev] 'IAX2 call variable passing between servers '
On Friday 11 August 2006 12:27, Andrew Kohlsmith wrote:
Honestly what is wrong with
exten = foo,n,IAXVAR(CHANNELTYPE)
exten = foo,n,IAXVAR(DNID)
exten = foo,n,IAXVAR(RDNIS)
exten = foo,n,Dial(IAX2/box-b/${DESTINATION})
Just nitpicking, but this should be:
Set(IAXVAR(CHANNELTYPE)=SIP)
Set(IAXVAR(DNID)=${CALLERID(dnid)})
Set(IAXVAR(RDNIS)=${CALLERID(rdnis)})
and on box-b:
exten = bar,n,Set(ORIGCHANNELTYPE=${IAXVAR(CHANNELTYPE)})
exten = bar,n,Set(ORIGDNID=${IAXVAR(DNID)})
exten = bar,n,Set(ORIGRDNIS=${IAXVAR(RDNIS)})
exten = bar,n,AGI(must_be_DRMd_AGI.agi)
--
Tilghman
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [asterisk-dev] 'IAX2 call variable passing between servers '
-Original Message- From: Andrew Kohlsmith [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 12:39 PM To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] 'IAX2 call variable passing between servers ' On Friday 11 August 2006 13:55, Douglas Garstang wrote: Aren't dnid and rdnis set by/when phone-B sends 'Moved Temporarily' back to Asterisk? If so, I don't understand how setting those variables on Asterisk-A is going to help. I thought rdnis was plucked out of the 'Diverted' header by Asterisk. Depends on what you were looking at; On my PRI I get RDNIS from the switch, and IIRC I am not able to send RDNIS to redirect. I have never tried, though. In that case, are you using 'g' in your Box-B dialplan and moving on from there? It's my understanding that rdnis comes from the phone. When someone forwards their calls, the phone sends back the 'Moved Temporarily' message to Asterisk. Asterisk interprets the SIP message and passes rdnis, dnid and extension back to the dial plan when it re-enters it. It tries to dial the new extension. My original DIAL() command has 'g' in it... which I guess is what causes Asterisk to re-enter the dial plan as it does, and try to find a match for the new extension. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] 'IAX2 call variable passing between servers '
On Friday 11 August 2006 14:43, Tilghman Lesher wrote:
Just nitpicking, but this should be:
Set(IAXVAR(CHANNELTYPE)=SIP)
Set(IAXVAR(DNID)=${CALLERID(dnid)})
Set(IAXVAR(RDNIS)=${CALLERID(rdnis)})
Bah, total brainfart there. Thank you. :-)
-A.
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] 'IAX2 call variable passing between servers '
On Friday 11 August 2006 15:00, Douglas Garstang wrote:
It's my understanding that rdnis comes from the phone. When someone
forwards their calls, the phone sends back the 'Moved Temporarily' message
to Asterisk. Asterisk interprets the SIP message and passes rdnis, dnid and
extension back to the dial plan when it re-enters it. It tries to dial the
new extension. My original DIAL() command has 'g' in it... which I guess is
what causes Asterisk to re-enter the dial plan as it does, and try to find
a match for the new extension.
Asterisk doesn't re-enter the dialplan, it CONTINUES along the SAME
extension, at the next priority when option 'g' is used for Dial().
e.g.
[ooga]
exten = 500,1,Dial(SIP/500,,)
exten = 500,n,NoOp(After trying 500...)
exten = 501,1,Dial(SIP/501,,g)
exten = 501,n,NoOp(After trying 501...)
exten = 501,n,Goto(${RDNIS},1)
(this is all untested, I don't have a SIP phone handy.)
In this example, if 500 has a redirect, Asterisk will (should) send back a
CHANUNAVAIL to whoever tried to call 500. However, whomever called 501
(which has the same redirect) should get another kick at the cat with
whatever the RDNIS was set to.
I think.
-A.
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [asterisk-dev] 'IAX2 call variable passing between servers '
-Original Message-
From: Andrew Kohlsmith [mailto:[EMAIL PROTECTED]
Sent: Friday, August 11, 2006 2:10 PM
To: asterisk-dev@lists.digium.com
Subject: Re: [asterisk-dev] 'IAX2 call variable passing
between servers
'
On Friday 11 August 2006 15:00, Douglas Garstang wrote:
It's my understanding that rdnis comes from the phone. When someone
forwards their calls, the phone sends back the 'Moved
Temporarily' message
to Asterisk. Asterisk interprets the SIP message and passes
rdnis, dnid and
extension back to the dial plan when it re-enters it. It
tries to dial the
new extension. My original DIAL() command has 'g' in it...
which I guess is
what causes Asterisk to re-enter the dial plan as it does,
and try to find
a match for the new extension.
Asterisk doesn't re-enter the dialplan, it CONTINUES along the SAME
extension, at the next priority when option 'g' is used for Dial().
e.g.
[ooga]
exten = 500,1,Dial(SIP/500,,)
exten = 500,n,NoOp(After trying 500...)
exten = 501,1,Dial(SIP/501,,g)
exten = 501,n,NoOp(After trying 501...)
exten = 501,n,Goto(${RDNIS},1)
(this is all untested, I don't have a SIP phone handy.)
In this example, if 500 has a redirect, Asterisk will
(should) send back a
CHANUNAVAIL to whoever tried to call 500. However, whomever
called 501
(which has the same redirect) should get another kick at the
cat with
whatever the RDNIS was set to.
I don't know if I'd call it a continuation of the dial plan. The relevant
context here has _X. in it, so there's nowhere else to go after it executes
that. Therefore, it must be matching _X. again.
ooga looks good... of course the problem here is that if you trunked the call
from pbxA to pbxB via IAX, you don't get rdnis. :(
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [asterisk-dev] 'IAX2 call variable passing between servers '
On Tue, 2006-08-08 at 09:05 -0600, Douglas Garstang wrote: -Original Message- From: Andrew Kohlsmith [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 08, 2006 7:31 AM To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] 'IAX2 call variable passing between servers ' On Monday 07 August 2006 16:02, Douglas Garstang wrote: UA-A --- Asterisk-1 --- IAX2 --- Asterisk-2 --- UA-B The call from Asterisk-2 to UA-B has to be a SIP call, because UA-B only talks SIP. It doesn't know anything about IAX2. I ABSOLUTELY do care about the other side, because when Asterisk-2 calls my AGI script that dials UA-B, it sets agi_type to IAX2, not SIP. If that UA-B transfers or forwards a call, and sends a 'Moved Temporarily' SIP message back to Asterisk-2, Asterisk-2 re-enters the dial plan again with agi_type set to IAX2 again, not SIP. Because the type is IAX2, we've lost our rdnis value which is essential for forwarding calls, and we've lost dnid which is essential for transferring calls. From Asterisk-2's point of view, the call is both IAX2 and SIP; unless you're leaving something out (I did see your other message), the call is BOTH IAX2 *AND* SIP, and what technology the call is depends on how you look at it. This appears to be an issue outside of Asterisk because as Kevin said, Asterisk doesn't flag calls as being of one technology or another. Indeed it makes no sense to do that from Asterisk's point of view, as it can be bridging between two or even more channel technologies. I am guessing Asterisk is setting the call_type to IAX2 because the source of the call *is* IAX2, but that is only a guess. Still can't understand how a 'Moved Temporarily' SIP message from the phone, which causes Asterisk to re-enter the dialplan, can be an IAX2 call. Because you are having a problem accepting that the portion of the call you are dealing with at this moment is simply IAX2 - Asterisk 2 When the SIP call is moved you re-entered the dialplan with ONLY a IAX2 link to deal with. It really does appear that your own scripting needs to be smarter, perhaps even so much so that you need to specifically set some dialplan variables before the AGI is called, and maybe even include some smarts to prevent it from looping calls when you receive the temporary failure messages. I don't think it's an issue of the scripting. My script can only work with the variables it receives when Asterisk runs it. If vital info such as rdnis and dnid are not set, no amount of logic in the AGI is going to help. I don't know what you mean by 'looping calls'... phone sends a moved temporarily message back to Asterisk which causes it to re-enter the dialplan and try to dial the number moved to. (specified by the SIP 'Redirect' header I think). Well, first we need you to get smarter, then you can work on making the changes necessary to get your script to work right. Well, that seems to be the problem. IAX, from what I understood was supposed to be exactly designed for this kind of thing. As soon as I changed to SIP between the Asterisk boxes, these problems went away. I really do fail to see this as an IAX2 issue... Asterisk will have the same trouble routing a call using any two different technologies. You can't have Asterisk drop out of the loop if it has to bridge two different technologies... That's like saying you want to drive from New York to London, but you refuse to accept that the ocean liner you drive your car on to must be there for the trip across the ocean... or something. :-) So, in summary, what we are essentially saying here is that IAX2 cannot be used to trunk calls between Asterisk systems, when both end-points at SIP based devices unless you want to lose SIP functionality. That's really what we are saying here. We've since gotten this to work with SIP trunking between the Asterisk systems, and didn't have any of the problems associated when using IAX2. Seems that MANY people use IAX2 to trunk calls from one side to another. You are experiencing PEBKAC errors and suffering from poor choices. You chose to originally try to use multiple transports which walled off certain features. It just seems bizarre, because this was exactly the type of situation IAX2 was created for... I thought. Where you privvy to the design documentation or meetings? You once again prove your troll status by throwing out a comment that shows your wish to stir up trouble. -- Steven [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [asterisk-dev] 'IAX2 call variable passing between servers '
-Original Message- From: Steven [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 08, 2006 11:22 AM To: Asterisk Developers Mailing List Subject: RE: [asterisk-dev] 'IAX2 call variable passing between servers ' On Tue, 2006-08-08 at 09:05 -0600, Douglas Garstang wrote: -Original Message- From: Andrew Kohlsmith [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 08, 2006 7:31 AM To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] 'IAX2 call variable passing between servers ' On Monday 07 August 2006 16:02, Douglas Garstang wrote: UA-A --- Asterisk-1 --- IAX2 --- Asterisk-2 --- UA-B The call from Asterisk-2 to UA-B has to be a SIP call, because UA-B only talks SIP. It doesn't know anything about IAX2. I ABSOLUTELY do care about the other side, because when Asterisk-2 calls my AGI script that dials UA-B, it sets agi_type to IAX2, not SIP. If that UA-B transfers or forwards a call, and sends a 'Moved Temporarily' SIP message back to Asterisk-2, Asterisk-2 re-enters the dial plan again with agi_type set to IAX2 again, not SIP. Because the type is IAX2, we've lost our rdnis value which is essential for forwarding calls, and we've lost dnid which is essential for transferring calls. From Asterisk-2's point of view, the call is both IAX2 and SIP; unless you're leaving something out (I did see your other message), the call is BOTH IAX2 *AND* SIP, and what technology the call is depends on how you look at it. This appears to be an issue outside of Asterisk because as Kevin said, Asterisk doesn't flag calls as being of one technology or another. Indeed it makes no sense to do that from Asterisk's point of view, as it can be bridging between two or even more channel technologies. I am guessing Asterisk is setting the call_type to IAX2 because the source of the call *is* IAX2, but that is only a guess. Still can't understand how a 'Moved Temporarily' SIP message from the phone, which causes Asterisk to re-enter the dialplan, can be an IAX2 call. Because you are having a problem accepting that the portion of the call you are dealing with at this moment is simply IAX2 - Asterisk 2 When the SIP call is moved you re-entered the dialplan with ONLY a IAX2 link to deal with. It really does appear that your own scripting needs to be smarter, perhaps even so much so that you need to specifically set some dialplan variables before the AGI is called, and maybe even include some smarts to prevent it from looping calls when you receive the temporary failure messages. I don't think it's an issue of the scripting. My script can only work with the variables it receives when Asterisk runs it. If vital info such as rdnis and dnid are not set, no amount of logic in the AGI is going to help. I don't know what you mean by 'looping calls'... phone sends a moved temporarily message back to Asterisk which causes it to re-enter the dialplan and try to dial the number moved to. (specified by the SIP 'Redirect' header I think). Well, first we need you to get smarter, then you can work on making the changes necessary to get your script to work right. Well, that seems to be the problem. IAX, from what I understood was supposed to be exactly designed for this kind of thing. As soon as I changed to SIP between the Asterisk boxes, these problems went away. I really do fail to see this as an IAX2 issue... Asterisk will have the same trouble routing a call using any two different technologies. You can't have Asterisk drop out of the loop if it has to bridge two different technologies... That's like saying you want to drive from New York to London, but you refuse to accept that the ocean liner you drive your car on to must be there for the trip across the ocean... or something. :-) So, in summary, what we are essentially saying here is that IAX2 cannot be used to trunk calls between Asterisk systems, when both end-points at SIP based devices unless you want to lose SIP functionality. That's really what we are saying here. We've since gotten this to work with SIP trunking between the Asterisk systems, and didn't have any of the problems associated when using IAX2. Seems that MANY people use IAX2 to trunk calls from one side to another. You are experiencing PEBKAC errors and suffering from poor choices. You chose to originally try to use multiple transports which walled off certain features. You obviously have not invested the time required in understanding the problem I am trying to solve, eventhough I did post a diagram of it a few days ago. I now see that you, after not having provided any evidence of actually having read it, decide to resort to derogatory
RE: [asterisk-dev] 'IAX2 call variable passing between servers '
On Tue, 2006-08-08 at 10:12 -0600, Douglas Garstang wrote: Why is it that whenever I ask tough questions, or point out the obvious, some people, rather than being constructive, choose to resort to name calling? Is that the best you can do? You did not ask a tough question. You point out your assumption. You fail to take the advice given to you. You assume it is other peoples fault. Does that make your sore feelings feel better? Until you correct the above problems, it is unlikely you will see much benefit here. And it can be said again. Since code has not been presented or discussed, this should go back to the -user list. -- Steven Critchfield [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [asterisk-dev] 'IAX2 call variable passing between servers '
-Original Message- From: Matt Riddell (NZ) [mailto:[EMAIL PROTECTED] Sent: Friday, August 04, 2006 12:41 AM To: Asterisk Developers Mailing List Subject: Re: [asterisk-dev] 'IAX2 call variable passing between servers ' -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Douglas Garstang wrote: As someone who I was explaining this to pointed out to me, IAX = Inter Asterisk Exchange. This is exactly the kind of thing that IAX was designed for, and SIP seems to handle it better. Maybe someone needs to re-evaulate the relevancy of IAX2. If you spent half as much time reading up on coding as you do typing your complaints, you could have easily solved the situation by now. You have 2 choices: 1) Do the work yourself 2) Pay for someone to do it for you No Matt. It's comical. This is exactly the type of situation that IAX2 was designed for, and it doesn't do it very well. The very fact that I have to make modifications to the code to get IAX2 to work, but not SIP (yet), indicates IAX2 is falling far short of it's expectations. I don't see how this is complaining. I am trying to solve a problem, and given the lack of documentation out there, this is one of the few places to turn. I can't understand why it is that whenever I ask questions that are due to limitations in Asterisk, it's called complaining. Doug. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] 'IAX2 call variable passing between servers '
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Cotton wrote: You have 2 choices: 1) Do the work yourself 2) Pay for someone to do it for you - -- Cheers, Matt Riddell No Matt you've got it wrong Decartes didn't say Je pense donc je suis he said Je râle donc je suis. :) - -- Cheers, Matt Riddell ___ http://www.sineapps.com/news.php (Daily Asterisk News - html) http://freevoip.gedameurope.com (Free Asterisk Voip Community) http://www.sineapps.com/rssfeed.php (Daily Asterisk News - rss) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0zFlS6d5vy0jeVcRAmA2AJ4+NnMeEDJRUuMgWRMph0wI5yOs9ACfUnoP ka91fvMpkU2JNNmlzVjpQdM= =DUTl -END PGP SIGNATURE- ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] IAX2 call variable passing between servers
Hi John,
I am very interested in the idea of passing extra data with IAX2 as I see
that is one of the most major areas that it is lacking.
My particular interest is in passing call related information at two times,
a) call establishment and b) call end.
The first fits in with what you have proposed here, and I agree that you
don't want to be sending or receiving all of the tasks 'environment'
variables. I also agree in principle with the thoughts behind the
inbound.variable, outbound.variable system, although I would tend to suggest
not directly linking the variables in the same 'name' space, instead you
might have:
SetCallVar(Q931BEARER=039090)
SetCallVar(Q931NOA=INTERNATIONAL)
and
ReadCallVar(Q931BEARER,BEARER)
ClearCallVar(Q931NOA)
blah blah ${BEARER}
Any variables that are set and contained in the 'callvar' name space will be
automatically passed on any outbound Dial call unless specifically cleared -
or maybe blocked with a Dial option.
These variables may be set by the application *but could also be set* by the
channel code itself, for example chan_zap.c/q931.c might set Q931BEARER, and
more importantly might *read* it and set it in the Q931 call setup packet.
With this mechanism in IAX2 and appropriate support in Zap/pri/q931 IAX2
then becomes a very real transport for telco applications where we need to
transit call flags.
Secondly, an additional variable that I would like to see passed would be
sent and read *in reverse* when a call clears. At the moment, a very real
restriction on IAX2 is that calls either connect and then clear or fail to
connect and clear. There is no way to tell *why* the call cleared. I'd like
to be able to pass, whether as a variable or otherwise a 'CLEARCAUSE'
variable whoes values could reflect a far wider range of values ( at the
very least Busy, Congested, Number Unobtainable, Call Failed, Call Rejected,
Out Of Order, Incompatible Equipment)
What do you think?
Linus
Magrathea
- Original Message -
From: John Todd [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 3:42 PM
Subject: [Asterisk-Dev] IAX2 call variable passing between servers
Here's an idea for you all to shoot down. I'll await the nonexistant
comments before I open a feature request.
We have the luxury of moving calls around with IAX2, where we (the
Asterisk community) have control of the protocol. Various hacks are
being installed into SIP headers to move data around, as I'm
experiencing with some of the installations I've now seen. With
IAX2, it seems apparent that we should be able to move variables
around semi-transparently, since IAX2 integrates with Asterisk
completely.
Sending all variables might be difficult/insecure/silly, as we don't
want to clutter the call setup with a slew of variables, some of
which may be inherently secure and should not leave the server on
which they were generated. Perhaps some naming convention could be
used to differentiate variables that would be passed to the remote
end as special case variables.
There are two possible methods that could be used to determine if
certain variables might get passed. The first method is the
simplest, which is to simply search all the named variables and see
if any of them begin with resend. and then transmit those
automatically. Alternately (and perhaps, in addition to this method)
one could add yet another modifier to the Dial command, such as v
which stands for send [v]ariables.
I propose a format like this for outbound: outbound.VARNAME
I propose a format like this for inbound: inbound.VARNAME
I think that it would be wise to sandbox the variables with a
distinguishing feature (name prefix) so that we do not inadvertently
move variables out of or into local/remote dialplan executions. The
extra two steps is a small enough effort. (really, one step at each
end is needed to be clean, but we could skip the re-translation at
the far end and just use ${inbound.VARNAME} if we were lazy.)
As an example:
exten = 123,1,SetVar(GREETING=hello there)
exten = 123,2,SetVar(NAME=John Doe)
exten = 123,3,SetVar(outbound.GREETING=${GREETING})
exten = 123,4,SetVar(outbound.NUMBER=${EXTEN})
exten = 123,5,Dial(IAX2/[EMAIL PROTECTED]/${EXTEN},,v)
Upon receiving the call, the other host (hub1) would then have to
translate back like this:
[from-remote1]
exten = _X.,1,SetVar(OURGREETING=${inbound.GREETING})
exten = _X.,2,SetVar(DIALEDNUMBER=${inbound.NUMBER})
exten = _X.,3,blah blah blah
SIP:
As far as having this work across channels other than IAX2: SIP can
handle almost any number of additional headers. It could be possible
to incorporate a custom header if there are any variables that fall
into the 'resend.' group. Of course, fully escaped syntax would need
to be followed. As an example, a custom header could be
generated/parsed:
Asterisk-Variables: FOO=hello there;NUMBER=123
PRI:
There are special areas in the PRI outbound call which
