Stuttering on second call

Discussion in '3CX Phone System - General' started by jonathanc, Mar 8, 2013.

Thread Status:
Not open for further replies.
  1. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    I have a problem when making or receiving a second call on my system, whether from the same phone or using different phones.

    The quality of the first call is superb; but when the second connects. both calls begin stuttering to an unacceptable extent.

    I am using 3CX v 10 (until i am sure the system is right for me) with Cisco SPA 303 phones - latest firmware.

    The problem is the same with both Draytel and Sipgate as service providers.

    Sipgate suggested I use 'sipgate.co.uk' as Proxy and Outbound proxy on my phones, and my Sipgate account credentials for User ID, Password and Auth ID. I tried this, and was able to make simultaneous calls which did not stutter. But then, of course, the calls were bypassing 3CX altogether and I lost all PBX functionality! Restoring the above parameters to reflect the extension settings in 3CX (as per http://www.3cx.com/sip-phones/ Updated link) brought the problem back with it.

    The relevant part of the Server Activity log (with details changed to protect the innocent) are as follows.

    22:07:01.779 [CM503008]: Call(24): Call is terminated
    22:06:59.223 [CM503008]: Call(23): Call is terminated
    22:06:36.758 [CM503007]: Call(24): Device joined: sip:167xxxx@sipgate.co.uk:5060
    22:06:36.755 [CM503007]: Call(24): Device joined: sip:107@192.168.1.31:5262
    22:06:34.246 [CM505003]: Provider:[Sipgate Church] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:167xxxx@5.61.196.247:5060]
    22:06:34.245 [CM503002]: Call(24): Alerting sip:167xxxx@sipgate.co.uk:5060
    22:06:32.737 Currently active calls - 2: [23,24]
    22:06:28.897 [CM503025]: Call(24): Calling VoIPline:07828510xxx@(Ln.10007@Sipgate Church)@[Dev:sip:167xxxx@sipgate.co.uk:5060]
    22:06:28.057 [CM503004]: Call(24): Route 1: VoIPline:07828510xxx@(Ln.10007@Sipgate Church)@[Dev:sip:167xxxx@sipgate.co.uk:5060]
    22:06:28.055 [CM503010]: Making route(s) to <sip:07828510xxx@192.168.1.4>
    22:06:28.052 [CM505001]: Ext.107: Device info: Device Identified: [Man: Cisco;Mod: SPA Series;Rev: General] Capabilities:[reinvite, replaces, unable-no-sdp, no-recvonly] UserAgent: [Cisco/SPA303-7.5.4] PBX contact: [sip:107@192.168.1.4:5060]
    22:06:28.051 [CM503001]: Call(24): Incoming call from Ext.107 to <sip:07828510xxx@192.168.1.4>
    22:06:11.801 [CM503007]: Call(23): Device joined: sip:165xxxx@sipgate.co.uk:5060
    22:06:11.799 [CM503007]: Call(23): Device joined: sip:106@192.168.1.31:5261
    22:06:09.454 [CM505003]: Provider:[Sipgate Personal] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:165xxxx@5.61.196.247:5060]
    22:06:09.453 [CM503002]: Call(23): Alerting sip:165xxxx@sipgate.co.uk:5060
    22:06:06.006 [CM503025]: Call(23): Calling VoIPline:01994419xxx@(Ln.10006@Sipgate Personal)@[Dev:sip:165xxxx@sipgate.co.uk:5060]
    22:06:05.167 [CM503004]: Call(23): Route 1: VoIPline:01994419xxx@(Ln.10006@Sipgate Personal)@[Dev:sip:165xxxx@sipgate.co.uk:5060]
    22:06:05.166 [CM503010]: Making route(s) to <sip:01994419xxx@192.168.1.4>
    22:06:05.163 [CM505001]: Ext.106: Device info: Device Identified: [Man: Cisco;Mod: SPA Series;Rev: General] Capabilities:[reinvite, replaces, unable-no-sdp, no-recvonly] UserAgent: [Cisco/SPA303-7.5.4] PBX contact: [sip:106@192.168.1.4:5060]
    22:06:05.161 [CM503001]: Call(23): Incoming call from Ext.106 to <sip:01994419xxx@192.168.1.4>

    One of the 'outside' phones is obviously a mobile in this case, but the same thing happens with two landlines involved.

    Is there something there which is glaringly obvious to everyone else but invisible to me, please?
     
  2. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,064
    Likes Received:
    58
    Stuttering or more likely jitter - is when the data packets arrive at differing intervals than when sent and in some cases, not in the same order as when sent. If severe enough, the jitter may be more than what the jitter buffer in the phone (assuming one is present) can overcome and as a result you may hear speech that, while pretty complete, is broken in that it is delivered to the ear in spits and spurts and some words or even may come across fine. You can generally understand what is being said, but it is disconcerting.

    For the most part, this is indicative of a lack of bandwidth. There is more data than what the pipe can handle and should it get too severe, there can be a dropping of packets which may ultimately result in dropped calls. There are a few things that you might try -

    Ensure that the phones are set to higher QOS/TOS/DSCP levels. These methods attempt to prioritize data packets, but are typically only useful within your private network. Search for QOS in the Blog for more detail.
    Drop to a codec setting that is not as bandwidth intensive as that which you may be using (this may be what happened when 3CX was bypassed)
    Get with the carrier provider and see if you can get more bandwidth - most likely the better cure.

    You are sharing the existing pipe with other traffic and it is not uncommon for the pipe to reach peak demand. The fact that a second phone seemingly pushed the envelope is indicative that the pipe is already reaching critical mass.
     
  3. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    Thank you, lneblett, for your full response and very helpful analogy.

    However, my incoming pipe can take 12 Mbps and my outgoing pipe 4 Mbps, and they normally carry only a dribble. Besides, if it were a bandwidth problem I would expect it to remain when the phones are connected to the carrier provider direct - or am I missing the point?

    I have changed the codecs used by the phones. but with no effect.

    Your mention of the term 'jitter' prompted me to play around with the jitter settings on my Cisco phones - again with no real effect.

    I can't see any QOS settings in my TP-Link WR841N router or any mention of QOS in the SPA303 User Guide. Perhaps I ought to upgrade my router's firmware or try another router?

    One perhaps relevant fact which I omitted to mention is that I am using a satellite broadband link with a latency of around 700 mS, so I suppose that might be a factor; but I wouldn't expect that to cause this stuttering - unless, of course, something in the system is attempting to cancel what it perceives as an echo, but that thinking is a bit beyond my capabilities!

    It's frustrating, because VoIP offers so much potential; but if we can only make one call at a time it rather defeats the object.

    Have I said anything which prompts any further thoughts, please?
     
  4. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,567
    Likes Received:
    246
    VoIP already has a bit of a delay due to encoding/decoding process, the second call seems to be too much to handle.
    The problem with VoIP, is that any corrupt or missing packets cannot be re-sent as can be done with "regular" Ethernet (data) traffic. As it is in real time, only so much can be done before voice quality begins to suffer. I'm not sure which Codecs you currently use but you might try changing those, if your provider will support that.

    I'm also assuming that your local network, is not creating any bottlenecks.
     
  5. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,064
    Likes Received:
    58
    In answer to the first question, yes you would expect it to be the same connected directly ........provided all else is equal. What is not known is what codec the carrier negotiated with the phones. Is the PBX set to provide audio? 700ms is a large amount of latency. Callers may have a tendency to over talk one another. QOS and such is mostly for the benefit of the LAN. If you really have little traffic, then you really won't gain much if any.

    Try going to http://www.pingtest.net and run their test and see what indicates.
     
  6. netswork

    netswork Active Member

    Joined:
    Mar 11, 2011
    Messages:
    577
    Likes Received:
    1
    With two calls going at the same time try to do an extended ping to your voip provider. ping -t x.x.x.x and see how much the response time varies between packets. If its more than 30ms then that's where your problem is. Voip over satellite is going to be tricky. In your firewall if you have QOS options you will want to make sure your voice traffic gets priority, not necessarily in how much bandwidth you assign to voice but making sure voice packets are processed first.

    I have only seen voip over satellite work well in one situation and that required having the same satellite service at both ends of the call.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    Thanks, folks for your suggestions and advice. Sorry for the gap in comms: I've been in hospital.

    I've just had a long and helpful call with the Cisco support guys, who analysed a Wireshark capture for me (they really do provide an excellent service!). They detected a 33.8% displacement of packets on the return (incoming) leg. They said that with the degree of latency inherent in satellite broadband I was lucky to be getting one good call, let alone two - thus confirming the general consensus above. So 3CX and the rest of the links in the chain are in fact doing very well.

    One thing they did say I could try was to increase the size of the jitter buffer in the PBX - but I can't see how to do this. Does anyone know if it's possible, please?

    Thanks again for all your help. I reckon I'll just be grateful I'm getting as much as I am and wait for cable to come our way!
     
  8. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,064
    Likes Received:
    58
    the jitter buffer is located in the phones. You will need to access thru the web interface. You might see a hint of improvement, but personally, I don't think it will be enough...but still try it out.
     
  9. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    Thanks, lneblett, I have tried all possible settings of the jitter buffer on the phone, with no effect either way.

    The PBX is not set to deliver audio; but checking this box makes no difference, either.

    I have also tried a variety of audio codecs, but without making any difference at all.

    And thank, you, netswork: I did an extended ping test on my VoIP service provider and yes, the difference between the times was sometimes much greater than 30 mS. But for the reasons below I'm not sure if we can blame this factor.

    After my call with Cisco Support, I was resigned to blaming my satellite broadband connection. However, on reflection, there are one or two things which this explanation doesn't seem to fit.

    As a test, I pared the system down to 3CX loaded onto a laptop and one SPA303 phone connected directly into the back of my TP-LINK WR841N router. I disconnected the rest of the LAN

    First, I configured Line #1 on the phone to connect directly to Sipgate account #1, and Line #2 to to Sipgate account #2.

    Two simultaneuos calls worked perfectly. OK, there was a bit of delay, but perfectly acceptable. There was no jitter/gapping on either call.

    Then I reconfigured the phone so that both Lines used 3CX, still to separate Sipgate accounts. The jitter/gapping problem returned immediately.

    Well not quite immediately: at the beginning of every 'second' call there was a period of between 3 and 10 seconds during which call quality was perfect - before the jitter/gapping began. Very curious. The problem is only on the incoming leg, incidentally - ie on speech from the distant phone.

    What I don't understand is this: if the problem is due to the high latency of the satellite broadband connection, how come it disappears when 3CX is taken out of the loop? And why does the problem only kick in after 3-10 seconds?

    Any suggestions gratefully received!
     
  10. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,567
    Likes Received:
    246
    Every device, that the call has to pass through can add to the latency. Not by much, and in a "normally" (read terrestrially) connected system,with decent bandwidth/low latency, probably not noticeable. But at some point, though your current network, you seem to be "reaching the straw that breaks the camels back".

    Others, that do not even use a satellite connection have found switches (or other network devices), that should not be causing issues, creating the same sort of problem, you are experiencing.
     
  11. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    Point taken, leejor, thank you. Yes, I thought it might be our ancient network switch to blame. But since my last post I have tried the 'direct-to-VoIP-provider' trick via the main LAN, and that produces two simultaneous flawless calls. So the signal is going local phone > network switch > router > modem > satellite > Sipgate > PSTN > remote phone and all the way back again - times 2 - without any problems. Put 3CX in the loop and you get breakup. That's the bit I don't understand - unless you're saying that passing through 3CX is itself the proverbial straw.

    And then there's the question of the 3-10 second initial OK-ness. Why does it take that long to break the camel's back?

    Incidentally, at the Cisco guy's suggestion I tried two simultaneous internal calls through 3CX, and they were fine - though I appreciate that the massive latency of the satellite link is missing in this case!

    Sorry to be so persistent, but it's turned into a bit of an intellectual challenge. Unless, of course, I'm simply misunderstanding some part of the technicalities.

    Anyway, thanks again for your help.
     
  12. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,567
    Likes Received:
    246
    Unfortunately, troubleshooting something like this doesn't necessarily follow logic, at least it doesn't always appear that way. Everyone's 3CX set-up is going to be slightly different, so the identical change on one system, that fixes an issue, isn't guaranteed to do the same thing on another system. It sometimes comes down to trial and error ans eliminating links in the chain between point A and B.

    As far as 3CX introducing (slight?) delay, yes, that is a distinct possibility. My understanding, is that while internal extension calls can be set-up to by-pass 3CX (communicate directly once connected), extension to trunks calls cannot (someone please correct me if I'm wrong). Add to this any transcoding that 3CX has to do (different codecs, phone to provider), and you will have additional latency added to that of the satellite connection. That might be enough to make attempting the second call, pointless.
     
  13. netswork

    netswork Active Member

    Joined:
    Mar 11, 2011
    Messages:
    577
    Likes Received:
    1
    Its my understanding that in the instance of an external gateway like a patton, that the RTP passes between the patton and phone only after call setup. If its a voip provider or bridge then 3cx is involved in the RTP flow.

    I asked this specific question during the training in Dallas so hopefully this is still correct. I installed a system recently where there are two locations, 1 3cx, and patton gateways at both locations. From what I can tell , I have not sniffed the traffic though, 3cx is not involved in RTP between the gateway and phone.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  14. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    Thank you all, but I have just this minute SOLVED the problem - by disabling music on hold. Even a silent file produced stuttering, so the only thing to do was to disable the 3CX Media Server service in Windows Services. Now I can make 3 simultaneous calls (I haven't tried 4) without jitter or gapping. At the expense of MOH, of course, so you have to warn callers not to expect it and ring off if you put them on hold. A quick and dirty fix, but one which has got me out of a hole. I just hope there isn't other functionality which depends on this service which is rather more vital.

    Thank you again for your ideas.
     
  15. netswork

    netswork Active Member

    Joined:
    Mar 11, 2011
    Messages:
    577
    Likes Received:
    1
    Does this jitter only happen when someone is on hold/park or if you have 2 active calls with no one on hold you experience the jitter unless you stop the media server?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  16. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,064
    Likes Received:
    58
    You may want to read the following:

    http://www.3cx.com/blog/docs/media-server/

    You really have not solved the problem per se, but possibly mitigated it to some degree. Your initial symptom descriptions followed by Cisco's evaluation still make it look like you have a bandwidth issue to me. Cutting the media sever likely cut the amount of data traversing the network, which may have bought you some space at the expense of limiting the type of connections you can now support. The by-product of removing 3CX from all voice paths is that MOH is no longer available, but it was never raised as being in any part of the testing and I don't really view MOH to be anything other than a substitute voice...just from a different source (3CX rather than the phone). Voice mail announcements, IVR, etc., are they no longer functional?

    Taking another step back, I guess there is also the possibility that the system upon which your are running 3CX might not be up to the task. I don't think we ever asked what processor, OS and all you might be running. I also don't think we asked what kind of modem is in use (make & model) for the satellite signal. I do wonder if killing the service made the processor more available.

    In any event, it still seems clear that the more you load the network, the less able it is to carry voice in the manner needed.
     
  17. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    I'm sure you're right, lneblett, in that I'm ameliorating the symptoms rather than curing the disease - a bit like taking whisky for a cold. But it works.

    To answer your questions, voicemail, IVR and prompts are all working as normal (once I'd remembered to set my firewall to allow automatic access to the Internet by 3CX Phone System IVR Service!).

    My system comprises an Intel Core i5-2400 CPU @ 3.10 GHz, with 8.00 GB of RAM running Windows 7 Home Premium SP1. The satellite modem is a ViaSat Surfbeam 2 model RM4100. The ISP is Avonline (based in Bristol, UK) and the satellite service is provided by Tooway, a European company using a Skylogic Ka band satellite. My download speed is a theoretical 12 Mbps - I get at least 8 - with an upload speed of 4 Mbps theoretical, 3.5 in practice.

    One thing I don't pretend to understand is the way my satellite broadband connection allocates bandwidth. In some circumstamces (eg if you're just casually browsing), a traffic log shows speeds well below your allotted (say) 12 Mbps. But you do get your maximum speed if you download a large file like a program update. If whatever controls the connection at the ISP's end is treating VOIP in the saame way it treats casual browsing, then perhaps this has something to do with the jitter/gapping problem - though the ISP does boast VOIP as one of its selling points.

    I found the link you supplied about Media Server fascinating - thank you - though I need to digest it a bit more, I think.

    Anyway, the system is up and running very satisfactorily now. The latency inherent in a satellite connection is noticeable, but with the right VOIP provider only if you're listening out for it. And if you listen carefully when 2 or 3 simultaneous calls are being made you can just hear in the background what sounds like an old analogue crossed line. I can't begin to guess where that comes from, but it's not prominent enough to downgrade the call quality rating to less than 90%.

    So thank you again for your help. We may not have cured the cold, but I'm enjoying the whisky!
     
  18. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    netswork, the problem is there (with 3CX Media Server running) with 2 active calls involving 2 extensions as well as when one call is on hold. Stopping the 3CX Media Server service allows at least 2 simutaneous calls with a call quality i would rate at 90%+.

    Thanks again for your help.
     
  19. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    Just to report that I've upgraded my satellite broadband connection to 20 Mbps down, 6 Mbps up and the problem has disappeared. I reactivated 3CX Media Server and can now make 3 simultaneous calls in top quality.

    Thanks again for all the advice.
     
  20. jonathanc

    Joined:
    Sep 3, 2012
    Messages:
    63
    Likes Received:
    1
    Oops - sorry, forgot to check this thread for some time.

    It's a bandwidth issue, as was originally suggested.

    I've upgraded to a 20 Mbps down, 6 Mbps up 2-way satellite link and everything works fine - except there is hideous latency and when one of you says something you have time to make a cup of tea before the other person hears it.

    Going via 3G incurs less of a delay but this varies according to network congestion.

    Hope this info helps - and thanks again for all suggestions.

    jonathanc
     
Thread Status:
Not open for further replies.