Conference Failures

This section examines troubleshooting techniques for the conference feature, which is one of the most frequently used features in any typical office environment. Two common issues related to conference are discussed in this section:

• Conference failure because of unavailable lines
• Conference failure because of a codec mismatch

Conference Failure Because of Unavailable Lines

Example 17-9 shows the configuration of CS_router with the phones for the additional employees added to the system. With this configuration in place, when CS Engineer1 tries to initiate a conference with fellow support engineers, it fails. After making the first call when the conference softkey is pressed, CS Engineer1 gets a "No line available" message on the phone display.

Example 17-9. Configuration of CS_router with Additional Phones

CS_router#show running-config !Output omitted for brevity ... ephone-dn 1 number 1001 name CS Engineer1 call-forward all 3001 ! ephone-dn 2 number 1010 name CS Engineer2 ! ephone-dn 3 number 1003 name CS Engineer3 ! ephone 1 mac-address 0007.EB46.299E type 7960 button 1:1 ! ephone 2 mac-address 0003.E373.76FB type 7960 button 1:2 ! ephone 3 mac-address 0030.94C2.9919 button 1:3 ! ephone 4 mac-address 000D.BDBE.F372 button 1:4

The debug ephone detail output for the phone of CS Engineer1 is shown in Example 17-10.

Example 17-10. debug ephone detail Output During a Conference Setup Failure

CS_router#debug ephone detail !Output omitted for brevity ... 3d01h: ephone-1[1][SEP0007EB46299E]:SoftKeyEventMessage event 13 line 1 callref 45 3d01h: ephone-1[1]:SK CONFERENCE line 1 ref 45 3d01h: SkinnyGetCallState for DN 1 chan 1 CONNECTED 3d01h: called DN 3 chan 1, calling DN -1 chan 1 phone 1 s2s:1 3d01h: SkinnyGetCallState for DN 1 chan 1 CONNECTED 3d01h: called DN 3 chan 1, calling DN -1 chan 1 phone 1 s2s:1 3d01h: SkinnyGetCallState for DN 1 chan 1 CONNECTED 3d01h: called DN 3 chan 1, calling DN -1 chan 1 phone 1 s2s:1 3d01h: ephone-1[1]:DisplayMessage: No Line Available 3d01h: ephone-1[1]:Conference with no idle line available: abort

The debug output shown in Example 17-10 displays a message similar to the one seen on the phone display. As indicated by the debug and the phone display messages, the phone is running out of ephone-dns to make the second call. When the conference softkey is pressed, the phone automatically puts the first line on hold and allocates the next available line to initiate the second call. You can solve this "No Line Available" problem by adding another line to the existing phone or by changing the existing line to a dual line.

You can modify the configuration example so that ephone-dn 1 is now a dual-line DN. You must delete the existing ephone-dn, and then add it again with the option dual-line. After you reconfigure the ephone-dn and restart the phone, you notice that the phone is registered without a number assigned to it. When you removed the existing ephone-dn, the software automatically also removed that extension (ephone-dn) from the configuration of ephone 1, because the extension does not exist anymore. If you look at the configuration, you can see that there is no longer a button 1:1 configuration under ephone 1. The button configuration is not added automatically when the ephone-dn is reconfigured as a dual-line DN. You should manually configure the buttons so that the phone gets registered with a number assigned to it.

Conference Failure Because of a Codec Mismatch

With the new configuration in place, CS Engineer1 now can make a conference call to all the employees in the customer service office. But the conference call still fails if one of the parties in the conference is located at the headquarters office. In this example, the conference originator can make the call to the destination party and gets connected but is unable to conference together all three parties. When the conference originator presses the conference button the second time to complete the conference, the phone displays the message "Cannot complete the conference." The output of the debug ephone detail command during the conference attempt is shown in Example 17-11.

Example 17-11. debug ephone detail Output During a Conference with an Unsupported Codec

