Friday, December 9, 2011

Cisco HWIC EtherSwitch (ESW) Module - QoS Support


HWIC ESW can be connected to IP Phones when it’s configured for untagged, dot1p, or none mode for voice vlans.

HWIC module has limited support to QoS features (the new hardware NM-ESW has much powerful QoS capabilities).

In HWIC-ESW, MLS QoS is enabled globally and can’t be disabled. Also, MLS QoS trust/untrust interface commands aren’t functional although they are configurable (the commands can be applied per interface to trust dscp or cos but they aren’t effective and this can be confirmed using ‘show mls qos interface ’ command).

interface FastEthernet0/3/2
 switchport access vlan 20
 switchport stacking-partner interface FastEthernet0/3/2
 mls qos trust cos
end

RTR#sh mls qos int fa0/3/2
FastEthernet0/3/2
trust state: not trusted
trust mode: trust cos
COS override: dis
default COS: 0
pass-through: none

But then if trust/untrust aren’t functional, how HWIC QoS works??

Each interface in HWIC module has two egress queues which are high and low priority queues. Incoming packets with dot1q tag will be mapped to egress queues (low queue or high queue) based on their CoS values as follow:

-          Packets are buffered in a high-priority queue for CoS values 4 to 7 and scheduled for expedited forwarding.
-          The low-priority queue is used for packets with CoS values 0 to 3

For untagged frames, they will be assigned the default CoS value configured per-port. Based on the CoS value configured on the port, ingress frames through that port will be assigned to egress queues (low and high).

interface FastEthernet0/3/2
 mls qos cos 4

VERY IMPORTANT: Note that the frame never gets tagged during this process. They will be only assigned to queues based on CoS without tagging.

Also, HWIC support CoS override feature to rest the CoS values of tagged frames to default one. Accordingly all frames entering that port will be assigned to same queue based on default CoS value.

interface FastEthernet0/3/2
 switchport access vlan 20
 switchport stacking-partner interface FastEthernet0/3/2
 mls qos cos 4
 mls qos cos override
end

RTR#sh mls qos int fa0/3/2
FastEthernet0/3/2
trust state: not trusted
trust mode: not trusted
COS override: ena
default COS: 4
pass-through: none

HWIC module doesn’t have ingress queues similar to catalyst switches. Traffic entering the ingress port is sent directly to the shared memory or CPU, depending on the priority.

Caller ID Display over ISDN PRI - PART 2

Mapping ISDN Display/Facility IEs to H323/SIP/MGCP Protocols


Mapping to H323 is one-to-one job since both ISDN and H323 are using same functional structure.
-          ISDN Display IE will be sent directly as H323 Display IE
-          ISDN Facility IE will be converted to H323 Display IE (after enabling the required features).

We just mentioned that “since Facility IE isn’t recognized by phone or CUCM” !! Then if CNAM is received over the PRI trunk as facility IE and CNAM as supplementary service isn’t enabled on the gateway, facility IE will be forwarded to CUCM without decoding and CNAM won’t be displayed since Facility IE isn’t recognized by phone or CUCM H323 Trunk

However, two features have been introduced in IOS 12.4(11)XW to fix this problem:

1.       When a Q.931 Setup message with a "name-to-follow" indication is received from an ISDN switch, the gateway can buffer the setup message until the subsequent Q.931 Facility message with calling name information is received. The name information from the Q.931 Facility message is now placed into the H.323 Setup message Display IE and sent to CUCM. If the buffer timer expires before the Q.931 Facility message is received, an H.323 Setup is sent with no name information and, if it subsequently arrives, the information is sent on using an H.323 Notify message.

At the voice service level:

voice service voip
  h323
  h225 timeout ntf <50-5000>
  isdn supp-service name calling

At the voice class level:

voice class h323 1
  h225 timeout ntf <50-5000>
  isdn supp-service name calling


2.       When a Q.931 Setup message with a "name-to-follow" indication is received from an ISDN switch, an H.323 Setup message with no name information is sent to CUCM. When the subsequent Q.931 Facility message is received with calling name information, it is mapped by the gateway to an H.323 Notify Display IE so that CUCM can interpret it correctly and display it on the IP Phone

At the voice service level:

voice service voip
  h323
    h225 display-ie ccm-compatible

At the voice class level:

voice class h323 1
  h225 display-ie ccm-compatible [system]

Now we are clear about mapping display between H323/ISDN in case Display IE is used or Facility IE. What about display map between SIP/ISDN??

The caller ID information is passed through from the ISDN-to-SIP by copying the number in the Calling Party Number IE in an ISDN Setup message into the Calling Number field of the SIP Remote-Party-ID and From headers.

