Webex for BroadWorks 문제 해결 프로세스

문제 보고

문제 해결 지침을 수행한 후, 문제가 발견된 위치를 합리적으로 파악해야 합니다.

1

문제와 관련된 시스템에서 최대한 많은 정보를 수집합니다.

2

적절한 Cisco 팀으로 연락하여 사례를 접수시킵니다(연락처 섹션 참고).

수집할 클라이언트 정보

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

  • 사용자 식별자: CI 이메일 주소 또는 사용자 UUID(이것은 Webex 식별자이지만 사용자의 BroadWorks 식별자도 확보하면 도움이 될 것입니다.)

  • 조직 식별자

  • 문제가 발생한 대략적인 시간대

  • 클라이언트 플랫폼 및 버전

  • 클라이언트에서 로그 보내기 또는 수집

  • 클라이언트에 표시된 경우, 추적 ID 기록

헬프 데스크에서 사용자 세부 정보 확인

1

https://admin.webex.com/helpdesk에 로그인합니다.

2

사용자를 검색한 후 클릭합니다. 그러면 사용자 요약 화면이 열립니다.

3

자세한 사용자 이름 구성을 확인하려면 사용자 이름을 클릭합니다.

이 보기에서 볼 수 있는 유용한 정보는 사용자의 UUID, 공통 아이덴티티(CI) 클러스터, Webex 앱 클러스터, 통화 행동, BroadWorks 계정 GUID 등입니다.

4

다른 도구에서 이 정보를 사용하려면 복사를 클릭하거나 Cisco 사례에 그것을 첨부하십시오.

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

1

https://admin.webex.com/helpdesk에 로그인합니다.

2

고객 조직 이름을 검색한 후 클릭합니다.

3

고객 포털 보기가 표시될 때까지 아래로 스크롤하고, 고객 이름 보기를 클릭하여 사용자 및 구성이 포함된 고객 조직의 읽기 전용 보기를 조회합니다.

Partner Hub에서 사용자 로그 검색

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

1

사용자에게 로그를 보내도록 요청합니다.

2

사용자에게 통화 환경 내보내기를 실시하여 ced.dat 파일을 보내 달라고 요청합니다.

3

Partner Hub 또는 헬프 데스크에서 클라이언트 로그를 받습니다(아래 참고).

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)가 표시되면 그 사용자는 Webex for BroadWorks를 사용하지 않는 것입니다.)

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

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

클라이언트 로그 또는 피드백 받기

  • Webex 데스크탑 클라이언트에서 특정한 클라이언트 로그를 찾거나 사용자에게 로그를 보내도록 요청하려면 리소스 섹션을 참고하십시오.

  • 모바일 클라이언트의 사용자에게 로그를 보내 달라고 요청한 후, Partner Hub 또는 헬프 데스크를 통해 이를 받을 수 있습니다.


로그 보내기는 비대화형 작업입니다. 그러나 사용자가 피드백을 보내면 이는 Cisco Webex 앱 개발팀으로 보내집니다. 나중에 Cisco에 확인하려면 사용자의 피드백 번호를 기록해 두십시오. 예:

통화 환경 데이터 받기

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

1

클라이언트에서 프로필 사진을 클릭한 후, 도움말 > 통화 환경 데이터 내보내기를 클릭합니다.

2

그 사용자의 통화 문제를 해결하기 위해 결과 파일 ced.dat를 저장합니다.

중요: 클라이언트에서 로그아웃하거나 클라이언트를 다시 시작하면 내부 캐시가 지워집니다. 그 후, ced.dat를 내보내면 내보낸 데이터는 캐시 전에 보내진 로그와 일치하지 않을 것입니다.

Webex 데이터베이스 초기화

1

클라이언트에서 도움말 > 상태 점검기를 클릭합니다.

2

데이터베이스 초기화를 선택합니다.

그러면 클라이언트의 완전한 초기화가 트리거되고, Webex 앱 로그인 화면이 로드됩니다.

