[c-nsp] QOS for VOIP 1811

[Yann Gauteron]

Hi Paul,

If I understand well, you're doing VoIP over a PPPoE link.

I never tried such a configuration (does not mean it should not work, just I
never had the chance to have to implement it), but as you're mentionning
that voice quality is not good, I would consider:
1) First thing very surprising to me is your class maps definitions: both
use the very same matches (match access-group 155 for Voice and Signalling).
This sounds as incompatible for me as you can not define that signalling is
matching one ACL, and that VoIP RTP streams is matching the exactly same ACL
- that is the same source/destination addresses and ports. Try to split RTP
and signalling into two different ACLs.

You're using an SBC which can perform the B2BUA behavior for both SIP
signalling and RTP flows I guess, then the following should be better (if
your LAN net is 172.16.100.0/24 and your SBC is at 192.168.200.200):
ip access-list extended aclVoipSignalling
 permit udp 172.16.100.0 0.0.0.255 eq 5060 host 192.168.200.200 eq 5060
ip access-list extended aclVoipRTP
 permit udp 172.16.100.0 0.0.0.255 host 192.168.200.200

class-map match-all Call-Signalling
  match access-group name aclVoipSignalling

class-map match-all Voice
  match access-group name aclVoipRTP
  match not access-group name aclVoIPSignalling

This way you ensures that class map Voice excludes SIP signalling. You can
also add a deny udp on ports 5060 in the ACL directly. This is a more
philosophical question now.

However this should not explain (to me) why your "show policy-map" displays
some traffic flowing in your "Call-Signalling" class ("(pkts output/bytes
output) 56/42988")

2) If 1 does not solve your problem. If your codec is G.711, increasing the
bandwidth reserved in your LLQ (priority command) to (let say) 120kbps.
PPPoE adds additional headers and headers are considered in
reserved/guaranteed bandwidths. If problem is solved, then you can start to
compute the exact value to allocate by knowing the codec, packetization
rate, IP+UDP+RTP headers, PPPoE headers. It's too early here now to start
for me computing this value (06:45am).

3) If 2 does not solve your problem. If your codec is G.711, ensure that
only one call is flowing over your PPPoE link. A second call would degrade
the overall quality of both calls, as the priority would police the traffic
exceeding 100kbps.

Good luck in your troubleshoot and let us know.

Cheers,
Y.