> > > > If anyone is really into solving this rare scenario, one possible > > solution is to wait a bit longer after the CANCEL, for example 64*T1 + > > T4. > > > > Unfortunately, this does not really solve the problem. Suppose we > have more than one proxy in a chain, each with this timer of 64T1+T4. > We end up having a problem still (since the first proxy's timer pops, > then the second, etc). It seems to me that we should set a timer for > 64T1 that causes a 408 to be forwarded back, and tear down the > transaction later (maybe another 64T1 later). This way, we can ACK > the responses that might come in as a result of timers popping > downstream. >
What I meant was that if the retransmission timer is 64*T1 and the cancel timer is a bit larger (e.g., 64*T1 + T4) then this case would be resolved because the retransmission would occur before the cancel, giving enough time for a 408 to propagate. It's possible I missed something, but I think the difference between the 2 suggestions is the cancel timer 64*T1+T4 vs 2*64*T1. > Alternately, we could just ACK all stray responses. ACKing stray responses is something that could have some issues: * Not all error responses have contact headers and in that case it's impossible to know the destination. * Contact headers may be different than the original request URI which may cause the ACK of an error response to go through a different path. * A source of possible DoS attack (?) Gilad. _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
