피드백을 보내 주셔서 감사합니다.

이 문서는 서비스 제공업체 조직에서 자체 기술 지원 및 고객 기술 지원을 담당하는 팀을 대상으로 합니다. 그들은 일반적인 문제 해결, 로그 읽기 및 가입자 사례 처리에 익숙해야 합니다.

이 글은 크게 세 부분으로 나뉩니다.

• 참고 자료 - 필요한 도구, 읽을거리, 기록 및 연락처 목록을 제공합니다.
• 프로세스 - 고객 문제 해결 중에 취할 수 있는 몇 가지 조치를 설명합니다.
• 구체적인 문제점 - 발생했던 문제점들을 분류하고 목록으로 정리하며, 문제점을 발견하는 방법과 해결 방법을 제시합니다.

유용한 로그 파일

추천 도서 목록

• Cisco BroadWorks 파트너 기술 자료 포털용 Webex
• XSP 플랫폼 구성 가이드(R23)
• BroadWorks 소프트웨어 관리 가이드(R23)
• Cisco BroadWorks 장치 관리 구성 가이드(R23)
• Broadworks XSP 명령줄 인터페이스 관리 가이드
• 긴 수명 인증 토큰 기능 설명 릴리즈 23.0
• SAML 인증 통합 가이드, R23
• Cisco BroadWorks SSL 지원 옵션 가이드
• Cisco CI 지원 기능 설명
• 알림 푸시 서버 (기능 설명)
• 통화 기능에 대한 푸시 알림 지원 설명 릴리즈 22.0
• Connect(Android)에서 Firebase로 마이그레이션하는 절차
• Cisco BroadWorks 푸시 알림용 장치 토큰 저장 기능 설명 (릴리스 22.0)
• Cisco BroadWorks 시스템 용량 계획 도구(스프레드시트)
• Cisco BroadWorks 플랫폼 규모 산정 가이드
• Cisco Broadworks 시스템 엔지니어링 가이드
• CI 인증 지원 요구 사항 문서 버전 1.0 MR-7136

알려진 문제 및 제한 사항

알려진 문제 및 제한 사항 문서에는 Webex for BroadWorks 솔루션에서 확인된 알려진 문제에 대한 최신 정보가 포함되어 있습니다.

서비스 가능성 커넥터

Webex 서비스 가능성 서비스는 Cisco 기술 지원 담당자가 인프라 문제를 진단하는 속도를 향상시켜 줍니다. 이 시스템은 진단 로그를 찾고, 검색하고, 저장하는 작업을 자동화하고, 관련 정보를 SR 사례에 입력합니다. 또한 이 서비스는 진단 서명에 대한 분석을 트리거하여 TAC가 온-프레미스 장비에서 더욱 효율적으로 문제를 식별하고 해결할 수 있게 합니다.

서비스 가능성 커넥터를 배포하는 방법에 대한 자세한 내용은 Cisco Webex 서비스 가능성 커넥터 배포 가이드를 참조하세요.

문제 확대

문제 해결 지침을 몇 가지 따라해 보시면 문제의 근본 원인이 어디에 있는지 어느 정도 파악할 수 있을 것입니다.

절차

1. 해당 문제와 관련된 시스템에서 가능한 한 많은 정보를 수집하십시오.
2. 시스코의 담당 팀에 연락하여 지원 사례를 개설하십시오.

어떤 고객 정보를 수집해야 할까요?

사례를 접수시키거나 문제를 보고해야 한다고 판단되면 사용자와 함께 문제를 해결하는 동안 다음 정보를 수집하십시오.

• 사용자 식별자: CI 이메일 주소 또는 사용자 UUID(Webex 식별자이지만, 사용자의 BroadWorks 식별자도 함께 알 경우 사례 세부 정보에 포함하십시오).
• 조직 식별자.
• 문제가 발생했던 대략적인 기간입니다.
• 클라이언트 플랫폼 및 버전.
• 클라이언트로부터 로그를 전송하거나 수집합니다.
• 클라이언트에 추적 ID가 표시되면 기록해 두십시오.

헬프데스크에서 사용자 정보를 확인하세요.

헬프데스크 관리자(기본 또는 고급) 역할 권한을 가진 파트너 관리자는 이 절차를 사용하여 헬프데스크 보기로 사용자 세부 정보를 확인할 수 있습니다.

절차

1. 헬프 데스크에 로그인하세요.
2. 사용자를 검색한 후 클릭합니다. 그러면 사용자 요약 화면이 열립니다.
3. 자세한 사용자 이름 구성을 확인하려면 사용자 이름을 클릭합니다. 이 보기에서 유용한 정보에는 사용자의 UUID, 공통 ID(CI) 클러스터, Webex 앱 클러스터, 통화 동작, BroadWorks 계정 GUID가 포함됩니다.
4. 다른 도구에서 이 정보를 사용하려면 복사를 클릭하거나 Cisco 사례에 첨부합니다.

헬프데스크에서 고객 조직 보기

헬프데스크 관리자(기본 또는 고급) 역할 권한을 가진 파트너 관리자는 이 절차를 사용하여 헬프데스크 보기에서 고객 조직 세부 정보를 볼 수 있습니다.

절차

