> -----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: [email protected] > > > 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? _______________________________________________ --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
