Same provider – IAX sounds bad, SIP sounds great

Home » Asterisk Users » Same provider – IAX sounds bad, SIP sounds great
Asterisk Users 46 Comments

On my Asterisk system, I’m using a provider that provides both IAX2 and SIP connectivity.

Personally, I’d prefer to use IAX2, and that’s what my account is setup to use. However, I’m having bad IAX audio quality:

With IAX2:
– Incoming Voice from my Provider -> Asterisk = Sounds great
– Outgoing Voice from Asterisk -> my Provider = Sounds terrible

By “terrible,” I mean skips, stutters, and distortion. It can be difficult (sometimes impossible) to understand. This situation is present regardless the codec I use (at least between G.729, GSM, or ulaw).

On the other hand:

With SIP:

– Incoming Voice from my Provider -> Asterisk = Sounds great
– Outgoing Voice from Asterisk -> my Provider = Sounds great

The obvious conclusion is to simply use SIP; however as I’ve said, I’d prefer to use IAX2 – plus, I’m curious why SIP sounds great, while IAX2 only sounds good one-way (ie. incoming to my asterisk system).

The server for my provider is identical in either case. So I figure it’s one of a few things:

– misconfiguration
– My ISP (Comcast) is throttling or giving a low priority to IAX, but not SIP
– If there’s something I can do here, I’d like to know, but I doubt it.
– a problem with my provider
– In which I’ll contact them.

For the first case – misconfiguration, I’d appreciate some input. My iax.conf is fairly straightforward:

[general]
bandwidth=low
jitterbuffer=yes
forcejitterbuffer=no
encryption = yes
autokill=yes
maxcallnumbers=12
maxcallnumbers_nonvalidated=4

[guest]
type=user
context=default
callerid=”Guest IAX User”

[myprovider]
type=friend
username=
secret=
context=somecontext
host=provider_server
qualify=1000
disallow=all
allow=g729
allow=ulaw
auth=md5,rsa
requirecalltoken=yes
trunk=yes

Firewall:
Asterisk is behind a connection-tracking firewall; in my case, I’ve noticed that my own connection to my provider has always been sufficient to allow connection tracking to “just work” – and incoming calls are accepted without problems, and voice travels in both directions (albeit not so well when outgoing).

I have configured my firewall to forward incoming connections on port 4569 to my Asterisk box, and tested. This had no effect on call quality (which is no surprise given it’s the /outgoing/ voice that’s problematic).

Outgoing connections are fairly typical for a NAT setup – anything can go out.

Any other ideas before I give up on using IAX?

