27 feb 2010 kl. 08.26 skrev Olle E. Johansson:

> 
> 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.

And after a few hours of hacking I know more. If the incoming channel dies, 
there will be no attempts at sending, so we won't have any network issues at 
all. The RTP channel in Asterisk is clocked on incoming media. The RTP timeouts 
we have today is the only solution for normally bridged calls.

The p2p rtp bridge behaves a bit differently and I think I found a bug in it, 
so I will have to investigate that part a bit more.

Now, we could hang up calls based on device status if needed. I have part of 
that code in the peerfailover branch.

/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

Reply via email to