in tm readme there is this kind of example regarding use of t_relay_cancel:
if (method == CANCEL) { if (!t_relay_cancel()) { # implicit drop if relaying was successful, # nothing to do
# corresponding INVITE transaction found but error occurred sl_reply("500", "Internal Server Error"); drop; } # bad luck, corresponding INVITE transaction is missing, # do the same as for INVITEs }
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?
-- juha
On Oct 07, 2010 at 13:52, Juha Heinanen jh@tutpro.com wrote:
in tm readme there is this kind of example regarding use of t_relay_cancel:
if (method == CANCEL) { if (!t_relay_cancel()) { # implicit drop if relaying was successful, # nothing to do
# corresponding INVITE transaction found but error occurred sl_reply("500", "Internal Server Error"); drop;} # bad luck, corresponding INVITE transaction is missing, # do the same as for INVITEs }
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
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?
-- juha
On Oct 07, 2010 at 15:52, Juha Heinanen jh@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 :-)
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.
Andrei
On Thu, Oct 7, 2010 at 9:16 AM, Andrei Pelinescu-Onciul andrei@iptel.org wrote:
On Oct 07, 2010 at 15:52, Juha Heinanen jh@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
Juha,
On Thu, Oct 7, 2010 at 8:52 AM, Juha Heinanen jh@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?
Maybe for reliability reasons? If something goes wrong with your proxy and it looses the state for a transaction, the proxy might just forward the request statelessly and hope for the best. I know there are many cases where this would not work (serial forking, etc.) in real world setups, but I guess we have just been trying to be as forgiving as possible in such cases.
-Jan
-
Andrei Pelinescu-Onciul -
Jan Janak -
Juha Heinanen