网真 : Cisco 网真 3010

CTS终端已进行会议与MCU 4505不能共享演示

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 23 日) | 反馈

简介

本文描述也许发生的问题,当MCU 4505是使用的为了会议本地思科网真设备,例如思科网真系统(CTS)时3000和CTS 1000。

贡献用Devasaayee Gopalan, Cisco TAC工程师

问题

当在MCU 4505会议和演示不工作时, CTS终端不协商内容信道。

情形 1:CTS终端在与a.c.的一呼叫-系列终端。C系列终端收到第二次呼叫并且添加第二次呼叫到与MCU 4505的一个Multiway会议。

方案 2:CTS终端和CTS终端B在一点到点(P2P)呼叫。CTS终端添加CTS终端C到与MCU 4505的会议。

日志分析

方案1详细解释此处。行为是相同的为第二个场景。

  1. CTS做第一个呼叫对C60,并且UDP /binary楼层控制协议(BFCP)协商。这时, CTS协商作为仅服务器(s)。

  2. C60接收此作为第二次呼叫并且尝试添加CTS到Multiway会议。单击接受和会议

  3. 在呼叫应答后, C60传送参考的信息对CTS通过Cisco Unified Communications Manager (CUCM)。

  4. CUCM更新CTS并且设立往MCU的一个新的呼叫段。

  5. CUCM发送在另一个现有呼叫段的一再邀请往CTS。

  6. MCU发送对CUCM的一200 OK答复。

    呼叫段往MCU > MCU发送邀请的200 OK从CUCM。

    在这中, MCU发送s在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. 在另一侧, CTS发送对CUCM的一200 OK答复。

    在也此200 OK, CTS发送s在UDP/BFCP线路。这是因为CTS协商s在其往C60的原始呼叫段。因为这是再邀请, CTS应该发送s和C在其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. 因为两个设备发送s (为了设法是服务器), CUCM拒绝BFCP并且做它0

    在CUCM日志,您看到此错误消息:

    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


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

解决方案

发现此问题与CTS软件的一问题。当响应对再邀请时,它必须发送s和C。但是它只发送s,导致内容信道谈判失败。

这是由Cisco Bug ID CSCty37410造成的在CTS软件方面。它在CTS版本1.10.7和以上修复。


相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


Document ID: 118767