46 thoughts on - Same provider – IAX sounds bad, SIP sounds great

  • I’d try turning off the jitterbuffer and see if that makes things better. I just traced a similar call quality issue transferring calls incoming DAHDI on one * box to another * box, and turning off the jitterbuffer on the side that “couldn’t hear” (in my case, the * box with the DAHDI lines, as the DAHDI callers couldn’t hear the remote callers) fixed the call quality issue.

  • My first two guesses are that encryption is hosing you or that the
    “single-channel” nature of IAX2 may have something to do with it. IAX2
    “talks” on 1 channel, SIP uses “twisted pair” connotation on two channels
    (as I understand it).

  • A serious bug with IAX2 trunking in recent versions of Asterisk (you did
    not mention what version you are using) was just resolved last week. You
    should test with ‘trunk=no’ to see if that is the cause of your problem;
    it seems very likely.

  • I’ve tried turning jitterbuffer off – doesn’t make a difference. (And
    why should it? The Jitterbuffer only applies to incoming calls, doesn’t
    it?)

    On 2012-02-28 21:12:48 +0000, Noah Engelberth said:

  • encryption=yes is meaningless if the provider doesn’t support it (mine
    doesn’t). I put it there in the wild hope they eventually will – and no
    config change will be needed on my part.

    Still, when I changed it to encryption=no, and tested there wasn’t any
    difference.

    So I’ve tried disabling the jitterbuffer, and encryption, and there’s
    no effect on call quality – outgoing (from me -> provider) sounds
    bad/distorted, while incoming sounds great.

    On 2012-02-28 21:14:55 +0000, Danny Nicholas said:

  • Google or click this link http://bit.ly/ywiwzteve ” Steve Totaro IAX” and
    then stop wasting your time, go with SIP even if you need to create VPN
    tunnel(s).

    Forget IAX2 and save yourself time you will never get back.

    IAX2 has put tens of thousands of dollars in my pockets from the DoD, DoS,
    prime contractors to ITSPs around the world.

    Thanks for IAX2 Digium!

    Thanks,
    Steve Totaro

  • Ok Steve, obviously you’ve outsmarted at least this poster. On the one
    hand, IAX2 has purchased things for you (won’t go as far as saying it bought
    your Mercedes), but on the other hand it is being dropped by providers as we
    speak. So are you saying it can be a good thing if you have the time and
    skill level to pursue it, but beginners should leave it alone?

    [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Steve Totaro
    Sent: Tuesday, February 28, 2012 3:59 PM
    great

    OOOOPSS

    http://bit.ly/ywiwzt

    On Tue, Feb 28, 2012 at 4:56 PM, Steve Totaro
    wrote:

    Google or click this link http://bit.ly/ywiwzteve ” Steve Totaro IAX” and
    then stop wasting your time, go with SIP even if you need to create VPN
    tunnel(s).

    Forget IAX2 and save yourself time you will never get back.

    IAX2 has put tens of thousands of dollars in my pockets from the DoD, DoS,
    prime contractors to ITSPs around the world.

    Thanks for IAX2 Digium!

    Thanks,

    Steve Totaro

    On Tue, Feb 28, 2012 at 4:30 PM, Troy Telford
    wrote:

    I’ve tried turning jitterbuffer off – doesn’t make a difference. (And why
    should it? The Jitterbuffer only applies to incoming calls, doesn’t it?)

    On 2012-02-28 21:12:48 +0000, Noah Engelberth said:

    I’d try turning off the jitterbuffer and see if that makes things better. I
    just traced a similar call quality issue transferring calls incoming DAHDI
    on one * box to another * box, and turning off the jitterbuffer on the side
    that “couldn’t hear” (in my case, the * box with the DAHDI lines, as the
    DAHDI callers couldn’t hear the remote callers) fixed the call quality
    issue.

  • On 2012-02-28 22:17:37 +0000, Danny Nicholas said:

    I understood Steve to mean the following:
    allow through a firewall, which is pretty compelling.

    At least, that’s my take.

  • People around here either hate me or love me. I post experience and am
    accused of bragging or whatever. As a reader, I want to know who is giving
    me advice and what it is based on.

    $40k/wk of long distance through VoicePulse. I have the invoices, that is
    high usage, others attack me for posting information like this, I think I
    know why but I don’t care.

    You have to have thick skin on these lists, the more technical, the more
    you better have done your homework or get flamed.

    It is from years of experience, not outsmarting anyone. It took me months
    to figure out that it just doesn’t work well and as you can see, all of the
    posts are very dated. Nobody outsmarted anyone, just pure experience and
    experience of MANY other people that use Asterisk. Many did not wish to
    make waves and emailed me directly that they either came to the same
    conclusion or that they switched due to my suggesting and had no more
    problems.

    Digium and Digium FanBoys will argue that IAX2 is the best thing since
    sliced bread.

    Digium will ALWAYS tow the party line. It was either Flemming or Lesher
    that actually posted that it was in an official release so it couldn’t have
    bugs. That was the end of listening to Digium about IAX2. That statement
    was archived with my reply of how ridiculous the statement was. It is all
    on the mailing list.

    The compensation thing is very true, people drink the cool-aide about IAX2
    and it sounds great. Then it turns out that they go to production, and
    audio sucks, customers are complaining. It becomes a huge problem
    obviously to an ITSP or any call center.

    As I said, my experience is dated, but I have been one of the most prolific
    people in the Asterisk community, I spoke at Astricon in 2007 on Large Call
    Center Track and was the #1 poster for the year, a year or two ago. I
    predate most of Digium Staff.

    I do this stuff in the real world, over VSAT or whatever connectivity you
    can think of, my experience is real, not a developer in the world of code.

    To answer your question, maybe you can spend time and get it to work
    correctly, I have no idea, but why?

    Why not just use SIP and be done with it.

    Also realize that the dated posts have replies that are ridiculous like
    VoicePulse is probably laying people off right now as we speak.

    If a challenge drives you and you have tons of time to possibly never
    figure it out and go to SIP, then by all means, do it.

    If you want it to just work, use OpenVPN to get your single port, don’t
    believe the Digium party line and replies about using OpenSER or whatever
    it is called now. I get past the firewall and NAT issues with OpenVPN.

    My standard now is Vyatta with NTOP, Asterisk, Webmin installed. I only
    use SIP and use OpenVPN.

    I build Asterisk from source and menuconfig, I remove all that is not
    needed, including IAX2. I do download all the sound files in different
    languages and codecs.

    It just works. I like things that just work.

    Thanks,
    Steve Totaro

  • I have no interest in the penis-measurement competition firing up
    here, but I’ll say that we have 100% abandoned IAX from all of our
    systems due to a myriad of issues. These days it offers no real
    advantages in our opinion.

    On Tue, Feb 28, 2012 at 4:03 PM, Steve Totaro
    wrote:

  • Roger That, I am an IC. I contract with the Government to little ten phone
    shops. From VA/MD/DC area, I have been contracted and flown in to many
    large call center locations that were CONUS and OCONUS.

    My facebook is Steve Totaro in Reston VA. LinkedIN is more accurate, but
    my resume speaks the truth.

    Thanks,
    Steve Totaro

  • On 2012-02-28 21:22:44 +0000, Kevin P. Fleming said:

    For the record: 1.8.8.2~dfsg-1 (via Debian packages).

    I’ve tried “trunk=no”, and it might have made a difference (I’ll have a
    better idea after some more testing.)

  • They said the same thing in 2005, 2008, now…. Every release.

    You never answered the question as to why you don’t want to use SIP. Is
    there a reason, or do you just want to torture yourself?

    Thanks,
    Steve T

  • BTW, Trunking was the other selling point of IAX2 besides using 1 port
    which is easily a DDOS target and also probably still
    an implantation problem of using one thread and one proc for all calls.

    Trunking allowed for less overhead then SIP since all the overhead for the
    concurrent calls were combined into one stream.

    Without trunking, you only have the single port thing. It is quite easy to
    open the correct ports for SIP, some just have GUI with a SIP checkbox,
    IPTables is simple and there are tons of howtos.

    Thanks,
    Steve T

    On Tue, Feb 28, 2012 at 6:29 PM, Steve Totaro
    wrote:

  • Wow Wikipedia was the only place that had the original meaning and not the
    slur or slang meaning.

    ” A *ghetto* is a section of a city predominantly occupied by a group who
    live there, especially because of social, economic, or legal issues. The
    term was originally used in Venice http://en.wikipedia.org/wiki/Venice to
    describe the area where Jews http://en.wikipedia.org/wiki/Jews were
    compelled to live.”

    On Tue, Feb 28, 2012 at 6:55 PM, Steve Totaro
    wrote:

  • On Tue, Feb 28, 2012 at 6:36 PM, Steve Totaro
    wrote:

    […]

    Nope. The main reason _we_ use IAX is because it’s easier for NAT

    It may be true for you but it’s certainly not “the truth”.

    – SIP requires redirection of ports if behind a NAT which is about 99%
    of home users, whether behind a WiFi router or an ISP private network.

    – SIP requires far more set-up and support effort and it’s not a valid
    choice for a simple to use home-phone. (a) ISP routers change IPs
    frequently, (b) the router may change the ATA’s private IP rendering
    the port redirection broken.

    – A public SIP (w/o a VPN) requires careful control (e.g.
    contactpermit in Asterisk) to limit the IPs that can connect to the
    public box. Else you will get serous harm from things like SIPVicious
    attacks. ISP change their IPs frequently so maintaining your user/ip
    list is almost impossible. IAX2 was very vulnerable as well up to 2009
    but many things in this regard have changed and are much better.
    Granted, these security issues are common for both SIP and IAX2 but
    IMHO it’s easier to manage with IAX.

    – In a NAT scenario SIP requires a couple of redirected ports per
    extension, which is a no-go for SMB installations requiring several
    ATAs without going to the extent of installing a more powerful
    equipment than a simple ATA.

    – You may use OpenVPN with SIP as you said but requires a PC which is
    not an option for a simple VoIP business that delivers something like
    Vonage, just plug it and it works. AFAIK there is no port redirection
    or any special configuration to use Vonage and it works almost on any
    network set-up (I don’t use Vonage but know people that do). So if
    something like Vonage is using SIP it’s probably using a VPN software
    like you recommend.

    Anyway, the point is that SIP and IAX2 have both pros and cons and I
    don’t consider IAX2 to be a broken bat like you state. On the
    contrary, I think it works pretty well, and we use both SIP and IAX2
    targeted to simple Home, SOHO and SMBs that just want to plug it and
    work. We get that with IAX2 and not with SIP so from our experience is
    completely the opposite of what you say.

  • On 2012-02-28 23:29:53 +0000, Steve Totaro said:

    Probably self-torture, yes. I want to at least try to use IAX2 because
    I can – learn more about Asterisk for the experience, etc. Now that
    I’ve found problems, I want to know if it’s a problem with my
    configuration, or if it was my ISP, or perhaps my provider.

    I have no problem at all with SIP. It seems to be the direction
    everybody is going – including Digium:

    From the Asterisk 10 “Codecs and Audio Formats” page:

    “Note that the additional codecs discussed here are available for use
    in Asterisk’s SIP channel driver, only. Asterisk 10 does not make them
    available for IAX2, MGCP, SSCP, H.323, UniSTIM, etc.”

    Digium’s fax driver doesn’t work with IAX2… even in ulaw passthrough mode.

    So if I can find that yes, it’s so much a problem with my configuration
    but a bug in the software, then I’ll be satisfied & switch to what
    works (ie. SIP).

  • Perhaps your users live in an internet ghetto where the routers are
    similar to Yugos with spinners. We haven’t run into any routers that
    don’t do NAT properly in a very very long time.

  • Please expand as to how you set-up a SIP ATA behind a common home
    router set-up, without port redirection and/or use of a SIP proxy
    and/or STUN server? Unless the ATA has some sort of magic (e.g. VPN
    support) it _cannot_ be done.

    […]

    Top posting seems to be more popular due to use broken smart phone
    MUAs that can’t reply in-line. But if you have the means it should be
    avoided for future reference and direct people to read the archives
    and find useful information.

    You should care. Words like “ghetto”, “your users”, and using name
    brands like Yugo in a pejorative way are all derogatory and may direct
    the discussions on a personal level which should always be avoided. I
    don’t drive a Yugo but if I did I could easily be offended by the
    pejorative use of the brand.

    We are all here to share our knowledge and our valuable time so to
    make it worthwhile we should all care about conserving netiquette.

  • Go buy a WRT-54G or nearly any consumer-class router and just plug in
    a SIP device. Done. It works. We *never* work on customer routers
    and very rarely have to tell them to reconfigure their router at all.
    My own home configuration is an Airport Extreme with zero
    configuration. So either these are very old routers you’re having a
    problem with, or buggy SIP devices, or something else.

    Hmm, let me check the reading…

    http://i1-win.softpedia-static.com/screenshots/Care-Meter_1.png

    It’s a piece of junk and everyone knows it, including the owners, so who cares?

  • And it is easier for NAT because it uses one port as I stated, next….

    Um, not when the server is on a public IP and the phones are configured
    correctly.

    What about Magic Jack or Vonage? The phone registers regularly with the
    server so that negates everything above.

    I don’t do simple home setups, but they are simple home setups, your words,
    not mine. I have only had to redirect ports if the server is behind a NAT.
    Get a SNOM 370, flash with OpenVPN, run as a client and no problems, not
    that there would be anyway. I have placed 20 business phones behind NAT
    with no special configuration and no issues but a bad phone or two in two
    years….

    I have hostage negotiators with OpenVPN and a softphone on their laptops,
    they travel the world and never have problems except maybe bandwidth.

    This can easily be mitigated by running on nonstandard ports. Fail2Ban,
    and a ton of other products can help, but yes, you are correct. A
    competent Admin is required to check logs daily and configure things
    correctly.

    I use IP=dynamic with no problems but people tying to guess a password that
    is the extension and MAC of the phone. Dictionary attack is nothing. With
    a Gig pipe and fail2ban, no problems.

    Also, I don’t know where you live but I got Comcast@home when it first came
    out and my IP has never changed. ISPs in this area say dynamic but they
    are static, at least the big two, Verizon and Comcast for home use.

    Security was never really the issue if you read the thread. It is about
    voice quality.

    Not in my experience, phone registers with server on public IP, no problems
    except some obscure setting on a firewall. Easy enough to google away.

    Wrong, the SNOM 370 works great with OpenVPN. You just contradicted
    yourself as far as plug and play.

    The SNOM 370 can also act as a bridge over the VPN tunnel using the LAN
    port so the whole office is behind either split tunnel or direct VPN.

    Any other SIP phone behind the SNOM with VPN bridging will also be on the
    VPN as well as workstations.

    Magic Jack is pure SIP, no VPN

    That is fine, I added disclaimers and small shops. I deal in the 15,000
    calls a day minimum realm, so we live in different worlds. Two cups and
    and a string work too….

  • Yes, I have had no problems with Grandstream first gen ATAs, configured
    with server and credentials and shipped off, they just work.

    I follow the direction of the conversation. If people are top posting,
    then I follow suit, bottom, then I bottom post, inline as we are, then that
    is what I do. When in Rome….

  • Just to stir the pot a bit, I am a member of a worldwide private network
    of Asterisk and AstLinux users. the network uses IAX exclusively, and we
    have no issues relating to audio quality with a large variety of
    providers, routers, host machines, and expertise in configuration of the
    specific nodes
    Many ( in the US and Canada ) use a PSTN connection as well as the
    private network using voip.ms with equally stellar quality using IAX

    IAX was chosen as the default network protocol because of the many
    issues with SIP, routers, and ( later ) the many attempts at break-ins.

    As an aside, didn’t the manufacture of the Yugo die with the death of
    Yugoslavia? Most of the Yugo’s shortly thereafter? If anyone has one
    now it may be close to the value of a Delorian

    No replies necessary or even desired.

    John Novack

    Carlos Alvarez wrote:

  • What you are saying seems impossible and makes no sense unless the
    router is assigning a public IP or is “SIP aware” and knows how to
    read the routing data contained inside the SIP packets, and none of
    the consumer routers are SIP aware AFAIK, especially not the WRT-54G.

    The other option is that the SIP ATA has WAN and LAN ports and the SIP
    device is being assigned a public IP.

    SIP does not NAT by itself because it can’t, because there is no
    routing info, it’s simply impossible.

  • You can:

    a. Continue to tell us that what we are doing every day is “impossible.”

    or…

    b. Go set up a test in your lab with an Asterisk server, a cheap
    router, and a SIP client and see.

  • On Tue, Feb 28, 2012 at 8:58 PM, Steve Totaro
    wrote:

    […]

    We use the HT-286, the server is on a public IP the nat setting on
    asterisk is set to yes and without port re-direction the ATAs have
    never connected from a private network, so I honestly find this “SIP
    plug and play” very hard to believe. But if it is true, then maybe you
    can actually help us figure out all the NAT issues we’ve had with SIP
    for the past 5 years. Perhaps, it is simply ignorance on our side and
    we have something fundamentally wrong in our set-up somewhere that may
    be have been causing these issues with NAT.

    Our set-up is fundamentally public and private Asterisk servers
    running on FreeBSD. Versions may vary from FBSD 7 thru 8.2 and
    Asterisk 1.4 and 1.6. We are planning to upgrade every server to FBSD
    8.2 and Asterisk 1.8 but we are in that process right now. Some
    Asterisk run in jails so I can understand the NAT issues there may be
    caused by the server itself. I honestly *love* your OpenVPN idea but I
    have to find a cheap ATA that could run as an OpenVPN client.

    Taking the simplest example a simple Asterisk 1.6 server on a public
    IP running on the base system (not in a jail):

    We run an operation that spans several countries including Canada, the
    US and the Latin American Andean region. As examples, with Canadian
    ISPs such as Rogers and Bell we have always had to redirect the ports
    and use STUN server for the HT-286 to register to the Asterisk server.

    In the US we have the same problem with Comcast networks, so I don’t
    understand how you say that you plug a Grandtream SIP ATA to a Comcast
    router and it just works. However, in a couple of NOLA countries the
    ISP’s routers actually give public IPs, so if the SIP ATAs are
    connected directly to the ISP router, or in the DMZ then it just works
    as you say, BUT if the ATA is connected behind the firewall, or to a
    WiFi router, then we’ve _allways_ had to redirect ports. In every
    sigle customer we have had to send instructions on how to redirect
    ports, and of course to configure firewall if present.

    I just don’t understand how you and other here say that a SIP ATA can
    “just work”. On the contrarty, with IAX2 using cheap AG-188N from
    Atcom they are just plug and play when shipped with a standard conf,
    and we have none of the quality issues you are referring to. We do
    have some call drops however, and some hangup problems but they don’t
    affect our clients as much as having to deal with NAT issues.

    We may not run 15K extensions like you but I think we have a pretty
    good testing ground and have dealt with a fair share of NAT problems
    with SIP, that you and others here apparently don’t have, so I am as
    amazed by your likeness of SIP as perhaps you are amazed as our
    likeness of IAX.

  • The number of ‘plain’ SIP endpoints deployed behind consumer-grade NAT
    devices talking to Asterisk servers on public IP addresses is in the
    millions, if not the tens of millions. As has already been posted,
    Asterisk itself handles all the far-end NAT traversal duties necessary
    for this to work; neither the remote endpoint nor the NAT device need to
    do anything special, nor do they require any configuration.

    Rather than post a lengthy exposition on how widespread your network is
    and how technically astute your people are, you would probably
    accomplish much more to setup a simple test scenario as has been
    previously suggested, and if it does not work for you, post the details
    of the scenario and the failure here.

  • […]

    We use SIP and IAX interchangeably, but had less hassle with IAX. The
    topic of the discussion on this thread was that SIP is so awesome and
    that IAX is a peice of crap. My point of view is that we’ve had many
    problems with SIP and NAT and that IAX just works great for us, and
    that in *our* experience IAX has worked better for us.

    Just to clear my head up a bit: are you supporting the argument that
    SIP is better for Asterisk than IAX?

  • I have no idea where you got that sort of conclusion. I was making a
    statement to counter your repeated arguments that using SIP behind a NAT
    without special configuration is ‘impossible’. It’s clearly not
    impossible, it’s not even impractical. It is commonplace.

    Certainly there are plenty of examples of SIP endpoints working poorly
    behind NAT devices, and replacing that endpoint with an IAX2 endpoint
    curing the symptoms. Invariably, this is caused by the fact that the NAT
    device was attempting to ‘help’ the SIP endpoint, and failed miserably.
    In every case I can remember, turning off any SIP-specific functionality
    in that NAT device (which is not always possible) allowed the SIP
    endpoint to work as expected.

    There are certainly scenarios where deploying a SIP endpoint behind a
    NAT can be problematic; usually, these revolve around deploying a SIP
    *server* behind a NAT, but even this can be handled reasonably well by
    configuration options already present in Asterisk. Deploying SIP
    *clients* behind NATs, talking to a SIP server that is on a public IP,
    is generally trivial and takes no special effort at all.

  • If you can post some SIP debug info from an ATA trying to register without
    any redirection and also the relevant portions of your sip.conf, I am sure
    I can help.

    Do it from a new location with an el cheapo home router, Linksys WRTXXX.

    If I cannot help you in a few emails, we can take this offline.

    Actually paste your entire sip.conf in pastebin or something, as well as
    sip debug.

    Also the configs of your ATAs.

    I think you have over-engineered to the point of creating problems. This
    is very common. My philosophy is “KISS”

    Thanks,
    Steve T

  • We have *never* found a single SIP “helper” to actually help anything.
    They always break everything. The only SIP-related setting I can
    think of that works is “Enable consistent NAT” found in Sonicwall
    routers (but turn off all other SIP “helpers”). The WRT54G and Apple
    Airport come to mind as stable and reliable home/small business
    routers that seem to just work. The WRTs seem to go bad every few
    years and need an occasional reboot, the Airports work forever in our
    experience without being touched. All stock out of the box.

    This is today’s reality. That’s why I mentioned the possibility that
    he’s using ancient devices and routers, or that Yugo.

  • Agreed with one exception, the endpoint behind the NAT DOES need to be
    setup correctly to keep the router from seeing inbound traffic to the
    device as unsolicited and drop it. That is a function of the router but
    keep alives from Qualify on the Asterisk side, and setting the device to
    register every few minutes will keep that mapping open and alive, letting
    traffic pass as solicited.

    Thanks,
    Steve Totaro

  • On Wed, Feb 29, 2012 at 8:41 AM, Steve Totaro
    wrote:

    We use qualify=yes on Asterisk and a few months ago turned OFF the
    keep-alive feature on all SIP clients on our entire system. This is
    working fine, and we did it because of a strange bug/behavior with
    certain versions of Cisco SPA series firmware.

  • So you turned it off on the phones but use it on the Asterisk side?

    Do you set a value or just use qualify=yes?

    I had many problems with qualify over VSAT as ping times and jitter are
    crazy. 700ms ping times were considered “Good” from the IZ in Iraq to
    Equinix data center in VA, it took some tweaking to find the right value so
    a phone that was “Reachable” was not labeled “Unreachable”, I did want
    phones that were truly unreachable to be marked as such, more to spot
    patterns and act on them or with the vendor.

    Did you submit a bug report? If it is easy to reproduce and you feel like
    helping out, report it. I do not report issues if there is a simple way to
    do the same thing, but I know I should.

    What does the debug or strange behavior look like? Probably a variance in
    the RFC implementation.

    Thanks,
    Steve T

  • On Wed, Feb 29, 2012 at 8:58 AM, Steve Totaro
    wrote:

    Yes, just as I said, just qualify=yes.

    Cisco makes it too difficult to submit bugs so I just don’t care to
    help them. When we find a service-impacting bug we report it to our
    distributor, who tests it and presumably reports it, but I’m not sure.
    Also I wasn’t sure if it was an Asterisk bug or Cisco bug, and didn’t
    care enough to find out since a clean work-around was possible.

    Soon as the keep-alive packet is sent, the phone is no longer
    reachable from Asterisk.

  • On 2012-02-28 21:22:44 +0000, Kevin P. Fleming said:

    trunk=yes was the source of the problem.

    So now I suppose I’ll have trunk=no while I “patiently” wait for the
    fix to appear in Debian.

    use the packages for pretty much all of the reasons packages were
    invented.

  • Thanks for following up! The patch to resolve this problem was very
    small, but I understand your desire to wait for a package. It will be in
    the 1.8.11 release, although of course the Debian team could choose to
    backport the one-line fix into their existing release if they so choose.

  • On 2012-02-29 15:25:49 +0000, Alejandro Imass said:

    The original question (mine) was that my sound quality when using IAX
    was bad; with SIP the sound quality was great. Critically, I mentioned
    that I wanted to use IAX; I even said I was willing to do some “self
    torture” to get IAX working properly.

    I only wanted some help in figuring out what was ‘wrong’ with my IAX
    configuration.

    After a few suggestions, Kevin Fleming noticed I was using “trunk=yes,”
    and it was likely that my Asterisk install was being affected by a
    just-fixed bug.

    Disabling trunking fixed the problem – the voice sounds great even in
    my worst-case scenerio (which was always almost unintelligible).

    The devolution into a flamewar is unfortunate, but such things are
    inevitable whenever a ‘this’ vs ‘that’ question is posed.

    For instance, is the Yugo really any worse than the competing Trabant?
    The only correct answer is to fling them both with a Trebuchet and see
    which one flies farther.

  • On Wed, Feb 29, 2012 at 10:34 AM, Steve Totaro
    wrote:

    […]

    Yeah, I think it’s time for me to shut up about SIP/NAT problems and,
    like you Carlos and Kevin pointed out, run a clean un-contaminated
    test lab to see if we can determine why our current set-up is so
    problematic with SIP and NAT.

    Thanks for offering to help. I will set-up a test lab but it’s gonna
    take me some time to free a public server to do so.

    But it is obvious that the problem is on our side after reading all
    the responses. After all, VoIP is *not* by any means our core business
    we just use it as a tool, and up until now I thought that *everyone*
    using SIP ATAs and Asterisk had these NAT woes, so we just assumed it
    was so, and thought that mostly everyone had to perform particular
    configurations on the endpoints. It now seems obvious we are wrong.

    Anyway, my whole argumentative line in this thread is that in our
    particular case we found that IAX2 works great for _our_ set-ups and
    we don’t share the view that IAX2 is a broken bat, and that in fact
    for us it just works great.

    Thanks,

  • Yeah, I wasn’t referring particularly to the original post, just the
    way the thread turned against IAX like if it’s not a viable solution
    and my point all along has been that for *us* IAX2 endpoints have
    worked better and easier to configure than SIP ones. Then it turned
    into a pissing contest, like you say, it happens in every list with
    the topic this or that.

    Again, as I pointed out to Steve above, and after reading all of your
    responses, our SIP/NAT woes seem obviously ignorance on our part, but
    that doesn’t shadow the fact that IAX2 is working great for us with
    el-cheapo endpoints like Atcom’s AG-188N and I would wish that many
    more manufacturers supported IAX2.

    We are happy with IAX and honestly never even had the need/curiosity
    to deal with the many SIP/NAT problems where sometimes it works great,
    and other times is a real pain in the ass that takes huge amounts of
    support to fix, and unhappy customers. On the other hand, IAX took
    some engineering efforts at first, but the support issues are
    practically non-existent.

  • I always posted that my view was based on experience.

    My nieces and I made a viable home phone system out of strings and paper
    cups….

    It is a real pain when you grow so large and then have to switch over to
    SIP, might as well go with an Industry Standard then code that is and has
    always been broken since it’s inception. You will find IAX2 trunking
    issues dating back to 2005 and all sorts of IAX2 related problems since I
    started way before Asterisk 1.0. They have never got it right, SIP either,
    but at least SIP is compliant enough to work just about all the time unless.

    Try IAX, the predecessor of IAX2.

    My alternator is currently not charging my battery enough for nightime
    driving unless I turn off the radio and A/C. It is fine without the extra
    variables. This is nothing new.

    Knowing that when the demand rises, my battery will die and the vehicle
    will falter and eventually stall means I am going to replace the
    alternator. Say I need my High Beams or to charge something via cig
    lighter, I will end up stranded and need to take emergency action.

    I could buy a used alternator, but I have no past experience with it and
    have no idea how it will perform.

    My choice of proper course of action is to put in something that is known
    by all to work, maybe a bad unit, but backed by an immediate exchange. I
    will replace the battery and inspect other potential problem areas and
    eliminate them as well.

    Now I will have averted any problems down the road by doing it the right
    way rather than hopping along on something that has been borken since day
    one.

    If you are going to do the job, do it right from the start so that you can
    grow or change with ease and use real recognized standards.

    If you are just playing around, do whatever. Actually do whatever, and
    learn the hard way, I don’t care, just trying to help.

    Thanks,
    Steve Totaro