[Asterisk-Users] Potential call logging problem for commercial systems..

[John Todd]

>At 13:03 14/11/03 -0800, you wrote:
>>>I have been playing around a lot with the CDR today and I may have 
>>>stumbled across a very serious problem, specifically where there 
>>>is billing taking place..
>>>
>>>If a call is placed between 2 phones and the network connection is 
>>>broken from both the phones with out hanging up first the call is 
>>>never logged to the CDR and it seems never termintaed.. It would 
>>>appear that Asterisk relys on recieving the SIP signals to tell it 
>>>that the call has terminated and so if it does not get that data 
>>>it will never release the call, there does not appear to be any 
>>>call progress checking that could terminate the call if the end 
>>>points could no longer be reached..
>>>
>>>This could have a major impact on, not only billing services, but 
>>>also on things like IAX trunks that could sit with an open channel 
>>>forever..
>>>
>>>I may have missed something in the config that would solve this 
>>>problem so if I have please reply and let us know what it is..
>>>
>>>Later..
>>
>>You should set a maximum timeout on any channel you bring up.  This 
>>kills SIP zombies.  It's not optimal, but prevents infinite calls.
>>
>>Alternately, if your RTP data stream is passing through Asterisk 
>>during the call, you could write a short extension to chan_sip 
>>which would look for "imbalanced" traffic or zero traffic.  In 
>>other words, if one side of the conversation kept sending audio 
>>data, but the other side became completely silent, then after a few 
>>minutes (configurable timer?) you could probably assume that the 
>>other side was disconnected.
>
>Boy, there would be a lot of girlfriends really annoyed by their 
>beaus hanging up on them!!

That is why I have a very long .gsm recording of "uh huh.  <silence> 
hm.  <silence>  yes.  <silence> [etc.]"

JT

>>Same thing if both side of the RTP stream were happily sending 
>>data, and suddenly they both stopped; kill the call.
>>
>>See http://bugs.digium.com/bug_view_page.php?bug_id=0000207
>>
>>JT