Mitel 3300's connect via SIP

[12345kevin]

We have a customer with 2 3300's on different sites. The voice traffic between sites is minimal and does not warrent the cost of IP trunking.They have a data connection between sites. However because they have some SIP licenses they have asked us to connect them ? I would assume the only way is sip extension on one and sip trunk on the other ?

 

[jon83]

just use sip trunks on both sites

 

[fissure]

Hi there,

it is possible to link 2 x Mitel 3300 with SIP trunk licenses each side (and it can indeed be cheaper than IP Trunking/IP Networking).

Use SIP trunks both sides, rather than SIP trunk one side, and SIP extension the other.

Neil

 

[kwbMitel]

Regarding the cost of IP trunking, are you saying the systems are not currently licensed for IP networking.

If they are licensed, and as you say there is already a DATA connection, and you require "minimal" voice traffic, then what costs are are you speaking about?

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[12345kevin]

They are not currently licensed for IP Trunking.

Only basic functionality is required, nothing fancy.

 

[kwbMitel]

How Basic?

What type of trunking do you have?

I know of a method using DISA to enable set to set calls.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[12345kevin]

set to set ideally.

They do this at the moment over the PSTN to DDI (extn number digit modded to insert DDI), so need to offer the same.

All I need to know, is it possible to connect with SIP trunks on each site ? or would I need SIP extension one end and Trunk the other ? I could then use disa with tone plans and digit mods, which is presumably what kwbMitel is suggesting ? Did this many times years ago when connecting LS/GS to another system extension


From above comments it would appear 2 SIP Trunks can connect. Although I can't see how at the moment.

 

[kwbMitel]

The DISA method is quite good and easy to maintain.

You still have not told me trunk type

Analog or PRI (PSTN can be either)

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[12345kevin]

PRI/ISDN30 both ends

 

[fissure]

I can confirm, we've connected 2 x Mitel 3300, directly, across a VPN, using SIP trunk licences, so sets at one site, can dial sets at the other.

No SIP User / Device licenses were needed.

We assigned 2 x SIP trunk licenses, at each end, to support 2 concurrent calls between the sites.

This was, much cheaper, than buying the IP Networking license for the two Mitels.

Any problems, just post, and I can check the configs

 

[12345kevin]

Thanks fissure, just what I needed to know, that it could be done.

 

[UncleRalph]

Do message waiting lamps work accross SIP trunks? (NuPoint, 6510)
what other features might me lost when using SIP trunks as opposed to Mitel IP trunking?

Ralph

 

[kwbMitel]

Using ARS to dial the full number is an OK solution but it can be cumbersome if the DDI's are not in the same range. This causes you to use different modified digit strings depending on the digits dialed.

I am writing this off the top of my head so I might miss something. If I do, just ask.

You can use DISA and Cluster programming to simplify the integration immensely. No other trunks required.

Basic setup:
On each system create a DISA number accessible via DDI, Use the one that requires account codes.

Setup cluster and create CEID digits for each system: This entry simplifies the ARS programming but requires Remote directory entries instead.
e.g. SYS1 - CEID = 1001, SYS2 - CEID = 1002

ARS Create unique Route. Mod dig and Cor from each site to the other. (Only 1 required for each system)

Create ARS Digits on each system for the remote system with digits to follow = extension length. (Same as you would with a cluster, use the CEID digits). Route = as setup above

In the System Account Code form, enter an account code to be used for DISA (same on both systems is simplest)

In the Individual Account Codes form, Enter the system account code above with appropriate COR and COS.

In Call Progress Tone Detection setup 2 plans
Plan 1 - Wait for tone = 0, Action on Timeout = Outpulse DTMF
Plan 2 - Wait for tone = 3, Action on timeout = Outpulse Default

Digit Modification
- Delete 0
- insert whatever required for normal PRI call(Such as call by call digits), and then the DDI for the remote system DISA.
- In the Final tone plan insert <T01><T02><A01>

Program the Remote Directory form with the extensions on the remote system. Each system for the other.

Optional, Add the names to the Telephone Directory for the remote system.

Call Flow
User dials extension (remote DN)
system finds digits in remote directory
system dials CEID digits for remote system
ARS digits selects route
Mod Dig inserts DDI for remote system DISA
Mod dig waits for dialtone from remote system then tone dials account code
ARS tone dials digits to remote system CEID+Digits dialed by user.
Remote system strips CEID digits as local and dials Local DN as dialed by remote user.
Call terminates to DN.


*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[slapin]

Looks like they are trying to cut long distance cost. DISA calls will be billable by telco, while SIP is virtually free.

Problem noticed with SIP trunks.
1. Multiple hold/resume sometimes result in no audio problem
2. When call is being transferred multiple times the same no audio problem
3. No MWI or remote DSS
4. Conference is crapping out some times when one of the parties behind a sip trunk.

Bottom line:
It will work kind of ok, but expect issues like dropped calls or lost audio issues in fancy cases.

With native IP trunking you get the same signaling like inside the controller, just encapsulated in IP transport. So no protocol translation. At least no major differences. Protocol interworking is always been a tricky business.
Just name products for H.323/SIP translation, I think it would be enough fingers to count and all come with limitations. The same is here, translation of internal messaging protocol into SIP has lost of limitations and issues.
Just my $0.02

 

[kwbMitel]

Slapin, the stated goal is minimal voice traffic and basic functions.

Using SIP introduces more problems than it solves.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.