Re: [SR-Users] TR: Failure Mode

2017-07-16 Thread Nicolas Breuer
Hello,

I moved all the « code" from Branch Failure to Route Failure and indeed it's 
working as expected now

Thanks for your help


De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : jeudi 13 juillet 2017 10:36
À : Nicolas Breuer <nicolas.bre...@belcenter.biz>; Kamailio (SER) - Users 
Mailing List <sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

408 has priority over 486, being a lower value. If you add the second branch in 
a branch-failure-event-route, then you have parallel forking and the lowest 
code is selected.

Anyhow, from your sip trace, it seems that the 486 was forwarded, not local 
generated, because it has the to-tag from callee side. The 408 is generated by 
kamailio.

Maybe you can enable cfgtrace for debugger an see what actions are executed, to 
be sure it runs over the config parts you expect to.

Cheers,
Daniel

On 12.07.17 16:01, Nicolas Breuer wrote:
Hello,

Thanks for this feedback. I can for sure remove the sl_send_reply from 
branch_failure_route and I can trace that, if I remove that
And the destination is busy , the kamalio will only send the 408 "time-out" 
reply.


De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : mercredi 12 juillet 2017 15:13
À : Nicolas Breuer 
<nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>; Kamailio 
(SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

do not send replies in branch failure route. At that phase, the outgoing 
branches are not yet completed. More important, do not use sl_send_reply() 
(this sends a stateless reply) after the transaction has been created (which is 
the case of branch failure route or failure route), use t_reply() if you are 
sure that transaction was created or send_reply() if you are not sure (so this 
option is the safest). Sending a stateless reply when a transaction is active 
doesn't have any effect on transaction state and tm module will send its own 
reply once it considers the transaction to be completed.

Also, creating a new branch in branch failure route 
(event_route[tm:branch-failure:...]) adds to parallel forking. Serial forking 
is done only from failure_route[...], when all branches sent out before were 
completed.
Hope these are clarifying the behaviour you get there.

Cheers,
Daniel
On 12.07.17 11:47, Nicolas Breuer wrote:
Hello Daniel,

The 486 is send by « myself" in the branch failure code.

##   486 busy
if (t_check_status("486") && $sht(branch=>$ci) != "" ) {
xlog("L_NOTICE", " Error 
received from the Carrier > Error $var(errorcode)");
sl_send_reply("486","Busy Here");
exit;
}

If I remove that, no "486" is send or put in acc.


So to be clear :


  *   486 is send by branch failure
  *   408 is send by route failure and the winning reply

Normally I don' t have to code to send a "486" on the branch.


De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : mercredi 12 juillet 2017 09:23
À : Nicolas Breuer 
<nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>; Kamailio 
(SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

your latest sip trace shows that 486 is sent out to caller (the acc record from 
syslog shows that the transaction was completed with that code as well). An ACK 
follows, but then I see also 408.

Can you check you config and see if there is some other place that can generate 
the reply, like a send_reply(...) or t_reply(...)?

Cheers,
Daniel

On 10.07.17 12:02, Daniel-Constantin Mierla wrote:

Hello,

the new trace shows a serial forking, with the first branch timing out, but the 
second branch is getting a 183 response, and that's all. It is not the same 
scenario you described. I need the full trace, from initial invite to the final 
response sent back to caller to see what is the winning response code.

Cheers,
Daniel

On 10.07.17 10:10, Nicolas Breuer wrote:
Hello,

Yes I'm sure the second branch is launched from Branch Failure Route.
If you check the timer trace, you can see the second is send 4 seconds later 
than the first ( I set the tm_inv to 4 seconds )

But in the trace I sent you the "last" invite. The kamailio sent 4 invites.

I will send you the complete trace




De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : lundi 10 juillet 2017 09:20
À : Nicolas Breuer 
<nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>; Kamailio 
(SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@

Re: [SR-Users] TR: Failure Mode

2017-07-13 Thread Daniel-Constantin Mierla
Hello,

408 has priority over 486, being a lower value. If you add the second
branch in a branch-failure-event-route, then you have parallel forking
and the lowest code is selected.

Anyhow, from your sip trace, it seems that the 486 was forwarded, not
local generated, because it has the to-tag from callee side. The 408 is
generated by kamailio.

Maybe you can enable cfgtrace for debugger an see what actions are
executed, to be sure it runs over the config parts you expect to.

Cheers,
Daniel


On 12.07.17 16:01, Nicolas Breuer wrote:
>
> Hello,
>
>  
>
> Thanks for this feedback. I can for sure remove the sl_send_reply from
> branch_failure_route and I can trace that, if I remove that
>
> And the destination is busy , the kamalio will only send the 408
> “time-out” reply.
>
>  
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* mercredi 12 juillet 2017 15:13
> *À :* Nicolas Breuer <nicolas.bre...@belcenter.biz>; Kamailio (SER) -
> Users Mailing List <sr-users@lists.kamailio.org>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> do not send replies in branch failure route. At that phase, the
> outgoing branches are not yet completed. More important, do not use
> sl_send_reply() (this sends a stateless reply) after the transaction
> has been created (which is the case of branch failure route or failure
> route), use t_reply() if you are sure that transaction was created or
> send_reply() if you are not sure (so this option is the safest).
> Sending a stateless reply when a transaction is active doesn't have
> any effect on transaction state and tm module will send its own reply
> once it considers the transaction to be completed.
>
> Also, creating a new branch in branch failure route
> (event_route[tm:branch-failure:...]) adds to parallel forking. Serial
> forking is done only from failure_route[...], when all branches sent
> out before were completed.
>
> Hope these are clarifying the behaviour you get there.
>
> Cheers,
> Daniel
>
> On 12.07.17 11:47, Nicolas Breuer wrote:
>
> Hello Daniel,
>
>  
>
> The 486 is send by « myself” in the branch failure code.
>
>  
>
>
> ##   486 busy
>
> if (t_check_status("486") && $sht(branch=>$ci) != "" ) {
>
> xlog("L_NOTICE",
> " Error received from
> the Carrier > Error $var(errorcode)");
>
> *sl_send_reply("486","Busy Here");*
>
> exit;
>
> }
>
>  
>
> If I remove that, no “486” is send or put in acc.
>
>  
>
>  
>
> So to be clear :
>
>  
>
>   * 486 is send by branch failure
>   * 408 is send by route failure and the winning reply
>
>  
>
> Normally I don’ t have to code to send a “486” on the branch.
>
>  
>
>  
>
>     *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* mercredi 12 juillet 2017 09:23
> *À :* Nicolas Breuer <nicolas.bre...@belcenter.biz>
> <mailto:nicolas.bre...@belcenter.biz>; Kamailio (SER) - Users
> Mailing List <sr-users@lists.kamailio.org>
> <mailto:sr-users@lists.kamailio.org>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> your latest sip trace shows that 486 is sent out to caller (the
> acc record from syslog shows that the transaction was completed
> with that code as well). An ACK follows, but then I see also 408.
>
> Can you check you config and see if there is some other place that
> can generate the reply, like a send_reply(...) or t_reply(...)?
>
> Cheers,
> Daniel
>
>  
>
> On 10.07.17 12:02, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> the new trace shows a serial forking, with the first branch
> timing out, but the second branch is getting a 183 response,
> and that's all. It is not the same scenario you described. I
> need the full trace, from initial invite to the final response
> sent back to caller to see what is the winning response code.
>
> Cheers,
> Daniel
>
>  
>
> On 10.07.17 10:10, Nicolas Breuer wrote:
>
> Hello,
>
>  
>
> Yes I’m sure the second branch is launched from Branch
> Failure Route.
>
> If you check the timer trace, you can see the second is
&

Re: [SR-Users] TR: Failure Mode

2017-07-12 Thread Nicolas Breuer
Hello,

Thanks for this feedback. I can for sure remove the sl_send_reply from 
branch_failure_route and I can trace that, if I remove that
And the destination is busy , the kamalio will only send the 408 "time-out" 
reply.


De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : mercredi 12 juillet 2017 15:13
À : Nicolas Breuer <nicolas.bre...@belcenter.biz>; Kamailio (SER) - Users 
Mailing List <sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

do not send replies in branch failure route. At that phase, the outgoing 
branches are not yet completed. More important, do not use sl_send_reply() 
(this sends a stateless reply) after the transaction has been created (which is 
the case of branch failure route or failure route), use t_reply() if you are 
sure that transaction was created or send_reply() if you are not sure (so this 
option is the safest). Sending a stateless reply when a transaction is active 
doesn't have any effect on transaction state and tm module will send its own 
reply once it considers the transaction to be completed.

Also, creating a new branch in branch failure route 
(event_route[tm:branch-failure:...]) adds to parallel forking. Serial forking 
is done only from failure_route[...], when all branches sent out before were 
completed.
Hope these are clarifying the behaviour you get there.

Cheers,
Daniel
On 12.07.17 11:47, Nicolas Breuer wrote:
Hello Daniel,

The 486 is send by « myself" in the branch failure code.

##   486 busy
if (t_check_status("486") && $sht(branch=>$ci) != "" ) {
xlog("L_NOTICE", " Error 
received from the Carrier > Error $var(errorcode)");
sl_send_reply("486","Busy Here");
exit;
}

If I remove that, no "486" is send or put in acc.


So to be clear :


  *   486 is send by branch failure
  *   408 is send by route failure and the winning reply

Normally I don' t have to code to send a "486" on the branch.


De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : mercredi 12 juillet 2017 09:23
À : Nicolas Breuer 
<nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>; Kamailio 
(SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

your latest sip trace shows that 486 is sent out to caller (the acc record from 
syslog shows that the transaction was completed with that code as well). An ACK 
follows, but then I see also 408.

Can you check you config and see if there is some other place that can generate 
the reply, like a send_reply(...) or t_reply(...)?

Cheers,
Daniel

On 10.07.17 12:02, Daniel-Constantin Mierla wrote:

Hello,

the new trace shows a serial forking, with the first branch timing out, but the 
second branch is getting a 183 response, and that's all. It is not the same 
scenario you described. I need the full trace, from initial invite to the final 
response sent back to caller to see what is the winning response code.

Cheers,
Daniel

On 10.07.17 10:10, Nicolas Breuer wrote:
Hello,

Yes I'm sure the second branch is launched from Branch Failure Route.
If you check the timer trace, you can see the second is send 4 seconds later 
than the first ( I set the tm_inv to 4 seconds )

But in the trace I sent you the "last" invite. The kamailio sent 4 invites.

I will send you the complete trace




De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : lundi 10 juillet 2017 09:20
À : Nicolas Breuer 
<nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>; Kamailio 
(SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

looking at the trace, the routing is parallel forking, because the two branches 
are sent out at the same time, it is no final response to the first branch 
before the second is sent out.

Are you sure you sent out the second branch from failure route? From the sip 
trace is doesn't seem so.

Cheers,
Daniel

On 07.07.17 15:38, Nicolas Breuer wrote:
Hello Daniel,

Thanks !

I sent all the information's to your email address


De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : vendredi 7 juillet 2017 13:21
À : Nicolas Breuer 
<nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>; Kamailio 
(SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Can you get a ngrep trace captured on kamailio server for such situation?

Also, can you paste the failure_route block here along with the log messages 
from the syslog?

Cheers,
Daniel


Re: [SR-Users] TR: Failure Mode

2017-07-12 Thread Daniel-Constantin Mierla
Hello,

do not send replies in branch failure route. At that phase, the outgoing
branches are not yet completed. More important, do not use
sl_send_reply() (this sends a stateless reply) after the transaction has
been created (which is the case of branch failure route or failure
route), use t_reply() if you are sure that transaction was created or
send_reply() if you are not sure (so this option is the safest). Sending
a stateless reply when a transaction is active doesn't have any effect
on transaction state and tm module will send its own reply once it
considers the transaction to be completed.

Also, creating a new branch in branch failure route
(event_route[tm:branch-failure:...]) adds to parallel forking. Serial
forking is done only from failure_route[...], when all branches sent out
before were completed.

Hope these are clarifying the behaviour you get there.

Cheers,
Daniel

On 12.07.17 11:47, Nicolas Breuer wrote:
>
> Hello Daniel,
>
>  
>
> The 486 is send by « myself” in the branch failure code.
>
>  
>
> ##  
> 486 busy
>
> if (t_check_status("486") && $sht(branch=>$ci) != "" ) {
>
> xlog("L_NOTICE", "
> Error received from the Carrier > Error $var(errorcode)");
>
> *sl_send_reply("486","Busy Here");*
>
> exit;
>
> }
>
>  
>
> If I remove that, no “486” is send or put in acc.
>
>  
>
>  
>
> So to be clear :
>
>  
>
>   * 486 is send by branch failure
>   * 408 is send by route failure and the winning reply
>
>  
>
> Normally I don’ t have to code to send a “486” on the branch.
>
>  
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* mercredi 12 juillet 2017 09:23
> *À :* Nicolas Breuer <nicolas.bre...@belcenter.biz>; Kamailio (SER) -
> Users Mailing List <sr-users@lists.kamailio.org>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> your latest sip trace shows that 486 is sent out to caller (the acc
> record from syslog shows that the transaction was completed with that
> code as well). An ACK follows, but then I see also 408.
>
> Can you check you config and see if there is some other place that can
> generate the reply, like a send_reply(...) or t_reply(...)?
>
> Cheers,
> Daniel
>
>  
>
> On 10.07.17 12:02, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> the new trace shows a serial forking, with the first branch timing
> out, but the second branch is getting a 183 response, and that's
> all. It is not the same scenario you described. I need the full
> trace, from initial invite to the final response sent back to
> caller to see what is the winning response code.
>
> Cheers,
> Daniel
>
>  
>
> On 10.07.17 10:10, Nicolas Breuer wrote:
>
> Hello,
>
>  
>
> Yes I’m sure the second branch is launched from Branch Failure
> Route.
>
> If you check the timer trace, you can see the second is send 4
> seconds later than the first ( I set the tm_inv to 4 seconds )
>
>  
>
> But in the trace I sent you the “last” invite. The kamailio
> sent 4 invites.
>
>  
>
> I will send you the complete trace
>
>  
>
>  
>
>      
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* lundi 10 juillet 2017 09:20
> *À :* Nicolas Breuer <nicolas.bre...@belcenter.biz>
> <mailto:nicolas.bre...@belcenter.biz>; Kamailio (SER) - Users
> Mailing List <sr-users@lists.kamailio.org>
> <mailto:sr-users@lists.kamailio.org>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> looking at the trace, the routing is parallel forking, because
> the two branches are sent out at the same time, it is no final
> response to the first branch before the second is sent out.
>
> Are you sure you sent out the second branch from failure
> route? From the sip trace is doesn't seem so.
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 15:38, Nicolas Breuer wrote:
>
> Hello Daniel,
>
>  
>
> Thanks !
>
>      
>
> I sent all the information’s to your email address
>
>  
>
>  
>
>  

Re: [SR-Users] TR: Failure Mode

2017-07-12 Thread Nicolas Breuer
Hello Daniel,

The 486 is send by « myself" in the branch failure code.

##   486 busy
if (t_check_status("486") && $sht(branch=>$ci) != "" ) {
xlog("L_NOTICE", " Error 
received from the Carrier > Error $var(errorcode)");
sl_send_reply("486","Busy Here");
exit;
}

If I remove that, no "486" is send or put in acc.


So to be clear :


  *   486 is send by branch failure
  *   408 is send by route failure and the winning reply

Normally I don' t have to code to send a "486" on the branch.


De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : mercredi 12 juillet 2017 09:23
À : Nicolas Breuer <nicolas.bre...@belcenter.biz>; Kamailio (SER) - Users 
Mailing List <sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

your latest sip trace shows that 486 is sent out to caller (the acc record from 
syslog shows that the transaction was completed with that code as well). An ACK 
follows, but then I see also 408.

Can you check you config and see if there is some other place that can generate 
the reply, like a send_reply(...) or t_reply(...)?

Cheers,
Daniel

On 10.07.17 12:02, Daniel-Constantin Mierla wrote:

Hello,

the new trace shows a serial forking, with the first branch timing out, but the 
second branch is getting a 183 response, and that's all. It is not the same 
scenario you described. I need the full trace, from initial invite to the final 
response sent back to caller to see what is the winning response code.

Cheers,
Daniel

On 10.07.17 10:10, Nicolas Breuer wrote:
Hello,

Yes I'm sure the second branch is launched from Branch Failure Route.
If you check the timer trace, you can see the second is send 4 seconds later 
than the first ( I set the tm_inv to 4 seconds )

But in the trace I sent you the "last" invite. The kamailio sent 4 invites.

I will send you the complete trace




De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : lundi 10 juillet 2017 09:20
À : Nicolas Breuer 
<nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>; Kamailio 
(SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

looking at the trace, the routing is parallel forking, because the two branches 
are sent out at the same time, it is no final response to the first branch 
before the second is sent out.

Are you sure you sent out the second branch from failure route? From the sip 
trace is doesn't seem so.

Cheers,
Daniel

On 07.07.17 15:38, Nicolas Breuer wrote:
Hello Daniel,

Thanks !

I sent all the information's to your email address


De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : vendredi 7 juillet 2017 13:21
À : Nicolas Breuer 
<nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>; Kamailio 
(SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Can you get a ngrep trace captured on kamailio server for such situation?

Also, can you paste the failure_route block here along with the log messages 
from the syslog?

Cheers,
Daniel

On 07.07.17 12:42, Nicolas Breuer wrote:
I think serial because the new branch is only created in case the first is 
timeout.

De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : vendredi 7 juillet 2017 12:40
À : Kamailio (SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>; Nicolas 
Breuer <nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

are you doing parallel forking or serial forking?

Cheers,
Daniel

On 07.07.17 12:24, Nicolas Breuer wrote:


Hello,

Some help here is needed

# auto-discard branches from previous serial forking leg
modparam("tm", "failure_reply_mode", 3)

I test a call with two branches.

1st branch received a 408 timeout error
2nd branch received a 486 busy.

Normally the failure route should be with the 486.

NOTICE: 

Re: [SR-Users] TR: Failure Mode

2017-07-12 Thread Daniel-Constantin Mierla
Hello,

your latest sip trace shows that 486 is sent out to caller (the acc
record from syslog shows that the transaction was completed with that
code as well). An ACK follows, but then I see also 408.

Can you check you config and see if there is some other place that can
generate the reply, like a send_reply(...) or t_reply(...)?

Cheers,
Daniel


On 10.07.17 12:02, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> the new trace shows a serial forking, with the first branch timing
> out, but the second branch is getting a 183 response, and that's all.
> It is not the same scenario you described. I need the full trace, from
> initial invite to the final response sent back to caller to see what
> is the winning response code.
>
> Cheers,
> Daniel
>
>
> On 10.07.17 10:10, Nicolas Breuer wrote:
>>
>> Hello,
>>
>>  
>>
>> Yes I’m sure the second branch is launched from Branch Failure Route.
>>
>> If you check the timer trace, you can see the second is send 4
>> seconds later than the first ( I set the tm_inv to 4 seconds )
>>
>>  
>>
>> But in the trace I sent you the “last” invite. The kamailio sent 4
>> invites.
>>
>>  
>>
>> I will send you the complete trace
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
>> *Envoyé :* lundi 10 juillet 2017 09:20
>> *À :* Nicolas Breuer <nicolas.bre...@belcenter.biz>; Kamailio (SER) -
>> Users Mailing List <sr-users@lists.kamailio.org>
>> *Objet :* Re: [SR-Users] TR: Failure Mode
>>
>>  
>>
>> Hello,
>>
>> looking at the trace, the routing is parallel forking, because the
>> two branches are sent out at the same time, it is no final response
>> to the first branch before the second is sent out.
>>
>> Are you sure you sent out the second branch from failure route? From
>> the sip trace is doesn't seem so.
>>
>> Cheers,
>> Daniel
>>
>>  
>>
>> On 07.07.17 15:38, Nicolas Breuer wrote:
>>
>> Hello Daniel,
>>
>>  
>>
>> Thanks !
>>
>>  
>>
>> I sent all the information’s to your email address
>>
>>  
>>
>>  
>>
>> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
>> *Envoyé :* vendredi 7 juillet 2017 13:21
>> *À :* Nicolas Breuer <nicolas.bre...@belcenter.biz>
>> <mailto:nicolas.bre...@belcenter.biz>; Kamailio (SER) - Users
>> Mailing List <sr-users@lists.kamailio.org>
>> <mailto:sr-users@lists.kamailio.org>
>> *Objet :* Re: [SR-Users] TR: Failure Mode
>>
>>  
>>
>> Can you get a ngrep trace captured on kamailio server for such
>> situation?
>>
>> Also, can you paste the failure_route block here along with the
>> log messages from the syslog?
>>
>> Cheers,
>> Daniel
>>
>>      
>>
>> On 07.07.17 12:42, Nicolas Breuer wrote:
>>
>> I think serial because the new branch is only created in case
>> the first is timeout.
>>
>>  
>>
>> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
>> *Envoyé :* vendredi 7 juillet 2017 12:40
>> *À :* Kamailio (SER) - Users Mailing List
>> <sr-users@lists.kamailio.org>
>> <mailto:sr-users@lists.kamailio.org>; Nicolas Breuer
>> <nicolas.bre...@belcenter.biz>
>> <mailto:nicolas.bre...@belcenter.biz>
>> *Objet :* Re: [SR-Users] TR: Failure Mode
>>
>>  
>>
>> Hello,
>>
>> are you doing parallel forking or serial forking?
>>
>> Cheers,
>> Daniel
>>
>>  
>>
>> On 07.07.17 12:24, Nicolas Breuer wrote:
>>
>> * *
>>
>>  
>>
>> Hello,
>>
>>  
>>
>> Some help here is needed
>>
>>  
>>
>> # auto-discard branches from previous serial forking leg
>>
>> modparam("tm", "failure_reply_mode", 3)
>>
>>  
>>
>> I test a call with two branches.
>>
>>  
>>
>> 1^st branch received a 408 timeout error
>>
>> 2nd branch received a 486 busy.
>>
>>  
>>
>> Normally the failure route should be with the 486.
>>
>>  
>>
>> NOTICE: 

Re: [SR-Users] TR: Failure Mode

2017-07-10 Thread Daniel-Constantin Mierla
Hello,

the new trace shows a serial forking, with the first branch timing out,
but the second branch is getting a 183 response, and that's all. It is
not the same scenario you described. I need the full trace, from initial
invite to the final response sent back to caller to see what is the
winning response code.

Cheers,
Daniel


On 10.07.17 10:10, Nicolas Breuer wrote:
>
> Hello,
>
>  
>
> Yes I’m sure the second branch is launched from Branch Failure Route.
>
> If you check the timer trace, you can see the second is send 4 seconds
> later than the first ( I set the tm_inv to 4 seconds )
>
>  
>
> But in the trace I sent you the “last” invite. The kamailio sent 4
> invites.
>
>  
>
> I will send you the complete trace
>
>  
>
>  
>
>  
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* lundi 10 juillet 2017 09:20
> *À :* Nicolas Breuer <nicolas.bre...@belcenter.biz>; Kamailio (SER) -
> Users Mailing List <sr-users@lists.kamailio.org>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> looking at the trace, the routing is parallel forking, because the two
> branches are sent out at the same time, it is no final response to the
> first branch before the second is sent out.
>
> Are you sure you sent out the second branch from failure route? From
> the sip trace is doesn't seem so.
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 15:38, Nicolas Breuer wrote:
>
> Hello Daniel,
>
>  
>
> Thanks !
>
>  
>
> I sent all the information’s to your email address
>
>  
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* vendredi 7 juillet 2017 13:21
> *À :* Nicolas Breuer <nicolas.bre...@belcenter.biz>
> <mailto:nicolas.bre...@belcenter.biz>; Kamailio (SER) - Users
> Mailing List <sr-users@lists.kamailio.org>
> <mailto:sr-users@lists.kamailio.org>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Can you get a ngrep trace captured on kamailio server for such
> situation?
>
> Also, can you paste the failure_route block here along with the
> log messages from the syslog?
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 12:42, Nicolas Breuer wrote:
>
> I think serial because the new branch is only created in case
> the first is timeout.
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
>     *Envoyé :* vendredi 7 juillet 2017 12:40
> *À :* Kamailio (SER) - Users Mailing List
> <sr-users@lists.kamailio.org>
> <mailto:sr-users@lists.kamailio.org>; Nicolas Breuer
> <nicolas.bre...@belcenter.biz>
> <mailto:nicolas.bre...@belcenter.biz>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> are you doing parallel forking or serial forking?
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 12:24, Nicolas Breuer wrote:
>
> * *
>
>  
>
> Hello,
>
>  
>
> Some help here is needed
>
>  
>
> # auto-discard branches from previous serial forking leg
>
> modparam("tm", "failure_reply_mode", 3)
>
>  
>
> I test a call with two branches.
>
>  
>
> 1^st branch received a 408 timeout error
>
> 2nd branch received a 486 busy.
>
>  
>
> Normally the failure route should be with the 486.
>
>  
>
> NOTICE: 

Re: [SR-Users] TR: Failure Mode

2017-07-10 Thread Daniel-Constantin Mierla
Hello,

looking at the trace, the routing is parallel forking, because the two
branches are sent out at the same time, it is no final response to the
first branch before the second is sent out.

Are you sure you sent out the second branch from failure route? From the
sip trace is doesn't seem so.

Cheers,
Daniel


On 07.07.17 15:38, Nicolas Breuer wrote:
>
> Hello Daniel,
>
>  
>
> Thanks !
>
>  
>
> I sent all the information’s to your email address
>
>  
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* vendredi 7 juillet 2017 13:21
> *À :* Nicolas Breuer <nicolas.bre...@belcenter.biz>; Kamailio (SER) -
> Users Mailing List <sr-users@lists.kamailio.org>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Can you get a ngrep trace captured on kamailio server for such situation?
>
> Also, can you paste the failure_route block here along with the log
> messages from the syslog?
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 12:42, Nicolas Breuer wrote:
>
> I think serial because the new branch is only created in case the
> first is timeout.
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* vendredi 7 juillet 2017 12:40
> *À :* Kamailio (SER) - Users Mailing List
> <sr-users@lists.kamailio.org>
>     <mailto:sr-users@lists.kamailio.org>; Nicolas Breuer
> <nicolas.bre...@belcenter.biz> <mailto:nicolas.bre...@belcenter.biz>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> are you doing parallel forking or serial forking?
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 12:24, Nicolas Breuer wrote:
>
> * *
>
>  
>
> Hello,
>
>  
>
> Some help here is needed
>
>  
>
> # auto-discard branches from previous serial forking leg
>
> modparam("tm", "failure_reply_mode", 3)
>
>  
>
> I test a call with two branches.
>
>  
>
> 1^st branch received a 408 timeout error
>
> 2nd branch received a 486 busy.
>
>  
>
> Normally the failure route should be with the 486.
>
>  
>
> NOTICE: 

Re: [SR-Users] TR: Failure Mode

2017-07-07 Thread Nicolas Breuer
Hello Daniel,

Thanks !

I sent all the information's to your email address


De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : vendredi 7 juillet 2017 13:21
À : Nicolas Breuer <nicolas.bre...@belcenter.biz>; Kamailio (SER) - Users 
Mailing List <sr-users@lists.kamailio.org>
Objet : Re: [SR-Users] TR: Failure Mode


Can you get a ngrep trace captured on kamailio server for such situation?

Also, can you paste the failure_route block here along with the log messages 
from the syslog?

Cheers,
Daniel

On 07.07.17 12:42, Nicolas Breuer wrote:
I think serial because the new branch is only created in case the first is 
timeout.

De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : vendredi 7 juillet 2017 12:40
À : Kamailio (SER) - Users Mailing List 
<sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>; Nicolas 
Breuer <nicolas.bre...@belcenter.biz><mailto:nicolas.bre...@belcenter.biz>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

are you doing parallel forking or serial forking?

Cheers,
Daniel

On 07.07.17 12:24, Nicolas Breuer wrote:


Hello,

Some help here is needed

# auto-discard branches from previous serial forking leg
modparam("tm", "failure_reply_mode", 3)

I test a call with two branches.

1st branch received a 408 timeout error
2nd branch received a 486 busy.

Normally the failure route should be with the 486.

NOTICE: 

Re: [SR-Users] TR: Failure Mode

2017-07-07 Thread Daniel-Constantin Mierla
Can you get a ngrep trace captured on kamailio server for such situation?

Also, can you paste the failure_route block here along with the log
messages from the syslog?

Cheers,
Daniel


On 07.07.17 12:42, Nicolas Breuer wrote:
>
> I think serial because the new branch is only created in case the
> first is timeout.
>
>  
>
> *De :*Daniel-Constantin Mierla [mailto:mico...@gmail.com]
> *Envoyé :* vendredi 7 juillet 2017 12:40
> *À :* Kamailio (SER) - Users Mailing List
> <sr-users@lists.kamailio.org>; Nicolas Breuer
> <nicolas.bre...@belcenter.biz>
> *Objet :* Re: [SR-Users] TR: Failure Mode
>
>  
>
> Hello,
>
> are you doing parallel forking or serial forking?
>
> Cheers,
> Daniel
>
>  
>
> On 07.07.17 12:24, Nicolas Breuer wrote:
>
> * *
>
>  
>
> Hello,
>
>  
>
> Some help here is needed
>
>  
>
> # auto-discard branches from previous serial forking leg
>
> modparam("tm", "failure_reply_mode", 3)
>
>  
>
> I test a call with two branches.
>
>  
>
> 1^st branch received a 408 timeout error
>
> 2nd branch received a 486 busy.
>
>  
>
> Normally the failure route should be with the 486.
>
>  
>
> NOTICE: 

Re: [SR-Users] TR: Failure Mode

2017-07-07 Thread Nicolas Breuer
I think serial because the new branch is only created in case the first is 
timeout.

De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : vendredi 7 juillet 2017 12:40
À : Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>; Nicolas 
Breuer <nicolas.bre...@belcenter.biz>
Objet : Re: [SR-Users] TR: Failure Mode


Hello,

are you doing parallel forking or serial forking?

Cheers,
Daniel

On 07.07.17 12:24, Nicolas Breuer wrote:


Hello,

Some help here is needed

# auto-discard branches from previous serial forking leg
modparam("tm", "failure_reply_mode", 3)

I test a call with two branches.

1st branch received a 408 timeout error
2nd branch received a 486 busy.

Normally the failure route should be with the 486.

NOTICE: 

Re: [SR-Users] TR: Failure Mode

2017-07-07 Thread Daniel-Constantin Mierla
Hello,

are you doing parallel forking or serial forking?

Cheers,
Daniel


On 07.07.17 12:24, Nicolas Breuer wrote:
>
> * *
>
>  
>
> Hello,
>
>  
>
> Some help here is needed
>
>  
>
> # auto-discard branches from previous serial forking leg
>
> modparam("tm", "failure_reply_mode", 3)
>
>  
>
> I test a call with two branches.
>
>  
>
> 1^st branch received a 408 timeout error
>
> 2nd branch received a 486 busy.
>
>  
>
> Normally the failure route should be with the 486.
>
>  
>
> NOTICE: 

[SR-Users] TR: Failure Mode

2017-07-07 Thread Nicolas Breuer


Hello,

Some help here is needed

# auto-discard branches from previous serial forking leg
modparam("tm", "failure_reply_mode", 3)

I test a call with two branches.

1st branch received a 408 timeout error
2nd branch received a 486 busy.

Normally the failure route should be with the 486.

NOTICE: