[OpenSER-Devel] question on t_relay on CANCEL

[Dan Pascu]

On Friday 08 February 2008, Juha Heinanen wrote:
> Dan Pascu writes:
>  > Not necessarily. You may have parallel forking and get multiple 180.
>  > Until you get a 200 OK, no dialog is really established.
>
> from section 12.1 of rfc3261:
>
>   Within this specification, only 2xx and 101-199 responses with a To
> tag, where the request was INVITE, will establish a dialog. A dialog
> established by a non-final response to a request is in the ÈearlyÉ
> state and it is called an early dialog.

Which means it is not really established. We can play with words as much 
as you like, but conceptually speaking the call is not yet established.

>
> thus, a single 180, for example, does establish a dialog, which is in
> early state.  looks like this creates confusion to UA implementers, who
> consider cancel after 180 as an in-dialog message and accordingly, add
> route header to it based on received r-r.
>
> i don't have experience on what would happen when such an UA receives
> 180 from more than one destination, i.e., would it send more cancels.

Since it's hop by hop it should only send one to the same entity it has 
sent the invite to.

>
>  > I've even seen devices
>  > that send a CANCEL after a 200 OK, but before the ACK, as they
>  > consider that the dialog is not established until confirmed by the
>  > ACK. Which makes sense because is cleaner to cancel a call setup
>  > with a CANCEL before it is confirmed, than to send an ACK and then a
>  > BYE (for example if I do not want to accept the session because the
>  > 200 OK contains something I do not agree on or is badly formatted,
>  > then I don't want to confirm the session with an ACK and then close
>  > it with a BYE).
>
> many things would make sense, but they are not conforming to rfc3261.

You misinterpreted what I said. I was not speaking about the in dialog 
versus out of dialog cancels here. If the rfc claims that after a 1xx you 
cannot use cancels anymore but have to use an ack and then a bye to end 
the session, then the rfc is grossly in error and should be reviewed soon 
(though I doubt that it says such a thing). Not even the receiving of a 
200 OK means that the call was setup. I need to acknowledge it (and I may 
choose not to for many reasons).


-- 
Dan