[SR-Users] Handle '486 busy here' from upstream carrier

2010-11-11 Thread JR Richardson
Hi All, Asterisk>http://pastebin.com/crfMe81D Here is a pastebin of the call graph: http://pastebin.com/rnQZDyFU I was thinking about including this in my failure route: if (t_check_status("486")) { append_branch(); t_relay(); } Would that do any good? Thanks. JR -- JR Richardson

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-11 Thread Iñaki Baz Castillo
2010/11/11 JR Richardson : > I was thinking about including this in my failure route: > > if (t_check_status("486")) { >     append_branch(); >     t_relay(); > } > > Would that do any good? The above code instructs Kamailio to create a new branch to the same destination upon receipt of hte 486 re

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-11 Thread JR Richardson
On Thu, Nov 11, 2010 at 6:29 PM, Iñaki Baz Castillo wrote: > 2010/11/11 JR Richardson : >> I was thinking about including this in my failure route: >> >> if (t_check_status("486")) { >>     append_branch(); >>     t_relay(); >> } >> >> Would that do any good? > > The above code instructs Kamailio

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-11 Thread Alex Balashov
On 11/11/2010 09:17 PM, JR Richardson wrote: So the append_branch should not be used, ok, what about just the t_relay and exit? if (t_check_status("486")) { t_relay(); exit; } Would this work? This is a failure route, a special type of reply route. Replies are automatically passed

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-12 Thread Daniel-Constantin Mierla
Hello, On 11/12/10 3:17 AM, JR Richardson wrote: On Thu, Nov 11, 2010 at 6:29 PM, Iñaki Baz Castillo wrote: 2010/11/11 JR Richardson: I was thinking about including this in my failure route: if (t_check_status("486")) { append_branch(); t_relay(); } Would that do any good? The ab

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-13 Thread Iñaki Baz Castillo
2010/11/12 Daniel-Constantin Mierla : >> The idea is to receive the 486 from the carrier and not send the >> INVITE SDP back to the carrier, this is causing the carrier to send a >> 482 loop detected. > > First, if you create a new branch and send to same SIP gateway and you get > loop detected, th

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-13 Thread JR Richardson
> -Original Message- > From: Iñaki Baz Castillo [mailto:i...@aliax.net] > Sent: Saturday, November 13, 2010 8:10 AM > To: Daniel-Constantin Mierla > Cc: JR Richardson; SR-Users > Subject: Re: [SR-Users] Handle '486 busy here' from upstream carrier > > 2

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-15 Thread Daniel-Constantin Mierla
Hello, On 11/13/10 3:09 PM, Iñaki Baz Castillo wrote: 2010/11/12 Daniel-Constantin Mierla: The idea is to receive the 486 from the carrier and not send the INVITE SDP back to the carrier, this is causing the carrier to send a 482 loop detected. First, if you create a new branch and send to sam

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-15 Thread Daniel-Constantin Mierla
On 11/13/10 5:42 PM, JR Richardson wrote: -Original Message- From: Iñaki Baz Castillo [mailto:i...@aliax.net] Sent: Saturday, November 13, 2010 8:10 AM To: Daniel-Constantin Mierla Cc: JR Richardson; SR-Users Subject: Re: [SR-Users] Handle '486 busy here' from upstream carrie

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-15 Thread JR Richardson
M >>> To: Daniel-Constantin Mierla >>> Cc: JR Richardson; SR-Users >>> Subject: Re: [SR-Users] Handle '486 busy here' from upstream carrier >>> >>> 2010/11/12 Daniel-Constantin Mierla: >>>>> >>>>> The idea is to receive th

Re: [SR-Users] Handle '486 busy here' from upstream carrier

2010-11-15 Thread Iñaki Baz Castillo
2010/11/15 Daniel-Constantin Mierla : > I expected the r-uri changes as well (serial forking). In regard to this > similar case, there is a difference between loop detection and spirals, > maybe sorted out in a follow-up rfc. Yes, in case the RURI changes (or some other headers as Route) then it's