1. 헬프 데스크에 로그인하세요.
2. 고객 조직 이름을 검색한 후 클릭합니다.
3. 고객 포털 보기 가 보일 때까지 아래로 스크롤한 다음 고객 이름 보기 를 클릭하여 사용자 및 구성을 포함한 고객 조직의 읽기 전용 보기를 확인하세요.

파트너 허브에서 사용자 로그를 검색합니다.

데스크톱 및 모바일 클라이언트 문제를 해결할 때 파트너(및 기술 지원 센터)가 클라이언트 로그를 볼 수 있는 것이 중요합니다.

절차

1. 사용자에게 로그를 보내도록 요청합니다. 도움이 필요하시면 다음을 참조하십시오. Webex 앱 | 문제 보고.
2. 사용자에게 통화 환경을 내보내고 ced.dat 파일을 보내달라고 요청하세요.
3. 파트너 허브 또는 헬프 데스크에서 클라이언트 로그를 가져오세요.

   Partner Hub 옵션:

   1. Partner Hub에 로그인하고 사용자의 고객 조직을 찾습니다.
   2. 문제 해결을 선택합니다.
   3. 로그를 선택합니다.
   4. (이메일로) 사용자를 검색합니다.
   5. 클라이언트 로그를 조회하고 zip 파일로 다운로드합니다.

   헬프 데스크 옵션:

   1. 헬프 데스크에 로그인합니다.
   2. 조직을 검색합니다.
   3. 조직을 클릭합니다(요약 화면이 열림).
   4. 아래로 스크롤하여 고객 보기를 클릭하세요.
   5. 문제 해결을 선택합니다.
   6. 로그를 선택합니다.
   7. (이메일로) 사용자를 검색합니다.
   8. 클라이언트 로그를 조회하고 zip 파일로 다운로드합니다.

클라이언트 버전을 찾는 방법

절차

1. 다음 링크를 사용자와 공유합니다. https://help.webex.com/njpf8r5
2. 사용자에게 버전 번호를 보내 달라고 요청합니다.

고객 통화 확인

절차

1. Webex 클라이언트에 로그인합니다.
2. 통화 옵션 아이콘(위에 기어가 있는 수화기)이 사이드바에 있는지 확인합니다. 아이콘이 없으면 아직 사용자가 Control Hub에서 통화 서비스에 대해 활성화되지 않았을 수 있습니다.
3. 설정/기본 설정 메뉴를 열고 전화 서비스 섹션으로 이동합니다. 로그인된 SSO 세션 상태가 보여야 합니다. (Webex Calling과 같은 다른 전화 서비스가 표시되는 경우, 사용자가 Cisco BroadWorks용 Webex를 사용하지 않는 것입니다.)

   이 검증은 다음을 의미합니다.

   • 클라이언트가 필요한 Webex 마이크로 서비스를 성공적으로 통과했습니다.
   • 사용자가 성공적으로 인증했습니다.
   • 클라이언트는 BroadWorks 시스템에서 장기간 사용 가능한 JSON 웹 토큰을 발급받습니다.
   • 클라이언트가 장치 프로필을 검색하고 BroadWorks에 등록했습니다.

고객 로그 또는 피드백을 받으세요

• Webex 데스크탑 클라이언트에서 특정한 클라이언트 로그를 찾거나 사용자에게 로그를 보내도록 요청하려면 리소스 섹션을 참조하십시오. 도움이 필요하시면 다음을 참조하십시오. Webex 앱 | 문제 보고.
• 모바일 클라이언트 사용자에게 로그를 보내달라고 요청하면 파트너 허브 또는 헬프 데스크를 통해 해당 로그를 받을 수 있습니다.
  로그 보내기는 비대화형 작업입니다. 단, 사용자가 피드백을 보내는 경우에 이는 Webex 앱 개발팀으로 발송됩니다. 나중에 Cisco에 확인하려면 사용자의 피드백 번호를 기록해 두십시오. 예:

  

통화 환경 데이터 얻기

Webex 클라이언트 로그는 개인 식별 정보를 제거하기 위해 충분히 편집됩니다. 문제가 발견된 동일한 세션에 있는 클라이언트에서 통화 환경 데이터를 내보내야 합니다.

절차

1. 클라이언트에서 도움말 을 클릭하세요. > 건강 진단 도구.
2. 데이터베이스 초기화를 선택합니다. 이렇게 하면 클라이언트가 완전히 재설정되고 Webex 앱 로그인 화면이 로드됩니다.

Webex가 BroadWorks에 등록해야 하는지 확인하십시오.

Webex 앱은 BroadWorks에 등록할지 여부를 결정하기 위해 다음 정보를 확인합니다.

• broadworks-connector에 대한 사용자 권한.
• 조직 및 사용자에 대한 호출 동작.

사용자의 통화 행동 및 커넥터 자격 확인

1. 파트너 관리자 자격 증명을 사용하여 헬프 데스크 에 로그인하십시오.
2. 사용자를 검색합니다.
3. 사용자를 클릭하고 통화 행동 항목을 확인합니다. 이는 "Webex의 Calling"이어야 합니다.

   

