VBR-NRT values for Polycom RMX Videoconference H264 High Profile

Unanswered Question
Sep 25th, 2013
User Badges:

Hello, we have HQ with 5 remote sites and videoconference on our old Polycom videoconference bridge worked fine. The new RMX Polycom videoconference bridge sends bursts up to 80% of it's configured bandwidth and it's creating video issues (blocks on the TV screen).


The new Polycom bridge is configured to do HD using H264 high profile @ 512 kilobits per seconds.

What is the uptimum VBR-NRT values for videoconferencing? Our WAN provider is suggesting vbr-nrt 2442 2442 1 but that does not seem right for a T1.


CURRENT: vbr-nrt 1792 1792 1

TEST: vbr-nrt 1792 1692 100 (IT'S BETTER BUT STILL NOT ACCEPTABLE)


configs:


HQROUTER3725-OC3>

class-map match-all llq-video

match access-group 101

policy-map llq

class llq-video

  priority 768

!

interface ATM1/0

description SIP ID XXXXXX/000036/UCN/001

mtu 1500

no ip address

atm ilmi-keepalive

pvc 0/16 ilmi

  ilmi manage

!

!

interface ATM1/0.101 point-to-point

description 1536K circuit ID JXXXXXXXXXX

ip address X.X.X.X 255.255.255.252

no ip mroute-cache

pvc 1/136

  vbr-nrt 1792 1792 1

  encapsulation aal5snap

  service-policy output llq

!

!

interface ATM1/0.102 point-to-point

description 1536K circuit ID XXXXXXXXX

ip address X.X.X.X 255.255.255.252

no ip mroute-cache

pvc 1/102

  vbr-nrt 1792 1792 1

  encapsulation aal5snap

  service-policy output llq

!

!

interface ATM1/0.103 point-to-point

description 1536K circuit ID XXXXXXXXX

ip address X.X.X.X 255.255.255.252

no ip mroute-cache

pvc llq 1/103

  vbr-nrt 1792 1792 1

  encapsulation aal5snap

  service-policy output llq

!

!

interface ATM1/0.104 point-to-point

description 1536K circuit ID XXXXXXXXX

ip address X.X.X.X 255.255.255.252

no ip mroute-cache

pvc 1/104

  vbr-nrt 1792 1792 1

  encapsulation aal5snap

  service-policy output llq

!

!

interface ATM1/0.105 point-to-point

description 1536K circuit ID XXXXXXXXX

ip address X.X.X.X 255.255.255.252

no ip mroute-cache

pvc llq-wpg 1/137

  vbr-nrt 1792 1692 100

  encapsulation aal5snap

  service-policy output llq

!

!

*************************************


REMOTEROUTER1721-T1>

class-map match-all video

match access-group 101

policy-map videoqos

class video

  priority 768

!

!

interface Serial0/0

description Allstream SIP ID 08/XXXXXXXXX/UCN/001 - 1536K

bandwidth 1536

no ip address

encapsulation frame-relay

ip route-cache flow

no ip mroute-cache

no fair-queue

frame-relay traffic-shaping

!

interface Serial0/0.19 point-to-point

description 1536K PVC WPG to Ottawa - IP

bandwidth 1536

ip address X.X.X.X 255.255.255.252

ip nbar protocol-discovery

ip pim dense-mode

snmp trap link-status

frame-relay class cirb

frame-relay interface-dlci 23 IETF

!

map-class frame-relay cirb

frame-relay cir 1536000

frame-relay mincir 1536000

service-policy output videoqos

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joseph W. Doherty Wed, 09/25/2013 - 10:48
User Badges:
  • Super Bronze, 10000 points or more

Disclaimer


The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.


Liability Disclaimer


In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.


Posting


If your video improved when you set a lower SCR, I would suspect the ATM PVC is overrunning the frame-relay T1.  Once again set PCR and SCR to same values, but try other lower values (perhaps in 50K increments).  Unfortunately as ATM overhead varies per packet, there's no 1:1 conversion.


What you can also try is reducing hardware FIFO queues, both on the ATM and frame-relay interfaces.  Set smaller or minimum tx-ring-limits.


Also on the frame-relay size, don't muck with CIR shaping; just use full interface bandwidth.  (If CIR is a real issue, increase it so it isn't.)


Are you seeing any drops on your LLQ?  If so, try increasing its bandwidth allocation.

Actions

This Discussion