[SR-Users] t_relay_cancel usage

[Jan Janak]

On Thu, Oct 7, 2010 at 9:16 AM, Andrei Pelinescu-Onciul
<andrei at iptel.org> wrote:
> On Oct 07, 2010 at 15:52, Juha Heinanen <jh at tutpro.com> wrote:
>> Andrei Pelinescu-Onciul writes:
>>
>> > > if proxy is processing all invites statefully, why anything needs to be
>> > > done when invite transaction corresponding the to cancel is missing?
>> > > isn't it a case of unmatched cancel and the cancel could just be
>> > > dropped?
>> >
>> > Well, IMHO it should be forwarded the same as one would forward the
>> > INVITE. Dropping it is quite a hardliner approach :-)
>>
>> andrei,
>>
>> i would challenge invite, but can't do that for cancel.  what is the
>> advantage of becoming an open unmatched cancel relay?
>
> www_authenticate() will return "authenticated" for ACK, CANCEL and
> PRACK. So unless you are using something different it would be difficult
> to challenge the CANCEL :-)

A bit more detail: It is impossible to challenge ACK or CANCEL because
one cannot increase their CSeq. The CSeq of CANCEL and ACK must match
the original INVITE transaction.

> It's possible to have a miss-routed CANCEL and in general I'm for a more
> relaxed approach: let CANCELs or ACKs that we don't know anything about
> pass through.
> Of course there are exception, like if the CANCEL is for some internal
>  gateway or something similar, but in general I would let them pass.

Yes, I agree.

-Jan