Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

Hello, On 8/23/13 8:33 PM, Steve Davies wrote: On 23 August 2013 19:42, Daniel-Constantin Mierla > wrote: Can you try the new patch attached? I overlooked that the code where to skip sending the reply was in between some #ifdef ... #else ... #endif and I

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 19:42, Daniel-Constantin Mierla wrote: > Can you try the new patch attached? > > I overlooked that the code where to skip sending the reply was in between > some #ifdef ... #else ... #endif and I did it only for the #else branch, > but actually the #ifdef was enabled by compile

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

Can you try the new patch attached? I overlooked that the code where to skip sending the reply was in between some #ifdef ... #else ... #endif and I did it only for the #else branch, but actually the #ifdef was enabled by compile. You have to apply the patch on clean sources. Daniel On 8/23

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

Steve Davies writes: > Trying to find a way to detect the case where t_relay fails but doesn't > call the failure block. daniel did some work on this recently when i brought the issue up regarding dead tcp destinations. it is now possible to set t_on_branch_failure("something"); and if t_relay

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

23 aug 2013 kl. 12:13 skrev Steve Davies : > > > > On 23 August 2013 11:18, Steve Davies wrote: > Here's what I put in RELAY route block: > > $var(rr) = t_relay(); > xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)\n"); > if (!$var(rr)) { > sl

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 14:56, Daniel-Constantin Mierla wrote: > I'll check the logs and most probably have to do some test myself, but > it's going to take a bit. > No prob, I'll come back to it later. Steve ___ SIP Express Router (SER) and Kamailio (Open

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

I'll check the logs and most probably have to do some test myself, but it's going to take a bit. Daniel On 8/23/13 2:50 PM, Steve Davies wrote: On 23 August 2013 14:24, Daniel-Constantin Mierla > wrote: Oh, I forgot that the group of t_set_* functions have on

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

Oh, I forgot that the group of t_set_* functions have one parameter, to allow set/unset the flag. Use: t_set_disable_internal_reply(1); Daniel On 8/23/13 1:34 PM, Steve Davies wrote: On 23 August 2013 12:22, Daniel-Constantin Mierla > wrote: correction for t

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 12:22, Daniel-Constantin Mierla wrote: > correction for the above line, the function name is: > > t_set_disable_internal_reply(); > I can't get the parser to agree its valid: 0(29626) DEBUG: [sr_module.c:680]: find_mod_export_record(): find_export_record: not found 0(29626

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 8/23/13 12:20 PM, Daniel-Constantin Mierla wrote: Hello, it seems that the flag not to generate the internal reply was lost when adopting the new ser tm module. Can you try the attached patch on 4.0.x? Once applied and kamailio reinstalled, before t_relay() use: t_disable_internal_reply

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

Hello, it seems that the flag not to generate the internal reply was lost when adopting the new ser tm module. Can you try the attached patch on 4.0.x? Once applied and kamailio reinstalled, before t_relay() use: t_disable_internal_reply(); An the return code should be -4 in this case. Let

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 11:18, Steve Davies wrote: > Here's what I put in RELAY route block: > > $var(rr) = t_relay(); > > xlog("L_NOTICE","SLD: in RELAY, t_relay returned $var(rr)\n"); > > if (!$var(rr)) { > > sl_reply_error(); > > } > > > > In 4.0.3, t_

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 08:13, Steve Davies wrote: > Here's all that is said about return codes from t_relay in the 4.0.x > module documentation ( > http://kamailio.org/docs/modules/4.0.x/modules/tm.html#t_relay). Looks > like there are docs that I didn't find? > > "Returns a negative value on fail

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

23 aug 2013 kl. 08:13 skrev Steve Davies : > > > > On 23 August 2013 07:55, Olle E. Johansson wrote: > > Please read the full documentation for t_relay. There's a lot of return codes > that actually is really helpful. If it fails, read the return code and take > action accordingly. > > Y

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

On 23 August 2013 07:55, Olle E. Johansson wrote: > Please read the full documentation for t_relay. There's a lot of return > codes that actually is really helpful. If it fails, read the return code > and take action accordingly. > > Yeah, I know I'm boring, but we do try to write proper referen

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

22 aug 2013 kl. 22:14 skrev Daniel-Constantin Mierla : > Hello, > > On 8/22/13 9:18 PM, Steve Davies wrote: >> Hi, >> >> I see that if 4.0.3 has a network error in sending a request, it sends back >> a 477 response, but does not execute the t_on_failure route block. >> >> Which I want to use

Re: [SR-Users] 477 Unfortunately error on sending to next hop occurred

Hello, On 8/22/13 9:18 PM, Steve Davies wrote: Hi, I see that if 4.0.3 has a network error in sending a request, it sends back a 477 response, but does not execute the t_on_failure route block. Which I want to use to route the call via a local alternative gateway. I saw a bug that talked ab

[SR-Users] 477 Unfortunately error on sending to next hop occurred

Hi, I see that if 4.0.3 has a network error in sending a request, it sends back a 477 response, but does not execute the t_on_failure route block. Which I want to use to route the call via a local alternative gateway. I saw a bug that talked about the failure_exec_mode modparam, but that's not l