Carrier load balancing between their two SBCs

[johnp]

I also created a custom template that added values to tinydns. I will need to test a bit more since my test machine doesn't have internet access., and the entries I added were private values and only one was active and routable. From what I've seen, just adding the custom info is all that is needed, my last test was without adding any host value. FWIW adding the custom template fragment isn't hard and if done this way it will remain after a normal upgrade.

[johnp]

Did more this evening and from what I see, custom-template is the way to go.

mkdir -p /etc/e-smith/templates-custom/var/service/tinydns/root/data  (Creates structure for custom fragment)

You can then copy my example to this location or touch /etc/e-smith/templates-custom/var/service/tinydns/root/data/61mycustomHostARecords and edit it. It looks like this:

{
    $OUT .= "# Custom A Records :60 is TTL value\n";
    $OUT .= "+yourhost.yourdomain.yourtld:255.255.255.255:60\n";
    $OUT .= "+yourhost.yourdomain.yourtld:254.254.254.254:60\n";
}

When installed and set, issue expand-template /var/service/tinydns/root/data (This recreates the structure within the tinydns data file adding your addition)

You then need to  cd /var/service/tinydns/root/
you can then issue a tinydns-data command (this puts all into the tinydns database)

signal-event dns-update (flushes the dns cache)

If uploading the attached has a ,txt so I could provide the example and it needs to be deleted

[ralph]

I have to admit that this is way over my head.
Did you say that this survives an upgrade?
Any chance I can talk you into writing up a How-To Doc with screenshots?  I'll create a page specifically for it.

Ralph

[johnp]

I can do that. As I have not tested sip trunk operation, this is just still somewhat theoretical although I believe it will operate.

[johnp]

This may help

[ralph]

Thanks John,
I put a copy on my dropbox because forum maintenance will delete the original after a couple of weeks.
The doc file can be downloaded here.

Ralph

[boycey9]

Where are you unable to add DDI authentication, what forms?

[johnp]

I think his issue is incoming did for sip peer

[ralph]

The problem is that the carrier has two SIP peers and I can only identify them via their DIDs.
I can't identify two peers with the same DIDs.

Ralph

[boycey9]

If you can confirm Ralph which form you are using to recognise the DDI may have an answer for you.

[ralph]

If you can confirm Ralph which form you are using to recognise the DDI may have an answer for you.

The form is SIP Peer Profile Assignment by Incoming DID

Ralph

[boycey9]

Ok, So when a call comes in to the system with a specific DDI, the system looks this up in the SIP Peer Profile Assignment by Incoming DID and assigns the features from your specified SIP peer profile to the inbound call. Its kinda like a COS for the incoming call, Therefore you do not need 2 different entries in this form and you can have two SIP Peer profiles.
The only time you have issues is if you are using username/password authentication but from your previous description you have IP auth so all will be ok.

[ralph]

It doesn't work that way in my experience.

(Just a note: We have an MBG as as SIP proxy.)

If the PBX sees a call coming Peer IP (B)  when it's identified by it's DID as Peer IP (A) the caller gets a 401 Unauthorized.

I have a work around for this particular customer.  ATT emailed me yesterday to find out what my solution was because  all the other Mitel dealers have the same problem.  Even their config guide points out the problem.

My solution was to route their other SBC to a different controller.

Ralph

[boycey9]

I can assure you this is how it works and I have it implemented on many sites . The clue is in the name of the form, it uses the settings of the SIP peer profile set against the DDI programmed in this form. Its a very powerful form as you can use it to manipulate many things based on incomming DDI.
The reason for a 401 are that the settings applied are not correct for the other Sip trunks, Maybe you are using username/password authentication if thats the case then your inbound call will use the wrong username/password hence the error, We use IP Authentication here so do not have the that issue.

[ralph]

I don't think we're talking about the same thing.
This is straight from Mitel ATT SIP Configuration guide May 2015, 08-4940-00014_7.

Failover: The current Mitel architecture is designed where only one (1) network element is
configured as the Mitel SIP peer to AT&T’s BVOIP services. Since it is standard practice for
AT&T to deploy at least two (2) IPBE pairs in the form of IPv4 host addresses, AT&T has created
an internal process specific to all Mitel products and releases. AT&T will advise the Network
Operations Center that this is a Mitel deployment which will trigger configuration of the standard
N+1 IPBE arrangement to Primary/Backup. This will alleviate the immediate issue where calls
might fail in the standard round-robin deployment. However if the primary AT&T IPBE fails, the
customer must manually intervene to configure the IPv4 address of the secondary IPBE as the
active network element in the Mitel system. When the primary IPBE is restored, the customer
must then revert back to the initial configuration in the Mitel system.