TelePresence : Cisco TelePresence System 3010

Os valores-limite Conferenced CTS com MCU 4505 não podem compartilhar da apresentação

20 Julho 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Feedback

Introdução

Este documento descreve um problema que possa ocorrer quando o MCU 4505 é dispositivos nativos usados do Cisco TelePresence da conferência, tais como o sistema do Cisco TelePresence (CTS) 3000, e CTS 1000.

Contribuído por Devasaayee Gopalan, engenheiro de TAC da Cisco

Problema

Os valores-limite CTS não negociam o canal satisfeito quando em uma conferência MCU 4505 e na apresentação não trabalha.

Cenário 1: O valor-limite CTS está em um atendimento com corrente alternada - valor-limite da série. O valor-limite da série C recebe uma segunda chamada e adiciona a segunda chamada em uma conferência de Multiway com MCU 4505.

Cenário 2: O valor-limite-Um CTS e o valor-limite-b CTS estão em um atendimento (P2P) ponto a ponto. O valor-limite-Um CTS adiciona o valor-limite-C CTS na conferência com MCU 4505.

Análise do log

A encenação 1 é explicada em detalhe aqui. O comportamento é o mesmo para a segunda encenação também.

  1. O CTS faz a primeira chamada a C60 e o UDP/protocolo de controle binário do assoalho (BFCP) é negociado. Esta vez, o CTS é negociado como um server somente (s-only).

  2. C60 recebe este como uma segunda chamada e tenta-o adicionar o CTS em uma conferência de Multiway. O clique aceita e conferência.

  3. Depois que o atendimento é respondido, C60 envia uma mensagem CONSULTAR ao CTS através do gerente das comunicações unificadas de Cisco (CUCM).

  4. CUCM atualiza o CTS e estabelece um trecho de chamada novo para o MCU.

  5. CUCM envia um Re-CONVITE no outro pé da chamada existente para o CTS.

  6. O MCU envia uma resposta de 200 APROVAÇÕES a CUCM.

    O trecho de chamada para MCU > MCU envia uma APROVAÇÃO 200 para o CONVITE de CUCM.

    Nisto, o MCU envia s-only na linha UDP/BFCP:

    38967255.005 |10:58:33.776 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP
    message from 10.8.151.10 on port 5060 index 18434 with 3552 bytes:
    [13108787,NET]
    SIP/2.0 200 OK
    Via: SIP/2.0/TCP 10.8.234.5:5060;branch=z9hG4bK140caf40663a0b;received=10.8.234.5;
    ingress-zone=CUCMPUB
    Call-ID: 6da10800-3fe17eb9-130803-5ea080a@10.8.234.5
    CSeq: 101 INVITE
    Contact: <sip:60943@vrl.com.au;gr=urn:uuid:d46fa924-ab3f-58cf-8c52-acb4b9639851>;
    isfocus
    From: "JAM-CPL-G-5 - 30001" <sip:30001@vrl.com.au>;tag=4514743~ab08cd8f-bad4-4697-
    95a3-fb104231f445-28328644
    To: <sip:60943@10.8.151.10>;tag=8E2210B3C0600003
    Record-Route: <sip:proxy-call-id=baec7051-f984-45e9-88f0-f186e9e8ffee@10.8.151.10:
    5060;transport=tcp;lr>
    Record-Route: <sip:proxy-call-id=baec7051-f984-45e9-88f0-f186e9e8ffee@10.8.151.10:
    5060;transport=tcp;lr>
    Allow: INVITE,ACK,CANCEL,OPTIONS,UPDATE,INFO,NOTIFY,BYE,REFER
    User-Agent: Codian MCU 4505 v4.4 (3.54)
    Supported: timer
    Session-Expires: 1800;refresher=uas
    Content-Type: application/sdp
    Content-Length: 2684

    v=0
    o=CODIAN 1774889505 1774889505 IN IP4 10.8.151.12
    s=-
    i=Codian MCU 4505 v4.4 (3.54)
    c=IN IP4 10.8.151.12
    b=AS:4000
    t=0 0

    m=application 56903 UDP/BFCP *
    a=floorctrl:s-only
    a=confid:1498387409
    a=floorid:2 mstrm:12
    a=userid:45083
    a=connection:new



    =====================


  7. No outro lado, o CTS envia uma resposta de 200 APROVAÇÕES a CUCM.

    Nesta APROVAÇÃO 200 igualmente, o CTS envia s-only na linha UDP/BFCP. Isto é porque o CTS negociou s-only em seu trecho de chamada original para C60. Desde que este é um Re-CONVITE, o CTS deve enviar s-only e c-only em sua resposta UDP/BFCP.

    38967403.002 |10:58:33.893 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP
    message from 10.8.151.50 on port 40731 index 21181 with 2524 bytes:
    [13108796,NET]
    SIP/2.0 200 OK
    Via: SIP/2.0/TCP 10.8.234.5:5060;branch=z9hG4bK140cb433de301c
    From: <sip:60302@10.8.234.5>;tag=4514737~ab08cd8f-bad4-4697-95a3-fb104231f445-
    28328637
    To: "30001" <sip:30001@10.8.234.5>;tag=001da238f59a000e18747fc4-221e3c71
    Call-ID: 001da238-f59a0004-0ce31763-39a27bf8@10.8.151.50
    Date: Thu, 28 Aug 2014 00:58:33 GMT
    CSeq: 105 INVITE
    Server: Cisco-Telepresence-#505/1.0
    Contact: <sip:c2592e5d-9bd0-996c-7e22-daf02cc2a4f4@10.8.151.50:40731;transport=tcp>;
    video;x-cisco-tip;x-cisco-multiple-screen=1
    Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,INFO,SUBSCRIBE
    Remote-Party-ID: "30001" <sip:30001@10.8.151.50>;party=calling;id-type=subscriber;
    privacy=off;screen=yes
    Allow-Events: kpml,dialog
    Content-Length: 1686
    Content-Type: application/sdp
    Content-Disposition: session;handling=optional

    v=0
    o=Cisco-SIPUA 10770 2 IN IP4 10.8.151.50
    s=SIP Call
    c=IN IP4 10.8.151.50
    b=TIAS:4628000
    t=0 0
    a=X-cisco-mux: cisco
    a=sendrecv

    m=application 28932 UDP/BFCP *
    a=floorctrl:s-only
    a=floorid:1 mstrm:12
    a=confid:1
    a=userid:5


    ====================


  8. Desde que ambos os dispositivos enviam s-only (a fim tentar ser o server), CUCM rejeita o BFCP e faz-lhe 0.

    Nos logs CUCM, você vê este Mensagem de Erro:

    38967409.120 |10:58:33.895 |AppInfo  |DET-SDPMsg-negotiateBFCPFloorCtrlRole :
    Reject BFCP: INVALID BFCPFloorCtrl Role recv device=2 farEnd=2

    38967443.001 |10:58:33.897 |AppInfo  |SIPTcp - wait_SdlSPISignal: Outgoing SIP TCP
    message to 10.8.151.50 on port 40731 index 21181
    [13108797,NET]
    ACK sip:c2592e5d-9bd0-996c-7e22-daf02cc2a4f4@10.8.151.50:40731;transport=tcp SIP/2.0
    Via: SIP/2.0/TCP 10.8.234.5:5060;branch=z9hG4bK140cb561171133
    From: <sip:60302@10.8.234.5>;tag=4514737~ab08cd8f-bad4-4697-95a3-fb104231f445-
    28328637
    To: "30001" <sip:30001@10.8.234.5>;tag=001da238f59a000e18747fc4-221e3c71
    Date: Thu, 28 Aug 2014 00:58:33 GMT
    Call-ID: 001da238-f59a0004-0ce31763-39a27bf8@10.8.151.50
    Max-Forwards: 70
    CSeq: 105 ACK
    Allow-Events: presence
    Content-Type: application/sdp
    Content-Length: 922

    v=0
    o=CiscoSystemsCCM-SIP 4514737 4 IN IP4 10.8.234.5
    s=SIP Call
    b=TIAS:4000000
    t=0 0

    m=application 0 UDP/BFCP *
    c=IN IP4 10.8.151.12


    =================================

Solução

Esta edição é encontrada para ser um problema com software CTS. Tem que enviar s-only e c-only quando responde ao Re-CONVITE. Mas envia somente s-only, que causa a falha satisfeita do Channel Negotiation.

Isto é causado pela identificação de bug Cisco CSCty37410 no software CTS. É fixado na versão 1.10.7 e mais recente CTS.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.