[ILUG] Asterisk / Trixbox Weirdness

[Brendan Minish]

On Sun, 2008-08-03 at 09:30 +0100, Kevin Brennan wrote:
> It would be worthwhile setting up a SIP trunk for incoming and see if 
> you have the same problem. If you do not have this already, you can pick 
> up a free one from freespeech. (Why bother renting a PRI from eircom ? - 
> ouch )/KB

Because outside of Dublin (&preahaps Cork & Galway) wholesale internet
connectivity good enough to reliably support voip with enough capacity
to handle a call centre (even a small one) costs lots and lots.  

Here in Castlebar, a 2Mb leased line has tail charges of 26K per year.
ESB fibre does not enter the county at any point. BT have fibre into
Ballina (30Km away) but in the past this has been subject to chunks of
downtime lasting days at a time (railway maintenance related I think) 
the real issue with connectivity at all levels is that the internal
wholesale transit market in Ireland is completely buggered.

We haven't seen this in sip to sip calls internally so I am not really
expecting it to happen on external sip calls either but I'll add this to
my list of things to check.

> 
> Brendan Minish wrote:
> > Bricky
> >
> > 	thanks for the helpful and detailed reply. I'll fill in a bit more
> > information  
> >
> > On Sat, 2008-08-02 at 22:29 +0100, Bricky wrote:
> >   
> >> Hey Brendan,
> >>
> >> First off, my sympathies: no one should have to work on stuff like this
> >> over a bank holiday weekend.  Hope they're paying you well.
> >>     
> >
> > frankly I would like to have been called in earlier since at this stage
> > many big changes have been made to the configs and indeed the builds
> > that it's now much harder to identify the change that broke things.
> >   
> >
> >   
> >> <quote who="Brendan Minish">
> >>     
> >>> (*) at which time the agent sometimes hears a fraction of a second long
> >>> burst of audio from the caller
> >>>       
> >> I think this is probably very significant.  To me this points towards some
> >> network hardware between asterisk and the snoms which isn't doing its job.
> >>  It would seem to indicate that the last audio packet (possibly smaller
> >> than the others?) is getting through.
> >>     
> >
> > Hmm, I had considered that too, however the sip trace looks identical on
> > a duff call 'vs'  a normal call 
> >
> >   
> >> Is the network setup complex there?  Could you swap out a switch or two?
> >>     
> >
> > no, this is small call centre and the network is dead simple, a flat
> > RFC1918 space lan, the phones and asterisk server are on their own
> > switch and a different switch has been tried with no change 
> >
> >   
> >> Second thing I'd look at is the snoms.  If you can grab the logs off one
> >> just after this happens I feel it would point you in the right direction. 
> >>     
> >
> > We have been looking at their logs, I am not seeing anything odd but
> > then again I may be missing the blindingly obvious, if so I do hope the
> > penny drops soon.. 
> >
> >   
> >> IIRC they also have some kind of packet dump facility?  If this is
> >> happening 10% of the time it might be worth setting this up on one to see
> >> what really is happening.
> >>     
> >
> > Yes I will do that tomorrow when things are quiet. I'll get wireshark in
> > on the job too 
> >
> >   
> >> Also, IIRC they update themselves automatically by default?  It might be
> >> worth checking when their last updates occurred (this could be a codec
> >> issue).
> >>     
> >
> > No but they were all manually updated before I arrived on the scene in
> > an attempt to resolve the issue. 
> >
> >   
> >> Have you any non-snom phones there?  Does it happen on them?  (the snom is
> >> a good phone and I'd generally trust it, but it'd be nice to be able to
> >> eliminate it from your list).
> >>     
> >
> > there's a couple of Aastra 480i phones and they have the same issue with
> > what appears to be about the same frequency of occurrence. 
> >
> >   
> >> Last thing I'd go for is the asterisk log itself.  I'm sure you're aware
> >> that asterisk has very extensive logging capabilities and it might be
> >> worth checking what asterisk itself thinks is going on.
> >>     
> >
> > We have been logging lots there and running multiple console with grep
> > sorting things into more manageable chunks. We simply aren't seeing
> > anything that appears different about the dead calls. we may still be
> > looking in all the wrong places though..   
> >
> >
> >   
> >> I actually think it's quite unlikely to be anything to do with the PRI -
> >> the call is fully established on that end and there is nothing happening
> >> there during the MOH -> Agent handoff, all the working is going on on the
> >> snom - asterisk end of the call.
> >>     
> >
> > yes that's kind of what I figured but complicating matters are issues
> > with the digium card loosing sync with the line at times (the sangoma
> > seems to be ok in this regard) and the timing of the issue which seemed
> > to coincide with the addition of extra DDI numbers 
> > The digium card worked 100% until it was put away as a spare (Sangoma
> > echo cancels )
> >
> > However it is also likely that the addition of the new ddi numbers to
> > trixbox was also when trixbox was upgraded to a newer asterisk 
> >
> > tomorrow I am going to downgrade astrisk a few minor versions and see if
> > that helps. 
> >
> > I also want to see what happens to an inbound call that is repeatedly
> > held and unheld and if this has any bearing on the 'no audio' calls  
> >
> >
> > regards
> >  Brendan 
> >
> >