[asterisk-dev] 'IAX2 call variable passing between servers '

[Douglas Garstang]

> -----Original Message-----
> From: Steven [mailto:critch at basesys.com]
> 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:akohlsmith-asterisk at benshaw.com]
> > > Sent: Tuesday, August 08, 2006 7:31 AM
> > > To: asterisk-dev at 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 remarks. At no time did I state I was unable to trunk calls from one Asterisk system to another with IAX2. I have however stated on several ocassions that the remote SIP end-point is not able to forward or transfer calls because information such as rdnis and dnid is lost. 

Poor choices? I am not aware of any public documentation that states that using IAX2 trunking will remove SIP features. Therefore, I fail to see how deciding to implement Asterisk trunking with the "INTER" "ASTERISK" "EXCHANGE" is a poor first choice.

> > 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. 

No. I was not privvy to the design documentation meetings. Therefore, I'd appreciate it if you could provide links to where that information is publically available.

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?