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
On Fri, Sep 18, 2009 at 5:08 PM, Juha Heinanen jh@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.
On Sep 18, 2009 at 23:36, Jan Janak jan@ryngle.com wrote:
On Fri, Sep 18, 2009 at 5:08 PM, Juha Heinanen jh@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?
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
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.
On Sep 19, 2009 at 15:55, I?aki Baz Castillo ibc@aliax.net wrote:
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.
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)
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
El Lunes, 21 de Septiembre de 2009, Andrei Pelinescu-Onciul escribió:
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).
Yes, that's the case of how a "wrong" 6XX from a UAS breaks a so common feature as voicemail.
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)?
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.
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.
On Sep 21, 2009 at 21:34, I?aki Baz Castillo ibc@aliax.net wrote: [...]
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?
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 :-)).
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.
Andrei
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
On Sep 18, 2009 at 18:08, Juha Heinanen jh@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
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
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
-
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
Jan Janak -
jh＠tutpro.com