Topic: Internal & External CID & E911 override

[steve-o]

First, I want to thank everyone for their help, I can't say how much I appreciate the support in this community.   Tbox is now offline for good here - all traffic is now running via SAIL.   Now I need to clean a few items up related to outbound callerID.

I am running SAIL in a home office environment - SAIL handles my home telephone, business telephone, and a SAILtoSAIL connection to another office location.

My primary & secondary (failover if primary fails) US outbound carriers require I pass a valid 10 digit number for caller-ID and that is what they pass onwards.

1)  I would like to have all calls from my home phones pass 5027xxxxxx out as the caller-ID (extensions 6300 to 6399)

2)  In the office, I would like one phone to pass a CallerID of 5024xx5xxx (Ext 6201) and the other office phone to pass another #, lets call it 5024xx2xxx (Ext 6202).  I may have one other Ext, say 6203, where I'll want to pass a toll-free # (i.e. 888xxxxxxx).   I've found if I setup the callerid= " " <##> at the extension level, I then lose the callerid for the extension # internally.

3)  For office to office calls, specifically internal calls on the SAILtoSAIL trunk, I only want the extension # to pass.  My extensions here are 6xxx while the other office is 5xxx.  (i.e. if I dial 5103 at the other location from 6201, I just want the ext #, 6201 to show up on caller ID).

4)  Last, to put a twist into everything, if 911 (Emergency) is dialed from any of the phones at my location whether it is a home or office line, I need to over-ride the callerID to 5027xxxxxx.  The 5027xxxxxx is the primary home telephone # at this location and has E911 service.  To get E911 to work, all 911 calls must pass that specific callerID # regardless of what phone it is dialed on.

Thanks and Kindest Regards,

Steve

[David Harper]

Unfortunately this stuff goes beyond my meagre understanding of SAIL, but selintra may be able to give you some clues.

3)  For office to office calls, specifically internal calls on the SAILtoSAIL trunk, I only want the extension # to pass.  My extensions here are 6xxx while the other office is 5xxx.  (i.e. if I dial 5103 at the other location from 6201, I just want the ext #, 6201 to show up on caller ID).

Isn't this the default behaviour if you haven't manually set a CID for the extension?

[steve-o]

David -

I manually set a CID for the extension.   By default, it does pass the extension number only and works correctly for internal SAILtoSAIL calls.

However, at the same time I am looking to send a specific 10 digit CID outbound via a VOIP trunk I have named Vitelity1, as this trunk handles most of my outbound calling.

If I call outside from an extension on an office phone, I would like to pass my office telephone # out over CID to the Vitelity1 trunk.

If I call outside from an extension on a home phone, I would like to pass my home telephone # out over CID to the Vitelity1 trunk. 

I notice there is a "Set Outbound CLID" at the trunk level, but that only gives me space to pass one specific CID. 

Am I perhaps approaching this the wrong way?  Is there another place I can set outbound callerID for the extension which is then passed onto my Vitelity1?

Thanks,

Steve

[David Harper]

I'm not sure SAIL can do what you are asking in terms of dual CID for the same trunk -- but then, I'm no expert

Perhaps as a workaround you could do as follows:

• Set the Vitality1 CID to your Office number
• Leave your Office phones with no CID, thus allowing them to pick up the default Vitality1 CID when they call out
• Set the Home phones with the Home CID, which would override the Vitality1 CID when thse handsets call out

The only issue I can see immediately in this scenario would be the CID if you made a call over your SAILtoSAIL trunk from a Home phone to an extension at the remote PBX. I'm not sure what number would display. Also, if SAIL doesn't work quite the way I think it does, something else may go amiss. Lastly, if your VOIP carrier doesn't honour custom CID requests this wouldn't work - not much can be done about that.

Selintra appears to have disappeared (to work on the Dahdi issues, one assumes) so we might be stuck for expert advice for the time being.

[steve-o]

David -

This sounds like it may be a good work-around for the time being.  You've been a great help, as has been Selintra.

As mentioned, I changed CID at the ext level with the callerid= "name" <5027xxxxxx> statement and this is sending the correct caller ID # onto Vitelity1 -- when I call someone outside via Vitelity1 trunk (say I call my neighbor or my mobile), the value in the callerid= <xxxxxxxxxx> is what displays the callerID for the party receiving the call.

As such, it works great for external telephone calls .. but when I call a SAILtoSAIL, instead of getting my ext #   they get my phone #, i.e. 502xxx2xxx, as that is what I placed in the callerid= statement. 

One other work around is setting up another extension on the same phone where callerid= "name" <ext>, but I would pro-actively have to use that ext for internal calls. 

