Little side note here: you keep mentioning about your internet speed. The key here is stability, not speed. We have clients who have a 1.5mps upload speed (on DSL) and their phones are working fine as long as the connection is stable…
True. I’ve noticed that 100 kps per client is the maximum. I just mentioned is because low performance is often reported as a factor in poor voip performance.
WiFi and VoIP don’t work well together, because of latency issues, although modern routers have features to try and mitigate this. Also, it comes across to me that you have highly contended network or you are using repeaters, both of which are not going to be good.
This is rural France - we live in an area which is not covered by internet services. It is getting better now with 4G installations, but masts often hidden from sight.
We share about 250 Mbps (guaranteed) between 115 members. We are using switches and point-to-point radios, which nibble off a few ms. Yet it is not bad.
Nearly all phones work without issues. We have two problems, but they also worked fine up to two months ago.
There is a networking issue, but I do not believe it is inherent to our setup.
Except everything points to the issue happening past the WAN at these two locations. That is now your setup.
That’s the download, your previous speed tests show this is not symmetrical. This is an issue with their upload. What is the upload speed you are guaranteed? On top of that you’ve mention users typically get 100Mbps x 50Mbps when using ipref3 testing. Your testing with the provider in a previous post was “good” with 151Mbps x 41Mbps.
I’m going to just go with 250Mx75M for this because it’s easier. At 115 users that means, per user, they should have 2.1Mbps down and 65Kbps up if you were evenly assigning bandwidth allocation to all 115 users. You could even go nuts with 3Mx1M allocation but that means once things start to get busy you’re going to have congestion and people will see slower speeds.
The fact you are saying individual users are getting 100Mx50M speed tests via ipref3 means you are not putting any limitations on your users and their bandwidth use. The upload is already pretty thing per user with 115 users and 75M (if that is what it is, even worse if lower) and you have two users with horrible outgoing audio issues that are all related to the upload of the user.
What is the actual upload cap you have, overall. And do you actually have limitations per user or are you just letting the users having what they want when they want it?
Hello BlazeStudios
Sorry for the late response. Somehow I missed the notification.
Contractually we have 1G/1G guaranteed, equally shared with two other partners in the area. However we transport this via wifi links and we can’t push that through.
I have configured our main links asymetrical - 75% for download, 25% for upload. The reported capacity is 300/73. My TCP measurements indicate about 250/60 or so.
Despite the fact we have a little over 100 users, we hardly ever come close to the maximum in either direction. Only a few people are active at the time. mostly with modest needs. Most demanding are the evening hours with people watching TV etc.
I regulate the download at the head of the network using Mikrotik queus, but that only kicks in when it is congested. The availble capacity is shared equally between all active users. (If some users require less their unused quota is distributed to those who want more).
If we are not close to the maximum, everyone can take whatever he needs.
I have made a few exceptions for people who download with 95 Mbps all day long. This person is limited to 20 Mbps during the daytime. He now limits these downloads to the nighttime
VOIP traffic is prioritised both down and up at all major switches.
I don’t believe network capacity, nor latency is the cause of the problem this one user faces.
Yesterday I captured a communication which exhibited the problem and started to analyse it using wireshark. I’ll post a summary tomorrow.
Thanks again!
I have been able to capture a communication which illustrates the problem.
Below some diagrams. The (mostly one-sided) converstion was short, but the statistics indicated 0.00 and 0.25% packet loss for the two streams.
The essence is that an outside person (black curve) called the client (blue curve) in our network. The call is answered and two way audio exists.
However, a few seconds into the call the VOIP provider starts to send re-invite messages. Our client phone does not respond, and the VOIP provider terminates the call.
I have inspected the re-invite messages but could not find a difference.
In particular I looked at the to,via and from fields in the SIP header, the contact information (for IP and port) and media description in the SDP part.
Any SIP specialist who can point me where to look for a possible reason for sending these re-invites?
Although it might now be fixed, X-Lite (soft phone) was or is broken with respect to Re-INVITE; it completely ignored them, rather than responding with either OK or rejection - even if it was unable to process them, it should have actively rejected them. Duplicates should get the same response as the original. Maybe your users’ phones have the same problem.
What type of device is being used at the users location? More importantly, where was this capture taken from? These two pieces of data are needed to give you a more defined answer.
However, as to why the re-INVITE is happening that is easy. They are sending you an INVITE with g711a, g711u and g729 as their supported codecs. The users device is telling them “I use g711a with NSE”. They are sending a re-INVITE for using g711a but no NSE and there is no response from the INVITE. They then send a BYE which also gets no response.
But basically this is them sending a re-INVITE and it being sent to the end user with no response. So it is important to know where this capture was taken.
This is completely unrelated and basically throwing pasta at the wall to see if it sticks. 1) X-Lite has been dead for years. Bria Solo replaced it. 2) The SDP shows that NSE is being used. NSE is a setting used for analog gateways as it has nothing to do with purely IP devices. 3) The capture shows numerous BYEs also being ignored as well. Not just that, the device does reply to the re-invite multiple times and the BYEs.
Everything is delayed and out of order. Right now everything is pointing to issues with the users network. That could be the WAN side or something happening with the users router and network.
The traces are captured close by our head of the network. The client is downstream by two wifi links and a switch. It is possible packets would get lost on that segment.
In order to capture at the client’s location, I would have to install additional equipment there.
I believe the IP phone is a SPA 112 adapter.
Most users take this as part of a complete solution from the provider. The phone is then locked and managed by the provider. It does seem odd the provider would specify codecs incompatble with their recommendations. It is possible to buy on configure your own phone, and just get a VOIP subscription. I will verify with the client.
The client phone list two codecs g711A and NSE with the first as preferred, correct? Does that not imply the agreed codec is g711A? Or are the reinvites an acknowledgement of the codecs to be used?
Strictly speaking, codecs aren’t negotiated. Each side sends the codecs that it is prepared to accept. The responder may limit the response to only include those specified by the requestor, but that isn’t a protocol requirement. Any of the codecs listed by the other side can be sent to it, at any time in the call, even if not listed by the local side.
ReINVITEs can be used for purposes other than codec changes; it is actually unusual to use them for that purpose. They are more commonly used to change the media destination (e.g. direct media), put streams on and off hold, updated connected line ID (a generalisation of caller ID), and for session (keep alive) timers. One needs to see the full requests and responses, not just the message sequence chart summaries.
I’d note that your logging doesn’t identify to which transaction a response belongs, but it does look as though a lot of both re-INVITEs and BYEs, or their responses, are getting lost.
I hadn’t heard of NSE before, but it seems to only be used by Cisco equipment, and Cisco systems are normally designed for corporate internets.
Strictly speaking, this is completely incorrect. Codecs are negotiated, this is why the order is important. If there is no successful negotiation then the call cannot be established and a 488 Not Acceptable Here. If party A only sends 1 codec and party B replies with 5 codecs and the shared codec is the 5th one, there is a high chance the call could fail because it never gets to the 5th in the list.
Again, this is incorrect. Codec changes or updates to the SDP, such as T.38, will always force a reINVITE.
I’m not sure how SPA1x2’s that are used by residential consumers and where marketed for that space are corporate interests. Grandstream HT’s have their own version of support modem/g711 passthrough for faxing/T38. Other gateways in the past have also had something to help with this.
OK this is a skewed test. You need to be as close to the end user as possible. Nothing from this test actually shows the traffic hitting the users network. It’s taking from two points upstream, all this shows it the traffic hit that point. So yes, there could be something happening between that point and the two hops to the user. You need to do testing at the user’s site.
They aren’t. NSE is not a standalone codec, it helps handle g711 passthrough for modem/fax tones/data traffic. This setup indicates they have set the SPA112 to support both voice and a fax machine being used on it.
Isn’t someone looking at the customers router when doing these tests? Also, you said two way audio exists but your original claims are that the outside party couldn’t hear the user, regardless of inbound or outbound calls. It sounds like they could hear just fine but the reINVITE issue is causing the call to drop.
Cisco proprietary Named Signaling Event (NSE) packets
Yes, I never said it wasn’t Cisco only. In fact, I pointed out that Grandstream HT’s (the next leader in the ATA market) have their own version of modem/fax passthrough settings. It’s not NSE per se but it is doing the same function.
The SPA devices did this before Cisco bought them. Cisco updated the firmware to use NSE as an option for passthrough. I have been doing this for a long time, I used the devices before Cisco bought Linksys and acquired the SPA lines. I still have old Linksys 2102’s that the SPA112 replaced. I still have old SPA 942’s which the SPA 504 replaced. Cisco made very little changes to the firmware outside of throwing some Cisco stuff in it.
Hello,
A quick update.
I have not been able to install any additional equipment at the customer’s site.
Initially most of the conversations went fine, but over the past few days there have been issues again.
I observed that, although the percentage of dropped packets was low, and most of the time packets were transmitted in regular 20 ms intervals, there were times that they came in bursts - a silence of 1000 ms or so, followed by an avalanche of packets. I need to pinpoint where this bottleneck exists.
The clients are, understandably, rarely using the phone until this issue is fixed. To generate traffic I’ve prepared a Raspberry PI running Asterisk which should play musicOnHold whne called. I had this running fine, but it stopped somehow. The music starts but immediately stops:
-- Executing [200@phones:4] MusicOnHold("SIP/huis-00000022", "") in new stack
-- Started music on hold, class 'default', on channel 'SIP/huis-00000022'
-- Stopped music on hold on SIP/huis-00000022
Someone any idea what is causing this? It used to work fine…
I found the issue. It had to do with codecs. In sip.conf I specified ‘pcma’ as codec instead of ‘alaw’.
I also had a g729 codec in the list, which led to the termination of MusicOnHold.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.