voip drops calls at 30-32 seconds, but only toll-free numbers

[wistlo]

My Android phone has started dropping VoipO outbound calls at 30-32 seconds.

Only calls to toll free numbers are dropping. I have a conference call application that offers both toll and toll free numbers. The toll number now drops at 30-32 seconds. The toll number works normally.

I tried this with various time and information service numbers listed at the following URL, and the behavior is the same: toll free drop at 30 or 32 seconds, toll numbers do not drop.

http://www.blindhog.net/phone-direct...scom/#comments

I had CSipSimple installed, removed that and got the same results with the native Android VOIP client. This problem was first observed this morning, around 07:00 Central.

My VoipO-supplied and configured Linksys ATA for the same VoipO account does not have this problem, only my Android BYOD device. Also, the problem does not appear when using wireless 3G connection, just when I use my wireline ISP (Cox). Problem does not appear when using BYOD device's native wireless (cellular) outbound calling mode.



My BYOD set up is Android 2.3.7, Cyanogenmod 7-20120420-NIGHTLY-Liberty, HTC LIberty (Aria)

[racerdude]

Had the exact same problem today with my BYOD line, TF calls dropping after 30 seconds. Opened a ticket with support and had calls re-routed for specific TF numbers I use daily, but any other TF numbers still have this problem. If you are able to look in you logs you will see that all TF calls routed through 207.223.64.xxx have the problem. This is a new route I have not seen before today, but clearly there is something wrong with this route.

It would be nice if they could take this route out for all TF calls until it is fixed, but the only thing you can do is ask that your specific TF numbers be re-routed due to this problem.

Good luck.

[wistlo]

Are these logs on your local BYOD device, or on VOIPO somewhere? I am using CSipSimple, not obvious to me where or if logs are collected. I use CSipSimple because the nuilt-in stock Android VOIPo client has inferior voice quality.

[racerdude]

This is with my home BYOD device, in my router logs I can see the RTP (media server) port being being used and the IP of the server. This issue is still happening today for TF numbers I didn't request to have support re-route. The interesting thing is that I tested this today by changing my dial plan to route TF calls through a free TF provider instead of Voipo and coincidentally they are also using this 207.223.64.xxx media server but I don't have the 30 second disconnect problem. That seems to indicate it's something on Voipo's side with this particular route.

I don't know if you can see the port details on your Android device, but it sounds to me that you're having the exact same problem I experienced. The only thing you can do at this point is open a support ticket and list the TF numbers you call and ask them to be re-routed.

Anyone from Voipo here (Tim you out there?) that can comment on this issue?

[VOIPoTim]

I would be willing to bet this is a NAT issue that could be resolved with port forwarding. Dropping at a set time like that almost always is.

I think this is reinforced by what the original poster is saying in that his VOIPo configured device doesn't have the issue likely because the NAT handling is configured differently. Outside of port forwarding, you could also try enabling STUN in your device which can help with NAT issues. All of our SIP servers run STUN on them so you can use the same server you register to as the STUN server.

Different carriers that we use handle audio differently so you could have NAT related issues with calls that route through one but not another.

Another option is to contact support and have us to "proxy" your audio which means we try to force it to go through our servers as a middleman.

[racerdude]

While this could be some sort of NAT issue, I am already port forwarding the RTP ports to my device so that would not be the cause. In the 1.5 years I have had this BYOD setup I've never run into NAT related problems before with any of my calls. I also have a second provider on my device and have not had any NAT problems with that line either. And it's also strange that using a different provider to route the TF calls through with the exact same media server works fine.

Tim can you test this on your side by calling a TF number and seeing it route through this particular carrier (207.223.64.xxx) using the sip-west01.voipwelcome.com proxy? If it works fine on your side then I would agree that it's most likely something with my setup, but I would be curious to know if you can reproduce the problem.

[atoliy]

