Home > Lucent Technologies > Communications System > Lucent Technologies DEFINITY Enterprise Communications Server Release 6 Instructions Manual

Lucent Technologies DEFINITY Enterprise Communications Server Release 6 Instructions Manual

    Download as PDF Print this page Share this page

    Have a look at the manual Lucent Technologies DEFINITY Enterprise Communications Server Release 6 Instructions Manual online for free. It’s possible to download the document as PDF or print. UserManuals.tech offer 413 Lucent Technologies manuals and user’s guides for free. Share the user manual or guide on Facebook, Twitter or Google+.

    Page
    of 2397
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-31 Multimedia Call Handling (MMCH) 
    5
    Beginning with Release 3.0, the status conference X command shows that MCV 
    is in effect by displaying av in the Video Status (Vs) column. Page 3 of the Status 
    Conference X Endpoint Y form also has a Broadcaster field that indicates MCV 
    is in effect with (SEE-ME) as the broadcaster. The same scenario can occur in a 
    CHAIR or UCC-controlled conference with a designated broadcaster. In this 
    situation the CHAIR/UCC has not released the designated broadcaster and 
    returned to VAS mode. If there is a UCC-designated broadcaster, status 
    conference X indicates a Video Status of u. Also, for UCC rollcall the return 
    video may appear to be stuck. Check the Video Status for an “R,” indicating 
    rollcall.
    If none of the examples above appears to be the cause, and if the room was 
    quiet, all speakers are valid video sources, the conference is voice-activated, 
    and the speaker can be heard, then escalate the problem.
    Video Never Switches to a Particular Party
    Description
    Verify that the endpoint is a valid video source as described in the “Calls 
    Terminate with No Video” section above. If it is, then the audio from the endpoint 
    may not have sufficient voice signal for the hardware to determine the parties at 
    the endpoint are speaking. Check the Talk field on page three of the Status 
    Conference X Endpoint Y form to see if the talking bit is y. Next, check the 
    audio by standing adjacent to the microphone and speaking at a normal level. 
    Solution
    If the audio is not muffled:
    1. Use the status conference command to determine which port on the 
    TN788B (VC board) is connected to this endpoint.
    2. Check the VC (TN788B) board using the test board xxyy long command.
    3. Drop the call.
    4. Find another available port, then:
    a. Busyout the port to which the endpoint was connected.
    b. Make another call to the same conference. If the problem corrects 
    itself, then the previous port may be bad. If there are other VC 
    boards with sufficient available ports to replace calls on the current 
    VC, then pull the board that has the bad endpoint on it (the status 
    conference command displays the encoder port associated with 
    the call). The system will automatically reestablish the VC 
    connections without dropping the call. If this fixes the problem, then 
    replace the board, as it has at least one bad port. Reseating the 
    board may temporarily fix the problem due to the hard reset done to 
    the board.  
    						
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-32 Multimedia Call Handling (MMCH) 
    5
    Audio Echo
    Echo in conference calls, particularly those with large delay characteristics, is 
    totally disruptive. When Voice Activated Switching is taken into account, the 
    effects are disastrous. Various arrangements of the microphone(s) and room 
    speaker(s) may be needed.
    For some Lucent Technologies Vistium endpoints, if an external speaker is 
    attached or was attached when the system was last rebooted, this endpoint will 
    cause audio echo throughout the conference. First, isolate the offending 
    endpoint by asking each endpoint to mute, one at a time, until the echo 
    disappears.
    If the input from an endpoint is located too close to the speakers of an endpoint, 
    then acoustic echo is created. The microphone must be moved away from the 
    speakers.
    Normally, if any microphone in the room is moved relative to the speakers, that 
    site will cause echo until the echo canceller in the codec retrains itself, some will 
    require a manual reset. If a PictureTel keypad is configured with external 
    microphones connected to the keypad, then the internal microphone and 
    external microphone(s) “sing” to each other if the “ext mic” bat switch is set to 
    “int mic” on the back of the keypad. In this configuration, VAS locked on that site, 
    and the acoustic “singing” was inaudible.
    Rate Adaptation
    Because of a lack of a clear explanation in standards, sometimes endpoints do 
    not work well with each other and the DEFINITY MMCH. The MMCH will only 
    allow a conference to downgrade from 64kbps to 56 kbps operation on 
    conferences that have the Rate Adaptation flag set to y.
    When a downgrade does occur, information on the Status Conference form 
    indicates the success or failure of the 64kbps-endpoints that are participants to 
    properly rate adapt to 56kbps. As a general indication that the conference has 
    rate adapted, the Conference Transfer Rate and Effective Transfer 
    Rate fields show initial and current transfer rates, respectively. For each 64-kbps 
    endpoint the column that indicates Rate Adapt shows an n if the endpoint did 
    not follow the procedures as specified by the H.221. If an endpoint shows y, it 
    did successfully rate adapt. If an endpoint shows c, it joined the conference at 
    56kbps.
    Once the conference rate adapts, the endpoints that do not properly follow suit, 
    will become audio-only endpoints. A conference will not rate adapt from 56 kbps 
    back to 64 kbps until all endpoints disconnect from the conference and it idles.
    The PictureTel 1000 Release 1.1C, PictureTel 6.01 software, and the Vistium 2.0 
    software successfully rate adapt with the MCU. External rate adaptation 
    techniques used by VTEL and CLI are known to cause problems with the 
    endpoint when used with this feature. 
    						
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-33 Troubleshooting ISDN-PRI Problems 
    5
    Endpoint or I-MUX in Loopback Mode
    Some endpoints have a loopback enable feature. This makes DEFINITY MMCH 
    data loopback at the MMCH when a connection is in progress. The loopback can 
    be enabled prior to or during a connection.
    The MMCH does not detect the loop and continues to VAS. In most scenarios, 
    the switch occurs, but within a few seconds, the broadcaster’s return video 
    becomes its own image. Once the broadcaster stops speaking, the system 
    “false” switches to an apparently random port that was not speaking.
    Troubleshooting ISDN-PRI Problems
    The following flow chart defines a layered approach when troubleshooting 
    ISDN-PRI problems. Since a problem at a lower layer affects upper layers, layers 
    are investigated from low to high. In the flowchart, the DS1 facility is layer 1, the 
    ISDN-PRI D-channel is layer 2, and the ISDN trunks are layer 3. Transient 
    problems are diagnosed on Page 2 of the flowchart. For problems with PRI 
    endpoints (wideband), see the following section. 
    						
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-34 Troubleshooting ISDN-PRI Problems 
    5
    Figure 5-7. Troubleshooting ISDN-PRI (Page 1 of 2)
    ARE THERE
    ALARMS OR ERRORS
    AGAINST UDS1-BD ORDETERMINE PRESENT STATUS
    OF DS-1 FACILITYVIA UDS1-BD
    OR DS1-BD MO SECTION.
    ARE THERE
    ALARMS OR
    ERRORS AGAINST
    ISDN-LINK OR
    ISDN-SGRIF MULITPLE ALARMS EXIST,
    INVESTIGATE IN FOLLOWING
    ORDER:
    ISDN-LINK
    ISDN-SGR
    FOLLOW REPAIR PROCEDURE
    FOR APPROPRIATE MO
    ARE THERE
    ALARMS OR
    ERRORS AGAINSTFOLLOW REPAIR
    PROCEDURE FOR ISDN-TRK
    TO
    PAGE
    2NOYES
    START
    YES
    NO
    YES
    END
    A
    NO
    DS1-BD
    ISDN-TRKFOLLOW REPAIR PROCEDURES 
    						
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-35 Troubleshooting ISDN-PRI Problems 
    5
    Figure 5-8. Troubleshooting ISDN-PRI (Page 2 of 2)
    PAGE
    YES END
    AFROM
    1
    ARE
    THERE
    TRANSIENT
    PROBLEMS MAKING
    ISDN-PRI
    ARE
    THERE BIT
    ERRORS OVER
    HAS A
    SYNCHRONIZATION
    SOURCE BEEN
    SYSTEM SWITCHING
    IF PROBLEMS
    STILL EXIST,
    THEN ESCALATECOMPARE INDICATED
    FACILITY TO RECORD
    OF PREVIOUS PROBLEMS
    ARE BIT
    ERRORS OCCURRING
    MORE FREQUENTLY
    THAN PREVIOUS
    RECORD INDICATED
    FACILITY AND, IF THIS
    CONTINUES TO OCCUR,
    CONTACT FACILITY OR
    EXTERNAL EQUIPMENT
    PROVIDER. THEN ESCALATE THE TI FACILITY?
    UNSTABLE?
    AWAY FROM IT?
    NO
    YES
    SEE UDS1-BD OR DS1-BD
    MO FOR REPAIR PROCEDURES
    IF SYNC PROBLEM IS DUE
    TO SLIPS. OTHERWISE,
    FOLLOW REPAIRPERFORM AN IN-DEPTH
    ANALYSIS OF T1
    FACILITY INCLUDING:
    TRANSMISSION FACILITY,
    EXTERNAL EQUIPMENT
    (DACS, CSUs, ETC.)
    AND ANY OTHER
    NOISE-PRODUCING
    EQUIPMENT.
    REFER TO AT&T PRACTICE
    #855-351-101 ISSUE 8,
    JANUARY 1987. THIS
    DESCRIBES T1 CABLING TO
    CSUs, ETC, IN DETAIL
    YES
    NO
    NONOYES
    END
    CALLS
    SEE SYNC MOHISTORY
    PROCEDURES FOR
    SYNC MO USE LIST
    MEASUREMENTS
    COMMAND 
    						
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-36 Troubleshooting ISDN-PRI Endpoints (Wideband) 
    5
    Troubleshooting ISDN-PRI Endpoints 
    (Wideband)
    The following flow chart defines a layered approach when troubleshooting PRI 
    endpoint problems. Because problems at lower layers affect upper layers, layers 
    are investigated from low to high. In this procedure, the DS1 facility is layer 1, the 
    TN1655 Packet Interface is layer 2, and the PRI endpoint ports are layer 3.
    The troubleshooting procedure described here is limited to diagnosing faults 
    between the switch and the line-side PRI terminal adapter or ISDN-PRI endpoint 
    equipment. Problems encountered on the network-side of a wideband 
    connection or problems with end-to-end equipment compatibility are beyond the 
    scope of this section. 
    						
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-37 Troubleshooting ISDN-PRI Endpoints (Wideband) 
    5
     START
    ¯
    Are there alarms or errors against any 
    of the following maintenance objects: 
    UDS1-BD PKT-INT SYS-LINK 
    ISDN-LNK ISDN-SGR PE-BCHLYES 
    ®Resolve those alarms or errors in the order 
    listed at left by following procedures for the 
    appropriate maintenance object in Chapter 
    9.
    ¯ NO
    Check out the status of the endpoint 
    equipment or Terminal Adaptor. Do 
    this at the endpoint, not at the G3-MT 
    on the switch. Does the adaptor or 
    endpoint indicate problems?YES
    ®Follow repair procedures recommended by 
    the provider of the Terminal Adapter or 
    endpoint equipment.
    ¯ NO
    Check administration at the endpoint 
    and on the switch (for example, port 
    boundary width). Are they 
    inconsistent?YES
    ®Correct the administration so that both ends 
    match.
    ¯ NO
    Does every call fail or are the failures 
    transient? 
    ¯ Transient FailuresAlways 
    Fails 
    ®Check the health of the application 
    equipment (for example, the video codec) 
    and that of the DEFINITY network. If constant 
    failures persist, follow normal escalation 
    procedures.
    Use list measurements ds1 to check 
    for bit errors over the DS1 interface 
    between the switch and the terminal 
    adapter or endpoint equipment.
    ¯ No bit errorsBit 
    Errors
    ®Perform an in-depth analysis of the DS1 
    interface including premises distribution 
    wiring, endpoint equipment, and any other 
    possible source of noise. If the problem 
    cannot be isolated, follow normal escalation 
    procedures.
    Check for alarms and errors against 
    SYNC. Has a synchronization source 
    been unstable? Has the system 
    switched synch sources?YES 
    ®Follow procedures described in SYNC in 
    Chapter 9.
    ¯ NO
    Follow normal escalation 
    procedures. 
    						
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-38 Troubleshooting ISDN-BRI/ASAI Problems 
    5
    Troubleshooting ISDN-BRI/ASAI 
    Problems
    Troubleshooting ISDN-BRI/ASAI problems can be a complex and involved 
    procedure. The reason for this is that ISDN-BRI devices communicate with the 
    SPE over the Packet Bus, as opposed to the TDM Bus. Therefore, it is possible 
    for failures of other Packet Bus-related system components to cause problems 
    with ISDN-BRI devices. Figure 5-9
     shows the connectivity of the Packet Bus as it 
    applies to ISDN-BRI signaling.
    Figure 5-9. ISDN-BRI/Packet Bus Connectivity
    Signaling Links
    T
    N
    7
    T
    N
    7
    Testing/
    Recon®g T
    N
    7
    7
    Signaling
    Links
    EPN
    Duplicated
    PNC
    Only
    Packet Bus
    BRI-PT ABRI-PT
    ASAI-ADJ T
    N
    5
    0 1
    5
    05
    5
    6
    T
    N
    7
    ABRI-PT
    T
    N
    Duplicated
    PNC
    OnlyT
    N
    7
    Packet Bus
    Signaling
    Links
    BRI-PT
    T
    N
    1
    6
    5
    5Testing/
    Recon®g
    T
    N
    1
    6
    5
    5
    T
    N
    7
    7
    PPN
    ASAI-ADJ 1
    5
    5
    65
    0 5
    0 
    						
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-39 Troubleshooting ISDN-BRI/ASAI Problems 
    5
    The flowchart in Figure 5-10 describes the steps that should be taken to isolate 
    and resolve ISDN-BRI problems. The order in which you should examine the 
    maintenance objects is determined by looking at how wide-spread the failure is. 
    For example, since all ISDN-BRI devices communicate with the TN1655 Packet 
    Interface circuit pack, this MO should be examined early in the sequence. On the 
    other hand, a failure of a TN570 circuit pack may cause ISDN-BRI failure in an 
    EPN, but could not be the cause of a failure in the PPN.
    NOTE:
    If the flowchart query ‘‘Is the problem affecting MOs on multiple BRI-BD 
    circuit packs?’’ is reached, and the port network in question has only one 
    ISDN-BRI circuit pack, then assume that the answer is ‘‘Yes’’ and follow the 
    repair procedure for PKT-BUS.
    When directed by the flow chart to refer to the Maintenance documentation for a 
    specific MO, keep in mind that the repair procedure for that MO may refer you to 
    another MO’s repair procedure. The flowchart tries to coordinate these activities 
    so that a logical flow is maintained if the ISDN-BRI problems are not resolved with 
    the first set of repair procedures.
    These following status commands may also be useful when diagnosing 
    ISDN-BRI problems:
    nstatus port-network
    nstatus packet-interface
    nstatus bri-port
    nstatus station
    nstatus data-module 
    						
    							DEFINITY Enterprise Communications Server Release 6
    Maintenance for R6r Volumes 1 & 2  555-230-126  Issue 2
    January 1998
    Responding to Alarms and Errors 
    Page 5-40 Troubleshooting ISDN-BRI/ASAI Problems 
    5
    Figure 5-10. Troubleshooting ISDN-BRI Problems (Page 1 of 2)
    START
    ARE THERE
    ALARMS OR
    ERRORS AGAINST
    PKT-BUS NO
    YES
    IS THIS A
    CRITICAL RELIABILITY
    SYSTEM?
    NOARE THERE
    ALARMS OR
    ERRORS AGAINST
    M/T-PKT YES
    IS THE
    PROBLEM
    ISOLATED TOARE THERE
    ALARMS OR ERRORS
    AGAINST EXP-INTF*
    THE PPN
    A TO
    PAGE
    2IS THE
    ISDN-BRI
    PROBLEM
    RESOLVED
    END
    ARE THERE
    ALARMS OR
    ERRORS AGAINST
    PKT-INT
    IS THE
    ISDN-BRI
    PROBLEM
    RESOLVED
    NO
    YES
    YES (DUPLICATED PNC)
    NO
    YES
    NO
    TO
    PAGE
    2NO
    B FOLLOW THE
    REPAIR
    PROCEDURE
    FOR PKT-INT
    FOLLOW THE
    REPAIR
    PROCEDURE
    FOLLOW THE
    REPAIR
    PROCEDURE
    FOR M/T-PKT
    YES
    END
    YES
    YES
    FOR EXP-INTF
    NO
    NO 
    						
    All Lucent Technologies manuals Comments (0)

    Related Manuals for Lucent Technologies DEFINITY Enterprise Communications Server Release 6 Instructions Manual