4. 사용자 이름을 클릭하여 사용자 세부 정보 화면을 엽니다.
5. 아래로 스크롤하여 entitlements 섹션을 찾고 broadworks-connector 가 포함되어 있는지 확인하십시오.

   

   Webex for Cisco BroadWorks 사용자는 Webex for Cisco BroadWorks를 사용하려는 경우 bc-sp-standard 권한을 보유해서는 안 됩니다. 이는 Cisco에서 관리하는 클라우드 통화 서비스를 통해 Webex 앱으로 통화할 수 있는 "Webex 통화(Broadcloud)" 권한입니다.

조직의 통화 행동 확인

1. 파트너 관리자 자격 증명을 사용하여 헬프 데스크 에 로그인하십시오.
2. 조직을 검색합니다.
3. 해당 조직을 클릭하고 통화 동작 항목을 확인하세요. 이는 Webex의 Calling"이어야 합니다.

PSLog를 분석하여 사용자 프로비저닝 문제를 파악합니다.

응용프로그램 서버의 PSLog를 사용하여 프로비저닝 브리지에 대한 HTTP POST 요청과 Webex의 응답을 확인합니다. 정확한 작동 사례에서 이 응답은 200 OK이며, 몇 분 후 사용자(및 첫 번째 고객인 경우, 새로운 고객 조직)가 Webex에서 만들어지는 것을 볼 수 있습니다. POST에 보이는 이메일 주소를 헬프 데스크에서 검색하여 이것을 확인할 수 있습니다.

시작하기 전에

테스트 사용자를 사용한 플로우 쓰루 프로비저닝 시도 중에 응용프로그램 서버에서 PSLog를 수집합니다.

절차

1. 먼저 HTTP 응답 코드를 확인하세요.
   • 200 OK 이외의 어떤 것도 사용자 프로비저닝 실패입니다.
   • 200 OK 응답은 프로비저닝 브리지 상위의 Webex 서비스에서 가입자 프로필 관련 문제가 발생한 경우 오류를 나타낼 수 있습니다.
   • 응답에 message 노드가 포함될 수 있습니다. 프로비저닝 브리지가 subscriberProfile안에 있는 항목을 처리할 수 없습니다. 구독자 세부 정보에 어떤 문제가 있거나 템플릿에 있는 설정과 호환되지 않을 수 있습니다.
   • 401은 AS에 입력된 프로비저닝 자격 증명이 Partner Hub의 템플릿에 입력된 것과 일치하지 않음을 의미합니다.
   • 403은 응용프로그램 서버에서 어떤 것이 잘못 구성되었음을 나타낼 수 있습니다. 요청의 대상을 확인합니다. 이는 IP 주소가 아니고 Partner Hub의 템플릿에서 볼 수 있는 프로비저닝 브리지 URL이어야 합니다.
   • 409는 제공된 subscriberProfile 와 기존 Webex 데이터 간의 충돌을 나타냅니다. 그 이메일 주소를 가진 기존의 사용자가 있는 것일 수 있습니다. 응답에서 대괄호 message ([]) 를 확인하세요.
2. 또한 원래의 HTTP POST에서 프로비저닝 실패의 원인일 수 있는 모든 의심되는 값을 확인할 수도 있습니다. POST 요청에는 subscriberProfile XML 구조가 포함되어 있습니다. 이 안에서 확인할 수 있는 유용한 노드는 다음과 같습니다.
   • bwuserid: BroadWorks에서 구독자를 프로필을 편집해야 하는 경우, 이를 사용하여 찾으십시오.
   • group: 템플릿이 "서비스 제공업체 모드"인 경우, 이 값은 소문자로 변환되어 파트너 허브에 표시되는 고객 조직 이름이 됩니다.
   • serviceProvider: 템플릿이 "기업 모드"인 경우, 이것은 소문자로 표기되며, Partner Hub에서 보이는 고객 조직의 이름이 됩니다.
   • primaryPhoneNumber: 반드시 존재해야 합니다. 이것이 없으면 프로비저닝이 실패합니다.
   • email: Webex에서 사용자 ID가 됩니다. 유효하고 Webex에 고유해야 하며, 그렇지 않으면 프로비저닝이 실패합니다.

     services 절은 무시하세요: 이것은 AS가 만들며, Webex는 이를 수락하지만 사용하지 않습니다.

XSP 로그를 분석하여 가입자 로그인 문제를 해결합니다.

이 흐름은 BroadWorks 인증 모드를 설명합니다. Partner Hub에서 BroadWorks 템플릿의 인증 모드를 볼 수 있습니다. 의 https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726고객 템플릿 구성을 참조하십시오.

다음 사다리형 다이어그램은 사용자가 Webex 앱에서 BroadWorks 인증을 수행할 때 사용자, 클라이언트, Webex 서비스 및 BroadWorks 시스템 간의 상호 작용을 보여줍니다. 또한 Webex와 XSP 간의 연결은 MTLS로 보호됩니다.

다음은 성공적인 로그인에 대해 로그를 조사할 때 볼 수 있는 정보에 대한 설명입니다.

사용자가 클라이언트와 상호 작용하고, 클라이언트는 Webex 서비스와 상호 작용합니다.

