TelePresence : Cisco TelePresence System 3010

Los puntos finales Conferenced CTS con MCU 4505 no pueden compartir la presentación

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe un problema que pudo ocurrir cuando el MCU 4505 es para dispositivos nativos usados del Cisco TelePresence de la conferencia, tales como sistema del Cisco TelePresence (CTS) 3000, y CTS 1000.

Contribuido por Devasaayee Gopalan, ingeniero de Cisco TAC

Problema

Los puntos finales CTS no negocian el canal contento cuando en una conferencia MCU 4505 y la presentación no trabaja.

Escenario 1: El punto final CTS está en una llamada con el A.C. - punto final de la serie. El punto final de la serie C recibe una segunda llamada y agrega la segunda llamada en una conferencia de Multiway con MCU 4505.

Escenario 2: El punto final-UNo CTS y el punto final-B CTS están en una llamada de punto a punto (P2P). El punto final-UNo CTS agrega el punto final-C CTS en la conferencia con MCU 4505.

Análisis del registro

El escenario 1 se explica detalladamente aquí. El comportamiento es lo mismo para el segundo escenario también.

  1. El CTS hace la primera llamada a C60 y se negocia el UDP/el Control Protocol binario del suelo (BFCP). Esta vez, el CTS se negocia como servidor solamente (s-only).

  2. C60 recibe esto como segunda llamada e intenta agregar el CTS en una conferencia de Multiway. El tecleo valida y conferencia.

  3. Después de que se conteste la llamada, C60 envía un mensaje del REFERIR al CTS vía el administrador de las Comunicaciones unificadas de Cisco (CUCM).

  4. CUCM pone al día el CTS y establece un nuevo tramo de llamada hacia el MCU.

  5. CUCM envía una Re-INVITACIÓN en la otra pierna de la llamada existente hacia el CTS.

  6. El MCU envía una respuesta de 200 AUTORIZACIONES a CUCM.

    El tramo de llamada hacia MCU > MCU envía una AUTORIZACIÓN 200 para la INVITACIÓN de CUCM.

    En esto, el MCU envía s-only en la línea 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. En el otro lado, el CTS envía una respuesta de 200 AUTORIZACIONES a CUCM.

    En esta AUTORIZACIÓN 200 también, el CTS envía s-only en la línea UDP/BFCP. Esto es porque el CTS ha negociado s-only en su tramo de llamada original hacia C60. Puesto que esto es una Re-INVITACIÓN, el CTS debe enviar s-only y c-only en su respuesta 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. Puesto que ambos dispositivos envían s-only (para intentar ser el servidor), CUCM rechaza el BFCP y le hace 0.

    En los registros CUCM, usted ve este mensaje de error:

    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


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

Solución

Este problema se encuentra para ser un problema con el software CTS. Tiene que enviar s-only y c-only cuando responde a la Re-INVITACIÓN. Pero envía solamente s-only, que causa el error contento del Channel Negotiation.

Esto es causada por el Id. de bug Cisco CSCty37410 en el software CTS. Se repara en la versión 1.10.7 y posterior CTS.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118767