[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