Mute outbound call syndrome; Betamax issue?
 

Hi. I made up a title for a problem I encounter fairly frequently using my VOIP setup. I call it "mute outbound call syndrome" (MOCS, for short). The problem manifests in the following way: very frequently (probably 25% of the time) when I place outbound calls, I can hear the person I'm calling perfectly, but they cannot hear anything I say. Or, if it's an automated system, I can hear the recording, but all key presses I make don't register at the automated system.

Here's my setup. I have a Sipura 2100 ATA that registers with Voxalot. My VSP is a Betamax reseller--justvoip. I should mention that both my phone and my ATA actually have two lines, and I've tried registering the second line directly with justvoip, e.g., making it such that my outgoing calls do not go through voxalot. No matter which of those two variants I use, I still get the MOCS problem. That leads me to believe the MOCS problem has to do with Betamax and their funky service.

MOCS is quite arbitrary. I can be making several calls, for example, and the first 2 or 3 tries result in MOCS: I can hear the person I'm calling but they can't hear me. Suddenly, on the next try, they can hear me. Or on a given day several tries over a period of a few hours result in MOCS. Later that same day, calls get terminated normally. I can't see any rhyme or reason to this. But again, as I said, this happens with some frequency--something like about 25% of the time I experience MOCS.

So, a coupla questions. Any others here who use Betamax as their VSP ever experience MOCS? And finally, are there any settings I might tweak on my ATA to address the issue? It's getting a bit frustrating.

Thanks,
James

EDIT: I was relying on some faint memories when I said I get MOCS as well when using line 2 (direct registration with justvoip, not using voxalot as intermediary). Now that I've resurrected line 2 for further experimentation, I'm backing off from the claim that the line that registers directly with justvoip is giving me MOCS problems. In severals days' testing, I've so far never gotten MOCS on that line. Rather, every time I call using line 1 (voxalot registration with justvoip as VSP) and get MOCS, if I immediately call back the same number using line 2 (direct registration with justvoip), the MOCS problem disappears. I'll do a further update to this post if I ever do get MOCS on line 2. But so far, in renewed testing, that has not happened.

I should add that I never have anything like the MOCS problem with incoming calls. So far as I can tell, I'm always able to hear callers making incoming calls and they can hear me as well. Hence the "outbound" part of the title I've created for this problem.

James

If you call from the Justvoip windows softphone, do you still get the problem?
It does sound like an ATA / network set-up isuue.

Is your ATA operating behind a router ?
Are you using the Voxaot STUN server (stun.voxalot.com:3478) ?

Thanks for your response, kurun. Unfortunately, I don't have any Windows on which I can run the justvoip softphone: I've striven to be Windows-free for a few years now, and have largely succeeded. Do you happen to know if/how that softphone functions under WINE? I could try that, if it actually runs under WINE.

And yes, my ATA is behind a router. Should've mentioned that when I described my setup. So that does add another possible point of failure. I tried at some point to fiddle with QoS settings, but did not comprehend very well what to do there. I do have the option of putting the ATA in the DMZ, which seems like it could affect things if I'm having router issues. I actually switched my STUN server to stun.justvoip.com. But I do believe that, at some point, I had it set to the voxalot STUN server.

Any recommendations based on this further description?

James

I can't get the justvoip softphone to function properly under WINE, so I couldn't try that. I tried using the Linphone softphone, which generally works for me. But it wasn't registering properly for some reason. So I went back to experimenting with the second line on my ATA--which, as mentioned above, is configured to register directly with justvoip, not going through voxalot.

Here are some initial results. Called a number using the second line and it terminated normally: I could hear the other party fine, and they could hear me fine. I asked if I could call back immediately and they agreed. I used line 1 for this second call--the line that registers with voxalot and uses justvoip as VSP. I got MOCS on that call: I could hear the other party fine, but they could not hear me. I hung up and called them back immediately again using line 2 (the one with justvoip direct register) and MOCS was not in play: just like the first call I made to them using line 2, I could hear them just fine and they could hear me.

So, it looks in this case like the issue has something to do with the way justvoip and voxalot are interacting, does it not? I'll keep experimenting to see whether, every time I get MOCS on line 1 (voxalot with justvoip as VSP), the issue goes away when I use line 2 (direct registration with justvoip, not going through voxalot). As I recall I did, in the past, have the MOCS issue on line 2 as well. But I'll have to try this all anew to confirm that.

Thanks,
James

