cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
581
Views
0
Helpful
7
Replies

CB RTP header compression

rmv72
Level 1
Level 1

R 3745 ( IOS 12.3(4)) and R1760 ( IOS 12.3(7)) connected through MPLS VPN.

I enabled class-based RTP header compression on R 1760-

policy-map VoIP

class rtp

compression header ip rtp

priority 100

class SIGNAL

bandwidth 8

After it the quality of voice conversation decreased.

Why it's so?

1 Accepted Solution

Accepted Solutions

The routers on both end of a link must have compression enabled. The Rcvd 0 shows that the 1760 received no compressed packets, but sent 702. If the router on the other end is not set for compression, it will not be able to decompress the packets sent by your 1760. If the headers cannot be decompressed the packets cannot be forwarded by the router.

With MPLS you will not be able to use compression end to end. You may be able to use compression on the serial link from the 1760 to your service providers router, but it would require them to enable it on their side as well.

View solution in original post

7 Replies 7

dgahm
Level 8
Level 8

Are you sure that RTP header compression can be supported over MPLS?

A 'show ip rtp header-compression' will tell you if the compression is actually working. You should see send and rcv packet counts.

I am using RTP header compression over frame with no loss of quality.

it seems work -

#sh policy-map int s0/0

Serial0/0

Service-policy output: VoIP

Class-map: rtp (match-all)

9218140 packets, 587901751 bytes

5 minute offered rate 8000 bps, drop rate 0 bps

Match: protocol rtp

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 100 (kbps) Burst 2500 (Bytes)

(pkts matched/bytes matched) 261999/16585825

(total drops/bytes drops) 0/0

compress:

header ip rtp

UDP/RTP (compression on, IPHC)

Sent: 1413 total, 1411 compressed,

52149 bytes saved, 32573 bytes sent

2.60 efficiency improvement factor

99% hit ratio, five minute miss rate 0 misses/sec, 0 max

rate 4000 bps

The packet headers are being compressed, but are they being decompressed?

Please post the output from this command:

show ip rtp header-compression

It's output from regional router( R1760) where i enabled rtp header compression. Router 1760 connected to local PSTN through FXO interfaces. The calls from local PSTN forwards to central HQ through MPLS-VPN to CCM. When i call from local PSTN i can hear other side w/o problem ( R 3745 from other side don't use RTP header compression), but they don't hear my voice ( my router use RTP header compression).

#show ip rtp header-compression

RTP/UDP/IP header compression statistics:

We're compressing using MQC profiles, use the

MQC commands to see the stats for each class.

Interface Serial0/0 (compression on, IPHC)

Rcvd: 0 total, 0 compressed, 0 errors, 0 status msgs

0 dropped, 0 buffer copies, 0 buffer failures

Sent: 704 total, 702 compressed, 0 status msgs, 39 not predicted

25659 bytes saved, 16323 bytes sent

2.57 efficiency improvement factor

Connect: 386 rx slots, 386 tx slots,

2 misses, 0 collisions, 0 negative cache hits, 385 free contexts

99% hit ratio, five minute miss rate 0 misses/sec, 0 max

The routers on both end of a link must have compression enabled. The Rcvd 0 shows that the 1760 received no compressed packets, but sent 702. If the router on the other end is not set for compression, it will not be able to decompress the packets sent by your 1760. If the headers cannot be decompressed the packets cannot be forwarded by the router.

With MPLS you will not be able to use compression end to end. You may be able to use compression on the serial link from the 1760 to your service providers router, but it would require them to enable it on their side as well.

is't necessary to use RTP header compression at both sides?

CRTP should be enabled on both sides of the link.