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? Thank you in advance, Bill
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Thank you jiri,
I totally agree, but I have a question that occured to me now and I cant find answer:
If Kamailio receives a CANCEL from a UAC after kamailio has responded with a 200 to the corresponding INVITE, what does t_relay_cancel() do in the following 2 cases:
1. CANCEL received before the ACK from UAC. This is legal from the side of the UAC, since the UAC may have sent the CANCEL before it receives the 200 to the INVITE that kamailio sent.
2. CANCEL received after the ACK . This is illegal, but anyway, kamailio must do something. I can't find in the RFC if it should respond 200 to the CANCEL and drop it, or 481(Call/Transaction Does Not Exist). Although 481 seems more resonable, 16.10 section of RFC says: "... If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request.". It does not discriminate if the corresponding INVITE has been 200ed or not. Any insights?
In the spirit of what you wrote in your reply, could I configure it somehow, to take initiative and translate the CANCEL to a BYE downstream, no matter whether CANCEL is received before or after the ACK?
Bill
On Fri, May 3, 2013 at 12:26 PM, Jiri Kuthan jiri@iptel.org wrote:
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.10http://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@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Bill,
plain-kamailio cannot send BYEs (not sure if some module can). The point is the proxy is sort of "passive element" and doesn't initiate transactions on its own.
Why isn't it enough to have the BYEs sent by UAC? I mean sometimes there can be some confusing situations (say forking downstream) and it is eventually the UAC that's in the best position to know what to BYE or CANCEL.
The point is this all seems a UAS business to me, for which a proxy can only do some approximiations risking it will be wrong. Like in the case 2, you may not even notice the ACK is already on its way (because you didn't record-route)... Getting control of this would really mean using the dialog module and running in B2BUA mode rather than proxy.
-jiri
On 5/3/13 11:59 AM, Vassilis Radis wrote:
Thank you jiri,
I totally agree, but I have a question that occured to me now and I cant find answer:
If Kamailio receives a CANCEL from a UAC after kamailio has responded with a 200 to the corresponding INVITE, what does t_relay_cancel() do in the following 2 cases:
- CANCEL received before the ACK from UAC. This is legal from the side of the UAC, since the UAC may have sent the CANCEL before it receives the 200 to the
INVITE that kamailio sent. 2. CANCEL received after the ACK . This is illegal, but anyway, kamailio must do something. I can't find in the RFC if it should respond 200 to the CANCEL and drop it, or 481(Call/Transaction Does Not Exist). Although 481 seems more resonable, 16.10 section of RFC says: "... If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request.". It does not discriminate if the corresponding INVITE has been 200ed or not. Any insights?
In the spirit of what you wrote in your reply, could I configure it somehow, to take initiative and translate the CANCEL to a BYE downstream, no matter whether CANCEL is received before or after the ACK?
Bill
On Fri, May 3, 2013 at 12:26 PM, Jiri Kuthan <jiri@iptel.org mailto:jiri@iptel.org> wrote:
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 <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@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
Yes, I used the term proxy to include statefullness and dialog awareness, which makes me think: What is the point of being transaction-aware without being dialog-aware? I am trying to find a use for it, but I cant.
On Fri, May 3, 2013 at 3:34 PM, Jiri Kuthan jiri@iptel.org wrote:
Hi Bill,
plain-kamailio cannot send BYEs (not sure if some module can). The point is the proxy is sort of "passive element" and doesn't initiate transactions on its own.
Why isn't it enough to have the BYEs sent by UAC? I mean sometimes there can be some confusing situations (say forking downstream) and it is eventually the UAC that's in the best position to know what to BYE or CANCEL.
The point is this all seems a UAS business to me, for which a proxy can only do some approximiations risking it will be wrong. Like in the case 2, you may not even notice the ACK is already on its way (because you didn't record-route)... Getting control of this would really mean using the dialog module and running in B2BUA mode rather than proxy.
-jiri
On 5/3/13 11:59 AM, Vassilis Radis wrote:
Thank you jiri,
I totally agree, but I have a question that occured to me now and I cant find answer:
If Kamailio receives a CANCEL from a UAC after kamailio has responded with a 200 to the corresponding INVITE, what does t_relay_cancel() do in the following 2 cases:
- CANCEL received before the ACK from UAC. This is legal from the side
of the UAC, since the UAC may have sent the CANCEL before it receives the 200 to the INVITE that kamailio sent. 2. CANCEL received after the ACK . This is illegal, but anyway, kamailio must do something. I can't find in the RFC if it should respond 200 to the CANCEL and drop it, or 481(Call/Transaction Does Not Exist). Although 481 seems more resonable, 16.10 section of RFC says: "... If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request.". It does not discriminate if the corresponding INVITE has been 200ed or not. Any insights?
In the spirit of what you wrote in your reply, could I configure it somehow, to take initiative and translate the CANCEL to a BYE downstream, no matter whether CANCEL is received before or after the ACK?
Bill
On Fri, May 3, 2013 at 12:26 PM, Jiri Kuthan <jiri@iptel.org mailto: jiri@iptel.org> wrote:
On 5/3/13 11:04 AM, Vassilis Radis wrote: Hello all, In the documentation of the t_relay_cancel() (TM module) there isan example that reads:
if (method == CANCEL) { if (!t_relay_cancel()) { # implicit drop if relaying wassuccessful, # 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, becausein RFC(http://tools.ietf.org/__**html/rfc3261#section-16.10http://tools.ietf.org/__html/rfc3261#section-16.10
<http://tools.ietf.org/html/**rfc3261#section-16.10<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. ItMUST*statelessly*
forward the CANCEL request (it may have statelessly forwarded the associated request previously). So aren't we supposed to immediately statelessly forward theCANCEL 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 wassuccessful,
# 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-usersmailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-** router.org sr-users@lists.sip-router.org> http://lists.sip-router.org/__**cgi-bin/mailman/listinfo/sr-__** users http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users< http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 05/03/2013 08:59 AM, Vassilis Radis wrote:
What is the point of being transaction-aware without being dialog-aware? I am trying to find a use for it, but I cant.
Lots of uses! Retransmission dampening, serial forking (branches), and many more.
-- Alex
On 5/3/13 2:59 PM, Vassilis Radis wrote:
Yes, I used the term proxy to include statefullness and dialog awareness, which makes me think: What is the point of being transaction-aware without being dialog-aware? I am trying to find a use for it, but I cant.
Things are simpler: restartig transaction-stateful causes less harm than restarting dialog-stateful, unless you care of replication/failover/etc.... You will also achieve better performance with transactions than with dialogs & transactions. That's a non-academic aspect especially for public services like iptel.org -- unsolicited traffic hits as first memory limitations and therefore you better use memory conservatively.
-jiri
On 03.05.2013 11:59, Vassilis Radis wrote:
Thank you jiri,
I totally agree, but I have a question that occured to me now and I cant find answer:
If Kamailio receives a CANCEL from a UAC after kamailio has responded with a 200 to the corresponding INVITE, what does t_relay_cancel() do in the following 2 cases:
Actually I do not know how t_relay_cancel() behaves in your scenarios, but: If a proxy receives a CANCEL for a transaction which was already replied with a final response, it doesn't matter how the CANCEL is processed.
The proxy forwards the final INVITE-response to the UAC, and the UAC has an established dialog (regardless if the UAC already sent a CANCEL, BYE or whatever). Also the response code of the CANCEL is irrelevant - the dialog is established and the UAC has to handle it.
regards Klaus
-
Alex Balashov -
Jiri Kuthan -
Klaus Darilion -
Vassilis Radis