3 May
2013
3 May
'13
12:26 p.m.
On 5/3/13 11:04 AM, Vassilis Radis wrote:
Hello all,
In the documentation of the t_relay_cancel() (TM module) there is an example that reads:
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
}
What bothers me is the phrase#do the same as or INVITEs, because in
RFC(http://tools.ietf.org/html/rfc3261#section-16.10 ) it says:
If a response context is not found, the element does not have any
knowledge of the request to apply the CANCEL to. It MUST*statelessly*
forward the CANCEL request (it may have statelessly forwarded the
associated request previously).
So aren't we supposed to immediately statelessly forward the CANCEL if
t_relay_cancel() did not find the INVITE transaction, instead of doing the same as
INVITEs, which could be t_relay() (not stateless)?. Like below:
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,
forward();
}
Am I correct or am i missing something?
It could be even more standardized this way indeed. Aparts
from standards, measured by common sense I cannot realize
that either way would break something. The CANCEL should
not be appearing there at all. Perhaps it would make a difference
when SER is restarted and one after it went alive again,
UAC sent a CANCEL. Then what you suggest would perform better.
If you want to make sure you have captured this case, also make
sure that branch ids are configured to be produced statelessly.
Otherwise SER-proxied CANCEL won't match the previous INVITE anyhow.
other than that, SER is much better than RFC3261. Its
registrar is stateless (in departure from the RFC, otherwise
it would be more vulnerable to DoS attacks), INVITE transaction
is hold after a 200 passes through (otherwise it would not
absorb retransmissions, create another transaction and
cause interop issues), and probably more.
I just wanted to say it is really important to look first
at what interop issues one may have or not, as SER the
way it is is likely to produce better interop than
consequent standard compliance. In most cases you
can achieve it by configuration changes, I just think
you don't want to :)
-jiri
Thank you in advance,
Bill
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users