MSDN over T1/E1

[danramirez]

Hi Guys,

Any guidelines to establish an MSDN link between two 3300?

I remember doing this long ago in a course for the SX2K.

Regards,

Daniel

http://www.hatkana.com

http://www.wtelecom.com

 

[kwbMitel]

you say T1/E1 but do you mean PRI?

**********************************************
What's most important is that you realise ... There is no spoon.

 

[danramirez]

Hi kwb,

I meant to use DPNSS

Cheers,

Daniel

http://www.hatkana.com

http://www.wtelecom.com

 

[kwbMitel]

You MUST have NSU's (not embedded module)
You MUST have xnet option enabled

If you have those, I can help you.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[Supernova99]

MSDN/DPNSS can be programmed on embedded not just NSU's
I suppose it depends on what you are trying to do.

Share what you know - Learn what you don't

 

[kwbMitel]

@Supernova, the setup using embedded is incomplete.

NOTE:The TDM XNET feature is not available on embedded T1/E1 framer modules (either dual or single), because it requires High-level Data Link Control (HDLC) resources which are not available on the modules. TDM XNET is supported only on migrated SX-2000 PRI cards and the Universal NSU. Hybrid XNET, however, is available on all digital trunks, including both single and dual embedded T1/E1 modules.

With Embedded modules you have a hybrid option where IP is used for the signalling channel.

This feature is useful where LAN infrastructure exists, but the available bandwidth is not adequate for full voice-over-IP support. In such situations, voice quality over the LAN may be poor, so the alternative approach of carrying voice over TDM may be the best solution.

So, as long as you have some LAN connectivity, then embedded can be used.

Without LAN connectivity, NSU's must be used.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[Supernova99]

Hi KWB yes I understand that but the original post did not mention XNET only MSDN/DPNSS
XNET can as you correctly state only be done via PRI on NSU or hybrid XNET on embedded PRI with LAN for signalling.
For everything else DPNSS supports full MSDN between systems.
Perhaps Dan can enlighten what he is trying to do.



Share what you know - Learn what you don't

 

[danramirez]

kwb and supernova,

I'll tell you guys why I'm doing all this: I have two 3300s in different locations, they are networked together using IP Networking (Mitel IP Trunks) over IPSec VPN. I have a SIP trunk provider connected to PBX in location A (MBG is used as SBC) and this provider only allows traffic from Public IP address in location A. So, when users in location B tried to use SIP trunks in location A, we got no audio whatsoever. By looking at the firewall sessions at firewall in B I noted that audio was trying to reach SIP provider directly from Public IP in B, and of course provider rejected audio as this was not an IP recognized by them.

So, what I'll do is to send calls from B to A over IP Tunking, then once the call reaches A I will loop the call (here is where I need DPNSS) from PBXA to PBXA to keed the call as TDM and them send it to normal ARS to use SIP trunk at location A. This way the call will be sent to the SIP provider from the E2T on PBX A.

I know this very costly as I am using two digital link licenses but it will solve me problem.

I already did the programmimg for the DPNSS loop trunk and it worked perfectly, it was enough with simple DPNSS and didn't need Xnet. I did it using two T1/E1 Combos.

Do you know of any other way to force the call to go the the Internet using Public IP Address at location A??

Cheers,

Dan

http://www.hatkana.com

http://www.wtelecom.com

 

[kwbMitel]

OK, That was not anywhere near expectations.

Correct me if I'm wrong but it seems that the goal here is to strip the IP header info from site B and originate the call on Site A with Site A IP info.

There are several ways this might be accomplished.

What I would be looking at first is the embedded analog trunks/stations. If these are not currently in use, then you have the potential of 4 easy speech paths for this purpose.
[ul]
[li]Call originates from Site B over IP trunking to Site A[/li]
[li]Call Seizes Analog trunk on Site A[/li]
[li]Analog trunk is looped back to Analog station on Site A[/li]
[li]Call is dialed out of site A from originating analog extension without any IP header info from site B[/li]
[/ul]

Does that seem feasible?



**********************************************
What's most important is that you realise ... There is no spoon.

 

[danramirez]

Hi kwb, that is exactly what I need, to remove the Ip infomation from site B and send the call to sip provider with ip information from site A.

Using analog trunk/stations will not allow me to Dial In from site B, unles I do things like DiSA, which I don't fancy very much.

Remember that users from B will dial pstn numbers using sip trunks at A, that's why I'm thinking I need Dial in trunks to do this. The other option I had was to use the quad bri frammer which will give me 8 channels of DDI trunks and don't use digital link licenses but don't like this as embeded bri tunks does not provide state as not seizable when diaconnected.

I will do some testings today with my two T1/E1 frammers and my DPNSS

I will post back later on today, cheers,

Daniel

http://www.hatkana.com

http://www.wtelecom.com

 

[Supernova99]

Hi Dan,
I am sure you can do this without the need of TDM conversion.
In the SIP Peer Profile in the Call Routing section there is an option 'Alternate Destination Domain Enabled' when enabled will allow the header to be changed.

Select 'Yes' to allow the administrator to specify the alternate domain to be used for this peer. Enter the alternate domain name. For example, when using the Microsoft Live Communications Server (LCS), the Office Communicator endpoint on the peer side may be in a different domain than the LCS.

When enabled, this option will insert the alternate FQDN or IP Address into the To header. In addition, the FQDN or IP Address may be used to find the appropriate Peer Profile on incoming calls.
Enter the Fully Qualified Domain Name or IP Address of the Alternate Destination Domain.

Note: Use this setting if the telephone service provider validates the domain name in the 'From address' field of SIP messages. This parameter modifies the 'To address' field so that it conforms to the following format: <Destination>@<DomainName> (for example, +61290239500@mitel.com)

Also there is another option 'Use To Address in From Header on Outgoing Calls'
When this option is enabled (set to 'Yes') the Address used in the SIP From header line will no longer be the physical 3300 IP address or FQDN. Instead the address will be replaced by the address to which the outgoing call is sent. Some providers require this for authentication purposes as it makes it look like the 3300 ICP is in the same domain as the SIP Server or SBC (Session Border Controller).

This option does not work with the 'Alternate Destination Domain FQDN or IP address' option. When the 'Alternate Destination Domain FQDN or IP address' option is enabled, the From Header continues to use the FQDN specified for this peer in the Network Elements form.

Have you tried/considered these options for what you are trying to do?
It is entirely possible to do LCR local breakout with SIP, it might take a bit of fiddling around with settings to get it working correctly.

Share what you know - Learn what you don't

 

[danramirez]

Supernova, your suggestion seem to be a more prefessional way to sort this out. I will give it a try and let you know. Thanks a lot, cheers

http://www.hatkana.com

http://www.wtelecom.com

 

[kwbMitel]

Agreed, I don't see much SIP where I'm from so I can't advise on that.

**********************************************
What's most important is that you realise ... There is no spoon.