8 Aug
2011
8 Aug
'11
12:11 p.m.
Module: sip-router
Branch: alexh/master
Commit: b668c7f441df0c3de4ffcd6e96e6232059591239
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=b668c7f…
Author: Alex Hermann <alex(a)speakup.nl>
Committer: Alex Hermann <alex(a)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;
}
8 Aug
8 Aug
1:52 p.m.
New subject: git:alexh/master: modules/tm: Make 487 a prioritized reply code too
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
2:05 p.m.
New subject: git:alexh/master: modules/tm: Make 487 a prioritized reply code too
On Monday 08 August 2011, Henning Westerholt wrote:
On Monday 08 August 2011, Alex Hermann wrote:
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?
--
Greetings,
Alex Hermann
[..]
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. 
3:40 p.m.
New subject: git:alexh/master: modules/tm: Make 487 a prioritized reply code too
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_mo…
klaus
4:10 p.m.
New subject: git:alexh/master: modules/tm: Make 487 a prioritized reply code too
On Monday 08 August 2011, Klaus Darilion wrote:
Am 08.08.2011 13:05, schrieb Alex Hermann:
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.
--
Greetings,
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)
6:31 p.m.
New subject: git:alexh/master: modules/tm: Make 487 a prioritized reply code too
Am 08.08.2011 15:10, schrieb Alex Hermann:
On Monday 08 August 2011, Klaus Darilion wrote:
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
Am 08.08.2011 13:05, schrieb Alex Hermann:
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. 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)
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.
9 Aug
9 Aug
1:12 a.m.
New subject: git:alexh/master: modules/tm: Make 487 a prioritized reply code too
2011/8/8 Alex Hermann <alex(a)speakup.nl>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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4856
days inactive
4856
days old
6 comments
4 participants
participants (4)
-
Alex Hermann -
Henning Westerholt -
Iñaki Baz Castillo -
Klaus Darilion