cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
802
Views
0
Helpful
8
Replies

Anyone using NM-CEM-4TE1 to replace PBX tie-lines

brian.a.balka
Level 1
Level 1

Is anyone out there using the Circuit Emulation over IP cards to replace PBX tie-lines. Today there are 4 T1s connecting two sites. Moving the sites to an OC-3 and want to push the voice traffic across with data traffic. It seems like it shouldn't be a problem but I don't have any experience with these modules and just wondering if anyone has some experience with them. Anything to be aware of?

8 Replies 8

amritpatek
Level 6
Level 6

A document that talks in & out about configuring Circuit Emulation over IP.

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801ee181.html

I have documentation on the module. I am looking for real world use of them. Anything to be aware of when trying to use them as a PBX tie-line replacement?

I have just seen reports about some significant delay!

over 100ms! I can't believe that. This application connects 4 E1 in a MAN area. So I cannot imagine where this delay comes from. I am in the process of getting more information here.

In comparison a pair of TDMoverIP Multiplexers of RAD showed delay around 5 ms on one E1 line transmitted. This sounds reasonable as packet assembly delay gets significant profit if you take 30 PCM samles in one PCM frame, and do not have to wait and collect from one audio stream.

Would be interested to hear from other users what the observed transfer delay in CEoIP is.

Wolfgang

cieftelecom
Level 1
Level 1

Hi, we are working with this kind of cards on 28XX. It's work fine with IOS 12.4(2)T and de-jitter buffer configured at 15ms. We have Gb lines between our sites. Before that, we have experienced echo on conversation.

Hi,

We are working to reduce the delay between two 2811s because the echo just would go away.So far the RTT is around 60ms. We managed to reduce the De-jitter buffer to 16ms, but the packet size is configured as 992bytes, couid you please let me know what is the configuration like in your router?

992 bytes is the default payload size for 31 channels (a full E1). This means 32 frames per packet, which is a serialization delay of 4 ms.

That does not sound unreasonable for me...

The command is "payload-size".

See http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_7/bbfeamod.htm#wp1049052

If you have any unused channels in the E1 reduce the number of timeslots in your "cem-group" command.

Really appreciated the reply.

As the PABX doesn't have the echo cancellation function, and the echo source is not easy to be tracked down at the moment, so reducing the delay appears to me that this is the best way to deal with echo. We were told to reduce the de-jitter buffer to 16ms as a recommendation. But as the network delay is around 8-10ms, plus the 4ms serailization, the echo would still be perceivable as the one-way delay is large than 25ms. Then it could be achievable if the de-jitter is being reduced to 11ms, so can we do it? and what side effect would be of doing that?

In a nicely QoS policed and managed LAN the de-jitter of 16 ms could be further reduced. I would say 8-12 ms. Do you have data about your network jitter? This cleary increases the chance for a playout-buffer underrun in the event of network jitter peaks.

The de-jitter works in finite units of packet, more than in ms. So with standard packet size, you can configure to hold 2,3 or 4 packets in the buffer. That corresponds to 8,12 or 16 ms.

Your target should be to hold the round trip delay under 50 ms. My experience is that 35-45 ms still is not perceived by humans. There is no hard treshold, except if you need to comply to a written quantified requirement.

You can decrease the packet size from the natural default to a smaller value, with the penalty of lower bandwidth efficiency. E.g. half the packet size will decrease the serialization delay by 2 ms. Not too much gain though.

In real life any VoIP link that allows telephony to the real world PSTN with analog subscribers asks for echo cancellation at the near end (before entering the IP cloud). In some installations where VoIP is reduced to low latency high-speed ethernet links it is possible to keep the delay down and be able to avoide echo cancellers.