I have a 908e in my test area that I have been playing around with, testing out various configurations. Is it possible to input SIP lines into the unit and then output them as a PRI? If so, is there documentation to explain the setup and test procedures? Thanks.
Absolutely possible and one of the main ways the unit is deployed. There are sample configurations in a lot of previous conversations here. Basics:
Debug commands for testing:
Absolutely possible and one of the main ways the unit is deployed. There are sample configurations in a lot of previous conversations here. Basics:
Debug commands for testing:
Jkesting,
Thanks for posting. Below are a couple of links to sample configurations that you may find helpful.
Total Access 9XXe - SIP to PRI sample configuration
Total Access 9XXe - SIP to dual PRIs sample configuration
Feel free to respond on this post if you have any further questions.
Thanks!
David
Thanks for the replies. I will look over the config guides and see if I can decipher this. The problems I always run into is trying to tie the two trunk groups together.
jkesting wrote:
Thanks for the replies. I will look over the config guides and see if I can decipher this. The problems I always run into is trying to tie the two trunk groups together.
Don't think of tying them together in terms of combining them. Think of the TA900 as a call routing engine "switchboard" that accepts a digit pattern from one or more trunks or users, possibly manipulates it, and routes it out to a different trunk based on a match in a grouped-trunk containing the outgoing trunk or to a user for a specific unique phone number.
Typically you will either have a PRI to the PSTN and a SIP-based PBX or SIP trunks to the PSTN and a PRI-based PBX.
Either way it works the same.
On the side facing the PSTN you'll create a grouped-trunk with a number of matching patterns, typically:
911 - Emergency
N11 - service codes
NXX-XXXX or NXX-NXX-XXXX local calls
1-NXX-NXX-XXXX 1-plus out of area calls
011-$ - international
etc.
These patterns are available as checkboxes in the grouped-trunk setup. Match what the PSTN expects and include the PSTN-facing trunk as a member of the trunk group.
On the PBX side I like to get more specific although some guides suggest a wildcard. Getting more specific prevents call loops, allows additional trunks or users to be added, reduces or eliminates post-dial delay and is much cleaner.
Let's assume that the PBX has the DID range of 312-555-0100 through 312-555-0199 and that the PSTN delivers calls as ten digits.
For the PBX grouped-trunk you would configure an advanced template to accept 312-555-01XX . Then add the PBX-facing trunk to the group and you're done.
Notice that there are GUI tabs on the trunk for DNIS match and substitute. This can be used to match different dial plans applied to the outbound trunks.
Suppose the PBX sends 7-digits for local calls and 1-NXX-NXX-XXXX for everything outside of the area code but the PSTN trunk expects ten digits on all calls.
On the PSTN-facing trunk you would have two match-substitute rules:
match 1-NXX-NXX-XXXX substitute NXX-NXX-XXXX
match NXX-XXXX substitute 312-NXX-XXXX
The grouped-trunk for PSTN would permit NXX-XXXX and 1-NXX-NXX-XXXX as received from the PBX but before delivering them to the PSTN the outbound trunk would strip the leading 1 from 1-NXX-NXX-XXXX calls and add the local area code to 7-digit calls.
Facing the PBX, you can use this feature to map other patterns to what the PBX expects.
Example: The customer's main number is 312-555-0100. They have a toll-free number delivered on the trunk as 800-555-1234 that is supposed to ring the main number, but the PBX doesn't recognize that pattern. Permit 800-555-1234 on the PBX-facing grouped-trunk. Match 800-555-1234 and substitute 312-555-0100 on the trunk itself.
Note that the PRI, if connected to a PBX, may expect a shortened number of digits, just enough to uniquely match an extension. The number of digits sent is set in the PRI interface configuration and should match the programming of the PBX itself. Typically these are 3, 4, 7, 10, or all digits.
Summary:
Trunk - connection to an external resource that accepts one or more (often a lot more) digit patterns.
Grouped-trunk - Definition of digit patterns as received by the TA900 to be routed to trunks included in the group.
DNIS match-substitute - Manipulate digit patterns after acceptance before they leave on the trunk. Programmed on trunk.
So I have my 908e up and working. I can make inbound and outbound calls. I guess I am still a little confused as to how this all works however. I had two SIP lines coming in and registered to the 908e on port Eth 0/2. I have an Avaya IP Office connected to the 908e via PRI on T1/PRI port 0/3. I can make and receive calls, but every outgoing call I make goes thru the first SIP line. Doesn't each channel of the PRI need a corresponding SIP line? I removed the 2nd SIP line completely, and I can go out and make 23 simultaneous calls from the IP Office and they all are using that first SIP line and show that number as the caller ID. Is this how it should be working?
jkesting wrote:
So I have my 908e up and working. I can make inbound and outbound calls. I guess I am still a little confused as to how this all works however. I had two SIP lines coming in and registered to the 908e on port Eth 0/2. I have an Avaya IP Office connected to the 908e via PRI on T1/PRI port 0/3. I can make and receive calls, but every outgoing call I make goes thru the first SIP line.
The routing of the calls is controlled by the voice grouped-trunk configuration. a call from the PRI will be routed to the grouped trunk with the most specific digit pattern and the lowest cost. If both SIP trunks are assigned to the same grouped-trunk you can control the order of selection with "resource-selection circular" or "resource-selection linear" in the grouped-trunk configuration. If you want a primary and a backup you can put them in different grouped-trunks and assign the backup a higher cost.
Doesn't each channel of the PRI need a corresponding SIP line? I removed the 2nd SIP line completely, and I can go out and make 23 simultaneous calls from the IP Office and they all are using that first SIP line and show that number as the caller ID. Is this how it should be working?
No, SIP trunks aren't channelized or limited by to a specific number of calls by nature of the transport. There are SIP providers with hundreds or thousands of calls on a single SIP trunk. The limitations are either by policy (you pay for X number of simultaneous calls) or by bandwidth of the underlying transport. Unlike a PRI where a call will fail if it exceeds the capacity of the transport, excessive calls for the bandwidth on a SIP trunk will result in degraded call quality for all calls on the over-subscribed medium but the call will go through.
As far as the caller-ID, this can be configured to pass through the ANI received from the Avaya, to identify all calls from the Avaya as coming from a specific number, or to specify a number only if none is provided by the Avaya. Your SIP providers should be able to work with you in terms of what caller-ID is presented. Be sure to test calls to a variety of toll-free numbers, many won't properly route if the caller-ID is missing or incorrectly formatted. Also verify that the correct caller-ID is presented to 9-1-1. Caller-ID presented generally shouldn't matter which SIP provider is used.
Thanks....this does help me.