Webex가 BroadWorks에 등록해야 하는지 확인

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

  • broadworks-connector에 대한 사용자 자격

  • 조직 및 사용자의 통화 행동

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

  1. 파트너 관리자 자격 증명으로 헬프 데스크(https://admin.webex.com/helpdesk)에 로그인합니다.

  2. 사용자를 검색합니다.

  3. 사용자를 클릭하고 통화 행동 항목을 확인합니다. 이것은 "Webex에서 통화"여야 합니다.

  4. 사용자 이름을 클릭하여 사용자 세부 정보 화면을 엽니다.

  5. 아래로 스크롤하여 자격 섹션을 찾고, broadworks-connector가 포함되었는지 확인합니다.


    Webex for BroadWorks를 사용하려는 사용자는 bc-sp-standard 자격을 갖고 있지 않아야 합니다. 이는 "Webex 통화(Broadcloud)"에 대한 자격으로, Cisco가 관리하는 클라우드 통화 서비스를 통해 이루어지는 Webex 앱 통화입니다.

조직의 통화 행동 확인

  1. 파트너 관리자 자격 증명으로 헬프 데스크(https://admin.webex.com/helpdesk)에 로그인합니다.

  2. 조직을 검색합니다.

  3. 조직을 클릭하고, 통화 행동 항목을 확인합니다. 이는 "Webex에서 통화"여야 합니다.

사용자 프로비저닝 문제에 대한 PSLog 분석

애플리케이션 서버의 PSLog를 사용하여 프로비저닝 브리지에 대한 HTTP POST 요청과 Webex의 응답을 확인합니다.

정확한 작동 사례에서 이 응답은 200 OK이며,몇 분 후 사용자(및 첫 번째 고객인 경우, 새로운 고객 조직)가 Webex에서 만들어지는 것을 볼 수 있습니다.

POST에 보이는 이메일 주소를 헬프 데스크에서 검색하여 이것을 확인할 수 있습니다.

시작하기 전에

테스트 사용자를 사용한 플로우 쓰루 프로비저닝 시도 중에 애플리케이션 서버에서 PSLog를 수집합니다.

1

먼저 확인할 것은 HTTP 응답 코드입니다.

  • 200 OK 이외의 어떤 것도 사용자 프로비저닝 실패입니다.

  • 구독자 프로필에 대한 어떤 것이 프로비저닝 브리지 상류의 Webex 서비스에서 작동하지 않는 경우, 200 OK가 여전히 오류를 나타낼 수도 있습니다.

  • 400에는 메시지 노드가 응답에 들어 있을 수 있습니다. 프로비저닝 브리지가 subscriberProfile에서 무언가를 처리하지 못했습니다. 구독자 세부 정보에 어떤 문제가 있거나 템플릿에 있는 설정과 호환되지 않을 수 있습니다.

  • 401은 AS에 입력된 프로비저닝 자격 증명이 Partner Hub의 템플릿에 입력된 것과 일치하지 않음을 의미합니다.

  • 403은 애플리케이션 서버에서 어떤 것이 잘못 구성되었음을 나타낼 수 있습니다. 요청의 대상을 확인합니다. 이는 IP 주소가 아니고 Partner Hub의 템플릿에서 볼 수 있는 프로비저닝 브리지 URL이어야 합니다.

  • 409는 제공된 subscriberProfile과 기존 Webex 데이터 간의 충돌을 나타냅니다. 그 이메일 주소를 가진 기존의 사용자가 있는 것일 수 있습니다. 응답의 메시지를 확인하십시오.

2

또한 원래의 HTTP POST에서 프로비저닝 실패의 원인일 수 있는 모든 의심되는 값을 확인할 수도 있습니다.

POST에는 subscriberProfile XML 구조가 포함되어 있습니다. 이 안에서 확인할 수 있는 유용한 노드는 다음과 같습니다.

  • bwuserid: BroadWorks에서 구독자를 프로필을 편집해야 하는 경우, 이를 사용하여 찾으십시오.

  • group: 템플릿이 "서비스 제공자 모드"인 경우, 이는 소문자로 표기되며, Partner Hub에서 보이는 고객 조직의 이름이 됩니다.

  • 서비스제공자: 템플릿이 "기업 모드"인 경우, 이것은 소문자로 표기되며, Partner Hub에서 보이는 고객 조직의 이름이 됩니다.

  • 기본 전화번호: 반드시 존재해야 합니다. 이것이 없으면 프로비저닝이 실패합니다.

  • 이메일: 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에 의해 보호됩니다.

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

그림 1. BroadWorks 인증 및 장치 구성

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

  • 사용자는 이메일 주소를 Webex 앱에 제공합니다(다이어그램에서 1).

  • CI는 (UAP를 통해) BroadWorks 비밀번호를 입력하도록 이 사용자를 리다이렉트하는 것을 알고 있습니다(다이어그램의 2).

  • IDP 프록시는 XSP의 Xsi 인터페이스로 프로파일 얻기 요청을 제출합니다.

tomcat 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

    헤더에는 인증이 포함되어 있습니다. Basicuser-agent: broadworksTeamsClient

  • 그 후, XSP는 BroadWorks에 대해 OCI-P 기본 인증을 수행하고(Xsi를 통해 기본 인증을 수행하는 다른 애플리케이션과 같이 AuthenticationVerifyRequest 및 AuthenticationVerifyResponse), UserGetRequest 및 ServiceProviderGetRequest로 구독자 정보도 수집합니다.

  • Webex에 대한 Xsi 응답에는 XML 프로필 블록 (BroadWorks 포함) userId 및 기타 세부 정보가 포함되어 있습니다(다이어그램의 2.2).

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

  • IDP 프록시가 BroadWorks에서 받은 사용자 프로필을 대조하고, SAML 어서션(assertion)을 클라이언트로 발급합니다(다이어그램의 2.3).

  • 클라이언트는 SAML 어셔션을 CI 토큰과 교환합니다(다이어그램의 3).

  • 클라이언트는 로그인한 사용자가 broadworks-connector 자격이 있는지 확인합니다(다이어그램의 4). 헬프 데스크에서 사용자 자격을 확인할 수 있습니다.

  • 클라이언트는 CI 토큰을 사용하여 IDP 프록시로 JSON 웹 토큰(JWT)을 요청합니다(다이어그램의 5).

  • IDP 프록시는 CI에서 CI 토큰의 유효성을 검증합니다.

  • IDP 프록시는 인증 서비스로 JWT를 요청합니다.

authenticationService 로그에서:

  • Webex의 토큰 요청을 검색합니다(다이어그램의 5.2). 예:

    GET /authService/token

    이는 http_bw_userid 헤더 및 다른 것을 갖고 있습니다.

  • XSP는 OCI-P UserGetLoginInfoRequest를 수행하여 제공된 사용자 ID가 BroadWorks 사용자와 일치하는지 검증합니다(다이어그램의 5.3). AuthService는 mTLS 연결을 통해 Webex와 트러스트를 수립했으므로 LLT를 발급할 수 있습니다.

  • LongLivedTokenManager의 응답을 검색합니다(다이어그램의 5.4) - 토큰 생성됨, 대상: bwksUserId@example.com, 발급자: BroadWorks ...

    StatusCode=200 이것을 trackingid: CLIENT… 헤더를 사용하여 원래의 요청과 연결시킬 수 있습니다.

XsiActionsLog에서:

  • 이제 클라이언트는 Xsi-Actions 인터페이스에서 장기 토큰을 제시하여 장치 프로필을 얻을 수 있습니다(다이어그램의 6). 예:

    GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device

    헤더 인증 사용: 베어러 토큰user-agent: WebexTeams(변형/버전)

  • Xsi-Actions 인터페이스는 authservice(루프백 인터페이스에 있도록 구성됨)에 토큰을 포스트(POST)합니다. 예: 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

    이것을 trackingid: CLIENT... 헤더(GET의 경우) 및 X-BROADSOFT-CORRELATION-ID : CLIENT... 헤더(POST의 경우)와 연관시킬 수 있습니다.

authenticationService 로그에서:

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

  • StatusCode=200을 다시 Xsi로 보냄.

  • 그리고 본문에 "token" JSON 블록이 있는 토큰 유효성 검증 응답.

  • 다음을 사용하여 trackingid 연관됨: 클라이언트...

XsiActionsLog에서:

  • authservice에서 200 OK를 받음. 클라이언트의 토큰이 검증되었으며, Xsi-Actions 애플리케이션은 이제 UserPrimaryAndSCADeviceGetListRequest를 위한 OCI-P 요청을 보냅니다.

  • OCI-P UserPrimaryAndSCADeviceGetListResponse(accessDeviceTable XML 구조 포함)를 받습니다.

  • OCI-P 응답은 AccessDevices XML 구조를 포함하여 클라이언트에 대한 Xsi 응답으로 인코딩됩니다. 이는 deviceTypes(예: Business Communicator – PC) 및 클라이언트가 장치 구성 파일을 검색할 수 있는 URL을 갖고 있습니다.

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

  • 장치 항목을 선택하고, DMS와 상호 작용하여 장치 프로필을 받습니다(다이어그램의 6).

  • DMS의 구성에서 검색한 SBC를 통해 BroadWorks에 등록합니다(다이어그램의 7).