CS_router#debug ephone detail !Output omitted for brevity ... C 3d03h: SkinnyGetCallState DN error -1 3d03h: SkinnyGetCallState for DN 4 chan 1 CONNECTED 3d03h: called DN -1 chan 1, calling DN 1 chan 1 phone 4 incoming s2s:1 3d03h: SkinnyGetCallState for DN 4 chan 1 CONNECTED 3d03h: called DN -1 chan 1, calling DN 1 chan 1 phone 4 incoming s2s:1 3d03h: ephone-4[3]:is_auto_local 1 for DN 4 3d03h: Skinny StartTone 53 sent on ephone socket [3] DtHoldTone 3d03h: ephone-1[1][SEP0007EB46299E]:SoftKeyEventMessage event 13 line 1 callref 54 3d03h: ephone-1[1]:SK CONFERENCE line 1 ref 54 3d03h: SkinnyGetCallState for DN 1 chan 2 CONNECTED 3d03h: called DN -1 chan 1, calling DN -1 chan 1 phone 1 s2s:0 3d03h: ephone-1[1]:Conference attempt with unsupported codec

The last line of the debug explains the problem. Conference calling requires G.711 codecs unless digital signal processor (DSP) transcoding is provisioned (available only with Cisco CME 3.2 or later). To fix the problem, you should configure the G.711 codec on the dial peers or upgrade to Cisco CME 3.2 with the necessary transcoding hardware. Another important point is that even if the router uses DSP resources for transcoding, the media mixing for the conference is done in software by the router. The transcoder converts all G.729 packets to G.711 and sends them to the Cisco CME router. There the software mixes the media from the three parties involved in the conference and sends the mixed media back out to the three phones.

The three debug segments in the next several examples show the output of show ephone during various states of a conference call. The conference initiator is 1001, and the other parties involved in the call are 1003 and 1004.

Example 17-12 shows the output after the first call is made.

Example 17-12. show ephone Output After the First Call

CS_router#show ephone ephone-1 Mac:0007.EB46.299E TCP socket:[1] activeLine:1 REGISTERED mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.141 49648 Telecaster 7960 keepalive 56 max_line 6 button 1: dn 1 number 1001 CH1 CONNECTED CH2 IDLE Active Call on DN 1 chan 1 :1001 10.10.10.141 24462 to 10.10.10.159 28488 via 10.10.10.141 G711Ulaw64k 160 bytes no vad Tx Pkts 451 bytes 77572 Rx Pkts 452 bytes 77744 Lost 0 Jitter 0 Latency 0 callingDn -1 calledDn 3 (media path callID 113 srcCallID 114) ephone-3 Mac:0030.94C2.9919 TCP socket:[4] activeLine:1 REGISTERED mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.159 52063 Telecaster 7960 keepalive 339 max_line 6 button 1: dn 3 number 1003 CH1 CONNECTED Active Call on DN 3 chan 1 :1003 10.10.10.159 28488 to 10.10.10.141 24462 via 10.10.10.159 G711Ulaw64k 160 bytes no vad Tx Pkts 452 bytes 77744 Rx Pkts 451 bytes 77572 Lost 0 Jitter 0 Latency 0 callingDn 1 calledDn -1

Example 17-13 shows the output after the second call is made.

Example 17-13. show ephone Output After the Second Call

