Re: [SR-Users] Wrong handling CANCEL message
2010/5/4 Alex Hermann a...@speakup.nl: On Friday 30 April 2010 13:25:13 Iñaki Baz Castillo wrote: Yes, I agree. In fact draft invfix solves it by adding a new state Accepted so when a 200 is sent the server transaction remains in memory for a while (to absorbe INVITE retransmissions). But anyway the transaction is in Accepted state, and not in Proceeding, so a CANCEL should have no effect and the proxy shouldn't reply 200 for the CANCEL as the proxy has canceled *nothing*. The response to the CANCEL doesn't indicate if anything has been canceled (just that the CANCEL is well received), the response to the INVITE does. Answering 200 OK to the CANCEL is the least interuptive response as it won't trigger an error in the UAC. A 481 might trigger that the call is aborted as the UAC might think the dialog is invalid. If the 200 OK is received by the UAC, it should handle it just like the well known INVITE + 200 OK / CANCEL race for which it should send a BYE if the dialog is to be ended. Interesting point of view. Maybe it's just easier as you describe. -- Iñaki Baz Castillo i...@aliax.net ___ 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
Re: [SR-Users] Wrong handling CANCEL message
On Monday 03 May 2010, Iñaki Baz Castillo wrote: We just drop them. In the sr configuration i think there is also a similar method implemented (etc/sip-router.cfg, route[CATCH_CANCEL]). In the past on our systems we've tried to forward them stateless, but this created some loop conditions, if i remember correctly. Sending a final response to the CANCEL (e.g. 491) also not worked out really well. Hi Henning, the problem is that the transaction still remains in memory for a while after the 200 has been routed (this is correct according to invfix draft which covers a bug in RFC 3261). So the CANCEL after the 200 *does* match the transaction in TM and then kamailio replies 200 for the CANCEL (which doesn't make sense as there is nothing to cancel). After the proxy relays the 200 for the INVITE the transaction gets in Accepted state (draft invfix) for a while. During this state a CANCEL would match the transaction but it shouldn't generate a 200 for such CANCEL (it's better to ignore it or reply 481). Hi Iñaki, ah, i thought you refer here to the general handling of CANCEL messages. Now it makes more sense for me, thanks for the clarification. Cheers, Henning ___ 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
Re: [SR-Users] Wrong handling CANCEL message
On Friday 30 April 2010 13:25:13 Iñaki Baz Castillo wrote: Yes, I agree. In fact draft invfix solves it by adding a new state Accepted so when a 200 is sent the server transaction remains in memory for a while (to absorbe INVITE retransmissions). But anyway the transaction is in Accepted state, and not in Proceeding, so a CANCEL should have no effect and the proxy shouldn't reply 200 for the CANCEL as the proxy has canceled *nothing*. The response to the CANCEL doesn't indicate if anything has been canceled (just that the CANCEL is well received), the response to the INVITE does. Answering 200 OK to the CANCEL is the least interuptive response as it won't trigger an error in the UAC. A 481 might trigger that the call is aborted as the UAC might think the dialog is invalid. If the 200 OK is received by the UAC, it should handle it just like the well known INVITE + 200 OK / CANCEL race for which it should send a BYE if the dialog is to be ended. -- Alex Hermann ___ 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
Re: [SR-Users] Wrong handling CANCEL message
On Friday 30 April 2010, Iñaki Baz Castillo wrote:
[..]
Not exactly, sorry, the proxy should forward the CANCEL stateless:
16.10 CANCEL Processing
[...]
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).
Hi Iñaki,
ok, but i think in the default server configuration we don't do it this way:
if (is_method(CANCEL))
{
if (t_check_trans())
t_relay();
exit;
}
We just drop them. In the sr configuration i think there is also a similar
method implemented (etc/sip-router.cfg, route[CATCH_CANCEL]). In the past on
our systems we've tried to forward them stateless, but this created some loop
conditions, if i remember correctly. Sending a final response to the CANCEL
(e.g. 491) also not worked out really well.
Henning
___
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
Re: [SR-Users] Wrong handling CANCEL message
2010/5/3 Henning Westerholt henning.westerh...@1und1.de:
16.10 CANCEL Processing
[...]
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).
Hi Iñaki,
ok, but i think in the default server configuration we don't do it this way:
if (is_method(CANCEL))
{
if (t_check_trans())
t_relay();
exit;
}
We just drop them. In the sr configuration i think there is also a similar
method implemented (etc/sip-router.cfg, route[CATCH_CANCEL]). In the past on
our systems we've tried to forward them stateless, but this created some loop
conditions, if i remember correctly. Sending a final response to the CANCEL
(e.g. 491) also not worked out really well.
Hi Henning, the problem is that the transaction still remains in
memory for a while after the 200 has been routed (this is correct
according to invfix draft which covers a bug in RFC 3261). So the
CANCEL after the 200 *does* match the transaction in TM and then
kamailio replies 200 for the CANCEL (which doesn't make sense as there
is nothing to cancel).
After the proxy relays the 200 for the INVITE the transaction gets in
Accepted state (draft invfix) for a while. During this state a
CANCEL would match the transaction but it shouldn't generate a 200 for
such CANCEL (it's better to ignore it or reply 481).
Regards.
PS: I've open a thread in sip-implementors about this topic.
--
Iñaki Baz Castillo
i...@aliax.net
___
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
Re: [SR-Users] Wrong handling CANCEL message
Am 30.04.2010 11:37, schrieb Iñaki Baz Castillo: 2010/4/30 Klaus Darilionklaus.mailingli...@pernau.at: 200 OK seems correct as long as the transaction is still in memory. http://tools.ietf.org/html/rfc3261#section-9.2 I don't agree. As per RFC 3261 when a proxy receives a 200 for an INVITE the transaction is terminated so a CANCEL after the 200 should not match such transaction. Then the proxy should reply 481 to the CANCEL rather than a 200. If the transaction for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on whether it has already sent a final response for the original request. This means that the transaction may still exists although the 200 OK was already sent (to absorb retransmissions) Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response. So 200 OK is fine. If it makes sense is a different point. regards klaus ___ 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
Re: [SR-Users] Wrong handling CANCEL message
2010/4/30 Klaus Darilion klaus.mailingli...@pernau.at: I don't agree. As per RFC 3261 when a proxy receives a 200 for an INVITE the transaction is terminated so a CANCEL after the 200 should not match such transaction. Then the proxy should reply 481 to the CANCEL rather than a 200. If the transaction for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on whether it has already sent a final response for the original request. This means that the transaction may still exists although the 200 OK was already sent (to absorb retransmissions) No, in RFC 3261 a INVTE transaction ends after a 200 is received, there is no state to absorbe retransmissions. In draft invfix the transaction is not inmediately removed upon receipt of a 200, instead it gets into a new Accepted state which allows absorbing ***INVITE*** retransmissions. But anyway, if the INVITE has been replied with a 200 it makes no sense at all to send a CANCEL so the proxy shouldn't reply 200 to the CANCEL, but a 481. Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response. So 200 OK is fine. If it makes sense is a different point. Again, RFC 3261 states that the transaction MUST be terminated when the 200 arrives so the CANCEL after it shouldn't match the transaction. In case of draft invfix, IMHO it has a bug in the specification (still a draft) since it says nothing aobut the CANCEL. It doesn't make sense that a proxy or UAS replies 200 to a CANCEL if the proxy or UAS already sent a 200 for the INVITE. draft invfix: http://tools.ietf.org/html/draft-ietf-sipcore-invfix-01 -- Iñaki Baz Castillo i...@aliax.net ___ 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
Re: [SR-Users] Wrong handling CANCEL message
2010/4/30 Iñaki Baz Castillo i...@aliax.net: But anyway, if the INVITE has been replied with a 200 it makes no sense at all to send a CANCEL so the proxy shouldn't reply 200 to the CANCEL, but a 481. Not exactly, sorry, the proxy should forward the CANCEL stateless: 16.10 CANCEL Processing [...] 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). -- Iñaki Baz Castillo i...@aliax.net ___ 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
Re: [SR-Users] Wrong handling CANCEL message
Iñaki Baz Castillo wrote: 2010/4/30 Klaus Darilion klaus.mailingli...@pernau.at: 200 OK seems correct as long as the transaction is still in memory. http://tools.ietf.org/html/rfc3261#section-9.2 I don't agree. As per RFC 3261 when a proxy receives a 200 for an INVITE the transaction is terminated so a CANCEL after the 200 should not match such transaction. That's a bug in the RFC and we shall not better projects RFC bugs in implementations :) A well behaving proxy shall keep the context for some period of time. Then the proxy should reply 481 to the CANCEL rather than a 200. well, once the transaction is gone, forwarding the CANCEL statelessly would seem a legitimiate behaviour, as long as the proxy is in position to produce branch ID consistently with that for INVITE. -jiri ___ 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
Re: [SR-Users] Wrong handling CANCEL message
2010/4/30 Jiri Kuthan j...@iptel.org: I don't agree. As per RFC 3261 when a proxy receives a 200 for an INVITE the transaction is terminated so a CANCEL after the 200 should not match such transaction. That's a bug in the RFC and we shall not better projects RFC bugs in implementations :) A well behaving proxy shall keep the context for some period of time. Yes, I agree. In fact draft invfix solves it by adding a new state Accepted so when a 200 is sent the server transaction remains in memory for a while (to absorbe INVITE retransmissions). But anyway the transaction is in Accepted state, and not in Proceeding, so a CANCEL should have no effect and the proxy shouldn't reply 200 for the CANCEL as the proxy has canceled *nothing*. Then the proxy should reply 481 to the CANCEL rather than a 200. well, once the transaction is gone, forwarding the CANCEL statelessly would seem a legitimiate behaviour, as long as the proxy is in position to produce branch ID consistently with that for INVITE. Yes, in fact this is the behavior RFC 3261: 16.10 CANCEL Processing [...] 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). But again, what does response context is not found?: - In RFC 3261 it means that the transaction server is terminated as per RFC 3261 it is ended when a 200 arrives and is forwarded (immediately). - But in draft invfix the transaction remains in Accepted state upon receipt of a 200 (to absorbe INVITE retransmissions). So the section 16.10 should be rewriten as: If a response context in state Proceeding is not found, the element does not have any knowledge of the request to apply the CANCEL to. Regards. -- Iñaki Baz Castillo i...@aliax.net ___ 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
