Mitel 3300 to 3300 via SIP Trunks

[ralph]

I'm playing with our lab system.
I'd like to connect our lab 5.0 system to our production system via SIP.

I couldn't find any "how-to" documents on MOL.
Anyone have a system connected this way that can share the SIP peer settings?

Ralph

[wiseguy]

I've done this several times for temporary test purposes and left all options set default.

[brantn]

Why SIP and not just IP trunks? But yes defaults should work since it is Mitel Prop SDP.

[ralph]

Why SIP and not just IP trunks? But yes defaults should work since it is Mitel Prop SDP.

This is experimental on my part.
But also, what our sales reps are telling me, if you have a non clustered environment it is substantially less expensive.  You don't have to purchase enterprise licenses for every phone.   Less expensive can translate to 'sell more systems'.

My next experiment I'd like to try is setting up an Asterisk box with SIP trunks to the 3300.   Several things I'm curious about but first I have to figure out how to even set one up.

Ralph

[ralph]

So my 1st pass at this isn't going as well as I'd hoped.
My production system is 4.2  and my lab ssytem is 5.0

Used all defaults for the SIP peer info.

Set x3658 from production sys to dial the lab system.  In the lab system 3658 is a speed dial to 500 -(AA).
When I call it, it's ringing x100.   SMDR shows what I'd interpret as my extension (3691) dialing 100.

So now I have to dig into a couple of things.   
1- how is it hitting 100?  There's no intercept to that.
2 - why isn't it dialing 500.

SIP traces show the correct 'to' number of 3658.

Still working through it.

Ralph

[ralph]

Just figured it out.
As I suspected it was an ID-Ten-T error.
Put the wrong Trunk Attribute number in the SIP peer profile.

Now to play...

Ralph

[brantn]

I hate ID-10-T errors. It might be cheaper but seriously devaluing sds and central admin is going to cost a lot more in the long run. When will sales people learn just cause it can be done doesn't mean it should be done. Same reason I don't burn cow pies in my fireplace.

[ralph]

Same reason I don't burn cow pies in my fireplace.

Love that!


I agree about the SDS and central admin.  Also loose resiliency.   
But...   When in a competitive situation where your choice is to sell a less optimal system or loose the sale completely it better to have options.

My next steps are to figure out what does or doesn't work

So Far:
Caller ID: ok
MOH - OK
MOH on transfer - OK

Still needing to check:
Conf calls  - two SIP trunks
SIP to SIP xfer - without tromboning.
Centralized VM with message waiting.

Ralph



 

[brantn]

I am with you on competition.

[ralph]

Ok,
Here's where I'm at now:
Working on centralized VM.
The message waiting work with no issues.
What doesn't work is forwarding a phone from one system to the other.   Although it does forward, it doesn't get to the mailbox.  Just get's to the AA.
I'm thinking this won't work for centralized VM.

Unless someone has a work around they'd like to share....

Ralph

[brantn]

Thinking out loud since I dont have time to lab anymore. But my thought is like Exchange UM reroute a speedcall to ars to vm? So laying it out

Extn 1000 RR FA to 7666
7666 is speed call to 7888 thru ars going to the VM Hunt group 7888 in VM PBX.

Extn 2000 RR FA to 7888 local VM Hunt group 7888.

I wouldn't see why it wouldn't work like Exchange as it is the same concept.

[ralph]

I can get the call to the VM but it gives me AA.
So I believe what is happening is the SIP trunk is not forwarding the rerouting information so the system doesn't know that it was a forwarded call.

I can think of a work around with NuPoint and alternative extensions but not with the embedded.

On second thought...   What if I set up a special ARS that used Advanced Analog Networking to insert digits?  Hmmmm.


Ralph