Thirdlane.com logo

Incoming call Authentication

Posted by conraddewet on Wed, 08/18/2010
Forums
Thirdlane platform General Questions

Hi All
Using thirdlane (multitenant PBX Manager 6.0.1.72). Incoming calls are being rejected with:

NOTICE[17964]: chan_sip.c:17107 handle_request_invite: Failed to authenticate user "+XXXXXXX" ;tag=as7850bc6c

Looks like thirdlane is expect the dial string to be the login information.

My ISP is sending me calls over a broadband connection - it unlikely that they will change their setting to service me. They most likely are not going to send username and password - i have just given them my IP address.

Question: How can I get thridlane to accept any incoming call regardless or without authentication. I can always manage this using inbound routs, so long as Asterisk accepts the call.

Thanks

Submitted by gregshap on Sat, 09/18/2010 Permalink

OK,

This is BS, why isn't this dealt with out of the box?

I spent 14 hours chasing my tail looking for the reason why my calls wouldn't come in.

My STE didn't have this problem but as soon as I launch the MTE with 1.6, boom this problem, that no one tells you about, kicks your B and waste valueable time that no one has an excess of.

Yes, I am venting but no one should go through what I did today without any tech support or RECENT documentation.

I feel better now,

Greg

Submitted by mattdarnell on Sun, 09/19/2010 Permalink

Greg,

That is challenge b/c the issue had nothing to do with Thirdlane. Asterisk rejected the call before Thirdlane even saw it.

I would suggest integrating a trunk before you load Thirdlane. That way you can know where the problem lies.

-Matt

Submitted by gregshap on Sun, 09/19/2010 Permalink

Matt,

I understand that it is a Asterisk issue. It would be helpful if these known issues were on a list somewhere with work-arounds provided as well so someone doesn't have to reinvent the wheel each time they buy the software.

Again, coming from STE with 1.4, I was blind sided with several issues that I don't normally deal with coming from STE.

I love the Thirdlane product but current documentation would probably soothe a lot of peoples frustration with having to "self-teach" themselves how it all works. Thats the least one could ask for from a paid product. Also, having a separate manual for STE and MTE as the old manual, when they put them both together, is hard to follow.

What did you mean by "integrating a trunk before you load Asterisk"?

Thanks

Greg (much calmer now)

Submitted by mattdarnell on Sun, 09/19/2010 Permalink

I meant integrating the trunk before you load thirdlane...made the edit - thanks.

Alex is working on docs, should be on the next couple of months.

Submitted by eeman on Mon, 10/11/2010 Permalink

gregshap, nothing changed in the way people were supposed to set up their trunks. What was happening before is there was an exploitable weakness in the config that allowed people to set their trunks up incorrectly yet still receive calls. This was creating an enormous headache trying to trouble shoot issues where they couldnt dial out and the assumption that the trunk was correct was wrong. Allowing guest sip calls is not only a flawed concept, it can impact you financially as well as be the butt-end of a telemarketing assault. Changing allowguest=no only helped identify those who needed to set insecure=port,invite all along. It should have _always_ been configured that way. There is no way to document this because how you peer with your upstream provider is a case-by-case issue. Only some upstream providers require insecure=port,invite. Those are systems that use IP-addresses as the mechanism of trust, not proxy authentication.