26 feb 2010 kl. 22.02 skrev JT: > Hmmm.... I agree that altering sip.conf with the RTP timeouts are somewhat of > a band-aid to the issue. But in my observations there is one clear indicator > that I am shocked is not used. > > When I have done this test - pulling the network cable on a device during a > call - Asterisk actually reports that the SIP device has become unreachable > within seconds of the device's removal. > > Now one would think, just like a regular phone company, if one device became > unresponsive (unreachable), the call would be automatically dropped. Like > unplugging from a POTS while on a call. > > So why would Asterisk not use the following logic: > Is Device reachable? > Yes - Do nothing > > No - Close all calls bridged to device > > Seems that would solve the issue quickly and cleanly... perhaps with the RTP > timeout being an additional measure of safety > > Is this an issue present in the latest version of Asterisk? My hope was it > was simply an older bug, fixed at some later trunk.
If there's a reason to send SIP messages during the call and they fail, the call WILL be hung up. Reading the 1.4 RTP source code, I don't think we're checking the return codes of the network writes. Now, that can be very tricky. For a call with NAT, we will have to send packets that fail until we receive something from the other end. I am just brainstorming here, but we could have a flag set when we've received RTp packets from the other end and from that moment start reacting on the result codes of the sendto() call. If it's indicating network issues, we could possibly have an option to tear the call down after a certain amount of failures. And no, I can't explain why someone hasn't thought of that. I think it would be a good addition. /O -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