• 사용자는 Webex 앱에 이메일 주소를 입력합니다(다이어그램의 1).
• CI는 (UAP를 통해) BroadWorks 비밀번호를 입력하도록 이 사용자를 리디렉션하는 것을 알고 있습니다(다이어그램의 2).
• IDP 프록시는 XSP의 Xsi 인터페이스로 프로파일 얻기 요청을 제출합니다.

톰캣에서 access_log:

• Webex에서 Xsi-Actions 인터페이스 쪽으로 구독자 프로필에 대한 GET 요청을 검색합니다(다이어그램의 2.1). 이것은 Webex 사용자 ID를 갖고 있습니다. 예를 들면,

  GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

XsiActionsLog에서:

• Webex의 프로필 GET 요청을 검색합니다(다이어그램의 2.1). 이것은 Webex 사용자 ID를 갖고 있습니다. 예를 들면,

  GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile 헤더에는 authorization: Basic 및 user-agent: broadworksTeamsClient가 포함됩니다.

• 그 후, XSP는 BroadWorks에 대해 OCI-P 기본 인증을 수행하고(Xsi를 통해 기본 인증을 수행하는 다른 응용프로그램과 같이 AuthenticationVerifyRequest 및 AuthenticationVerifyResponse), UserGetRequest 및 ServiceProviderGetRequest로 구독자 정보도 수집합니다.
• Webex에 대한 Xsi 응답에는 (BroadWorks) userId 및 기타 세부 정보를 포함하는 XML Profile 블록이 있습니다(다이어그램의 2.2).

클라이언트 및 Webex 서비스 상호 작용:

• IDP 프록시는 BroadWorks에서 수신한 사용자 프로필과 일치하는 항목을 찾아 클라이언트에 SAML 어설션을 발행합니다(다이어그램의 2.3).
• 클라이언트는 SAML 어설션을 CI 토큰으로 교환합니다(다이어그램의 3번).
• 클라이언트는 로그인한 사용자가 broadworks-connector 자격이 있는지 확인합니다(다이어그램의 4). 사용자 권한은 헬프데스크에서 확인할 수 있습니다.
• 클라이언트는 CI 토큰을 사용하여 IDP 프록시(다이어그램의 5번)로부터 JSON 웹 토큰(JWT)을 요청합니다.
• IDP 프록시는 CI에서 CI 토큰의 유효성을 검증합니다.
• IDP 프록시는 인증 서비스로부터 JWT를 요청합니다.

authenticationService 로그에서:

• Webex에서 보낸 토큰 요청(다이어그램의 5.2)을 찾아보세요. 예를 들면 다음과 같습니다. GET /authService/token 헤더와 기타를 포함하는 http_bw_userid 입니다.
• XSP는 제공된 사용자 ID가 BroadWorks 사용자에 해당하는지 확인하기 위해 OCI-P UserGetLoginInfoRequest를 수행합니다(다이어그램의 5.3). AuthService는 mTLS 연결을 통해 Webex와 트러스트를 설정했으므로 LLT를 발급할 수 있습니다.
• LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks … 및 StatusCode=200 에서 받은 응답(다이어그램의 5.4)을 찾아 trackingid: CLIENT… 헤더를 사용하여 원래 요청과 연결하세요.

XsiActionsLog에서:

• 클라이언트는 Xsi-Actions 인터페이스에 장기 토큰을 제시하여 장치 프로필을 가져올 수 있습니다(다이어그램의 6). 예를 들면, GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device 헤더 authorization: Bearer token 및 user-agent: WebexTeams (variant/version)와 함께
• Xsi-Actions 인터페이스는 토큰을 인증 서비스(루프백 인터페이스에 있도록 구성됨)로 POST 요청을 보냅니다. 예를 들면 다음과 같습니다. 127.0.0.1:80 POST http://127.0.0.1:80/authService/token 는 GET 의 [ trackingid: CLIENT… 헤더 및 POST의 X-BROADSOFT-CORRELATION-ID : CLIENT… 헤더와 연관시킬 수 있습니다.

authenticationService 로그에서:

• Xsi로부터 POST 수신(루프백)

• Xsi로 돌아가기 StatusCode=200

• 그리고 토큰 유효성 검사 응답에는 본문에 "token" JSON 블록이 포함됩니다.

• 다음을 사용하여 연결됨 trackingid: CLIENT…

XsiActionsLog에서:

• 인증 서비스로부터 클라이언트 토큰 유효성 검사에 성공한 200 OK 응답을 받은 Xsi-Actions 애플리케이션은 이제 OCI-P 요청을 보냅니다. UserPrimaryAndSCADeviceGetListRequest
• accessDeviceTable XML 구조를 포함하는 OCI-P UserPrimaryAndSCADeviceGetListResponse 를 수신합니다.
• OCI-P 응답은 클라이언트에 대한 Xsi 응답으로 인코딩되며, 여기에는 deviceTypesAccessDevices XML 구조가 포함됩니다. 예를 들면, Business Communicator – PC 및 클라이언트가 장치 구성 파일을 검색할 수 있는 URL.

클라이언트는 정상적으로 계속합니다.

• 장치 항목을 선택하고 DMS와 상호 작용하여 장치 프로필을 가져옵니다(다이어그램의 6).
• DMS에서 가져온 구성에서 SBC를 통해 BroadWorks에 등록합니다(다이어그램의 7).

파트너 허브 문제

