Tuesday, April 17, 2012

CME IPv6 Support

I have captured few notes from Cisco articles about IPv6 support for CME and thought to share them.

CME provide support for IPv6 for SCCP phones ONLY starting from version 8.0. The following SCCP phones and devices are supported on IPv6: 7911, 7931, 7941G, 7941GE, 7961G, 7961GE, 7970G, 7971G, 7971G-GE, 7942, 7962, 7945, 7965, 7975, SCCP analogue gateway, Xcoder, and Hardware Conference devices.

CME can run in IPv4 mode only, IPv6 mode only, or Dual-Stack (both IPv4 & IPv6).

telephony-service
 ip source-address {ipv4 address | ipv6 address} port port [secondary {ipv4 address | ipv6 address}
 protocol mode {ipv4 | ipv6 | dual-stack [preference {ipv4 | ipv6}]}

Example,

telephony-service
protocol mode dual-stack preference ipv6
....
ip source-address 10.10.2.1 port 2000
ip source-address 2000:A0A:201:0:F:35FF:FF2C:697D

Restrictions in IPv6

  • Multicast MOH isn't supported in IPv6 phones
  • IOS TFTP server isn't supported in IPv6
  • MWI Relay & Presence Server are supported in IPv4 only

Real Time Protocol Umbrella

Real Time Protocol

RTP protocol is used to carry the voice and video streams between the endpoints. As mentioned in other sections, in CUCM system, RTP stream will flow directly between endpoints. However, in CME system, RTP stream will flow directly between endpoints ONLY if both endpoints are local to CME. In case one endpoint resides in different cluster, CME will act as MTP/CUBE between both endpoints (i.e, Endpoint A <-----> CME <-----> Endpoint B).

RTP protocol is UDP based with RTP header attached to it. The payload of RTP packet is the audio/video signals.


RTP header adds extra features over UDP protocol which are time stamp, sequence numbers, delivery monitoring. Those features allow the receiving endpoint to buffer RTP packets, reorder their sequence, remove the jitter, and play back as continuous stream.

Then if those features are required, why to use UDP and add extra RTP header instead of TCP??? Those features are inherited in TCP ???

Because TCP protocol uses flow control mechanism and retransmission. Each packet should be acknowledged. If not, then it will be retransmitted. This add extra delay to voice/video stream. In VoIP environments, packet loss can be accepted but not delay. This is provided by UDP protocol in addition to RTP.

The Payload Type (PT) value in RTP header indicate the codec used in the payload (to compress the audio/video stream). Codecs are covered in details in different section. Below is the mapping between PT values and codecs as per IANA.

PT        encoding name   audio/video (A/V)  clock rate (Hz)  channels (audio)  Reference
--------  --------------  -----------------  ---------------  ----------------  ---------
0         PCMU            A                  8000             1                 [RFC3551]
1         Reserved         
2         Reserved
3         GSM             A                  8000             1                 [RFC3551]
4         G723            A                  8000             1                 [Kumar][RFC3551]
5         DVI4            A                  8000             1                 [RFC3551]
6         DVI4            A                  16000            1                 [RFC3551]
7         LPC             A                  8000             1                 [RFC3551]
8         PCMA            A                  8000             1                 [RFC3551]
9         G722            A                  8000             1                 [RFC3551]
10        L16             A                  44100            2                 [RFC3551]
11        L16             A                  44100            1                 [RFC3551]
12        QCELP           A                  8000             1                 [RFC3551]
13        CN              A                  8000             1                 [RFC3389]
14        MPA             A                  90000                              [RFC3551][RFC2250]
15        G728            A                  8000             1                 [RFC3551]
16        DVI4            A                  11025            1                 [DiPol]
17        DVI4            A                  22050            1                 [DiPol]
18        G729            A                  8000             1                 [RFC3551]
19        Reserved        A
20        Unassigned      A
21        Unassigned      A
22        Unassigned      A
23        Unassigned      A
24        Unassigned      V
25        CelB            V                  90000                              [RFC2029]
26        JPEG            V                  90000                              [RFC2435]
27        Unassigned      V
28        nv              V                  90000                              [RFC3551]
29        Unassigned      V
30        Unassigned      V
31        H261            V                  90000                              [RFC4587]
32        MPV             V                  90000                              [RFC2250]
33        MP2T            AV                 90000                              [RFC2250]
34        H263            V                  90000                              [Zhu]
35-71     Unassigned      ?
72-76     Reserved for RTCP conflict avoidance                                  [RFC3551]
77-95     Unassigned      ?
96-127    dynamic         ?                                                     [RFC3551]

RTP protocol is using dynamic UDP port numbers ranging from 16384 to 32767. RTP protocol will use the even ports within the range while the odd ports are used for RTCP which is covered in next section.

Note: In streaming environment, RTP protocol is used in conjunction with RTSP protocol. RTP will carry the media while RTSP will control the streaming server (establish and control media sessions such as play and pause). This isn't available in IP Telephony environment.

In CUCM, you can control the port range in two places (this can't be done at GW level):
  • SIP Profile
  • Phone Configuration

Real Time Control Protocol

RTCP is engaged with RTP protocol. Each active RTP steam will have RTCP stream. RTCP stream will use the next odd UDP port (e.g. RTP is using UDP 18384 and RTCP will use 18385). Endpoints will exchange RTCP streams periodically. RTCP payload carries statistics about RTP reported from each endpoint. Below are the info provided by RTCP:
  1. Bytes sent
  1. Packets sent
  2. Lost packets
  3. Jitter
  1. Feedback
  1. Round trip delay

RTCP packet types:
  1. Sender Report Packet
  1. Receiver Report Packet
  2. Source Description RTCP Packet
  3. Good Bye RTCP packet
  4. Application-Specific RTCP Packets
At gateways (H323/SIP/MGCP) level, RTCP timer can be tuned using the command ip rtcp report interval. In CUCM RTCP can be disabled/enabled per device configuration (Device > Phone > #Select Phone# > Product Specific Configuration Layout > RTCP).

RTCP passthrough will be supported for SWMTP, TRP, RSVP and HWMTP in passthrough mode (codec passthrough). This is applicable to CUCM 9.0

Restrictions
  • CME call-flows are not supported for RTCP passthrough.
  • RTCP for transcoding call-flows is not supported.
  • RTCP is not supported for conference calls.

To verify the statistics provided by RTCP,

  • At Gateway level, use the command show call active voice brief or show voip rtp connections
  • At Phones level, double click on ? Button or from the browser type the IP address of the phone

CSCtj37861 Bug Details
RTCP is sent by CIPC even though it is disabled in CUCM
Symptom:

CIPC Administration Guide suggests that RTCP is disabled by default but phone still sends out RTCP.

Conditions:

In CUCM version 6.x, device specific configuration for enabling or disabling RTCP for CIPC is not available

Test on CUCM version 7.x, call between CIPC 7.0.(3) and 7941 IP Phone with RTCP enabled on both shows RTCP.

- If RTCP on both phones are disabled from packet captures we can still see that RTCP is being sent by CIPC.

Workaround:
none identified so far 

Hope this helps !! Remaining are Compressed RTP and Secured RTP which will be covered later in QoS & Voice Security posts.

CME Localization Support

Localization is used to define phone parameters on country bases. Those parameters can be language to use for text displays (user-local) or country-specific tones and cadences (network-local).  CME has built-in system-locals for 16 countries and 12 languages.

For SCCP phones:
  • For 7905, 7912, 7940, and 7960 phones, system-locals files are preloaded in IOS. Only remaining is to apply the desired localization.
  • For 6921, 6945, 7906, 7911, 7921, 7931, 7941, 7961, 7970, 7971, 8941, 8945, and Cisco IP Communicator phones, system-locals files should be uploaded to IOS (obtained from cisco.com site). The next step will be applying the desired local.

For SIP phones localization has been introduced in CME 8.6. But you need to upload the local files for system-built locals (this is applicable for all SIP Phones types).

CME has an option to create user-defined locals. Those will allow to create custom parameters (user/network locals) and upload their own files.

Important Note about User Localization

Phone displays (menus and prompts) are managed by CME Dictionary & IP Phone Local File. Those displays can be localized by User-Local. Other types of displays which are configured by IOS can't be localized (English display only).

The following display items are localized by the IP phone (.jar file):
• System menus accessed with feature buttons (for example, messages, directories, services, settings, and information)
• Call processing messages
• Soft keys (for example, Redial and CFwdALL)

The following display items are localized by the dictionary file for Cisco Unified CME:
• Directory Service (Local Directory, Local Speed Dial, and Personal Speed Dial)
• Status Line

Display options configured through Cisco IOS commands are not localized and can only be displayed in English. For example, this includes features such as:
• Caller ID
• Header Bar
• Phone Labels
• System Message

Configuration

  1. Download the tar file which contain all localization files.
  1. Extract the file in routers flash (archive tar /xtract source-url flash:/file-url)
  1. Create TFTP alias for localization files (for phones that require manual upload of the files). Two files should be assigned to TFTP server which are user-local and network-local:
    tftp-server flash:/jar_file alias directory_name/jar_file 
    tftp-server flash:/g3-tones.xml alias directory_name/g3-tones.xml

    TIP: You may initiate a "debug tftp packets" to see the exact file name which phones are requesting after changing the local. Then you configure the correct alias.

  1. Apply the required local globally to SCCP/SIP CME. This will be applied to all phones.  telephony-service
     user-locale DK
     network-locale DK
    !
    voice register global
     user-locale DK
     network-locale DK


    Note: In case the files are missing from the TFTP server default local will be used which is English US.

Additionally, each CME can provide support up to 5 simultaneous locals. To achieve this, you need to assign 5 tags to 5 locals (languages and tones), then recall those tags in ephone-templates/voice-register-templates. Finally those templates should be assigned to endpoints. Those will override the global local applied in CME.

Example,

telephony-service
 user-locale 1 DE
!
ephone-template  1
 user-locale 1
!
ephone  1
 ephone-template 1

Alternatively, new feature is introduced in CME which is local installer (SCCP in version 7.0.1 and SIP in version 9.0). In this feature you need to define the local language/country to be used as well as the localization tar file. CME will automatically, extract the tar file and create TFTP alias for the required files. 

telephony-service
 user-locale [user-locale-tag] country-code load TAR-filename
!
voice register global
 network-locale [user-locale-tag] country-code load TAR-filename

Note: In case this feature is used, TAR file should be located in the same path for phone configuration file.

DNS Performance Troubleshooting

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