Module: sip-router Branch: alexh/master Commit: b668c7f441df0c3de4ffcd6e96e6232059591239 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=b668c7f4...
Author: Alex Hermann alex@speakup.nl Committer: Alex Hermann alex@speakup.nl Date: Tue Jul 19 12:27:04 2011 +0200
modules/tm: Make 487 a prioritized reply code too
---
modules/tm/t_reply.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/modules/tm/t_reply.c b/modules/tm/t_reply.c index 4b9c581..8f31688 100644 --- a/modules/tm/t_reply.c +++ b/modules/tm/t_reply.c @@ -998,6 +998,7 @@ inline static short int get_4xx_prio(unsigned char xx) case 15: case 20: case 84: + case 87: return xx; break; }
On Monday 08 August 2011, Alex Hermann wrote:
[..] modules/tm: Make 487 a prioritized reply code too
Hi Alex,
there is this passage in RFC3261, 16.7, bullet 6 "Choosing the best response":
"The proxy SHOULD give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen."
Not sure if I interpret it correctly, but 487 does not affect the resubmission of a request, I think.
Henning
On Monday 08 August 2011, Henning Westerholt wrote:
On Monday 08 August 2011, Alex Hermann wrote:
[..] modules/tm: Make 487 a prioritized reply code too
Hi Alex,
there is this passage in RFC3261, 16.7, bullet 6 "Choosing the best response":
"The proxy SHOULD give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen."
Not sure if I interpret it correctly, but 487 does not affect the resubmission of a request, I think.
You're correct from an rfc point of view. I made this patch because i've seen the 487 loose from an earlier received response, even though the caller cancelled the call and would expect a 487 as repsonse tot the INVITE.
Don't you think that if a caller cancels a call, the response to the INVITE should always be 487, even if there are (higher priority) responses from other branches?
Am 08.08.2011 13:05, schrieb Alex Hermann:
Don't you think that if a caller cancels a call, the response to the INVITE should always be 487, even if there are (higher priority) responses from other branches?
modparam("tm", "failure_reply_mode", 3)
http://www.kamailio.org/docs/modules/3.1.x/modules/tm.html#failure_reply_mod...
klaus
On Monday 08 August 2011, Klaus Darilion wrote:
Am 08.08.2011 13:05, schrieb Alex Hermann:
Don't you think that if a caller cancels a call, the response to the INVITE should always be 487, even if there are (higher priority) responses from other branches?
modparam("tm", "failure_reply_mode", 3)
That parameter is unacceptable in this/my case. In this case the proxy must choose the best response from all branches, even old ones. But if the caller cancelled the request, a 487 must win.
Anyway, i won't push this patch, because it still has other issues. A 404 still wins from the 487... I need to treat 487 special somehow.
Am 08.08.2011 15:10, schrieb Alex Hermann:
On Monday 08 August 2011, Klaus Darilion wrote:
Am 08.08.2011 13:05, schrieb Alex Hermann:
Don't you think that if a caller cancels a call, the response to the INVITE should always be 487, even if there are (higher priority) responses from other branches?
modparam("tm", "failure_reply_mode", 3)
That parameter is unacceptable in this/my case. In this case the proxy must choose the best response from all branches, even old ones. But if the caller cancelled the request, a 487 must win.
If you need a certain behavior I think it would be best to add another failure_reply_mode.
Anyway, I think a client which needs to receive 487 is broken. If the client sent a CANCEL, then it canceled the requests and should not care about the response value (except 200 OK of course which would trigger a BYE request)
regards Klaus
Anyway, i won't push this patch, because it still has other issues. A 404 still wins from the 487... I need to treat 487 special somehow.
2011/8/8 Alex Hermann alex@speakup.nl:
You're correct from an rfc point of view. I made this patch because i've seen the 487 loose from an earlier received response, even though the caller cancelled the call and would expect a 487 as repsonse tot the INVITE.
Don't you think that if a caller cancels a call, the response to the INVITE should always be 487, even if there are (higher priority) responses from other branches?
When a UAC sends a CANCEL and receives 200 (CANCEL) from the proxy, it's done. Of course it must wait (*in background*) for a final reply to the INVITE. This is indeed 487 usually, but anything can occur (even a transaction timeout, so local 408) and it should not affect at all to the UAC (and ever less to the human managing the device).
I don't think that a proxy should give preference to an existing 487 after CANCEL is received. It could, but I see no need for that.
Regards.
-
Alex Hermann -
Henning Westerholt -
Iñaki Baz Castillo -
Klaus Darilion