Skip to main content

Trunk Issues..

Posted by fredbear34 on Tue, 03/16/2010

I have setup a tenant for testing and was working fine.. so i added a second trunk and i could not make in bound calls on either..

i deleted that and created a second tenant... once created a trunk in that tenant i was unable to call the first tenant.. until deleting the trunk in the second tenant..

any help gratefully appreciated..


Submitted by eeman on Wed, 03/17/2010 Permalink

need more information about how you configured each trunk before someone can give you ideas on where you screwed up. try pasting the sip.conf information on both trunks.

Submitted by fredbear34 on Wed, 03/17/2010 Permalink

here is the snip from the sip.conf below..
both trunk were configured the same..

[4325]
qualify=3000
nat=no
secret=xxxxxx
;=description=4325
host=210.xx.xx.x
username=4325
callerid=088xxxxxxx
dtmfmode=rfc2833
context=from-outside
type=friend
insecure=very
canreinvite=yes
disallow=all
allow=ulaw
allow=alaw

cheers... by the way screwed up ?? Is that a technical term ?

Submitted by eeman on Wed, 03/17/2010 Permalink

you cannot have 2 trunks to the same ip if you are basing trunks off ip. when IP is the ONLY delimiter that is parsed then how exactly do you propose the system know which trunk the call is intended on when they both have the same address?

/personified - "i need to pick which trunk this call is associated with.. lets see...

trunk 1 are calls from 192.168.1.1

trunk 2 are calls from 192.168.1.1"

you'd be better off giving the trunk name and the username a name that identifies the trunk. When your trying to debug and your looking at a bunch of

SIP/4325 instead of SIP/MySipProvider you'll hate yourself

btw if calls are all coming from a single provider from a single IP that is doing IP addressed based authentication, you only need a single trunk for all your tenants.

Submitted by fredbear34 on Wed, 03/17/2010 Permalink

i need more than one trunk to this provider.. but when i add the second trunk the first stops receiving incoming calls..

is there a fix or a way to do this..

Submitted by fredbear34 on Wed, 03/17/2010 Permalink

i do as they are not sending me DID info.. only trunk info.. ( eg i can not route by DID )

and this is authd by username name and password.

bottom line is this is how i have done it need to setup thirdlane to work like this..

can i set multipule incoming trunks and one outgoing ??

Submitted by eeman on Wed, 03/17/2010 Permalink

the config you set up is NOT auth'd by username password.

as soon as you set insecure=very or insecure=port,invite asterisk STOPS requesting proxy authentication. the insecure option is how you disable authentication and trust the ip implicitly.

they are legally required to send you DID, who is this fly-by-night suck provider that is not adhering to what they need to send? You cannot scale MTE to even a small operation if you have to create a sip trunk for every damn DID they send you.

what sort of switch is this far end? There is no class5 switch that does SIP that I'm aware of that would try and require a different sip account for each and every DID. Every tenant I have has somewhere around 5 - 10 DID each. If you have even 100 tenants that's 500 trunks just to take inbound calls. You aren't going to be able to scale at all.

Submitted by fredbear34 on Wed, 03/17/2010 Permalink

I'm not sure what to do as to change this i would have to shift upstream providers.

and to the best of my knowledge in Australia at this point there is no way of shifting current VOIP DID's

Submitted by thirdlane on Thu, 03/18/2010 Permalink

You may want to use your existing system (or a SIP server) to reroute the DIDs you have for existing customers to the MTE, and start getting DIDs from a provider who gives you a proper trunk with multiple DIDs for the new customers (eventually offering your existing customers the new DIDs).

Submitted by eeman on Thu, 03/18/2010 Permalink

so your country doesnt have laws for LNP (number portability) the way they have them on the books here?

as far as voip vs pstn, at some point that # is assigned to a switch on the PSTN, so legally it can be ported away from the PSTN carrier regardless of who is reselling it, providing you have LNP laws. Here, one must simply provide a recent bill showing you are being billed for that #.

Submitted by fredbear34 on Thu, 03/18/2010 Permalink

Erik

We do have legislation regarding number porting for PSTN. What i was saying is I'm sure we do not have any laws yet regarding VOIP. Which is an issue, using my clients as an example.. most of my clients have 1300#'s and i can shift them to the new system and give them a new DID and point their 1300 to that. But for the clients that have just a DID. there is no way for us to port a VOIP DID to another provider..

Regards Mick

Submitted by eeman on Thu, 03/18/2010 Permalink

what you're not grasping is that it isnt a VOIP number.. its a PSTN number..

A -> B -> C -> D -> E -> F
           \-> K

regardless if its converted to SIP at D, E, or C ... its still a number that resides on the PSTN. The only numbers that are truly voip numbers are things like SKYPE. Theres no way to dial a skype user from the PSTN. If you can pick up an analog # at your house and reach one of your customers.. then that number is in the PSTN network and therefore can be ported away from one PSTN company who is converting it to SIP, to an entirely different company. So lets say its being converted to SIP at step C. Then company K (your new provider) can port that number away from C. In the USA they compare CallerID Name that is registered to that number with a recent copy of the bill. This proves its your number and thats more or less it. Dont let someone convince you that just because its delivered via SIP that it is somehow immune to LNP. A lot of those analog and T1 voice lines are delivered via SIP to the customers premises without the customer having a clue, yet they are ported all the time.

Submitted by fredbear34 on Sat, 03/20/2010 Permalink

Thanks you Erik..

I hadn't thought of it like that. But that does make sense.

I will put port orders in Monday and see if i can't simplify this mess of SIP trunks running everywhere.

Regards Mick