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

[Maxim Sobolev]

Klaus Darilion wrote:
>  From the "sip-implementors" list - looks like Maxim is right.

Thanks, Klaus! Should this behavior be the default one then?

> regards
> klaus
> 
> 
> Robert Sparks schrieb:
>> Part of why it does this is to deal with the case that the first
>> INVITE the proxy sent actually got somewhere, but its response was
>> lost. The retransmission will stimulate a retransmission of the
>> response, letting you move forward to sending the CANCEL from the
>> proxy.
>>
>> RjS
>>
>> On Mar 7, 2008, at 7:06 AM, Bob Penfield wrote:
>>
>>>
>>> The INVITE transaction must still complete independent of the
>>> CANCEL. So the proxy would continue to re-transmit the INVITE. If
>>> the proxy does receive a provisional response, it would then stop 
>>> retransmissions and send the CANCEL down stream. If timer B fired,
>>> it would send a 408 response to the INVITE.
>>>
>>> Note that the proxy should respond to the CANCEL with 200 OK when
>>> it receives it since the INVITE transaction is in progress.
>>>
>>> cheers, (-:bob
>>>
>>> -----Original Message----- From:
>>> sip-implementors-bounces at lists.cs.columbia.edu 
>>> [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf
>>> Of Klaus Darilion Sent: Friday, March 07, 2008 4:11 AM To:
>>> Sip-implementors at lists.cs.columbia.edu Subject: [Sip-implementors]
>>> CANCEL retransmisson question of no provisional response!
>>>
>>> Hi!
>>>
>>> Could someone help me please with this question.
>>>
>>> Scenario: A transaction-stateful proxy forwards the INVITE request.
>>> The proxy does not receive a provisional response, thus starts 
>>> retransmissions. Now, the caller CANCELs the call. How is the proxy
>>>  supposed to handle this? Does the proxy still have to retransmit
>>> the INVITE or can it stop retransmitting the INVITE?
>>>
>>> From logical point of view I would think that the proxy should stop
>>> the retransmissions, but from Figure 5 in RFC 3261 it looks like
>>> the only way to come from "Calling" state to "Terminated" state is
>>> waiting for Timer B fires (as there is no provisional response
>>> yet).
>>>
>>> thanks klaus

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