same issue, i am running asterisk 1.6. toll free call to 1-800-999-3355 gets dropped after 30 seconds. no issues on any other calls. looking at logs seems some kind of reinvite issue.. any suggestions on sip.conf configuration for voipo would be appreciated. I am not behind NAT

[atoliy]

here is the log - seems like an invite to 207.223.64.238 but its not handled correctly by asterisk.. adter a couple of these i get BYE packet

<--- SIP read from UDP:67.228.182.2:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 209.141.60.170:5060;branch=z9hG4bK68e82078;rport=5 060
Record-Route: <sip:199.96.248.140;lr=on>
Record-Route: <sip:67.228.182.4;lr=on;ftag=as7ad374a3;did=eed.df 0edbc2>
Record-Route: <sip:67.228.182.2;lr=on;ftag=as7ad374a3>
From: <sip:[MY NUMBER]@67.228.182.2>;tag=as7ad374a3
To: <sip:18009993355@sip.voipwelcome.com>;tag=4KZ3y302 QB8cQ
Call-ID: 5bd2cbb16e7ca39a26fe37f702223775@209.141.60.170
CSeq: 103 INVITE
Contact: <sip:18009993355@67.228.182.4:5060;transport=udp >
User-Agent: AlcazarSBC 1.10
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 228

v=0
o=Sonus_UAC 22892 27655 IN IP4 207.223.64.238
s=SIP Media Capabilities
c=IN IP4 207.223.64.133
t=0 0
m=audio 12176 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=maxptime:20


here is the good bye packet

<--- SIP read from UDP:67.228.182.2:5060 --->
BYE sip:2015417796@209.141.60.170 SIP/2.0
Record-Route: <sip:67.228.182.2;lr=on;ftag=cccgpH48H6QZD>
Record-Route: <sip:67.228.182.4;lr=on;ftag=cccgpH48H6QZD>
Via: SIP/2.0/UDP 67.228.182.2;branch=z9hG4bK5b84.8f30e3b3.0
Via: SIP/2.0/UDP 67.228.182.4;rport=5060;branch=z9hG4bK5b84.97c9725 2.0
Via: SIP/2.0/UDP 199.96.248.140;rport=5060;branch=z9hG4bK5b84.7c1b4 212.0
Via: SIP/2.0/UDP 10.1.50.24:5004;rport=5004;branch=z9hG4bK8ZNg97XQ8 pSZm
Max-Forwards: 67
From: <sip:my number@67.228.182.2>;tag=cccgpH48H6QZD
To: <sip:my number@67.228.182.2>;tag=as2ede53d4
Call-ID: 188a230d02f16aa922f2a83c3e415221@209.141.60.170
CSeq: 28145080 BYE
Contact: <sip:18009993355@67.228.182.4:5060;transport=udp >
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, NOTIFY
Reason: SIP;cause=408;text="ACK Timeout"
Content-Length: 0
P-Asserted-Identity: <sip:MY Number@67.228.182.2>

[VOIPoTim]

We're not able to replicate this issue with any of the devices we provide.

The commonality seems that all of you reporting it are using Asterisk or some form of BYOD.

[christcorp]

FYI. I have the same problem; ONLY on my android (BYOD). Not a major issue. I tried calling my bank (1-800) and it dropped the call after about 30 seconds. I called 1-505-xxx-xxxx and it worked fine. I found this for quite a few numbers. Unfortunately, some numbers only have a 1-800/888/866 and not a local in state number.

I tried using "Stun" in my settings with Sipdroid, but then my sipdroid (BYOD android) voipo line wouldn't register. Didn't matter if I used voipo or a public stun address. Any stun and my android wouldn't register. Me personally, I don't call a lot of toll free. But it would be nice. Part of the reason for putting sipdroid on my android was so I could use the voipo and not have to have a bigger cell minutes plan. Not a big deal, just inconvenient. I just use cell for calling toll free and mobile to mobile, and use voipo/android for other calls. mike....