Voice over Ip over frame

[r-godden]

scenario 2 sites connected via frame-relay.

Should i use 2 pvc's , one for data and one for voice

or would interleaving and fragmentation mean only

one pvc is required.

second question, is path optimisation h175/176 using qsig supported yet ?

[dgoodwin]

If you are doing VoIPoFR then you should not need 2 separate PVCs, you can use LLQ over the frame relay to prioritize the voice and signaling paths. See:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/dtfrpqfq.htm

You should need to use fragmentation in the frame-relay map-class if your CIR is slower than about 768kbps.

About your second question... are you referring to "anti-tromboning" where if a call is transferred or forwarded back out the same path as the originating call leg, that 0 bearers will be tied up instead of 2? I don't know that this is supported natively in the Q.SIG support in Cisco IOS yet, but if you have Q.SIG PBXs on both sides of the connection you could use the Transparent CCS feature to carry the signaling between the PBXs supporting this feature and it should work. See:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dt_tccs.htm

[sergio.ribeiro]

Hi David,

I read your answer, but I have a doubt related with the same issue, for example if I'm using 2 PVCs, one for data and other one for voice, why can I need to use fragmentation at both PVCs? I'm asking you because I already made some tests, and I can verify that, if take out the fragmentation from voice PVC the quality goes worst (when the link is partly full), could you please explain me?

Thanks for your help,

Sergio Ribeiro

Equant Brazil.

[dgoodwin]

Whether or not you need to do any kind of fragmentation has nothing to do with the number of PVCs or the CIR. It has everything to do with the actual circuit speed. The lower the circuit speed (the cut-off tends to be anything less than 768kbps) then the longer it will take to serialize large data packets that have not been fragmented -- e.g. a 1500 byte data transfer packet.

http://www.cisco.com/warp/public/788/voice-qos/qos_basics.htm

While the large packet is being serialized and placed onto the wire for transmission, the voice packet(s) has been waiting for so long that the far end has no voice to output to the other party on the call. And since this is going to occur in a staggered fashion, the interarrival time for the voice packets is not going to be the same. Instead of having a packet arrive every 20ms for example, you will get one at 20ms, another one at 30ms, another one at 200-300ms, another one at 20ms, etc. This is jitter.