Skip to main content

Thirdlane With Nextone

Posted by mobashirahmed on Wed, 04/29/2009

I guess no one answered the last one.

So i am simplifying this.

Is anyone using ThirdLane with Nextone.

If yes, I would like to create a SIP Trunk from Thidlane to Nextone. And an Outbound Route for it.

I would be thankful if you could guide me with it, so I can show this on this month's meeting, and replace the PBX we have now, with ThirdLane.

Nextone needs no username and password and it doesnt needs ThirdLane to register with it. We just send calls to Nextone's IP and it allows it by its IP, for which it has a endpoint.

I shall seek a reply.

Thanks in advance.


Submitted by eeman on Wed, 04/29/2009 Permalink

so you're saying that it uses IP and IP alone as its identification. Set it up like any other trunk, include the IP as the hostname and add insecure=very to the additional options. that will allow you to trust the ip to send you the call.

Submitted by eeman on Wed, 04/29/2009 Permalink

by now the provider should have examples of using asterisk with them. If you post that information I can tell you how that translates to the UI in pbxmanager.

Submitted by mobashirahmed on Thu, 04/30/2009 Permalink

Thanks for the reply.

Its our nextone, and in previous asterisk's we created a Custom Trunk with the dial string as:

SIP/$OUTNUM$@nextone-ip:5060

An with an consequent Outbound Route (for this Trunk) the calls worked.

Submitted by mobashirahmed on Tue, 05/05/2009 Permalink

Thank you very much Eeman.

That works, and i can send calls to Nextone, and it gets terminated.

But, one more stone to be removed.

The calls are going outside without a caller ID. As "anonymous"

The following is a CDR from nextone:

>End-Time = 2005-05-02 06:34:05 (GMT)

>Ingress Gateway = THIRDLANE SIP GW

>Ingress DNIS = 1956xxxxxxx

>Transit DNIS = #xxx#1956xxxxxxx

>Egress DNIS = 1956xxxxxxx

>Egress Gateway = [PROVIDER] PROVIDER SIP GW

>Ingress ANI = anonymous

Where can i define the settings which will send the defined Caller ID.

Thanks again.

Submitted by eeman on Tue, 05/05/2009 Permalink

callerid is defined in several places. send me the general section of your sip.conf. Your outbound routes should not be matching against the general category they should be specific to a trunk.

Submitted by mobashirahmed on Wed, 05/06/2009 Permalink

**sip.conf**

[general]

port=5060

bindaddr=0.0.0.0

disallow=all

allow=ulaw

allow=alaw

allow=gsm

callerid=anonymous

context=from-outside ; Default context for incoming calls

Replacing the "callerid=anonymous" changes the ANI for every call going outside the system.

We basically want to assign individual Trunks to individual Tenants. (using Thirldlane MT) so that different Tenants have Different Caller-Ids.

Can it be done

Thanks for your replies though

Submitted by thirdlane on Mon, 05/18/2009 Permalink

You should be able to set external caller id on the tenant management screen.

Best regards,

Alex

Submitted by arunpereira on Tue, 05/19/2009 Permalink

Just as a note insecure=very is depreciated. Please look at using insecure=port,invite.

Alex is right. There is no point in creating multiple trunks for each tenant. The simpler approach would be to create a single trunk and then set the correct caller id at the tenant or extension level as required. This is the approach I currently use and it works out quite well.

Submitted by eeman on Tue, 05/19/2009 Permalink

its also important to note that callerid= in sip.conf is for inbound sip traffic. If defined it will overwrite all callerid info (such as calls comming in from handsets). You dont want to set a callerid= statement on trunk connections because otherwise calls received will be overwritten with this wrong value. For these trunks, no callerid= statement should be defined at all.

if you are going to use insecure=very or insecure=port,invite the type needs to be set to peer not user. If you set a sip trunk up as type=user and do not use proxy authentication it will not work. What will instead happen is the call will process under the [general] settings and you will likely just see an ip address as the sip channel in use. This can be confirmed by setting allowguest=no in the general section of sip.conf. If the call now fails, you are not using the correct information to process the call.