in general of sip.conf set allowguest=no

under the trunk set insecure=port,invite

Thanks

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

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

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)

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.

Matt,

sorry, i am one of those lazy people that load from ISO, so that wouldn't work !

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.

Thanks Erik,

your insight is always appreciated here !

Greg