The Calling Name from the ISDN Display IE is copied into the SIP Display Name field in the SIP Remote-Party-ID and From headers.

*Mar  1 12:13:05.084: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:2001@100.100.100.100:5060 SIP/2.0
Date: Fri, 10 Sep 2010 08:51:07 GMT
Call-Info: ;method="NOTIFY;Event=telephone-event;Duration=500"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
From: ;tag=cae0565b-8d47-419c-8985-9aaae65055d7-19223684
Allow-Events: presence, kpml
P-Asserted-Identity:
Supported: timer,resource-priority,replaces
Min-SE:  1800
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Content-Length: 0
User-Agent: Cisco-CUCM7.0
To:
Contact:
Expires: 180
Call-ID: 8bc81500-c891f17b-42-832ca8c0@192.168.44.131
Via: SIP/2.0/TCP 192.168.44.131:5060;branch=z9hG4bK5b7d08e5bb
CSeq: 101 INVITE
Session-Expires:  1800
Max-Forwards: 70

The Calling Party Number IE contains a Presentation Indicator (PI) field that is set to presentation allowed, presentation restricted, number not available due to interworking, or reserved. Presentation allowed and presentation restricted are translated into privacy set to off or privacy set to null, respectively, in the SIP Remote-Party-ID header field. This means that SIP is marking that Calling Number IE as private but its not removing it from SIP message. To strip this information from SIP message so that its not sent to the next-hop (instead of marking it as private ONLY),

voice service voip
 clid strip pi-restrict all
!
dial-peer voice dial-peer-number voip
 clid strip pi-restrict all

SIP support display name substitution. When this is enabled, if there is no Display Name field in Display IE but there is a number, it copies the number into the Display Name field, so the number is displayed on the recipient's Call-ID display.

voice service voip
 clid substitute name
!
dial-peer voice dial-peer-number voip
 clid substitute name

The display information can be mapped as well to P-Asserted-Identity Header or P-Prefered-Identity header instead of Remote-ID header. This depends on the implementation of SIP protocol.

Nov 12 00:10:21.615: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:3001@142.6.65.254:5060 SIP/2.0
Via: SIP/2.0/UDP 142.6.64.254:5060;branch=z9hG4bKAB58
From: "5001" ;tag=141484-508
To:
Date: Sat, 12 Nov 2011 00:10:21 GMT
Call-ID: 8B999D14-BF911E1-801EE53F-B7CD48C9@142.6.64.254
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2341900212-200872417-2149115199-3083684041
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1321056621
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
P-Asserted-Identity: "5001"
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 238

v=0
o=CiscoSystemsSIP-GW-UserAgent 6045 3096 IN IP4 142.6.64.254
s=SIP Call
c=IN IP4 142.6.64.254
t=0 0
m=audio 16474 RTP/AVP 18 19
c=IN IP4 142.6.64.254
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:19 CN/8000
a=ptime:20

Typical implementation of PAI and PPI will follow this:

The P-Preferred-Identity header field is used by user agent to proxy to carry the identity the user sending the SIP message wishes to be used for the P-Asserted-Header field value that the trusted element will insert.

The P-Asserted-Identity header field is used to carry the identity of a user sending a SIP message after getting authenticated by SIP Proxy server. Usually SIP Proxy server will replace PPI with PAI.

To enable/disable those three SIP headers:

PAI

voice service voip
 sip
   asserted-id pai
!
or
!
dial-peer voice 1 voip
 voice-class sip asserted-id pai
 session protocol sipv2

Remote-ID

sip-ua
 remote-party-id

PPI

voice service voip
 sip
   asserted-id ppi
!
or
!
dial-peer voice 1 voip
 voice-class sip asserted-id ppi
 session protocol sipv2


What about MGCP gateways ?? How is CNAM display handled ??

On MGCP gateways, CNAM can be displayed using both display IE as well as Facility IE. However, this is controlled from CUCM MGCP Gateway configured. No changes are required on local gateway since Q931 messages are backhauled to CUCM.


‘qsig decode’ feature can’t be used in mgcp gateways and therefore called name can’t be displayed.

Note:
Any changes done on MGCP gateway (such as enabled display IE, enabled facility IE, enabled progress IE, etc) in CUCM requires restart of mgcp service on gateway using ‘no mgcp / mgcp’ commands.

In digital networking (SIP or H323) both called and calling name/number will be displayed on both phones (calling and called). This is the beauty of digital networking compared to analog SIMPLICITY !!

DNS Performance Troubleshooting

When you are troubleshooting internet performance, there are different parts of the connection should be verified:   ·         DNS Pe...