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

Douglas Garstang dgarstang at oneeighty.com
Fri Aug 4 07:32:05 MST 2006


> -----Original Message-----
> From: Matt Riddell (NZ) [mailto:matt.riddell at sineapps.com]
> Sent: Friday, August 04, 2006 8:28 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:
> 
> > 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.
> 
> It indicates that more people have an understanding and are coding for
> SIP because it is more widely used.
> 
> > 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.
> 
> If you want to solve it, put up a bounty, if others think its 
> a problem,
> they'll add to it.
> 
> Have you tested the patch which was supposed to implement it?

Are you referring to the patch that addresses passing variables in IAX? As my posts said, that's not the only issue. A far more serious issue is that at the other end of that trunk, when Asterisk makes calls to SIP phones, and those phones transfer or forward calls, all new calls generated from those are flagged as IAX calls instead of SIP calls. Data such as rdnis and dnid are lost, which is critical to programming the behaviour of transfers and forwards etc. It's as if the initial trunk overrides all calls generated at the other end. SIP trunks don't cause this behaviour to occur. This is a really serious limitation, when you can't forward or transfer calls at the other end of a trunk.


More information about the asterisk-dev mailing list