TelePresence : Cisco TelePresence System 3010

Les points finaux Conferenced CTS avec MCU 4505 ne peuvent pas partager la présentation

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit un problème qui pourrait se poser quand MCU 4505 est les périphériques indigènes utilisés de TelePresence Cisco de conférence, tels que le système de TelePresence Cisco (CTS) 3000, et le CTS 1000.

Contribué par Devasaayee Gopalan, ingénieur TAC Cisco

Problème

Les points finaux CTS ne négocient pas le canal satisfait quand dans une conférence MCU 4505 et la présentation ne fonctionne pas.

Scénario 1 : Le point final CTS est dans un appel avec le courant alternatif - point final de gamme. Le point final de série C reçoit un deuxième appel et ajoute le deuxième appel dans une conférence de Multiway avec MCU 4505.

Scénario 2 : Le point final-Un CTS et le point final-b CTS sont dans un appel point par point (de P2P). Le point final-Un CTS ajoute le point final-C CTS dans la conférence avec MCU 4505.

Analyse de log

Le scénario 1 est expliqué en détail ici. Le comportement est identique pour le deuxième scénario aussi bien.

  1. CTS fait le premier appel à C60 et l'UDP/Control Protocol binaire de plancher (BFCP) est négocié. Cette fois, CTS est négocié en tant que serveur seulement (réservé à la s).

  2. C60 reçoit ceci en tant qu'un deuxième appel et essais pour ajouter CTS dans une conférence de Multiway. Le clic reçoivent et conférence.

  3. Après que l'appel soit répondu, C60 envoie un message de RÉFÉRER à CTS par l'intermédiaire de Cisco Unified Communications Manager (CUCM).

  4. CUCM met à jour le CTS et établit un nouveau tronçon d'appel vers le MCU.

  5. CUCM envoie une Re-INVITATION sur l'autre tronçon existant d'appel vers CTS.

  6. Le MCU envoie une réponse de 200 OKS à CUCM.

    Le tronçon d'appel vers MCU > MCU envoie un OK 200 pour l'INVITATION de CUCM.

    En cela, le MCU envoie réservé à la s dans la ligne 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. De l'autre côté, CTS envoie une réponse de 200 OKS à CUCM.

    Dans cet OK 200 également, CTS envoie réservé à la s dans la ligne UDP/BFCP. C'est parce que le CTS a négocié réservé à la s dans son tronçon d'appel initial vers C60. Puisque c'est une Re-INVITATION, CTS devrait envoyer réservé à la s et réservé à la C dans sa réponse de l'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. Puisque les deux périphériques envoient réservé à la s (afin d'essayer d'être le serveur), CUCM rejette le BFCP et lui fait 0.

    Dans les logs CUCM, vous voyez ce message d'erreur :

    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


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

Solution

Cette question s'avère un problème avec le logiciel CTS. Il doit envoyer réservé à la s et réservé à la C quand il répond à la Re-INVITATION. Mais il envoie seulement réservé à la s, qui entraîne la panne satisfaite de négociation de canal.

Ceci est provoqué par par l'ID de bogue Cisco CSCty37410 en logiciel CTS. Il est réparé dans la version 1.10.7 et ultérieures CTS.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118767