1. 관리자는 고객 조직을 볼 수 없습니다.

Webex에서 파트너 조직의 관리자로서 전체 관리자 역할을 보유해야 합니다. 이 역할은 관리자가 자신 및 다른 사용자에게 관리 권한을 지정하는 것을 포함하여 파트너 조직을 관리하는 데 사용됩니다. 고객 조직을 관리하려면 자신(또는 다른 사람)에게 영업 전체 관리자 역할 또는 영업 관리자 역할을 부여해야 합니다. 자세한 내용은 Control Hub에서 조직 계정 역할 할당을 참조하세요.

사용자 프로비저닝 문제

1. 통합 IM & 특정 기업에 대한 P 오류 / 고객

예를 들어 UC-One SaaS와 Cisco BroadWorks용 Webex처럼 서로 다른 클라우드 협업 서비스를 사용하는 기업이 혼합되어 있는 경우, 기업별로 프로비저닝 어댑터를 수정하도록 선택했을 수 있습니다.

통합 IM에 대해 어떤 설정이 되어 있는지 확인하려면 & P(더 구체적인 설정이 없는 한 기업의 기본값), AS_CLI/Interface/Messaging> get실행. 특정 기업의 프로비저닝 매개변수를 확인하려면 해당 기업을 열고 서비스 로 이동하세요. > 통합 IM & P.

해당 기업의 통합 IM&P 구성이 Partner Hub의 고객 템플릿에 표시되는 것과 일치하는지 확인합니다. 다음 설정은 반드시 일치해야 합니다. 그렇지 않으면 기업의 모든 사용자에서 프로비저닝이 실패합니다.

2. 통합 IM & 특정 사용자에 대한 P 오류

