18 Sep
2009
18 Sep
'09
6:08 p.m.
this is a summary of what i still need in order to be able to use sip
router in production. they are not new issues. all of them have been
mentioned on the mailing list before:
- async t_uac_dlg support and allowing asycn mi commands by mi_rpc
module. i have seen various commits related to thius by andrei, but
if i have understood correctly, at least mi_rpc part is not done yet.
- any test "if (something)" must succeed if something evaluates to
non-zero int or non-empty string.
- this warning needs to go away:
Sep 2 21:00:18 localhost sip-router: WARNING: tm [tm.c:502]: WARNING:
on_sl_reply("stateless_reply"): empty/non existing route
when onreply_route [stateless_reply] exist.
- tm needs to have param
1.3.18. disable_6xx_block (integer)
please correct me if some of the items have already done and i can
remove them from the list.
if these issues are not taken care of, it is likely that i'm not using
sip-router in next version of my sip proxy.
-- juha
19 Sep
19 Sep
12:36 a.m.
On Fri, Sep 18, 2009 at 5:08 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
- tm needs to have param
1.3.18. disable_6xx_block (integer)
I can help you with this one. Do I understand it correctly that this
was implemented in Kamailio and you need to integrated it into the
shared tm module?
Jan.
1:07 a.m.
On Sep 18, 2009 at 23:36, Jan Janak <jan(a)ryngle.com> wrote:
On Fri, Sep 18, 2009 at 5:08 PM, Juha Heinanen
<jh(a)tutpro.com> wrote:
Actually I'm not sure that's needed.
sip-router handles 6xx in the rfc way (cancels all branches on which no
reply was received and stops forking). This should be equivalent to
disable_6xx_block=0.
However one can override it, by simply adding branches in the failure
route (the ideea being that if you add a branch in the failure route,
you know what you're doing an you want forking re-enabled). If I understand
correctly this is mostly equivalent to disable_6xx_block=1, at least for
the voicemail scenario.
Am I correct in assuming that we don't need it, because sr handles this
automatically?
Andrei
- tm needs to have param
1.3.18. disable_6xx_block (integer)
I can help you with this one. Do I understand it correctly that this
was implemented in Kamailio and you need to integrated it into the
shared tm module? 
4:55 p.m.
El Sábado, 19 de Septiembre de 2009, Andrei Pelinescu-Onciul escribió:
However one can override it, by simply adding branches
in the failure
route (the ideea being that if you add a branch in the failure route,
you know what you're doing an you want forking re-enabled). If I understand
correctly this is mostly equivalent to disable_6xx_block=1, at least for
the voicemail scenario.
Am I correct in assuming that we don't need it, because sr handles this
automatically?
You miss the usual case in which there is parallel forking and a "wrong" UAS
replies 603 "Decline" (instead of a better 480 code). The 603 reply makes the
proxy cancelling the parallel branch (still ringing in other branch) and this
is, commonly, an undesirable behaviour.
So IMHO, "disable_6xx_block" as it's implemented in Kamailio TM module
should
also exist in SR as its funcionality is not covered by the current code.
Regards.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
21 Sep
21 Sep
8:28 p.m.
On Sep 19, 2009 at 15:55, I?aki Baz Castillo <ibc(a)aliax.net> wrote:
El S?bado, 19 de Septiembre de 2009, Andrei
Pelinescu-Onciul escribi?:
Juha asked initially for voicemail after 6xx (which should work out of
the box).
Just to clarify:
in the above case SR will send a CANCEL on all the open branches that
have not received a final reply yet. (so the "ringing" should stop on
all of them)
However one can override it, by simply adding
branches in the failure
route (the ideea being that if you add a branch in the failure route,
you know what you're doing an you want forking re-enabled). If I understand
correctly this is mostly equivalent to disable_6xx_block=1, at least for
the voicemail scenario.
Am I correct in assuming that we don't need it, because sr handles this
automatically?
You miss the usual case in which there is parallel forking and a "wrong" UAS
replies 603 "Decline" (instead of a better 480 code). The 603 reply makes the
proxy cancelling the parallel branch (still ringing in other branch) and this
is, commonly, an undesirable behaviour.
So IMHO, "disable_6xx_block" as it's implemented in Kamailio TM module
should
also exist in SR as its funcionality is not covered by the current code.
So what you want is a treat 6xxx like a normal reply config option
(both parallel forking and cancel branches disabled)?
BTW here are other possible differences in reply handling:
- received 503 triggers dns failover. If 503 is the final reply, it's
replaced with a 500. Also if the blst_503 parameter is on (default
off), the source of the 503 reply is blacklisted (using the value
in the Retry-After header if present and the blst_503 def_timeout,
min_timeout and max_timeout parameters).
- if the final reply is 401 or 407, all the www & proxy auth. headers
from all the 401 & 407 replies received on all the branches are
aggregated into the final reply (can be turned off with
aggregate_challenges).
- reply priority (negative reply that wins):
6xx
3xx
4xx
5xx
4xx priority: 401, 407, 415, 420, 484 and then the rest (ascending
order of their number)
With the exception of 4xx, all other replies in the same class, are
sorted according to their number (e.g. 501 wins over 502).
Andrei
10:34 p.m.
El Lunes, 21 de Septiembre de 2009, Andrei Pelinescu-Onciul escribió:
Yes, that's the case of how a "wrong" 6XX from a UAS breaks a so common
feature as voicemail.
Yes. It's needed (IMHO) to "fix" a wrong behaviour of UA's rejecting
calls
with 603 instead of using a more appropriate code as 480 or 403.
You miss the
usual case in which there is parallel forking and a "wrong"
UAS replies 603 "Decline" (instead of a better 480 code). The 603 reply
makes the proxy cancelling the parallel branch (still ringing in other
branch) and this is, commonly, an undesirable behaviour.
Juha asked initially for voicemail after 6xx (which should work out of
the box). Just to clarify:
in the above case SR will send a CANCEL on all the open branches that
have not received a final reply yet. (so the "ringing" should stop on
all of them)
And that's the reason why I ask for a disable_6xx_block parameters as it
exists in original Kamailio's TM module. Some UA's use 603 to reject a call
breaking any parallel forking or serial forking (i.e. voicemail service).
It would be great if disable_6xx_block would be implemented as an optional
flag in t_relay() function.
So IMHO,
"disable_6xx_block" as it's implemented in Kamailio TM module
should also exist in SR as its funcionality is not covered by the current
code.
So what you want is a treat 6xxx like a normal reply config option
(both parallel forking and cancel branches disabled)? BTW here are other possible differences in reply
handling:
- received 503 triggers dns failover. If 503 is the final reply, it's
replaced with a 500. Also if the blst_503 parameter is on (default
off), the source of the 503 reply is blacklisted (using the value
in the Retry-After header if present and the blst_503 def_timeout,
min_timeout and max_timeout parameters).
- if the final reply is 401 or 407, all the www & proxy auth. headers
from all the 401 & 407 replies received on all the branches are
aggregated into the final reply (can be turned off with
aggregate_challenges).
Doesn't SR's TM module implement these features?
- reply priority (negative reply that wins):
6xx
3xx
4xx
5xx
4xx priority: 401, 407, 415, 420, 484 and then the rest (ascending
order of their number)
With the exception of 4xx, all other replies in the same class, are
sorted according to their number (e.g. 501 wins over 502).
I think it's the correct order.
Regards.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
22 Sep
22 Sep
2:11 a.m.
On Sep 21, 2009 at 21:34, I?aki Baz Castillo <ibc(a)aliax.net> wrote:
[...]
It does, what's listed are differences in reply handling from ser 0.9.x.
I don't know what k does, so I listed them just in case someone needs a
different behviour and we need another switch for turning something off
(the default behaviour is rfc conformant, but so is the 6xx handling
:-)).
Andrei
BTW here are other possible differences in reply
handling:
- received 503 triggers dns failover. If 503 is the final reply, it's
replaced with a 500. Also if the blst_503 parameter is on (default
off), the source of the 503 reply is blacklisted (using the value
in the Retry-After header if present and the blst_503 def_timeout,
min_timeout and max_timeout parameters).
- if the final reply is 401 or 407, all the www & proxy auth. headers
from all the 401 & 407 replies received on all the branches are
aggregated into the final reply (can be turned off with
aggregate_challenges).
Doesn't SR's TM module implement these features? - reply priority (negative reply that wins):
6xx
3xx
4xx
5xx
4xx priority: 401, 407, 415, 420, 484 and then the rest (ascending
order of their number)
With the exception of 4xx, all other replies in the same class, are
sorted according to their number (e.g. 501 wins over 502).
I think it's the correct order.
19 Sep
19 Sep
5:04 p.m.
Andrei Pelinescu-Onciul writes:
sip-router handles 6xx in the rfc way (cancels all
branches on which no
reply was received and stops forking). This should be equivalent to
disable_6xx_block=0.
However one can override it, by simply adding branches in the failure
route (the ideea being that if you add a branch in the failure route,
you know what you're doing an you want forking re-enabled). If I understand
correctly this is mostly equivalent to disable_6xx_block=1, at least for
the voicemail scenario.
Am I correct in assuming that we don't need it, because sr handles this
automatically?
see inaki's reply.
-- juha
1:28 a.m.
On Sep 18, 2009 at 18:08, Juha Heinanen <jh(a)tutpro.com> wrote:
this is a summary of what i still need in order to be
able to use sip
router in production. they are not new issues. all of them have been
mentioned on the mailing list before:
- async t_uac_dlg support and allowing asycn mi commands by mi_rpc
module. i have seen various commits related to thius by andrei, but
if i have understood correctly, at least mi_rpc part is not done yet.
Right now, we have tm.t_uac_wait, which should behave like t_uac_dlg
(there are some output differences, but we can have another version with
whatever output format is needed) and it works "async" on xmlrpc.
There is no support for mi_rpc async, but is it really needed? Is there
another async mi command ?(even if it is, it might be easier to re-write
it in terms of rpc then try to make mi_rpc translate also the mi async
callback to rpc).
- any test "if (something)" must succeed if something evaluates to
non-zero int or non-empty string.
We discussed it, long time ago (see
http://lists.sip-router.org/pipermail/sr-dev/2009-April/001578.html).
For testing empty/non empty strings we have $foo=="", $foo!="",
strlen($foo),
strempty($foo).
The problem with if(string) is that we don't have a boolean context in
sr, we have only int and string and
(int)string = 0 if the string cannot be converted to int
(e.g. (int)"a"=0, (int)""=0, (int)"123"=123).
Any change would most likely brake all the other int expressions and
adding boolean now (in the last minute) is not really an option
(especially since this was known long time ago).
The script porting requires changing lines like if($v) with
if (!strempty($v)) or if ($v!="") (I did it for ser).
- this warning needs to go away:
Sep 2 21:00:18 localhost sip-router: WARNING: tm [tm.c:502]: WARNING:
on_sl_reply("stateless_reply"): empty/non existing route
when onreply_route [stateless_reply] exist.
- tm needs to have param
1.3.18. disable_6xx_block (integer)
This might not be needed, see my other email.
Andrei
22 Sep
22 Sep
4:49 p.m.
Andrei Pelinescu-Onciul writes:
Right now, we have tm.t_uac_wait, which should behave
like t_uac_dlg
(there are some output differences, but we can have another version with
whatever output format is needed) and it works "async" on xmlrpc.
There is no support for mi_rpc async, but is it really needed? Is there
another async mi command ?(even if it is, it might be easier to re-write
it in terms of rpc then try to make mi_rpc translate also the mi async
callback to rpc).
andrei,
for me xmlrpc transport is enough for tm.t_uac_wait. i thought to test
it today, but cannot find documentation about its parameters. would it
be possible to add the t_uac_wait to tm README?
-- juha
4:52 p.m.
Juha Heinanen writes:
for me xmlrpc transport is enough for tm.t_uac_wait.
i thought to test
it today, but cannot find documentation about its parameters. would it
be possible to add the t_uac_wait to tm README?
again i'm answering to myself. t_uac_wait parameters are described in
the code:
const char* rpc_t_uac_wait_doc[2] = {
"starts a tm uac and waits for the final reply, using a list of string "
"parameters: method, ruri, dst_uri send_sock, headers (CRLF separated)"
" and body (optional)",
0
};
-- juha
5544
days inactive
5548
days old
10 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
Jan Janak -
jh＠tutpro.com