Hi as yet I haven't had any feedback from anywhere I have tried, the feeling is that it can be done but as yet we have seen no evidence.

Regards

Steve Whitfield

Have you thought about using QSIG trunks instead of trying to figure out how to tunnel MSDN? Would QSIG work for you?

We feel that T-CCS will work in this environment. T-CCS should transparently tunnel MCDN over an IP Network. As for using QSIG, we would rather not have to force the customer to make changes to their PBX's.

Thanks for the suggestion.

We have set up TCCS for the MCDN signaling in the past and it works OK. The only issue is that it takes up DSP resource and the processing through the DSP adds some extra delay to the packet. Past experience with the Nortel proprietary signaling is that it can be extremely delay intolerant and the trunks may be busied out by the PBX due to traffic not arriving in the expected time window.

We have fixed this problem by using the legacy STUN feature - this allows a HDLC framed packet to be taken in on a timeslot and tunneled across the IP network to a corresponding interface at the remote site.

Instead of configuring the timeslot for the D channel as a DS) group, you configure it as a channel-group. This creates a 'interface serial ...' which can be set as STUN encapsulation.

As a packet comes into the interface, it is wrapped in a IP header and forwarded to the configured destination.

STUN uses TCP port 1994, so if necessary, you can configure a dedicated LLQ class for the signaling traffic.

Attached is a sample config that shows how to set up the STUN for E1 interfaces, the associated voice port configs and some basic QOS statements.

This config has been used on many types of PBX brands including NEC, Nortel, Avaya, Alcatel and Rolm.

On the ISR range of routers, the basic IPVoice feature set does not have the STUN feature, so you will need to ensure you have one of the more advanced feature sets running on the routers.