482 Loop Detected

[UKenGB]

I have 2 accounts with my VOIP provider (each with their own external number of course) and snomONE is configured to have 2 each (identical matching) Trunks, Hunt Groups and Extensions (and Dial Plans). Nothing should be shared. They should both behave identically and you can ring the either's Hunt Group or extension number directly and it all works as it should. In fact calling either external number from anywhere except out through the PBX produces the correct results for both accounts.

 

But, I am now finding (no idea when it started) that if I try to call one of those (external) numbers out through the PBX, the call fails with a reported "482 Loop Detected", although calling the other number in an identical way works PERFECTLY. This has me very puzzled since both these accounts ought to behave exactly the same, they use all the same settings (apart from the obvious) and there is no forwarding configured. I simply cannot see why it might think the same call is traversing the trunk in both directions simultaneously. What could be causing one of them to fail in this way?

[pbx support]

PBX has some protection against the "same" call coming back to the PBX to avoid endless loops. If the admin knows if this call is "safe" to come back to PBX, then you can turn off the "Admin->Settings->General->Loopback detection" option.

[UKenGB]

Yes, but the 2 accounts are (as far as I can tell) identical, so why do I get this problem when calling one but not the other? What are the circumstances that might trigger the error? Is it possible I have unknowingly introduced some variation into the configuration, or is the PBX somehow screwing up, or is it possible my VOIP provider is somehow causing it?

[Vodia PBX]

Your service povider is probably just using a "naked" SIP proxy (no SBC) and does not change the Call-ID for the SIP call. The PBX must be very careful with such calls, as they can easily create a loop or avalanche and eat up all resources immediately (http://tools.ietf.org/html/rfc5393, paragraph 3 is worth reading). That is why the PBX does not accept looped calls by default. When you allow it, the PBX is "picky" with the proper handling of the From/To tags, they must be used strictly according to the RFC.

[UKenGB]

Yes, I can appreciate all that, but it doesn't answer my question. Since the 2 accounts are with the same VOIP provider and the PBX is apparently set up identically for both accounts, why do I get this problem with just one of the accounts and NOT the other?

 

As I said, could it be a PBX issue or is it likely/possible that it's my provider?

[Vodia PBX]

Hmm. Maybe it is kind of random depending which of the accounts issued the last registration. But in order to nail this one, we need to see the SIP trace, ideally embedded into the log from the PBX.

[UKenGB]

I'm wondering if that 'Loop Detected' problem is related to my VOIP provider. I'll have to check with them.

 

But I have now experienced what looks more like a snomONE problem. All registrations appeared normal and correct and I could dial out using either of the 2 SIP Trunks, but incoming calls to those numbers indicated they were 'unobtainable'.

 

In the end I stopped the PBX, waited a minute and re-started. Incoming calls now work again as they should. But, was this a PBX problem or some issue with my VOIP provider which cleared once the Trunk registrations were dropped and then re-registered? Either way, this is a bit of a big deal since although everything looked correct, in fact incoming calls were failing completely with NO notifications being generated that this was occurring. As I said, this is a fundamental part of a PBX, calls failing silently is no good at all.

 

Anyone comment on whether this is likely to be PBX or VOIP provider related?

[UKenGB]

Back to the original problem, but it's no longer reporting 'Loop Detected'.

 

One of the Trunks is still causing grief. If I call the VOIP number to which the trunk is registered, I get 'unobtainable'. But if I call the Hunt Group to which the Trunk is directed, or any of the extensions in that Hunt Group, the call works as expected. Why is the call to the external VOIP number failing?

 

I have another account which should be identical to this and also another which may differ slightly and I can call both of them from any extension and it works. There is just this problem Trunk. If I call the same external VOIP number from outside the LAN i.e. the call going direct to my VOIP provider and not out via the PBX (I've tried from other PSTN number, or VOIP number or mobile) it works.

 

The problem only manifests itself when calling this Trunk's VOIP number, from INSIDE the PBX.

 

I turned off 'Loopback detection:' as suggested and it made NO difference.

 

I've got the logfile entires from both calls, i.e. when it succeeds for one Trunk but fails for the other (in fact each is calling the other). Where can I best send these for you to have a look at? They're both identical initially, but then there's a small divergence, but it's not clear to me where the problem is occurring.

[Vodia PBX]

Yea probably it is a lot easier if you attach the log (not inline) as a file.

[UKenGB]

Yea probably it is a lot easier if you attach the log (not inline) as a file.

They should be attached to this post.

failure.txt

success.txt

[pbx support]

In both the log files, I see "No dial plan available" and PBX sending back "404 Not found".

In both cases User-Agent: OpenSIPS (1.5.1-notls (i386/linux)) sends back ACK.

After that, in the "success" case PBX receives the CANCEL from m9, but in the "failure" case PBX receives "404 Not found" (same one it sent out before).

 

Because the loopback detection is turned off, PBX is not reporting "482 Loopback detected" as expected.

 

Is there any difference between trunks Ken and Cathy?

[UKenGB]

Everything for 'Ken' and for 'Cathy' is identical, apart from the obvious. For each there is an account with the VOIP provider, a Trunk, an Extension and a Dial Plan.

 

You're right, with 'Loop Detection' turned on, it does still report that as the problem, but why does it still fail when it's turned off?

 

This morning I checked again and find that the success/failure situation has reversed. Previously it seemed quite reliable that my number worked, but Cathy's did not. Now, Cathy's is working and mine is not. Whichever the PBX decides to fail, it then seems seems quite consistent for some time, but at some point it can switch. So this would indicate it is not related to any configuration differences between the accounts.

 

I have been trying out some Dial Plan changes and had thought that this might somehow be involved, but I switched both Extensions to the default Dial Plan and nothing changed. So it's not that. However, why does it report "Dial Plan not found"? When is it looking for a DP? That's only involved when the call is initiated and it works because the correct Trunk is used.

 

So the question remains, why does it consistently have a problem with one account, but not the other - even when 'Loop Detection' is OFF?

 

I am sure that this problem did not exist originally, but the latest update has introduced some instability (see earlier post) and this is beginning to look like a bug has been introduced.

[UKenGB]

Just tried both accounts again and this time they are BOTH giving 'Loop Detected' errors.

 

Irrespective of which account the PBX chooses to fail or not, what is causing this? What do the log files tell us?