[OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Mar 10 13:28:17 CET 2008
From the "sip-implementors" list - looks like Maxim is right.
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
More information about the Devel
mailing list