3cx Soft Phone without Tunnel

[craigreilly]

Anybody know what could be so significant in the setup of 3cx SoftPhone ?

I can use it successfully at a remote location - but getting a handset to work is ridiculous.

The remote phone registers fine and can make and take calls. I have two way audio going - but any calls I make from the remote extension (Yealink T22) dies after 32 seconds - every time. The local side realizes this and terminates the call as well. If the remote side hangs up before the call dies - the local side doesn't know about it until the 32 second mark. This is when I am in TCP transport.

When I change to UDP Transport the call lasts longer than 32 seconds but can only make outbound calls. Inbound calls do not work - the remote phone rings and the person answers but the local side shows still calling.

I know everyone has put in their two cents on this for me before - but there has to be a key factor missing as the soft phone works all the time.

 

[leejor]

It may have something to do with how the set is registering (IP and port). STUN issue? Compare a registration of the 3CX phone with that of the Yealink, in the 3CX log.

Have you confirmed the issue at more than one (remote) location? Does the set perform properly if allowed to pick up a public IP, as opposed to being behind a router?

 

[craigreilly]

So far my testing is limited to a 2nd public ip connected to a router in the same building. This way I can have 2 phones side by side for testing.

I have not tried using a public ip as this will not be available at the remote end. The user is a road warrior with a home office on DSL.

What would I look for in the logs? I have verbose logs on at the moment so probably a good time to find it. The SoftPhone does have an option to set Local SIP Port to Any and the phone needs a specific port. I did try 0 but no go.

btw: the iPhone works same as SoftPhone...

EDIT: 8:27am 6/1/12
I am attaching a PDF file that shows 3 side by side calls. 2 are Softphones (3cx and Zopier for Mac) and 1 is the Yealink T22.
The primary difference I see is that when calling the softphones, the log shows:

08:20:26.521 [CM503025]: Call(990): Calling Ext:Ext.5955@[Dev:sip:[email protected]:61004;transport=UDP;rinstance=00bb0b73a1eded5a]

however, the Desk Phone shows:

08:09:36.410 [CM503025]: Call(977): Calling Ext:Ext.5954@[Dev:sip:[email protected]:1024]

The softphones use ext 5955 and the deskphone 5954. Both set up:
PBX Delivers Audio: OFF
Supports Re-Invite: ON
Support Replaces Hesder: ON

 

[craigreilly]

update posted.

 

[leejor]

When i have some time later today, i'll look over the zip file.

My first "guess' is that it has something to do with the port number that the device is registering with and that 3CX is trying to contact it on. Most SIP devices tend to have ports assigned in the 5060+ range. You have to be sure that remote sets behind a common router don't use the same ports number, nor one that is conflicting with other devices on the network. You might also have a router that is doing some port translations, which might cause some issues.

What it comes down to, and you can confirm this in the logs, when a set first registers, there will be a public IP (in this case) and a port number. Any message that 3CX then sends out to that set need to be able to get through using that information. If it is incorrect, changes, or is blocked/misdirected, then that set will not get the message.

 

[craigreilly]

Deskphone: Extension 5954 is registered, contact: sip:[email protected]:5162
Softphone: Extension 5955 is registered, contact: sip:[email protected]:58494; rinstance=317a41a0807f7a2d; transport=UDP

Remote right now is using a Netgear WNR2000 but it could be anything as these are Road Warriors with a home office and DSL or Cable service from the local providers.

Thanks for looking at this for me. Much appreciated.

I just tried an Aastra 6753 off a Packet8 install - it works as expected - except after about 10 minutes, if the local side calls it - it doesn't respond... Like registration expired. There is no keep alive on those phones. So make a call on remote end. Now local end can call it for another 10 minutes.

There is a registration renewal timer that I am playing with. I had it at 5 minutes and 3 minutes. Either way it loses connectivity. It can make outbound calls - but no inbound.
There is also an LLDP interval...

 

[leejor]

From the looks of this, it may be your "remote" router. To confirm, you could try testing the set at another location, or find an old router sitting around doing nothing.
http://forum1.netgear.com/showthread.php?t=68171

 

