[OpenSER-Devel] question on t_relay on CANCEL

[Bogdan-Andrei Iancu]

Hi Juha,

In stateful mode, having Route header in cancel make no sense (as the 
transaction takes care to route it as the invite).

But we need to take into consideration that not all proxies on the way 
are stateful, and we might have also stateless server which cannot map 
the CANCEL over INVITE in order to send it to the same destination.
In this case, the routing logic of a stateless server MUST route CANCELs 
exactly the same as INVITEs (even if they do it independent, with no 
relation between). So, in order to do so, the CANCEL needs to care all 
the routing information tht were also available for INVITE - if the 
INVITE had ROUTE, CANCEL must also have.

Regards,
Bogdan

Juha Heinanen wrote:
> Bogdan-Andrei Iancu writes:
>
>  > CANCEL is only hop by hop (according to RFC 3261), so Route has no 
>  > sense. If present, it will be ignore as the RFC clearly states that 
>  > CANCEL must be sent to the same destination, with same VIA and RURI, as 
>  > the INVITE it cancels.
>
> this is what i think too, but i didn't find rfc 3261 very explicit about
> route header(s) in CANCEL.  9.1 says:
>
>   If the request being cancelled contains a Route header field, the CANCEL
>   request MUST include that Route header field's values.
>
> it does not say what should happen if invite doesn't include (pre-loaded)
> route header, but, for example, 180 received by UAC had Record-Route
> headers.
>
> also, i haven't found in rfc 3261 a clear statement if CANCEL sent after
> 180, for example, is considered an in-dialog request or an initial
> request.  at that point the dialog has been established already.
>
> anyway, this question resulted when i saw that a Cisco UA to included in
> CANCEL a Route header based on R-R header it received in 180.  it is
> good if openser ignores such Route headers when it processes a CANCEL
> that cancels an existing transaction.
>
> -- juha
>
>
>
>