이는 플로우스루 프로비저닝을 사용하는 경우에 적용되며, 프로비저닝이 정상적으로 작동하고 있다고 가정합니다. some/most 사용자(따라서 구성 문제를 배제할 수 있습니다). 통합 IM이 표시되는 경우 & 예를 들어 BroadWorks에서 발생하는 P 오류 “[Error [18215] 메시징 서버 프로비저닝 오류 발생] “[Error "18211] 메시징 서버와의 통신 오류"가 발생한 경우, 다음과 같은 잠재적 원인을 조사해야 합니다.

• 사용자의 이메일 주소가 이미 CI에 존재할 수 있습니다. 헬프데스크에서 해당 사용자를 검색하여 이메일 주소가 이미 등록되어 있는지 확인하십시오. 이것이 반드시 확정적인 것은 아닙니다. 해당 사용자가 헬프데스크에서 볼 수 없는 조직에 속해 있을 수도 있기 때문입니다.
• 사용자가 통합 IM&P 서비스를 지정하기 전에 독립적으로 Webex에 가입했습니다. 이 경우 한 가지 옵션은 사용자가 무료 계정을 삭제하고 프로비저닝 중인 고객 조직에 가입하도록 하는 것입니다. 안내 사항은 다음과 같습니다. https://help.webex.com/5m4i4y
• 해당 사용자의 프로필에 기본 전화번호가 등록되어 있지 않습니다(Webex for Cisco BroadWorks 가입자는 모두 기본 DID를 등록해야 합니다). AS에서 PSLog 분석에 대한 주제를 참조하십시오.

3. 프로비저닝 브리지 응답에서 사용자 프로비저닝 실패

통합 인스턴트 메시징(IM)을 할당한 후 몇 분 이내에 사용자가 Control Hub에 나타나지 않는 경우 & P님, 프로비저닝 브리지 서비스의 응답 코드를 확인해 보세요. PSLog를 실행하여 HTTP 응답 코드를 살펴보십시오.

200 OK

200 OK 응답 은 사용자가 성공적으로 프로비저닝되었다는 것을 의미하지 않습니다. 이는 프로비저닝 서비스가 요청을 수신하고, 해당 사용자 만들기 요청을 상류의 서비스에 성공적으로 제출했다는 의미입니다. 프로비저닝 트랜잭션은 설계상 비동기적입니다. 사용자 생성 프로세스는 몇 분 정도 소요될 수 있으며, 성능상의 이유로 동일한 사용자를 생성하려는 요청이 여러 번 발생하는 것을 방지하기 위해 서비스는 200 OK 응답을 보냅니다. 하지만 200 OK 응답을 받은 후에도 사용자가 고객 조직에 나타나지 않으면 프로비저닝 서비스 상위의 Webex 서비스에서 사용자 생성이 실패했을 가능성이 있습니다. 200 OK 응답을 받은 프로비저닝 실패는 보고해야 합니다.

400 잘못된 요청

프로비저닝 서비스에서 이 응답을 유발할 수 있는 잠재적인 문제에 대한 보다 자세한 설명이 있는 HTTP 응답을 확인하십시오. 노드의 일부 예:

• "BroadWorks 이메일을 레거시 프로비저닝 API를 사용하여 신뢰할 수 없습니다." 사용자 프로비저닝 요청 실패와 관련된 이메일 주소가 유효하지 않거나 잘못 입력되었으나 관리자가 그 이메일 주소를 신뢰할 수 있다고 템플릿에서 어설션(assert)했습니다. BroadWorks의 사용자 프로필, 특히 이메일 ID를 확인합니다.
• 고객 조직이 데이터베이스에서 발견되지 않았으며, 새 조직 생성 플래그도 활성화되어 있지 않습니다. 이 실패한 프로비저닝 요청은 Webex에서 새로운 고객 조직을 만들어야 하지만 새 고객 조직을 만들지 못하도록 템플릿이 구성되었습니다. 새 조직을 허용하려면 Webex에 있는 기존의 고객과 일치하지 않는 이메일 도메인일 경우, Partner Hub에서 템플릿을 다시 구성하고 프로비저닝 요청을 다시 테스트할 수 있습니다. 그러나 이 사용자에 대해 새로운 조직이 만들어지는 것을 예상하지 않았다면 이메일 주소가 잘못 입력되었을 것입니다(특히 도메인 부분). BroadWorks에서 사용자의 이메일 ID를 확인합니다.

403 금지됨

구성을 수정하기 전까지는 프로비저닝 요청이 성공할 수 없습니다. 이 경우에는 요청과 응답 내용을 조사해야 합니다. 예를 들어, 조직에 대해 적절한 프로비저닝 브리지 URL 대신 IP 주소가 프로비저닝 요청의 대상으로 보인다면(솔루션 안내서에서 방화벽 구성 주제 참조) 이것은 응용프로그램 서버에 필요한 패치(ap373197)가 없음을 나타내는 것일 수 있습니다.

필요한 모든 패치가 응용프로그램 서버에 적용되고, 성공적인 플로우 쓰루 프로비저닝을 위한 관련 구성을 완료했는지 확인합니다.

409 충돌

요청에 있는 이메일 주소와 일치하는 기존의 사용자가 Webex에 있기 때문에 프로비저닝 요청을 진행할 수 없습니다.

4. 사용자가 이미 CI에 있음

구독자 이메일을 HTTP POST 요청에서 제거하고 헬프 데스크에서 검색합니다. 권한이 없으면 해당 사용자를 보지 못할 수 있지만 그 사용자가 '무료' 조직(예: "소비자")에 있다면 볼 수도 있습니다. 그 사용자에게 무료 계정을 삭제하도록 요구하거나 다른 이메일 주소를 사용하여 계정을 프로비저닝할 수 있습니다. https://help.webex.com/ndta402을(를) 참조하십시오.

사용자 로그인 문제

1. 사용자 활성화 포털이 로드되지 않습니다.

정상적인 Cisco BroadWorks용 Webex 로그인 흐름에는 사용자가 비밀번호를 입력하는 사용자 활성화 포털이 포함됩니다. 웹엑스 앱 로그인 화면에서 사용자가 이메일 주소를 입력한 후에도 이 포털이 로드되지 않는 경우가 있습니다. 이 문제는 클라이언트 측 또는 서비스 측에서 발생할 수 있습니다. 클라이언트 측에서는 일반적으로 클라이언트의 고유 브라우저가 서비스와 어떤 식으로든 호환되지 않아서 발생합니다.

2. 통합 인증 실패

• BroadWorks에서 사용자가 Webex 앱에 대한 장치 유형이 할당되었는지 확인하십시오(솔루션 가이드의 환경 준비 ] 섹션에 있는 []장치 프로필 섹션 참조).
• 사용자가 올바른 비밀번호를 사용하고 있는지 확인하십시오. 파트너 허브에서 사용자의 고객 조직을 프로비저닝하는 데 사용한 템플릿이 BroadWorks 인증용으로 구성된 경우 사용자는 BroadWorks "웹 액세스" 암호를 입력해야 합니다. 사용자의 이메일 주소가 대체 사용자 ID로 구성되어 있지 않은 경우, BroadWorks 사용자 ID를 입력해야 할 수도 있습니다. 사용자가 대문자와 소문자를 정확하게 입력했는지 확인하십시오.

통화 구성 및 등록 문제

Webex에서 사용자가 프로비저닝되고 Webex 앱에 성공적으로 로그인하면 앱이 BroadWorks에 등록됩니다. 다음은 예상되는 회원가입 절차와 (Webex 앱에서 확인할 수 있는) 정상적인 회원가입의 결과입니다.

1. 예상 등록 순서

1. 클라이언트는 XSI를 호출하여 장치 관리 토큰 및 DMS로의 URL을 얻습니다.
2. 클라이언트는 1단계의 토큰을 제시하여 DMS로 장치 프로필을 요청합니다.
3. 클라이언트는 장치 프로필을 읽고 SIP 자격 증명, 주소 및 포트를 검색합니다.
4. 클라이언트는 3단계의 정보를 사용하여 SIP REGISTER를 SBC로 보냅니다.
5. SBC는 AS로 SIP REGISTER를 전송합니다. (SBC가 SIP 사용자를 이미 알고 있지 않은 경우 NS에서 조회를 수행하여 AS를 찾을 수 있습니다.)

2. 성공적인 고객 등록의 예상되는 징후

Webex 인터페이스에 통화 옵션 아이콘이 나타납니다.

