Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

One-way issue using cRTP in the WAN

Hi,

Anybody knows what means this message?

This message happens WHEN:

1. First we just has one-way audio,

2. Then the compression mechanism resynchronize

3. Finally then the call works fine.

1. ONE-WAY AUDIO

-------------

*Jun 26 21:29:21.309: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 IPCRC incorrect

*Jun 26 21:29:21.309: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 IPCRC incorrect

*Jun 26 21:29:21.309: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 IPCRC incorrect

*Jun 26 21:29:21.309: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 IPCRC incorrect

*Jun 26 21:29:21.309: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 IPCRC incorrect

*Jun 26 21:29:21.309: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 IPCRC incorrect

*Jun 26 21:29:21.309: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 IPCRC incorrect

SYNCHRONIZING IP HEADER-COMPRESSION

------------------------------------

*Jun 26 21:29:21.309: IPHC(UDP) Se0/1/0.1 DLCI 124: Invalid sequence (cs 3, recv. 12, exp. 5)

*Jun 26 21:29:22.429: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 rate limited resync

*Jun 26 21:29:22.441: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 rate limited resync

*Jun 26 21:29:22.441: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 rate limited resync

*Jun 26 21:29:22.441: IPHC(UDP) Se0/1/0.1 DLCI 124: CS 3 rate limited resync

TWO-WAY AUDIO

-------------

*Jun 26 21:29:33.653: IPHC(UDP) Se0/1/0.1 DLCI 124: Ignoring UDP packet (3031->389)

*Jun 26 21:29:33.657: IPHC(UDP) Se0/1/0.1 DLCI 124: Ignoring UDP packet (3031->389)

*Jun 26 21:29:33.833: IPHC(UDP) Se0/1/0.1 DLCI 124: Ignoring UDP packet (3031->389)

*Jun 26 21:29:33.837: IPHC(UDP) Se0/1/0.1 DLCI 124: Ignoring UDP packet (3031->389)

Thanks

2 REPLIES
Community Member

One-way issue using cRTP in the WAN

Hi

Did you ever find a solution for this?

I have hit on the same problem. I am trying to use SIP signalling with IOS 15 on remote router. I experience the same one-way audio problem, coincides with the same error.

In addition, I also a "failed to fastswitch" error

Oct 01 13:14:18 10.130.186.30 5652: Oct  1 13:14:19.230: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:18 10.130.186.30 5653: Oct  1 13:14:19.246: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:18 10.130.186.30 5654: Oct  1 13:14:19.250: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:18 10.130.186.30 5655: Oct  1 13:14:19.262: IPHC(UDP) Se5/7.1 DLCI 100: CS 0 IPCRC incorrect

Oct 01 13:14:18 10.130.186.30 5656: Oct  1 13:14:19.262: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:18 10.130.186.30 5657: Oct  1 13:14:19.266: IPHC(UDP) Se5/7.1 DLCI 100: CS 1 IPCRC incorrect

Oct 01 13:14:18 10.130.186.30 5658: Oct  1 13:14:19.266: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:18 10.130.186.30 5659: Oct  1 13:14:19.286: IPHC(UDP) Se5/7.1 DLCI 100: CS 0 IPCRC incorrect

Oct 01 13:14:18 10.130.186.30 5660: Oct  1 13:14:19.286: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:18 10.130.186.30 5661: Oct  1 13:14:19.290: IPHC(UDP) Se5/7.1 DLCI 100: CS 1 IPCRC incorrect

Oct 01 13:14:18 10.130.186.30 5662: Oct  1 13:14:19.290: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:19 10.130.186.30 5663: Oct  1 13:14:19.302: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:19 10.130.186.30 5664: Oct  1 13:14:19.306: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:19 10.130.186.30 5665: Oct  1 13:14:19.326: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

Oct 01 13:14:19 10.130.186.30 5666: Oct  1 13:14:19.326: IPHC(UDP) Se5/7.1 DLCI 100: Failed to fastswitch

I changed the config slightly to try to fix. Before I was using FR traffic shaping:

policy-map WAN-EGRESS-512/512-8CALLS

class VOICE

  priority 318

   compress header ip rtp

  .....

  class class-default

   fair-queue

   random-detect

map-class frame-relay Voice&Data-512/512-8CALLS

frame-relay cir 512000

frame-relay bc 51200

frame-relay be 0

frame-relay mincir 512000

service-policy output WAN-EGRESS-512/512-8CALLS

int s5/7

frame-relay traffic-shaping

int s5/7.1 point-to-point

frame-relay interface-dlci 100

  class Voice&Data-512/512-8CALLS

I changed this to

policy-map VOICE&DATA-512/512-8

class class-default

  shape average 512000 5120 0

  shape adaptive 512000

  service-policy WAN-EGRESS-512/512-8CALLS

interface Serial5/7.1 point-to-point

frame-relay ip rtp header-compression periodic-refresh

service-policy output VOICE&DATA-512/512-8

(it's essentially the same, only I moved from FR traffic shaping to MQC and put compression on the interface direct instead of the policy-map)

Same result, but the periodic-refresh seems to shorten the error time to 2 seconds. (This option was not available in policy-map command)

Did you by chance resolve? Was this to do with a mismatch of IOS version in the connected routers?

I found this bug:

Cisco bug  CSCsd91454

RTP calls get disconnected when cRTP enabled

Symptom: Person 'A' and 'B' speaking. At some random point during the call, person A would stop being able to hear person B, person B would still be able to hear person A and if the call was put on hold, then resumed, both would be able to speak and listen normally till this happened again. Conditions: Have seen the issue on links with 768k bandwidth Workaround: Disable cRTP

Unfortunately we are running low capacity sat links and need to squeeze every drop of b/w. disabling is not really an option.

Many thanks

Phil

Hall of Fame Super Gold

One-way issue using cRTP in the WAN

The bug shows;

Fixed-In Fixed-in

12.4(4)XC6

12.4(4)XC7

12.4(4)XD5

12.4(6)T6

12.4(9)T3

12.4(11)T

12.4(11)XV1

12.4(12.3)T

12.4(12.4)PI6

12.4(6)XE3

12.4(11)XJ5

12.4(22.3.4)PIC1

12.4(24.5.2)PIC1

If you are running software newer than that on both routers, you will have to contact TAC and open case.

399
Views
4
Helpful
2
Replies
CreatePlease to create content