[craigreilly]

I have read that post about Netgear and did indeed turn the feature off as suggested.
I set up an Aastra 6753 from an old Packet 8 install and it worked in both directions but after about 5 minutes callers could not reach the external phone - until they made an outbound call. Then it would work again for about 5 minutes. I found the Keep-Alive feature in 3cx which talks about VOIP Connections - but turned it on anyway. It seems to be working. After the entire weekend, I can still call the external extension and it rings as expected.

 

[lneblett]

Craig- I will have a similar setup to work on come tomorrow. Will let you know how it goes.

 

[craigreilly]

I see Yealink UK is releasing a new T2x firmware and they mention Keep Alives and a STUN Issue.
Maybe that has been my problem. I am anxiously awaiting its release.

I am taking an Aastra home tonight to test it on my router at home to get a range of device support ironed out.

Thanks for checking in.

 

[lneblett]

Craig -

I did not spend a whole lot of time on it, but here is what I saw. T22 at remote location behind netgear wnr1000 v2 router. Server 600 miles away behind Dlink router. V2009p at other remote location behind Dlink router of same model as at server location. Both remote locations use dynamic IP from different cable providers. Server location using shared t1 for the remote, but outbound calls are using gxw4108 with PSTN lines.

V2009p location was able to register and make calls with no issue, no tunnel and without Stun.it could not have been any easier.

The t22 site was a different story. Used same exact setting as v2009 location. No joy. Forwarded ports directly to phone, no joy. Tried stun, no joy. Could never even see registration attempts or other inklings that any data was making it thru. Unlike you, I was able to use sip proxy. Was then able to register and make a call from the server side to the remote, but remote side would not pass rtp packets back to server side if it originated call until I turned on PBX provides audio. From this point on, no problems. Calls made successfully in any direction and of any duration. I tried numerous settings within netgear router to include sip alg on/off. I had remote control of netgear.

We will be swapping out the netgear with a Dlink to see if router really is at issue or if perhaps cable provider blocking ports. We even called cable provider and they assured us that no ports were blocked.

I have used the netgear business class routers with no issue, so am a little surprised at how a Dlink consumer router seemingly performs so much better than one of its netgear peers. I guess I will know more once we try the swap to Dlink. the remotes are at homes so getting a higher class/cost device is not really an option.

 

[craigreilly]

Strange the different results we all get. I was happy to get the Aastra working and sent them to their new homes. We'll know more when the users plug them in...
Waiting for the t2x firmware update and keeping fingers crossed.

 

[lneblett]

I scoured the Netgear forums last night after I posted. There were a number of issues for VoIP and SIP and after sifting through it all, it appeared that one of the main "proposed" solutions was to establish the Phone or ATA as the DMZ device and port forward to it. I say "proposed" as I did not really see anyone come back and indicate success or failure, so am uncertain, but being the DMZ with most fireall protection down, I suppose this could be a workaround.

At the time of the post, the Netgear folks talked about how the WNR1000 was obsolete and that it was unlikely that any new firmware releases would be forthcoming. The also indicated that the WNR2000 (your model) might have similar issues, but because it was still current that some firmware mods would more than likley be made.

This may explain some of the differences between our findings. You might try the DMZ suggestion. My client went ahead and bought the Dlink as they did not want to mess around any longer and are convinced that because the one at the server side works so well, there is no reason to think that the remote side won't also work.

I will be working the Dlink later today. Will let you know.

 

[craigreilly]

The testing was done with the Netgear - but because the home worker could have anything - I didn't want to have to mess with DMZ, etc. So I was happy to get the Aastra working.
Now, I am installing the t22 firmware v 7.61.23.11 now on the UK Website... Maybe I'll see some different results...

New Firmware Test: Phone registered right away as usual. And, calls made to it can now be picked up. I am not sure if I learned something setting up the Aastra or the firmware actually did have a bug fixed or feature added. But I have no special router rules set up on the remote end and it is working 8|