Archive for February, 2012

Why do they call it a Trunk anyway?

February 22, 2012 Leave a comment

Ever wondered why they call a phone trunk a “trunk”? Has this not been something keeping you awake at night?

In the interest of helping those losing sleep over this question, the following might provide some assistance:

A very long time ago when telephones were being installed, it was necessary to bury cables in the ground that would connect houses to the phone company offices, which then connected to what is now known as the PSTN, (Public Switched Telephone Network). These cables were 3 or 4 inches around, grey in color, and resembled the look of an elephant “trunk”. As cables were laid, and the PSTN network grew the name “trunk” stuck. The intern-connecting of these pacaderm appendages came to be known as the act of “trunking” 

Categories: Lync EV, Uncategorized

To E1 or to T1? – that might be the question

February 22, 2012 Leave a comment

I was recently working on a Lync engagement that involved deploying Lync Enterprise Voice to connect to a legacy PBX. In order to route calls to and from the legacy PBX, we needed to configured a media gateway and a Q.SIG trunk. Q.SIG is a protocol that runs on a T1 PRI. It was originally invented as an industry standard to allow PBX’s from different vendors to route calls to each other. Prior to Q.SIG, if you have a Nortel PBX, (“switch”), and an Avaya PBX, and you wanted to route calls, there was no way to do this because each legacy PBX vendor used their own proprietary protocols to route and communicate with their own PBXs.

Q.SIG was developed to allow different vendor PBXs to route and communicate calls. Q.SIG runs on a standard T1 PRI. The Q.SIG protocol contains various pieces of information such as the Called Number, (who you are trying to dial), and the Caller ID, (who is calling). In order to connect two PBXs with a Q.SIG trunk, each PBX is installed and configured with a Q.SIG “card” so that the T1 PRI cable, (i.e. what we call a standard RJ45 Ethernet cable), can connect the two. The connection can also be a leased line T1 but for simplicity I am using the cabling example.

It turns out that media gateways from the major vendors also support Q.SIG, so that if you want to integrate a legacy PBX supporting Q.SIG with Lync, then you can use a media gateway to do the protocol conversion by connecting the Q.SIG port on a media gateway to the legacy PBX, and then configure the Ethernet “side” of the media gateway to communicate with Lync.

Q.SIG running over a T1 PRI only supports 23 concurrent calls occurring between the media gateway and the legacy PBX. The reason that it is only 23 calls, is that a T1 is a 1.5 MB “pipe”. Since each call is dedicated 64 kb/s of bandwidth you then divide 1.5 mb/s by 64 kb/s and you get the number 23. You might notice that the “maths” does not quite come out as “23” but there is another channel called the “D” channel that provides the signaling, (i.e. start the call, stop the call, etc.). The “D” channel is the telephony version of SIP, whereas the voice channels are the media streams like RTP in the Lync “world”.

But what if you wanted to get a few more calls from your Q.SIG connection?

Turns out that the T1 standard is used in the US, and that the E1 standard is used outside the US. The E1 standard has 30 channels instead of 23, (still 64 kb/s) and total bandwidth of 1.5 MB/s. When Q.SIG was developed, the designers accounted for both the T1 and E1 standards. This means that when you set up the Q.SIG card on the PBX, you can have the PBX administrator set it to “E1” instead of “T1”, and on the media gateway set the gateway to use Q.SIG with “E1” instead of “T1”, and you will then get up to 30 concurrent calls between the PBX and the gateway & Lync.

Categories: Lync EV, Uncategorized

Integrating Lync with a T1: What to make sure you and the customer ask the phone company

February 22, 2012 Leave a comment

When integrating Lync with a T1 PRI via a media gateway there are some questions that you might wish to ask the customer prior to beginning the Lync / Telephony integration that can save you and the customer some time:

