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

[Bogdan-Andrei Iancu]

Hi Maxim,

I have to agree (and to push the discussion in this direction, again) 
that from network loss point of view, the problem can be interpreted in 
several ways and debated with many arguments (pro and against).

Also the common sense differs from person to person :). As said, for me, 
it says that if CANCEL is received, the proxy should not follow any 
attempt to forward the call.

Anyhow, common sense and personal opinions should go on the second plan 
- Firstly we need to discover is the RFC3261 really enforce or advice in 
this matter. I did some diggings in the RFC, but nothing useful so far, 
so I agree with Klaus approach in pushing the question on the 
"sip-implementers" list - there are people with much better 
understanding on the RFC and they may spear us from having parallel 
debated....

Thanks and regards,
Bogdan

Maxim Sobolev wrote:
> Bogdan-Andrei Iancu wrote:
>> Hi Maxim,
>>
>> You stated:
>>
>> <quote>
>> The correct behavior of the tm module in this case would be to 
>> continue with INVITE re-transmits until we get provisional response 
>> and immediate CANCEL once that response comes in.
>> </quote>
>>
>> Is this based on RFC indication or a personal opinion? If RFC based, 
>> could you please point me out the relevant section?
>>
>> I'm asking mainly because, following my own logic, I would rather say 
>> that once the transaction is cancelled on UAS side, no further 
>> attempts (read retransmissions) should be done on UAC side.
>
> Bogdan,
>
> It's based on common sense. 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 
> 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.
>
> Regards,