Calls dropping after 30 seconds

[Kamen]

Both RTP and RTCP should be packaged over UDP (but go out two different ports, usually successive). You need to make sure that those packets can not only traverse the NAT firewall going out but coming back in or X-Lite will assume that your call was disconnected. You are using a fairly uncommon configuration and it will be difficult to get help.
It is not reasonable to expect a SIP endpoint to have the ability to ignore the lack of RTCP acknowledgements because otherwise there would be a lot of stuck, never-ending calls. Although I do understand the frustration of those who are having trouble for a valid reason (e.g., outside of their control) and wish there was at least a mechanism in X-Lite where you could keep the call alive manually.
Kamen

[Derek Jacobs]

Hi Kamen

There is a setting available in X-Lite 3 under options advanced, network.
The issue is only with the BETA where that setting has not yet been exposed.


Derek

[Kamen]

Thanks again, Derek. Then it must be something else when I was having the "32-second-disconnect" problem because I had that setting off in X-Lite 3.0. It definitely was an inactivity thing because the issue was that I had two clients on different machines registering with the same credentials (and, consequently, the server sending acknowledgements to the wrong PC). Ultimately, there have to be acknowledgements - at both endpoints (client and server) - or calls would never get disconnected when a connection is lost.
Kamen

[Derek Jacobs]

You are all OK now though correct?
Or are you still seeing the problem?

[Kamen]

Oh, yes, that problem is gone. It was a stupid mistake from my part - it's a little confusing to be registered with the same account from two different computers and expect the server to know to which account to send the acknowledgements back (although it knew to send the RTP traffic to the proper client). With proper registration, from any client (including Bria) - whether it's behind a VPN or a direct connection - I don't get regularly disconnected. I know this all could be improved a lot but the standard is vague - when you have to deal with all sorts of servers and clients on the other side, you can only rely on the standard, and when that is not clear enough...
Right now the only disconnections I am experiencing is when I first establish a connection, sometimes as I start my video (or the other client starts their video) it will freeze and then say "Could not start video" and drop the connection. After a couple of retries, though, it usually starts working. The bandwidth configuration is a little confusing in X-Lite - it's hard to make it use less bandwidth. I recently had a connection with someone whose video looked very pixelated (over the entire call, which lasted over an hour) and even though we tried adjusting the network connection speed, it would not change from the 512 kbps (most of which for video). But don't let me hijack this thread!
Kamen

[andres.moya]

"You are using a fairly uncommon configuration and it will be difficult to get help."
Sorry, what is unusual in proxying voice for passing NAT correctly? If i am not proxying then there will be no traffic at all, and then drop after 30 secons of silence will be reasonable. But i can talk all this 30 seconds!

[Kamen]

You should address this question to the people who issued RFC 3261 and the entire SIP suite, and to those who developed RTPproxy (this all assuming you have configured the proxy the best way it could be configured). And, frankly, proxying is not the best way to handle real-time traffic, anyway.
Kamen

[andres.moya]

well. let me know if i am doing something wrong.
i have serious problems with NATed clients. Many people have routers, who doing NAT on application level. It mean they open your INVITE, Change all addresses inside from private to router address. Cool, then clients trying to establish connection direct, router now somehow have firewall to protect against media stream. I can not say client, oh sorry you should change router, maybe another will work. I read internet many routers have broken SIP ALG. I agree, it is a job for routers to pass media correctly, proxy is not best solution.
Well anyway, XLite receive in body of invite address where to send a stream. Xlite do so fine. And call is going fine. Question is why it drops?
Is it possible somehow to drop media stream? It is UDP. So it cant say reset or fin.... will monitor traffic carefully. Maybe my rtpproxy actually drops few seconds before... Lets say close UDP socket and send ICMP port not reachable? but how XLite can see it behind NAT? will try more.

[bsimmons21]

I get dropped calls after 30 seconds on xlite beta when I call into a conference bridge on both a windows adn a mac machine. appeasr to be a rtcp issue within the xlite beta client is this being worked on?

[rdubuque]

I am using the 3.0 version and have unchecked the SIP keep alive and still have the same problem. I am using phone.com and am running XP and use Charter as my ISP. W0ould really like to see this work.

If this is not possible, can you recommend another softphone?

[Derek Jacobs]

Have you checked a Wireshark trace to see exactly WHY you are dropping calls?

[newton10471]

So, is the call-dropping problem with Snow Leopard resolved in Bria 2.5 for Mac OS X?

[jwburley]

Re the posts about the contacts not working in Win 7. Just set the program icon to run in xp mode and it works perfectly. Better in fact than eyebeam which has a memory leak and freezes up.

[goodgod]

Thanks for your tutorial and remember me it is an beta version on a Operating system is not supported.
But my biggest Pb, actually, is not X lie anymore, it is Wire shark which doesn't want to start.

[JdeP]

Hey guys, forget the geek speak.. this is what did it for me.. give it a try.

http://www.comprendo.co.uk/wordpress/co ... 0-seconds/

I paid for the Eyebeam software which is the 'Suckers Own X-lite' give or take a few rudimentary rather small bells and whistles.

I had been buggering about with this Mickey Mouse software for days over the issue of calls dropping after 30 secs. Forget sip_alg and telnetting, that has absolutely no effect whatsover. In fact after making the changes recommended in the link above, I switched the facility back on on after reading up on the function (Wikipedia) of sip_alg, and on the premise that if a Draytek designer decided it was a necessary function that was good enough for me. Enabling sip_alg had the same effect as disabling it before, nothing whatsover.

Anyway I have finally got this thing working now.
Despite my somewhat disparaging comments above about call dropping (now seemingly sorted) it (Eyebeam v1.5.20.1) does run rather well in Win 7 Ultimate.