Maybe you want to take a look in this topic. I experience that but very rarely. Sometimes the line is total silence, simetimes the audio is just one way. On some other ocasions I can't hear the ring tones, but it goes back to normal once the calee picks up the phone. I don't use an ATA, I use Voxalot and PBXes Callthru.

I am told that the Betamax softphone does not run correctly under Wine, though I have never tried it myself.

I am using the Ekiga softphone under Ubuntu and it seems to work quite well with Betamax accounts. I have tested it with Voipcheap, Intervoip, Actionvoip and Poivy.

I use the Voxalot Stun server to connect behind the firewall.

Are you using different SIP and RTP ports for the 2 accounts on your ATA?

I am also using a couple of Betamax accounts with my Voxalot account registered on a Grandstream ATA, and generally the calls to PSTN numbers go through with no problem.

Since yesterday I've been getting MOCS on line 1 (voxalot registration with justvoip as VSP) every time I call a PSTN number. If I immediately call back that same number using line 2 (direct registration with justvoip), the MOCS problem goes away. I don't think I've ever had MOCS persist for so lengthy an interval.

And yes, I do have different SIP ports configured for these two accounts--5060 and 5061. I do not see any option in the ATA's web interface to set differing RTP ports, though. I have switched back to the voxalot STUN server, by the way, which has not resolved the MOCS problem.

As I'm now thinking of some analysis I was formulating earlier with regard to this problem, I was previously leaning toward the conclusion that this problem relates to voxalot rather than to my betamax provider. As I'm now recalling, one key factor leading me to lean toward that conclusion was the fact that I sometimes get MOCS when I'm calling another voxalot user: in those cases, there can be no question of poor interaction between voxalot and a VSP, since it all goes through voxalot. We haven't placed such a call for a few weeks since my father-in-law is now visiting us. But during much of the year we call him very regularly, and I've definitely seen the MOCS problem in the past when calling him, and he's seen it when calling me, too (I set up and ATA configured to register his voxalot account on his internet connection).

Thus, the mystery deepens . . .

James

Try setting the second account to Port 5062.
Not sure if this makes a difference with Voxalot.

Also, have you tried using your ATA with a public IP address just to identify if it is an NAT issue?

Unfortunately, I am not familiar with the Sipura 2100 ATA setups.

I haven't tried giving the ATA a public address yet because I'm afraid it might interfere with my dyndns connection to my router. But it's certainly true doing that could be revelatory.

For now, though, I want to continue experimentation with line 2 (the one with direct registration with justvoip). I was recalling--as I posted above--that I sometimes get MOCS on that line, too, but I'm now uncertain about that. I'll keep trying that line each time MOCS occurs on line 1 (voxalot registration with justvoip set as VSP on that line) to see if I can ever get MOCS to occur on line 2. So far it hasn't, but it's only been about a day since I reconstituted that line. Seeing whether my recollection that MOCS sometimes occurs on that line is correct or not could also be revelatory of where the problem lies.

Further updates to come as I continue these tests.

Thanks,
James

Hi.
Each time I got something like this, it was related in a way with NAT/STUN.

I don't know the SPA2100. Do you really need to change the port from 5060 to something else? In the different hardware I got until now, this is the smartness of the device to forward calls to correct line according to phone number (SIP uri).
And each time I tried to play with ports on a "smart" device, I got problems of that kind...

If your main router has SIP ALG feature, you don't even need STUN and won't have NAT problem, except if you change port.
If your main router is not SIP aware, then you need to forward ports (worst case) or use STUN (better).

