[Serusers] SER Nokia CANCEL Problem

[Bogdan Pintea]

Hi Jiri,

Jiri Kuthan wrote:
> The other problem (1) is a kind of amplifier in that it enlarges the race condition
> window through lacking reliability of provisional answers.
>   
> So I think that the solution is the same ... put the burden on UAC. It is then
> UAC's responsibility to terminate a too-late-cancelled call (even if "too late"
> is actually caused by reliability issues).
>
>    RFC3261
>    "If the INVITE results in 2xx final response(s)
>    to the INVITE, this means that a UAS accepted the invitation while
>    the CANCEL was in progress.  The UAC MAY continue with the sessions
>    established by any 2xx responses, or MAY terminate them with BYE."
>   

Yeah, you're right, my "there is no way" was too categorical. The callee 
is left at the mercy of the two "MAY"s above, and the existence of 
"ghost calls" would indicate that none of the two is chosen, while not 
really breaking the specs... (it's not like "must either send 2xx or 
bye"). It only takes a responsible caller client to make sure that the 
"tried-to- cancel-but-actually-failed, 
even-though-in-a-successful-manner" dialog gets eventually brought down, 
not let to timeout on callee's side.

I think I even saw this scenario as an attack for capacity starvation on 
PSTN GWs somewhere.

But the 'generic finding' was that the proxy knows what's going on and 
could, theoretically, put a quick end, in a predictable way, to callee's 
lurch, but it can't (as it's just a proxy; maybe yet another, not so 
solid, argument for B2Bs in network's core...).


Bogdan.

> So I guess that the harm is sustainable even though it indeed doesnt look
> too nice.
>   
>> (callee which will, however, time out, eventually, waiting for the ACK).
>>     
>
> How come? UAS keeps retransmitting 200s till ACK comes. The ACK should come
> rather early. It is then UAC's choice to BYE the too-late-cancelled 
> call or not.
>
> -jiri 
>
>   

-- 
Bogdan Pintea

iptego GmbH  -  VoIP Security
http://www.iptego.de