----- Original Message ----- From: Douglas Garstang [mailto:dgarstang@oneeighty.com] To: Asterisk Users Mailing List - Non-Commercial Discussion [mailto:asterisk-users@lists.digium.com] Sent: Wed, 02 Aug 2006 13:50:56 -0300 Subject: [asterisk-users] Limitations of IAX> I'm about ready to give up on IAX2. It seems to have some SERIOUS > limitations.You may have run into these limitations in your deployment but others are using IAX2 fine for what it was designed to do. No software out there can anticipate everyone's needs. Those who do run into issues end up working around the limitations or modifying it to their needs. You will probably need to do the same or seek an alternate solution.> Incoming PSTN call comes into to user A on pbx1. We look for user A locally, > and don't find them. We then do a DUNDi lookup, get a path, and dial user A > on pbx2 with IAX2. User A picks up the call. > > When IAX passes the call from pbx1 to pbx2, it does not pass some of the > dial plan variables. Namely dnid, which is set to 'unknown'. Consequently > (for reasons I don't yet understand) when user A on pbx2 tries to do a blind > transfer, the dnid is not set, and as a result, we _must_ fail the call > because we have no source number on our network.Have you reported a bug on this DNID not being passed?> Also, the account code is not picked up on pbx2 as well.As previously pointed out transporting the account code may be a security risk as well. If you really need it why don't you encode it into the dialed number or something?> :(Joshua Colp Digium
I'm about ready to give up on IAX2. It seems to have some SERIOUS limitations. Incoming PSTN call comes into to user A on pbx1. We look for user A locally, and don't find them. We then do a DUNDi lookup, get a path, and dial user A on pbx2 with IAX2. User A picks up the call. When IAX passes the call from pbx1 to pbx2, it does not pass some of the dial plan variables. Namely dnid, which is set to 'unknown'. Consequently (for reasons I don't yet understand) when user A on pbx2 tries to do a blind transfer, the dnid is not set, and as a result, we _must_ fail the call because we have no source number on our network. Also, the account code is not picked up on pbx2 as well. :(
> -----Original Message----- > From: Joshua Colp [mailto:jcolp@digium.com] > Sent: Wednesday, August 02, 2006 7:42 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Limitations of IAX > > > ----- Original Message ----- > From: Douglas Garstang > [mailto:dgarstang@oneeighty.com] > To: Asterisk Users Mailing List - > Non-Commercial Discussion [mailto:asterisk-users@lists.digium.com] > Sent: > Wed, 02 Aug 2006 13:50:56 -0300 > Subject: [asterisk-users] Limitations of > IAX > > > > I'm about ready to give up on IAX2. It seems to have some SERIOUS > > limitations. > > You may have run into these limitations in your deployment > but others are using IAX2 fine for what it was designed to > do. No software out there can anticipate everyone's needs. > Those who do run into issues end up working around the > limitations or modifying it to their needs. You will probably > need to do the same or seek an alternate solution.How many CLEC's are you aware of that are using Asterisk to provide not just enterprise features, but carrier grade features?> > > Incoming PSTN call comes into to user A on pbx1. We look > for user A locally, > > and don't find them. We then do a DUNDi lookup, get a path, > and dial user A > > on pbx2 with IAX2. User A picks up the call. > > > > When IAX passes the call from pbx1 to pbx2, it does not > pass some of the > > dial plan variables. Namely dnid, which is set to > 'unknown'. Consequently > > (for reasons I don't yet understand) when user A on pbx2 > tries to do a blind > > transfer, the dnid is not set, and as a result, we _must_ > fail the call > > because we have no source number on our network. > > Have you reported a bug on this DNID not being passed?No... last time I opened a bug I got told it wasn't a bug, the bug was closed, and I was given bad feedback.> > > Also, the account code is not picked up on pbx2 as well. > > As previously pointed out transporting the account code may > be a security risk as well. If you really need it why don't > you encode it into the dialed number or something?Yeah well, I know if the account code isn't passed, we can't bill the call. How is passing the account code in the dialled string any less insecure than passing it somewhere else in the IAX protocol?
> -----Original Message----- > From: Andrew Kohlsmith [mailto:akohlsmith-asterisk@benshaw.com] > Sent: Wednesday, August 02, 2006 11:54 AM > To: asterisk-users@lists.digium.com > Subject: Re: [asterisk-users] Limitations of IAX > > > On Wednesday 02 August 2006 09:42, Joshua Colp wrote: > > As previously pointed out transporting the account code may > be a security > > risk as well. If you really need it why don't you encode it > into the dialed > > number or something? > > Because that's a completely shitty workaround for something > that "may" be a > security risk. DISA "may" be a security risk too but it's > there in all its > glory; why not allow people to shoot themselves in the foot? > Why not have a > "restrictvars=yes" in iax.conf? If I create a patch to do > this against svn > trunk, would such a thing be accepted? > > Mr. Garstang is very grating at times but he has brought > forward a number of > shortcomings which if fixed would make the use of Asterisk far more > intuitive. And as I am certain you have seen on this very > list, some of the > workarounds people have done in order to make things work are > hideous, > hideous abominations.Thankyou, Mr Kolhsmith (I think...?) A large part of my frustration with Asterisk is that, without intentionally sounding conceited, we are pushing the evelope on what it can do. Most Asterisk users are implementing it in an enterprise environment. We are 'trying' to implement it in a carrier environment, ie providing a hosted IPT service to enterprises, which means that the features and functionality required make my head spin sometimes, and push Asterisk beyond what it was designed to do. Doug.