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

[Anatoly Pidruchny]

Dan Pascu wrote:
> On Thursday 13 March 2008, Alex Hermann wrote:
>   
>>> I was expressing more of an idea for an alternate approach, out of
>>> the RFC specs, because as it is the RFC seems to not be able to cover
>>> this case. What I meant, is that if the CANCEL is sent after a 200
>>> OK, but before the ACK, it should mean that the call is no longer
>>> desired (it was canceled already).
>>>       
>> The INVITE can't be cancelled anymore because the transaction is
>> deleted in the UAS after sending the 200 OK (and it is not allowed to
>> send more than 1 final response), so there is no way to indicate that
>> the INVITE is cancelled.
>>     
>
> With the current RFC specs, yes. But if the CANCEL would be allowed to be 
> sent until the dialog is confirmed by the ACK, then the UAS would be 
> required to keep the transaction around until ACK-ed and could process 
> this case.
>   

The INVITE transaction IS kept around in the UAS until ACK is received. 
But yes, the dialog is created when 200 OK is sent.
>> If you looking for way to extend/change the SIP rfc's, why not allow a
>> BYE instead of the ACK, or introduce a NACK request to get the wanted
>> behaviour?
>>     
>
> I'm sure there is more than one way to do this. The NACK sounds the 
> simplest and least disruptive of all the ideas mentioned so far.
>   

The NACK may work, but it would be a very big and fundamental RFC 
change. And it would be very disruptive, because it is not compatible 
with the current RFC.

How about my proposal to stop resending INVITE and start resending 
CANCEL in a proxy if a provisional response is not received? May be I am 
wrong, but I think it can help and it is really a minor change in RFC 
that in fact preserves compatibility.

>>> Of course as it is now, any device that is RFC conformant will ignore
>>> that CANCEL, but if this callflow would be a valid one, devices could
>>> cope with scenarios like the ones discussed in this thread.
>>>       
>> What happens (in practice) if you send a BYE instead of the ACK?
>>     
>
> I don't know, but a BYE sounds too much like the sessions is already 
> established and needs to be closed.
>   

BYE is another transaction. BYE in this situation may, just may, work 
for some implementations. But, for example, it will not be pretty for 
proxies that work on transaction level. Terminating the dialog with BYE 
does not mean that the INVITE transaction will be canceled.

Regards,
Anatoly.