On Thu, Nov 11, 2010 at 6:29 PM, Iñaki Baz Castillo ibc@aliax.net wrote:

2010/11/11 JR Richardson jmr.richardson@gmail.com:

...

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 response. So obviously it's wrong. What do you want to achieve with the above code??

-- Iñaki Baz Castillo ibc@aliax.net

Hello,

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. I would like to recognize the 486 response from the carrier as a busy and relay it to the original INVITE server then exit, so then another route can be processed by the INVITE server and not handled as a loop and dropped.

I don't understand why kamailio would send an ACK then an INVITE SDP to the carrier after receiveng a 486 Busy?

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 production system, so I can't just throw trial and error code at it and hope it works. I'm not sure how to mock up and test the various codes I'm seeing from the carrier. My test lab works great with basic functionality and execution, I'm only seeing some of these scenarios in production.

Thanks for your suggestions.

JR

Hello,

On 11/12/10 3:17 AM, JR Richardson wrote:

On Thu, Nov 11, 2010 at 6:29 PM, Iñaki Baz Castilloibc@aliax.net wrote:

...

2010/11/11 JR Richardsonjmr.richardson@gmail.com:

...

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 response. So obviously it's wrong. What do you want to achieve with the above code??

-- Iñaki Baz Castillo ibc@aliax.net

Hello,

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, then the gateway is broken. It does not see that there is a different branch value in the top Via header.

I would like to recognize the 486 response from the carrier as a busy and relay it to the original INVITE server then exit, so then another route can be processed by the INVITE server and not handled as a loop and dropped.

I don't understand why kamailio would send an ACK then an INVITE SDP to the carrier after receiveng a 486 Busy?

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?

t_relay() is only for SIP __requests__, not for SIP __replies__.

If you want to let the 486 go back to the initiator of INVITE, just exit the failure route:

if (t_check_status("486")) { exit; }

In case you want to change the reply code to something else, then you can use t_reply() to overwrite the reply received, for example, change the 486 is 404:

if (t_check_status("486")) { t_reply("404", "Not found"); exit; }

This is a production system, so I can't just throw trial and error code at it and hope it works. I'm not sure how to mock up and test the various codes I'm seeing from the carrier. My test lab works great with basic functionality and execution, I'm only seeing some of these scenarios in production.

So far, I haven't seen a better testing suite than a production environment ;-)

Cheers, Daniel

Thanks for your suggestions.

JR

-----Original Message----- From: Iñaki Baz Castillo [mailto:ibc@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

2010/11/12 Daniel-Constantin Mierla miconda@gmail.com:

...

...

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, then the gateway is broken. It does not see that there is

a

...

different branch value in the top Via header.

Hi Daniel, the 482 reply is correct:

---

---

RFC 3261 - 8.2.2.2 Merged Requests

If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction.

  The same request has arrived at the UAS more than once, following
  different paths, most likely due to forking.  The UAS processes
  the first such request received and responds with a 482 (Loop
  Detected) to the rest of them.

---

---

This is exactly the case the user is experimenting: the INVITE arrives twice to the same server, with same From tag, Call-ID and CSeq, but different branch/transaction. So 482 is the correct response.

Regards.

-- Iñaki Baz Castillo ibc@aliax.net

[JR Richardson] So I think I figured out what is going on here, I'm not configured correctly for this upstream carrier, using Dispatcher with only one server is causing the issue. When I get a failure or busy, I am branching back to the same server and there is the problem, I should not call ds_next_dst(); in my failure route for this carrier because there are no more destination servers.

I think this is causing another problem I am seeing as well so I will focus on this for a bit and see if I can get it worked out.

Thanks you for your advice and clarification.

JR

On Mon, Nov 15, 2010 at 9:13 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:

On 11/13/10 5:42 PM, JR Richardson wrote:

...

...

-----Original Message----- From: Iñaki Baz Castillo [mailto:ibc@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

2010/11/12 Daniel-Constantin Mierlamiconda@gmail.com:

...

...

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, then the gateway is broken. It does not see that there is

a

...

different branch value in the top Via header.

Hi Daniel, the 482 reply is correct:

---

---

RFC 3261 - 8.2.2.2 Merged Requests

If the request has no tag in the To header field, the UAS core MUST    check the request against ongoing transactions.  If the From tag,    Call-ID, and CSeq exactly match those associated with an ongoing    transaction, but the request does not match that transaction (based    on the matching rules in Section 17.2.3), the UAS core SHOULD    generate a 482 (Loop Detected) response and pass it to the server    transaction.

The same request has arrived at the UAS more than once, following       different paths, most likely due to forking.  The UAS processes       the first such request received and responds with a 482 (Loop       Detected) to the rest of them.

---

---

This is exactly the case the user is experimenting: the INVITE arrives twice to the same server, with same From tag, Call-ID and CSeq, but different branch/transaction. So 482 is the correct response.

Regards.

-- Iñaki Baz Castillo ibc@aliax.net

[JR Richardson] So I think I figured out what is going on here, I'm not configured correctly for this upstream carrier, using Dispatcher with only one server is causing the issue.  When I get a failure or busy, I am branching back to the same server and there is the problem, I should not call ds_next_dst(); in my failure route for this carrier because there are no more destination servers.

I think this is causing another problem I am seeing as well so I will focus on this for a bit and see if I can get it worked out.

It is what I spotted in a previous email. ds_next_dst() should be used in a IF condition and only when the returned value is true, then relay again.

Yes, my ds_next_dst() is wrapped in an if statement:

if(ds_next_dst()) { append_branch(); t_on_failure("FAIL_ONE"); t_relay(); }

I was able to mock up a failure test and what I am seeing is the append_branch() is causing the retransmit of the invite back to the failed server, which in turn causes the loop error. But if I take the append_branch() out of the failure route, then I get these errors:

ERROR: t_forward_nonack: no branches for forwarding ERROR: w_t_relay_to: t_relay_to failed

So I don't understand the purpose of the append_branch() in a failure and why it is retransmitting the invite back to a failed server?

I also found that specifying an error code and exiting will work and not retransmit the invite back to the failed server.

if (t_check_status("404")) { xlog("L_INFO", "request is 404 - exit\n"); exit; }

Thanks.

JR

2010/11/15 Daniel-Constantin Mierla miconda@gmail.com:

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 not loop but a spiral. However the author of the thread didn't modify the RURI, just created a new branch and sent it again.