• For calls to the PSTN: How does the T1 PRI expect to receive the Called Number and Calling Number fields from Lync? For example, should those numbers be 10 digits or 11 digits or is the T1 provider capable of accepting both?
• For calls from the PSTN: How will the T1 PRI provider send the Called Number and Calling number fields to the media gateway? For example, while they be 10 digits, or 11 digits, (Phone providers other than SIP providers won’t send E.164).
• What T1 PRI protocol(s) does the T1 PRI that has been provisioned support, (e.g. NI2, 5ESS, 4ESS or DMS100)? This is needed to configure the media gateway to communicate with the T1 PRI.
o Make sure to avoid the customer purchasing a T1 PRI that is utilizing CAS. CAS does not support CallerID, (i.e. you won’t know who is calling)
• What phone numbers are being routed to the T1 PRI? For example, is it a block of numbers or a list of numbers out of sequence? If all numbers are going to a single Lync server/pool, then the gateway can be configured to route all calls on the T1 PRI to Lync’s IP address. However, if you have multiple locations you may need to set up routing tables on the media gateway that depending on the Called Number may dictate to which Lync server/pool the call is routed.
• Before going onsite ask the customer, “Has the T1 PRI local loop has been turned-up and accepted”. When a phone provider, (i.e. the CLEC) technician goes onsite, they will connect the T1 to a box known as a DMARC (demarcation point). At that time the phone technician will verify that the T1 can communicate back to the phone company, (i.e. the “CO” – central office). After that is done, the customer will be asked to call the phone provider, and “accept the local loop” for that T1. At that time, the customer should ask the person on the phone to verify that BOTH the data and voice channels are “up”. Very often a phone provider will “turn up” the data channel, (the “D” channel) and not “turn up” the voice channels, (really).
• After the T1 PRI “turn up” is verified, then make sure that the customer also calls the phone provider to accept the block of phone numbers, (i.e. DIDs) that have been provisioned. This is a separate call since it will be a separate work order for the phone company, (really). The customer should tell the phone provider to go ahead and “point” those numbers to the new T1 even though the media gateway has not been yet connected.

Hopefully this is helpful when rolling out a media gateway with Lync and a T1 PRI by saving you some time onsite engaging in thumb-twiddling exercises 

Categories: Lync EV, Uncategorized Tags:

A Unique and clever method for providing Lync and legacy phone co-existance with minimal user pain

February 2, 2012 Leave a comment

I recently have been at a client who has decided to move from Centrex based phones to Lync EV. This customer decided that doing a something like a weekend cut-over to Lync from their legacy phone system would be too drastic for end users, (about 15,000 people). This organization like many has legacy functions such as hunt groups, (e.g. 3 or 4 phones ring at the same time in a dept and anyone can answer). The team responsible for the move to Lync and eventual support of Lync decided that they needed a solution that allowed both “phone” systems to run in parallel so that users can use both Lync and their legacy phones while legacy functionality such as response/hunt groups can be migrated to Lync.

This customer came up with a somewhat unique and clever way allow Lync to run alongside the legacy system, and provide EV without changing the end user’s phone number. This particular customer is using Centrex, but this would easily apply to Cisco, Avaya, or other PBX infrastructures. This solution also has the added benefit of providing a path for the customer to stop using TDM voice and move to a SIP provider:

Lync and Centrex co-existence – how it is done:

• Customer purchased block of DIDs on a Windstream SIP trunk, (e.g. 202 475 xxxx)
• User is enabled for Lync and Lync EV
• User is enabled for Exchange UM for voice mail
• Current Centrix DID, (e.g. +1 303 444 1234) is saved as LineURI field (E.164 format)
• User is assigned a DID from the Windstream SIP trunk, (e.g. +1 202 475 1234)
• User’s SIP trunk DID is set as a Lync Unassigned number using set-csunassignednumber cmdlet
• A Lync Announcement is created that forwards calls to the unassigned SIP URI of the +1 202 475 1234 number to the LineURI of the user, (e.g. +1 303 444 1234). This is done by using set-csannouncement cmdlet BUT not assigning a greeting AND setting the -TargetURI parameter to the SIP address of the end users’ LineURI, (e.g. tel:+13034441234). This means that calls forwarded from the end users’ Centrex phone to their SIP trunk DID, (e.g. 1202 475 1234), to route to the unassigned number, ( +1202 475 1234) which plays NO greeting and itself is forwarded to the end users’ LineURI, (i.e. the -targetURI parameter of the set-csannouncement).
• At this point the following behavior occurs for a user:
o User maintains their current phone number
o User places calls from Lync via the SIP trunk and their CallerID is their Centrex number
o Calls placed to their Centrex number forward directly to their Lync client/phone
o If the user wishes to not receive calls on their Lync client they can turn off the autoforward. If they make calls from Lync their CallerID will still be their Centrex number
• At a later point in time the customer will begin porting the Centrex numbers over to the Windstream SIP trunk provider and start to get rid of Centrex phones.

Categories: Lync EV