7 Oct
2010
7 Oct
'10
1:52 p.m.
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
7 Oct
7 Oct
3:46 p.m.
On Oct 07, 2010 at 13:52, Juha Heinanen <jh(a)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
3:52 p.m.
Andrei Pelinescu-Onciul writes:
andrei,
i would challenge invite, but can't do that for cancel. what is the
advantage of becoming an open unmatched cancel relay?
-- juha
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 :-)
4:16 p.m.
On Oct 07, 2010 at 15:52, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
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
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 :-) 
5:06 p.m.
On Thu, Oct 7, 2010 at 9:16 AM, Andrei Pelinescu-Onciul
<andrei(a)iptel.org> wrote:
On Oct 07, 2010 at 15:52, Juha Heinanen
<jh(a)tutpro.com> wrote:
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.
Andrei Pelinescu-Onciul writes:
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 :-) 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 :-) 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
5:04 p.m.
Juha,
On Thu, Oct 7, 2010 at 8:52 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
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
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 :-)
5167
days inactive
5167
days old
5 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Jan Janak -
Juha Heinanen