Frequent SIP call drops Inbound and Outbound

Discussion in 'General' started by yesmat, Mar 7, 2010.

  1. yesmat

    Joined:
    Mar 16, 2009
    Messages:
    103
    Likes Received:
    0
    Hi Guys,

    we are having major problems with our SIP clients that started impacting our business. we almost stopped actively seeking more customers untill we figure this one out.

    Most, if not all, of our clients are experiencing SIP call drops both inbound and outbound to different degrees and many have started complaining and even threatening to rip the whole thing out.

    These are the common and uncommon ground between all of these customers:

    1- All are using different 800 series Cisco DSL routers.
    2- All are using the same ITSP provider. Some connecting directly while others are connecting through our own softswitch (OpenSER) then to the provider for billing purposes.
    3- Some use G711 with VDSL where 26Mbps of bandwidth is available, while others use G729 (Digium licensed) when normal ADSL is deployed.
    4- Some (older ones) are using Trixbox, while all others are using Elastix 1.6
    5- All are using SIP and NOT IAX.
    6- None of them are configured with sip_nat.conf.
    7- Our provider uses Asterisk as their main switching platform, which we thought is great.

    Call drops are so random that it is very difficult to get customers, during their busy business day, to write down info about such calls like when do they drop, were they inbound or outbound, after how long did they drop, did they drop to a complete silence or to a busy tone etc....

    It's hard to believe that these are isolated issues. Has anyone been experiencing such issues? which areas do we need to look at? could it be the SIP protocol itself, do we best change to IAX? so many questions.

    Your feedback and guidance is highly appreciated.

    Thanks
     
  2. Siu

    Siu

    Joined:
    Jan 15, 2010
    Messages:
    30
    Likes Received:
    0
    Try add canreinvite=no to all trunk and Sip extensions
     
  3. yesmat

    Joined:
    Mar 16, 2009
    Messages:
    103
    Likes Received:
    0
    canreinvite=no is the default setting for SIP extensions anyway and we never change that, so yes it is set to no.

    Under the trunk we also have canreinvite=no under PEER DETAILS but not under USER DETAILS. could that be an issue?

    Here are trunk configs:

    PEER DETAILS
    username=8883111
    type=peer
    secret=XXXXXXXX
    qualify=yes
    insecure=very
    host=sip1.domain.com
    canreinvite=no

    USER DETAILS
    username=8883111
    type=user
    secret=XXXXXXXXX
    qualify=yes
    fromuser=8883111
    context=from-trunk

    any other suggestions?
     
  4. ramoncio

    Joined:
    May 12, 2010
    Messages:
    1,663
    Likes Received:
    0
    Hi yesmat,
    Have you searched the logs for ERROR Error and error?
    This is what I would do:
    - Get a new box.
    - Reinstall and configure Elastix 1.6 from scratch.
    - yum update -y and update unembedded freepbx modules.
    - If possible, configure a different VoIP provider.
    - Replace the box that is giving you more problems.
    - Take that box to your office, or some other place with a completely different environment (ITSP, VoIP provider, routers), and test it furtherly.

    This should give you an idea if the problem is with the box itself, or with the environment.
     
  5. yesmat

    Joined:
    Mar 16, 2009
    Messages:
    103
    Likes Received:
    0
    We are having the same problem with multiple customers at completely different locations as mentioned in my initial post.

    We never do "yum update -y" we only do "yum update elastix -y". Is it recommended to run "yum update -y"? I thought this was not recommended since it actually updates every thing including Centos etc....and may potentially cause issues.

    We are just about to do exactely what you are saying (except without yum update -y) and using a totaly different provider and will see what happens. The provider we are using is one of the biggest in our location and would be difficult to belive that they have an issue while most other people using them.

    I was just hoping that someone would look at our trunk configs and point out any missung configuration lines that need to be there or suggest removing some of the exsisting lines that potentially could be causing our grief.

    Based on our trunk configs, do you see any thing that doesn't seem right? is that how would you configure your SIP trunks?

    As far as the logs are concerned, where would you start and what would you look for? It is very hard to look at sea of log entries, so any clues would be really appreciated.

    Thanks
     
  6. yesmat

    Joined:
    Mar 16, 2009
    Messages:
    103
    Likes Received:
    0
    Any other ideas guys?
     
  7. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    The only logical common factor is your SIP provider, did you try an alternate (perhaps just for outbound so it's not too disruptive)?
     
  8. yesmat

    Joined:
    Mar 16, 2009
    Messages:
    103
    Likes Received:
    0
    welcome aboard dicko.

    The reason why we still haven't tried any other provider is that the one we are using is the biggest in our area and they are providing services to "call centres" around the country and we they would not survive if they were that bad. But it seems that this is our only way of at least ruling out that area.

    Have you any comments in regards to the way we configure our SIP trunks in previous post? would you do it any differently?
     
  9. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Have you always had this problem, or did it recently appear?


    That you have a variety of deployments and you seem to have adequate routers (and I assume the servers are varied and adequate also), would logically lead me to network or provider issues, You state that the network connections are also varied and with separate providers, so eliminate that as a primary reason, your trunk configs seem pretty vanilla and unless your VSP indicates otherwise I would be happy with them, by a process of elimination that leaves you with the VSP.

    The clue is "random", systematic errors in configurations are rarely random but generally identifiably repetitive.

    It should be easy enough to add an alternate vendor for outbound calls without disrupting anything else (apart from maybe your wallet, but that is small change if you face loosing clients) especially for those using your proxies, if the drops then are restricted to the inbound calls, then QED, if not it's back to tcpdump and head scratching. However if so, it is still going to be tcpdump and head scratching so you can prove to the vendor that "We have a problem", remember that the biggest weapon that many VSPs have is "finger-pointing".

    dicko
     
  10. yesmat

    Joined:
    Mar 16, 2009
    Messages:
    103
    Likes Received:
    0
    well....we have always had this problem since day one. But now because we have more customers the problem is bigger.

    One more common factor with all of our instllations is, we always use an ATOM based 1.6Ghz motherboard system with 1GB RAM. The biggest site that we have deployed so far is for 35 users.

    I think you are right, we will be setting up a test box using the same common hardware etc....and hook that up to a different provider and see what happens.

    I ahve recentley made contact with our provider and they sent us a copy of what the trunk configs should look like here it is:

    [VSP]

    type=friend
    username=yournumber
    fromuser=yournumber
    secret=yourpassword
    host=SIPDOMAIN.COM
    context=default ; or your own selected context if desired
    dtmfmode=rfc2833
    disallow=all
    allow=ilbc
    allow=gsm
    allow=alaw
    allow=ulaw
    ;allow=g729 ; only if you have licenses to use it
    nat=yes
    canreinvite=no
    insecure=very

    The only thing that was missing from our configs is the "nat=yes", which we have configured on a test server and testing goes on.
     
  11. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    That your VSP recommends you use codecs in this order:

    allow=ilbc
    allow=gsm
    allow=alaw
    allow=ulaw

    Which is lowest quality lowest bandwidth first is indicative that they are under resourced, I would definitely not use ilbc (don't even know if it's in the later Elastix Builds anymore)

    If you have the bandwidth then use ulaw/alaw depending on your locale it just sounds better, so I agree try another VSP, you normally get what you pay for. If you are i fact trans-coding as many as 35 calls simultaneously to ilbc then an atom might indeed be a little stressed, but I still suspect your VSP.

    good luck

    dicko
     

Share This Page