[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