Webex 앱의 전화 서비스 탭에서 (예: 설정 > 전화 서비스 Windows의 환경 설정 > 전화 서비스 (Mac에서) "SSO 세션:"이라는 메시지가 표시됩니다. 로그인되었습니다"라는 메시지는 앱이 (이 경우는 BroadWorks에) 성공적으로 등록되었음을 의미합니다.

3. 클라이언트에 통화 아이콘이 없습니다.

대부분의 경우, 이는 사용자가 정확한 라이센스/자격을 갖고 있지 않다는 의미입니다.

이것은 등록 실패입니다. Webex 앱 클라이언트가 BroadWorks에 등록되지 않는 데에는 여러 가지 이유가 있습니다.

4. 동일한 클라이언트를 대상으로 여러 통화 서비스를 테스트 중입니다.

이 문제는 클라이언트가 여러 개의 통화 백엔드를 변경하기 때문에 발생할 수 있습니다. 이러한 현상은 (동일한) Webex 앱 클라이언트를 통해 제공되는 다양한 통화 서비스를 테스트하는 동안 발생할 가능성이 가장 높습니다. 클라이언트 데이터베이스(링크)를 재설정하여 이 문제를 해결할 수 있습니다.

5. 인증 서비스 구성 오류

솔루션 안내서에서 인증 서비스를 호스팅하는 XSP를 확인합니다(참조: Cisco BroadWorks용 Webex XSP에서 서비스 구성). 구체적으로:

• RSA 키(한 XSP에서 생성하는 것)는 모든 XSP에 복사됩니다.
• 인증 서비스 URL이 모든 XSP의 웹 컨테이너에 제공되고, Partner Hub의 클러스터에 정확하게 입력되었습니다.
• 인증서에 의해 외부 인증이 구성됩니다.

  XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication>get

  allowUserApp = false

  allowClientApp = true

• MTLS를 사용하는 경우 Webex 클라이언트 인증서를 XSP에 업로드해야 합니다(인증서는 BroadWorks 설정 페이지의 파트너 허브에서 얻을 수 있습니다).

6. BroadWorks 태그의 잘못된 구성

Webex 앱에 필요한 BroadWorks 태그가 구성되어 있는지 확인하십시오. 구성 태그에 대한 자세한 내용은 Webex for Cisco BroadWorks 구성 가이드 를 참조하십시오. 충돌이나 잘못된 값이 없는지 확인하십시오. 구체적으로 말하면, %SBC_ADDRESS_WXT% 태그는 Webex 앱 클라이언트의 SIP 등록기관에 대한 SBC여야 합니다.

7. 데스크톱 클라이언트가 SSO 연결 성공 후 전화 서비스를 끊습니다.

이 문제는 동일한 사용자가 동일한 플랫폼 유형의 여러 클라이언트에 로그인함으로써 발생할 수 있습니다. 예를 들어, 사용자가 Windows에서 Webex 앱에 성공적으로 로그인한 후 다른 Windows 컴퓨터에서 Webex 앱에 로그인하면 두 컴퓨터 중 하나에만 SSO 세션이 활성화됩니다. 이는 설계에 의해 의도된 것입니다. 이 문제를 반드시 해결해야 하는 경우, BroadWorks가 동일한 장치 유형의 여러 인스턴스를 사용하도록 구성할 수 있지만 고유한 SIP 주소가 있어야 합니다. 이 구성은 Cisco BroadWorks용 Webex의 범위를 벗어납니다.

8. 사용자에게 데스크톱 장치가 할당되지 않았습니다.

이 서명은 클라이언트 로그에서 확인할 수 있습니다.

[0x70000476b000] BroadWorksConfigDownloader.cpp:106

onAccessDeviceListSucceeded:BWC:SCF: ConfigDownload - the device profile 'Business Communicator - PC' is not found.

9. 수신 전화가 한 번만 울리거나 받을 수 없습니다.

Webex 모바일로 걸려오는 전화가 한 번만 울리거나, 사용자가 전화를 받을 수 없는 경우. 같은 사용자의 다른 단말기는 계속해서 벨이 울릴 수 있습니다.

어떻게 식별할 수 있을까요?

Webex 모바일 클라이언트 로그에서 푸시 통화 흐름 중 XSI 오류 코드 101002를 찾으십시오. 예를 들면,

응답 코드: 400

handlePushCallInfoFailure:BWC:INTERNAL: 푸시 알림: callID에 대한 xsi 상태: <callID> xsi 오류 코드: 101002

closePushCallWithReason:BWC:INTERNAL: ID를 사용하여 푸시 알림을 종료해 보세요. = <callID>, 이유 = 통화 중단됨

원인: 오류 코드 101002는 LocateUser 응답에서 잘못된 애플리케이션 서버(AS)가 반환되었음을 나타낼 수 있습니다. 이는 사용자가 보조 AS로 마이그레이션했을 때 발생할 수 있습니다.

권장 점검 사항:

푸시 기능이 배포된 ADP 또는 XSP에서 영향을 받는 사용자에 대해 LocateUser 를 실행합니다.

curl 'http://:80/servlet/LocateUser?url=&returnCompatibleXSP=true&callPRequest=true'

예: curl 'http://1.1.1.1:80/servlet/LocateUser?url=9721112222@gmail.com&returnCompatibleXSP=true&callPRequest=true'

해상도: 만약 LocateUser 가 사용자의 보조 AS를 반환하면 기본 NS 서버에서 migrateUserToDefaultNode.pl 스크립트를 실행하여 사용자를 클러스터의 기본 애플리케이션 서버로 다시 마이그레이션합니다.

SSH를 통해 NS 서버에 로그인하고, /usr/local/broadworks/bw_base/bin 디렉토리로 이동하여 다음 명령을 실행하십시오.migrateUserToDefaultNode.pl

예: migrateUserToDefaultNode.pl bwas1

hostingNE 값을 얻으려면 다음을 실행하세요. NS_CLI/System/Device/HostingNE> get

스크립트는 먼저 인수로 제공된 호스팅 NE를 찾을 수 있는지 확인합니다. 호스팅 NE가 유효한지 확인한 후, DN, 확장자 및 URL을 해당 호스팅 NE의 기본 노드로 업데이트합니다.

가능하면 트래픽이 적은 시간대에 스크립트를 실행하세요. 하지만 영향을 받는 사용자의 서비스를 복구해야 할 경우 언제든지 스크립트를 실행하는 것이 일반적으로 허용됩니다.

해당 스크립트는 단일 사용자 전용으로 실행할 수 없습니다. 이 기능은 LocateUser 출력에 나열된 모든 사용자를 마이그레이션합니다. 스크립트를 실행할 수 없는 경우 BroadWorks에서 해당 사용자를 삭제하고 다시 생성하여 올바른 AS에 사용자가 다시 생성되도록 하십시오.

사용자 장치에서 보조 AS로 전송되는 모든 SIP 메시지는 사용자의 마이그레이션을 유발할 수 있습니다. 사용자는 일반적으로 기본 15분 간격 후에 기본 AS로 롤백하지만, 수신 요청이 보조 AS에 계속 도달하는 경우에는 예외입니다. 예를 들어 SBC가 AS1에 연결할 수 없고 보조 AS로 재귀적으로 연결하는 경우, 영향을 받는 사용자는 보조 AS로 전환될 수 있습니다. 배포 방식에 따라 SBC가 기본 AS에 연결하는 데 계속 문제가 발생하는 경우 단일 트렁크 그룹 또는 사용자가 보조 AS에 고정된 상태로 유지될 수 있습니다.

자세한 정보는 다음 문서를 참조하십시오.

• Cisco BroadWorks 이중화 가이드의 섹션 3.4.5 애플리케이션 서버 사용자 롤백 기능 및 섹션 5.4.5 자동 롤백을 참조하십시오.

• Cisco BroadWorks ASR 기능 향상 설명

통화 설정 웹뷰 문제

1. 자가 관리 button/link Webex 앱에 표시되지 않음

이 문제의 다른 증상은 버튼/링크가 표시되지만 그것을 클릭하면 외부 브라우저가 열리는 것입니다.

• 필수 클라이언트 구성 템플릿이 배포되었는지, CSW 태그가 올바르게 설정되었는지 확인하십시오. (Webex for Cisco BroadWorks 솔루션 가이드의 통화 설정 웹뷰 섹션을 참조하십시오.)
• BroadWorks에서 Webex 앱이 통화용으로 등록되어 있는지 확인하십시오.
• Webex 앱이 CSWV를 지원하는 최신 버전인지 확인하십시오.

2. 셀프 케어를 클릭한 후 빈 페이지가 표시되거나 오류가 발생합니다. button/link

일반적으로 Webex 앱에서 이러한 동작이 나타나는 것은 BroadWorks XSP의 CSWV 애플리케이션 구성 또는 배포 문제임을 나타냅니다. CSWV 로그, 액세스 로그, config-wxt.xml 저장소 및 템플릿 파일을 포함하여 추가 조사를 위한 세부 정보를 수집한 후 사례를 보고하십시오.

도메인 소유권 문제

도메인을 클레임할 때 오류가 발생하여 사용자 등록 오류가 일어날 수 있습니다. 도메인을 클레임하기 전에 다음을 확실히 이해해야 합니다.

• 서비스 공급자는 관리하는 고객 조직의 도메인을 클레임하지 않아야 합니다. 해당 공급자는 서비스 공급자의 내부 조직에 있는 해당 사용자의 도메인만 클레임해야 합니다. 사용자 인증 요청이 고객 조직이 아닌 서비스 공급자를 통해 라우팅되면 개별 조직 내 사용자의 도메인(서비스 공급자가 관리하는 것 포함)을 클레임하면 고객 조직에 있는 사용자에 대한 등록 오류가 발생할 수 있습니다.
• 두 개의 고객 조직(회사 A 및 회사 B)이 동일한 도메인을 공유하고 있으며 회사 A가 도메인을 클레임한 경우, 사용자 인증 요청이 클레임된 도메인이 있는 조직(회사 A)을 통해 라우팅되므로 회사 B 사용자에 대한 등록은 실패할 수도 있습니다.

  오류로 도메인을 클레임하고 클레임을 제거해야 하는 경우, 도메인 관리 Webex 문서를 참조하십시오.

최종 사용자 오류 코드

다음 표는 클라이언트 사용자 활성화 포털에 표시될 수 있는 최종 사용자 오류 코드를 요약한 것입니다.

디렉터리 동기화 오류 코드

다음 오류 코드는 디렉터리 동기화에 적용됩니다.