I believe your idea should be good as a work-around -- the only thing it doesn't address is a callerID override for all extensions to send the home CID # when 911 is dialed.  The home # is the only # that E911 recognizes , unless I purchase and setup E911 service for other outbound CID #'s which increases my monthly cost and is redundant since the #'s are at the same physical location. 

Here I need to be careful; if I pass a CID to 911 that is not setup with E911 service, I'm subject to an $85 penalty.  Fortunately I can test if E911 is working properly by dialing 811 on the trunk.

Until I get this worked out, I'll just use a mobile phone if I need 911 service or call the police dept directly.

I'm thinking it probably won't hurt to look at the .conf files on Tbox to see if I can work out how they handle this and perhaps look at a custom app..  I'll probably wait to see what Selintra says first. 

Thanks again!

Steve

[SARK devs]

As you know, you can set a CLI in the extension or in the trunk (or both).  Trunk will override extension (probabaly wrong, but there you go).

Default behaviour (as David said) is to send the extension number, which is fine if you are going intra or inter Asterisk.  Unfortunately if you override this in the extension with a different CLI, then that is what will get sent (which, I think you've already discovered).

This leaves the trunk.  Whatever you set in the trunk will be loaded into the CLI immediately prior to the dial. 

So that's good.

Unfortunately, you want to send different DiDs depending upon trunk choice and extension... and SAIL really wasn't designed to do this.  Any solution is going to be a bit of a bodge I'm afraid.  Having said that, you can probabaly get away with it by using duplicate trunks...

For example, to handle 911 calls should be easy enough using dupliactes...  You can set up another instance of the Vitelity trunk (with a different trunk name).  Most carriers aren't smart enough to know that you've defined them twice.  So then, you can create a unique route (EMERGENCY) which has a dial plan of 911 and in that route, reference the duplicate trunk you created.  In the duplicate trunk you can set the correct CLI for the 911 call.  Bit of a bodge, but logically sound.

You may also be able to solve some of your other requirements using this idea of "duplicate" trunks.


Kind Regards

S

[gippsweb]

I don't know about other countries, but here in Aus I could never get 2 trunks to one itsp to work. (We tried with a number of providers).

Only the first trunk would register correctly, hence even calls pointing to the second trunk instance would go out over the first one.

From memory it was something to do with the way asterisk reads the sip.conf file from the bottom up..

[steve-o]

Thanks, everyone.

I'm going to try a few things to work-around on this one!

-- Steve

[SARK devs]

...here in Aus I could never get 2 trunks to one itsp to work.

Er...
you can if you bend the rules just a little.  We use it to send different CLID's on the same account.  When you create a trunk, it will usually (depending upon the trunk type) ask for 5 data items so....

Trunk Name: 
DiD Number: 
Carrier's URL/IP Address: 
Username : 
Password :

We use a tier 2 carrier, Gamma, to carry most of our traffic.  Here are our Gamma entries...

Trunk Name:  GM1
DiD Number:  gamma1
Carrier's URL/IP Address:  gw1.man1.theiptele.com 
Username :  our-username
Password :  our-passwd

Trunk Name:  GM2
DiD Number:  gamma2
Carrier's URL/IP Address:  gw1.man1.theiptele.com 
Username :  our-username
Password :  our-passwd

The user-id & passwd are the same in both cases and furthermore, we only register through GM1.   However, now we can ship calls over GM1(gamma1) or GM2(gamma2) using different routes.  Since we can set up different CLIDs in the GM1 and GM2 trunks, we just sorted our problem.  By the way, if you are wondering how we handle inbound calls from Gamma, we don't use these trunks, we use separate PTT-DiD-Group trunks.

Finally, here are our two trunks living in harmony (viewed from the asterisk console)...

Code: [Select]

switch*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status
SER/switch                  192.168.1.220              5060     OK (1 ms)
MVP3010/MVP3010        (Unspecified)    D          0        Unmonitored
GM2/XXXXXXXXXX        88.215.60.14                5060     OK (29 ms)
tesip1/84425937           77.240.48.94                5060     OK (27 ms)
GM1/XXXXXXXXXX        88.215.60.14                5060     OK (40 ms)

Regards

S




 

[Teviot]

but here in Aus I could never get 2 trunks to one itsp to work. (We tried with a number of providers).

Maybe try port 5060 on one trunk and 5061 on the next trunk?

Just a thought

[gippsweb]

Maybe try port 5060 on one trunk and 5061 on the next trunk?

Had tried that, we spent quite a bit of time with WDP trying to work out why it happened the way it did. Changed ports, had different trunk names, setup a second account. It work still only register on one of the trunks.
I still think it is something at WDP's end.

In the end it didn't really matter as I've got 1 trunk that allows multiple incoming calls anyway.
I just can't run multiple DiD's..