Skip to main content

Multiple inbound/outbound routes with the same host

Posted by andrewyager on Fri, 06/27/2008

Hi,

We have the following scenario

Box 1:
core voice server
asterisk 1.4

connected to

Box 2:
hosted pbx
asterisk 1.4
pbxmanager 6 mte

Each tenant on Box 2 has a trunk to Box 1 for their outbound calls, and there is one trunk from box 1 to box 2 for inbound calls.

According to asterisk bug 9678, Asterisk only pays attention to the "first" SIP peer (which is the "last" added to the sip.conf file) when processing inbound calls.

This means that whenever I add a new trunk from Box 2 to Box 1, I have to move the inbound trunk to the end so that it is matched, otherwise the console throws:

[Jun 27 20:17:45] WARNING[8347]: chan_sip.c:12330 handle_response_invite: Received response: "Forbidden" from '"xxx" <sip:xxx@xxx>'

on the core server and

WARNING[31891]: chan_sip.c:8379 check_auth: username mismatch, have , digest has
[Jun 28 10:30:39] NOTICE[31891]: chan_sip.c:13817 handle_request_invite: Failed to authenticate user "xxx" <sip:xxx@xxx>;tag=as4d07afa5

on the hosted server.

This error can be fixed by moving the [inbound-hosted] SIP context to the end of the file, but it's a bit monotonous to do this every time. The other option is to (of course) split inbound and outbound servers, but that's a bit of a pain, and actually requires more work! Does anyone have a clever way to solve this problem using the GUI?

Thanks,
Andrew


Submitted by dozment on Fri, 06/27/2008 Permalink

I think I have a similar scenario except that my "box 1" is a sip trunking provider. I use one trunk from my provider for inbound calls, and I have a seperate trunk for each tenant for outbound calls. I have never seen the error that you're getting. I wonder if it is because I am registering my inbound trunks.

ie,

register => xxxxxx.xxxxx@my.sip.provider.com

Just a hunch, but are you registering the inbound trunk?

Submitted by eeman on Fri, 06/27/2008 Permalink

I use a single trunk between my gateway box and my MTE pbx manager box. I use dialplan to separate the calls between tenants on the gateway.

Submitted by andrewyager on Sun, 06/29/2008 Permalink

I think the single trunk is the best solution. I've temporarily used IAX and it just locked my core server, which is not very nice! We use account codes at the moment to seperate billing for clients. Is it safe to trust the MTE to set the right account code? Can we define a default code for each tennant that users can't override?

Submitted by eeman on Mon, 06/30/2008 Permalink

i use account codes but my billing CDR isnt collected by MTE, for starters, in thirdlane, each call can have 3, 4, 5, 10 cdr entries which is not compatible for billing purposes. My gateway box collects CDR. Each call is a single record. I set the account codes by creating outbound trunks that aren't modifiable by the customer. The outbound call is prepended with their account code.

If my outbound trunk is going to send (in e.164 format) +15025551212 and their account code is 5023150500 i send the following

IAX2/ROUTING/5023150500+15025551212 to my gateway

my gateway box then delivers it to a context that splits it out. You can do it however you like, define variables or send it to contexts.

exten => _XXXXXXXX.,1,Goto(${EXTEN:0:10}_out,${EXTEN:10},1)

Submitted by andrewyager on Tue, 07/01/2008 Permalink

So you are using IAX2 for your outbound routing at that point, rather than SIP?

I think my IAX Deadlock issue is actually a bug in Asterisk 1.4.21, which they have released a patch for in 1.4.21.1. Sometimes it doesn't pay to upgrade to fix bugs - you only introduce new ones! :-S

Submitted by eeman on Tue, 07/01/2008 Permalink

I know what you mean. despite running beta's now they still come out with a .1 release. I use IAX2 mostly because I am a big fan of trunking, and at one time it was the only trunk with a jitter buffer. I am still on 1.4.20 but was on 1.4.18 before that. I wait a while before I move and always run it on my machine at home first. I tried 1.4.21 at home and kept dropping conversations mid call with just 1 call on the box.