So, since your JustVoip is playing well, I would suggest to go back with port 5060 and stun.voxalot.com. (And no port forwarding on NAT!)
If it still fails, take a look at options "handle symmetric NAT" and "optimize audio path" in your Voxalot account. (I'm pretty sure that those two options are not concerned, but anyway...)

In renewed testing, so far every time I get MOCS when using line 1 (voxalot registration with justvoip set as VSP), if I immediately call back the same number using line 2 (direct registration with justvoip, not using voxalot as an intermediary), the call terminates normally: I can hear the party I'm calling just fine, and they can hear me. Furthermore, MOCS seems to be happening more frequently on line 1 (voxalot registration with justvoip set as VSP). Today, all calls I tried on line 1 resulted in MOCS: I could hear the party/system I was calling just fine, but they could not hear me. This seems to point to some problem with voxalot or with my voxalot configuration, does it not?

Will continue with testing and posting results.

James

Thanks for your input, which I am considering. Line 1 (voxalot registration with justvoip as VSP) is set to use port 5060. Line 2 (direct justvoip registration) I set to use port 5061. I do currently have stun.voxalot.com:3478 set as my STUN server. My router (wrt54g flashed with dd-wrt) is not SIP-aware--at least not the firmware version I currently have on it. Anyway, in addition to having the STUN server set on my ATA, I also set port forwarding on my router: it currently forwards port 5060, 5061, 5082, 4569, and 3478 to the ATA. Still thinking . . .

James

Since the router is not SIP aware, you have two possibilities:
- using STUN without port forwarding (direct call from outside not possible)
- using port forwarding (5060 + audio stream dynamic ports) without STUN

If you mix port forwarding and STUN, you'll have troubles... (Even if sometimes it works fine, it is not reliable and can behave differently from call to call).
I would first test with only STUN, removing all forwarding rules from NAT.
You can also use the STUN from JustVoip with Voxalot account, I already got some compatibility issues with the one from Voxalot in the past.

If STUN still fails, this is probably because of your NAT which is badly implemented or is symmetric. But since your JustVoip account works fine, I don't think so.

As far as forwarded ports....also add the RTP range that your ATA uses...in Linksys models you can find this under the SIP Tab I believe...
(The range in my PAP2 and SPA3102 was 16384-16482)

One other thing to try:
In VoXalot:
-Under Member page set Symmetric NAT to No,
Under provider settings (for JustVoip):
-Set Optimize Audio to Yes
-Set your codecs to:
ulaw;alaw;g726;g729;ilbc;gsm

Reboot your ATA after making those changes...

I still get MOCS on line 1 (voxalot registration with justvoip set as VSP), even with port forwarding turned off but the STUN server still set.
I get MOCS on line 1 with this setup, too. Whether the STUN server is set or not (with port forwarding activated), the problem persists.
I tried changing the STUN server back to justvoip and I still get MOCS on line 1.
That's the confusing part: why does line 2 (direct registration with justvoip, not using voxalot as an intermediary) seem to work fine every time (no MOCS), while line 1 has those problems? In fact, every call I've tried to make over the last 2 days on line 1 has resulted in the MOCS problem. Hmmm . . .

I took the radical step of upgrading my router's firmware, thinking that might influence the issue, but it seems to be having no effect. I still get MOCS with each call I try to make using line 1.

I also wondered whether it might have to do with the fact that line 2 is registering my justvoip account, so that account somehow becomes dysfunctional when I'm trying to use it via voxalot. But if that were the case, I don't see why I'd be able to use it at all, i.e., why I could even make an outgoing call (being able to hear the party I'm dialing, while they can't hear me). Strange.

Then, there's one of the main reasons I even bothered to set up line 2 to register directly with justvoip: I was, in part, trying to eliminate the FUP exceeded charges I was seeing on my justvoip account. Setting up line 2 like that and using it to make calls to the PSTN does seem to have resolved the extraneous FUP exceeded charges, by the way. And I should also mention, if I haven't already, that I sometimes get MOCS when calling another voxalot user (i.e., not using any VSP), and he sometimes gets MOCS when calling me (again, no VSP involved). That indicates the problem lies with voxalot or with the way my/his hardware (different hardware, btw) is/is not interacting with the voxalot servers.

I still don't see where the problem lies here. But I intend to keep testing and searching for a solution.

James

Thanks for your input, emoci. I checked my router and that range of ports has been forwarded all along--I didn't need to change anything there.

I tried these settings and rebooted the ATA. Optimize audio was already set to "yes." Even with the settings at the values you recommend and a reboot, I still get MOCS on line 1 (registration with voxalot, justvoip set as VSP): I can hear the party I'm calling perfectly well, but they can't hear me (or detect keystrokes if I'm dialing an automated system that expects me to enter numbers).

I'm open to further suggestions--including the possibility that I'm doing something very basic wrong. I don't claim to possess a thorough understanding of VOIP.

James

The last thing I could recommend to test is another modem-router, the most basic you can find around, without port forwarding and with STUN on your ATA.

What you described looks so much to NAT/STUN issues that I would insist on testing around this point. Why? Because the problem occurs on incoming audio stream, exactly what STUN/NAT is involved in... And exactly the kind of issue I've been used to see most of time.

Just one more thing: ensure that both ends have same codecs activated! At least one common, I would suggest alaw(g711a)/ulaw(g711u).
For example: if your device has only g729 activated and your callee has other codec(s) activated but not g729, I think you could get the same result.

While testing, since it also appears from Voxalot to Voxalot, I would continue testing without VSP since it brings some more complexities, thus potential concurrent issues.

Good luck...

I needed to do some further experimentation today owing to a MOCS-like problem: for the first time ever since I've set this up and have been using voxalot, I got mute caller syndrome on an incoming call. That is to say, someone called me and I could hear them speaking, but they could not hear me. This has never happened on an incoming call before to my knowledge. So now I have, not only MOCS, but MICS (mute incoming call syndrome).

I decided it was time to get drastic with my set-up. So I put the ATA in front of the router. Now it--not the router--has the public IP. So my router and the rest of my network is now on a subnet established by the ATA.

The good news is that dyndns seems to work ok on my router, despite the fact that it doesn't have a public IP. The bad news is that this does not resolve the MOCS problem: after I put the ATA in front of the router, i.e., such that it gets the public IP and establishes a private subnet for my router and network (now located behind it) every call I've tried to make using line 1, I get MOCS. Again, line 1 is set to register with voxalot, using a betamax reseller as VSP.

And just as has happened without fail since I've started this new round of testing--regardless of whether the ATA is in front of or behind the router--every call I've made using line 2 has worked pretty much flawlessly: I can hear the party I'm calling just fine, and they can hear me. Again, line 2 registers directly with the betamax reseller, not using voxalot as intermediary.

So, what in the world could be going on here? I think that, by putting the ATA in front of the router, such that it has the public IP, I've effectively eliminated the possibility of NAT issues--have I not? Could it be some kind of weird hardware issue? I suppose that if I switched the configuration of line 1 to be like line 2 and vice versa I might learn something about that.

But anyway, up until today, I believe every incoming call on line 1 (voxalot registration, betamax reseller as VSP) worked normally with respect to the MICS problem: I could always hear the party who was calling me, and they could hear me. But today I got MICS on line 1: I could hear the person calling me, but they could not hear me. And again, every time I've made an outgoing call using line 2 (direct registration with my betamax reseller, with no voxalot intermediary) it worked pretty much flawlessly: I could hear the party I was calling just fine, and they could hear me--and that's regardless of whether the ATA or the router had the public IP.

Further troubleshooting suggestions will be appreciated.

Thanks,
James

PS I just (after having put the ATA in front of the router) received an incoming call on line 1 which worked fine, i.e., there was no MICS issue with this call, unlike the calls that came earlier today.

Yesterday I called my VOIP-friend and get MOCS. Call was Voxalot -> Voxalot.
Next call to him was thru FreeCall (Betamax) provider. Voxalot -> Freecall 883510004xxxxxx -> Voxalot. Call was disconnected after 30 sec.
I try one more time thru Actio provider. Voxalot -> Actio -> Actio. The call connected and we talked 50 minutes.

Is it Voxalot issue?


I would suggest:
1. Try without registration on line 2 with justvoip.
2.1. Try with Sipsorcery or PBXes instead of Voxalot. Justvoip as provider in Sipsorcery/PBXes. Line 2 with direct registration with justvoip.
2.2. Try with Sipsorcery or PBXes instead of Voxalot. Justvoip as provider in Sipsorcery/PBXes. Line 2 without registration with justvoip.
3.1 Try with Sipsorcery or PBXes. Voxalot as provider in Sipsorcery/PBXes and justvoip as provider in Voxalot. Line 2 with direct registration with justvoip.
3.2 Try with Sipsorcery or PBXes. Voxalot as provider in Sipsorcery/PBXes and justvoip as provider in Voxalot. Line 2 without registration with justvoip.

Thanks,
Józef

Yeah, I've gotten MOCS with voxalot to voxalot calls as well. Happened to me just a couple weeks ago. The fellow whom I was trying to reach also sometiomes gets MOCS when he calls me, too.

Here's another wierd thing to add into the mix. I sometimes have the MOCS problem on toll-free calls as well, but it seems to happen with far less frequency when I dialing tool-free numbers. In fact, I just placed a successful toll-free call on line 1 (voxalot registration with betamax reseller as VSP--though the VSP doesn't come into play on toll-free calls): it all worked fine. Immediately afterward, I tried a call on line 1 to a PSTN number and got MOCS.

The ATA is still in front of the router, btw, i.e., it has the public IP and my router is behind it on a subnet established by the ATA. Don't see how this could be a NAT issue for that reason.

James