On Thu, Oct 7, 2010 at 9:16 AM, Andrei Pelinescu-Onciul <and...@iptel.org> wrote: > On Oct 07, 2010 at 15:52, Juha Heinanen <j...@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 _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users