[Devel] Re: TM failure route bug

[Bogdan-Andrei Iancu]

Hi Juha,

the cancel doesn't match because there is no INVITE transaction yet 
(cancel is processed prior to invite).

To be honest I like your idea bout dealing with these cases - but there 
is a drawback: you cannot make distinction between CANCELs which does 
not match because it;s broken or because the CANCEL haven't arrived yet.

I was thinking to another approach (suggested by Klaus) - when creating 
the INVITE transaction, see if there is an already created CANCEL 
transaction for it (this search is easy since both are on the same 
hash). If so, stop the INVITE and reply with 487.
By doing so, you can distinguish between broken cancels and cancels 
without invite.

regards,
bogdan


Juha Heinanen wrote:

>Klaus Darilion writes:
>
> > Bogdan-Andrei Iancu wrote:
>
> > >    1) a fast CANCEL happens and the CANCEL is processed by the proxy 
> > > prior to INVITE. So, no INVITE is matched by CANCEL.
> > >    2) CANCEL is is just forwarded statefully without any other info 
> > > regarding the INVITE
> > >    3) the INVITE is finally processed and, without any knowledge of 
> > > CANCEL, it's statefully forwarded.
>
>when cancel is not matched by any existing transaction, it means that
>cancel arrived earlier than the invite or the invite got lost.  would it
>then make sense to create an (invite) transaction based on the cancel
>and respond with 487 and start waiting for ack?  if matching invite
>arrives when the transaction still exists in the proxy, it would be
>silently discarded.
>
>-- juha
>
>  
>