[Serusers] SER Nokia CANCEL Problem
Bogdan Pintea
pintea at iptego.de
Tue Feb 20 12:04:09 CET 2007
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
More information about the sr-users
mailing list