CS_router#show ephone ephone-1 Mac:0007.EB46.299E TCP socket:[1] activeLine:1 REGISTERED mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.141 49648 Telecaster 7960 keepalive 66 max_line 6 button 1: dn 1 number 1001 CH1 HOLD CH2 CONNECTED Active Call on DN 1 chan 2 :1001 10.10.10.141 20472 to 10.10.10.1 2000 via 10.10.10.141 G711Ulaw64k 160 bytes no vad Tx Pkts 223 bytes 38356 Rx Pkts 224 bytes 38528 Lost 0 Jitter 0 Latency 0 callingDn -1 calledDn 4 ephone-3 Mac:0030.94C2.9919 TCP socket:[4] activeLine:1 REGISTERED mediaActive:0 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.159 52063 Telecaster 7960 keepalive 348 max_line 6 button 1: dn 3 number 1003 CH1 CONNECTED Active Call on DN 3 chan 1 :1003 10.10.10.159 28488 to 10.10.10.141 24462 via 10.10.10.159 G711Ulaw64k 160 bytes no vad Tx Pkts 28296 bytes 4866912 Rx Pkts 28296 bytes 4866912 Lost 0 Jitter 0 Latency 0 callingDn 1 calledDn -1 ephone-4 Mac:000D.BDBE.F372 TCP socket:[3] activeLine:1 REGISTERED mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.158 50900 Telecaster 7960 keepalive 357 max_line 6 button 1: dn 4 number 1004 CH1 CONNECTED Active Call on DN 4 chan 1 :1004 10.10.10.158 24508 to 10.10.10.1 2000 via 10.10.10.158 G711Ulaw64k 160 bytes no vad Tx Pkts 476 bytes 81872 Rx Pkts 475 bytes 81700 Lost 0 Jitter 0 Latency 0 callingDn 1 calledDn -1 (media path callID 118 srcCallID 117)

Example 17-14 shows the output after all three parties are in the conference call.

Example 17-14. Output After All Three Parties Are in the Conference

CS_router#show ephone ephone-1 Mac:0007.EB46.299E TCP socket:[1] activeLine:1 REGISTERED mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.141 49648 Telecaster 7960 keepalive 72 max_line 6 button 1: dn 1 number 1001 CH1 CONNECTED CH2 CONNECTED CH1 conferencedCH2 conferenced Active Call on DN 1 chan 2 :1001 10.10.10.141 20472 to 10.10.10.1 2000 via 10.10.10.141 G711Ulaw64k 160 bytes no vad Tx Pkts 8968 bytes 1542496 Rx Pkts 8968 bytes 1542496 Lost 0 Jitter 3 Latency 0 callingDn -1 calledDn 4 ephone-3 Mac:0030.94C2.9919 TCP socket:[4] activeLine:1 REGISTERED mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.159 52063 Telecaster 7960 keepalive 354 max_line 6 button 1: dn 3 number 1003 CH1 CONNECTED Active Call on DN 3 chan 1 :1003 10.10.10.159 26034 to 10.10.10.1 2000 via 10.10.10.159 G711Ulaw64k 160 bytes no vad Tx Pkts 14348 bytes 2467856 Rx Pkts 14349 bytes 2468028 Lost 0 Jitter 0 Latency 0 callingDn -1 calledDn -1 (media path callID 116 srcCallID 115) ephone-4 Mac:000D.BDBE.F372 TCP socket:[3] activeLine:1 REGISTERED mediaActive:1 offhook:1 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 IP:10.10.10.158 50900 Telecaster 7960 keepalive 363 max_line 6 button 1: dn 4 number 1004 CH1 CONNECTED Active Call on DN 4 chan 1 :1004 10.10.10.158 24508 to 10.10.10.1 2000 via 10.10.10.158 G711Ulaw64k 160 bytes no vad Tx Pkts 9220 bytes 1585840 Rx Pkts 9220 bytes 1585840 Lost 0 Jitter 0 Latency 0 callingDn 1 calledDn -1 (media path callID 118 srcCallID 117)

Examples 17-12 and 17-13 show that the media is sent directly between the phones involved in the call. In Example 17-14, as soon as the conference is active, the destination's IP address changes to the Cisco CME router's IP address for all three phones. All the routers send the Real-Time Protocol (RTP) packets directly to the Cisco CME router, which mixes them and sends them back to the respective phones. This can take a considerable amount of CPU cycles and, hence, affects system performance. You can configure the maximum number of simultaneous conferences on a Cisco CME system with the command max-conference. The default value for this command varies, depending on the type of platform you are using.