[asterisk-users] SIP Disconnects from Network - Asterisk Does not hangup
Olle E. Johansson
oej at edvina.net
Sun Feb 28 04:25:13 CST 2010
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
More information about the asterisk-users
mailing list