[OpenSER-Devel] Possible bug in the tm module in the presence of packet loss/branches

Klaus Darilion klaus.mailinglists at pernau.at
Fri Mar 7 10:35:33 CET 2008



Maxim Sobolev schrieb:
> Klaus Darilion wrote:
>>
>>
>> Dan Pascu schrieb:
>>> On Thursday 06 March 2008, Maxim Sobolev wrote:
>>>> The issue at hand has lead me to discovering the problem, which is hard
>>>> to observe, but the problem itself IMHO is important one and by no
>>>> means non-existing in the real world. As I said in the other message,
>>>> I've seen this issue many times before in normal conditions, but
>>>> attributed it to some kind of CPE failure. This could also happen not
>>>> only due to network problems but due to UDP packets loss when server is
>>>> loaded. Run "netstat -su" on the any more or less loaded Linux server
>>>> running OpenSER and see how many UDP packets are getting dropped every
>>>> second ("packet receive errors" item).
>>>
>>> Udp:
>>>     219469376 packets received
>>>     154 packets to unknown port received.
>>>     16936 packet receive errors
>>>     261877247 packets sent
>>>
>>> This is from a box which is loaded close to the limit of the number 
>>> of users a single box can handle. Yet the packet loss is only 
>>> 0.0077%, which is insignificant and can be dealt with by the 
>>> retransmission mechanism.
>>>
>>> My issue with what you're proposing is that it tries to modify the 
>>> SIP callflow to something no specified in the RFC, to solve a non-SIP 
>>> problem. I also do not like the idea that the proxy would keep 
>>> retransmitting on a branch after the originator has canceled the call.
>>
>> If you really want to solve this I think the proper approach is using 
>> PRACK.
> 
> Klaus,
> 
> PRACK has nothing to do with it. It is for reliable delivery of non-100 
> provisional replies (i.e. 180, 183 etc). For 100 reliable delivery 
> relies on INVITE retransmits.

Ok. You are right. But usually with SIP clients there is usually a non 
100 provisional response immediately after the 100, which would be 
retransmitted in case of PRACK

klaus



More information about the Devel mailing list