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

[Maxim Sobolev]

Dan Pascu wrote:
> networks with high packet loss issues. Retransmissions deal nicely with 
> occasional packet loss and that's where it should end.

The TCP/IP operates just fine in networks with 5-10% packet loss. Since 
it's the same 3-way handshake method, I see no reason why SIP would not. 
With SIP making inroads into wireless networks, which are by nature much 
more volatile when it comes to delays and packet loss making SIP server 
properly handling such scenarios is crucial.

>> Unless UAC does number of retransmits 
>> specified by the RFC it can never be sure whether absence of
>> provisional reply has been caused by the dead destination or network
>> packet loss issue and the destination is in fact ringing. In the tm
>> module you always assume "dead destination", which is IMHO wrong. In my
>> situation this problem has been aggravated by the magnitude of packet
>> loss, but in general I've seen this issue before once in a while on a
>> network with close to zero packet loss rate.
>>
>> Another bad decision is to generate 487 locally in the presence of
>> unconfirmed active branches. SIP proxy should not do it unless it is
> 
> It's not active anymore. It did timeout after the timer has expired, so it 
> has generated an implicit 408.

No, it's not. According to the RFC, explicit 408 happens after Timer B 
expires, in your case tm module assumes that transaction is dead 
immediately, without waiting for that.

>> prepared to generate BYE if 200 OK comes from any of those branches
>> (i.e. proxy provides some kind of dialog functionality). Again, in the
>> real world, where packets are getting lost from time to time this could
>> lead to 200 OK coming from the branch even if you do stop INVITE
>> retransmitions. You will get yourself in the situation with originating
>> UA already received fake final negative 487 from proxy, while
>> terminating UA having dialog established, so that the only way to "fix"
>> the issue is to send BYE from the proxy to the terminating UA.
> 
> Not true. The dialog is not final until the ACK comes and it'll never come 
> as the originating side has already received a final 487 reply. So a RFC 
> compliant UA on the callee side should discard the dialog itself without 
> any BYE if the ACK is not received after a certain amount of time.

Still, ACK timeout would take 30 seconds to happen. You will possibly 
get a complain from the user about "no audio after picking up" as well 
as a 30-second billing mismatch between your system and remote system in 
the case of call going to some other network.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com