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

이 문서는 자신과 고객을 지원하는 서비스 제공업체 조직의 기술 지원 팀을 위한 거예요. 일반 문제 해결, 로그 읽기, 구독자 사례 처리에 익숙해야 해요.

이 기사는 크게 세 섹션으로 나눠져 있어요.

• 리소스—필요할 수도 있는 도구, 읽기 자료, 로그, 연락처 목록을 제공합니다.
• 프로세스—고객 문제를 해결하는 동안 취할 수 있는 몇 가지 조치를 설명해요.
• 특정 문제—발생한 것으로 알려진 문제, 문제를 발견하는 방법, 잠재적으로 해결할 수 있는 방법을 분류하고 나열해요.

유용한 로그 파일들

읽기 목록

• 시스코 브로드웍스용 웹엑스 파트너 지식 포털
• XSP 플랫폼 구성 가이드 (R23)
• 브로드웍스 소프트웨어 관리 가이드 (R23)
• 시스코 브로드웍스 장치 관리 구성 가이드 (R23)
• 브로드웍스 Xsp 커맨드 라인 인터페이스 관리 가이드
• 수명이 긴 인증 토큰 기능 설명 릴리스 23.0
• SAML 인증 통합 가이드, R23
• 시스코 브로드웍스 SSL 지원 옵션 가이드
• 시스코 CI 지원 기능 설명
• 알림 푸시 서버 (기능 설명)
• 통화 푸시 알림 지원 기능 설명 릴리즈 22.0
• 커넥트 (안드로이드) Firebase로 마이그레이션 절차 방법
• 시스코 브로드웍스 푸시 알림용 디바이스 토큰 스토리지 기능 설명 릴리스 22.0
• 시스코 브로드웍스 시스템 용량 플래너 (스프레드시트)
• 시스코 브로드웍스 플랫폼 크기 측정 가이드
• 시스코 브로드웍스 시스템 엔지니어링 가이드
• CI 인증 지원 요구 사항 문서 버전 1.0 MR-7136

알려진 문제들과 한계점들

알려진 문제 및 제한 사항 문서에는 Webex for BroadWorks 솔루션에서 확인한 알려진 문제에 대한 최신 정보가 있어요.

서비스성 커넥터

Webex Serviceability 서비스는 시스코 기술 지원 직원이 인프라 문제를 진단할 수 있는 속도를 높여줘요. SR 케이스에 진단 로그와 정보를 찾고, 검색하고 저장하는 작업을 자동화해요. 또한 이 서비스는 TAC가 온프레미스 장비의 문제를 더 효율적으로 식별하고 해결할 수 있도록 진단 시그니처에 대한 분석을 트리거해요.

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

문제 에스컬레이션하기

문제 해결 지침을 따르고 나면 문제의 원인이 어디인지 합리적으로 알 수 있을 거예요.

절차요

1. 문제와 관련된 시스템에서 가능한 한 많은 정보를 수집하세요.
2. 케이스를 열려면 Cisco 담당팀에 연락하세요.

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

케이스를 개설하거나 문제를 에스컬레이션해야 한다고 생각되면 사용자와 문제 해결하면서 다음 정보를 수집하세요.

• 사용자 식별자: CI 이메일 주소 또는 사용자 UUID (이것은 Webex 식별자이지만 사용자의 브로드웍스 식별자도 받는 경우 사례 세부 정보에 포함하세요).
• 조직 식별자예요.
• 문제가 발생한 대략적인 시간대예요.
• 클라이언트 플랫폼 및 버전.
• 클라이언트에서 로그를 보내거나 수집해요.
• 클라이언트에 표시되는 경우 추적 ID를 기록해 두세요.

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

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

절차요

1. 헬프 데스크에 로그인하세요.
2. 사용자를 검색하고 클릭해요. 사용자 요약 화면이 열려요.
3. 사용자 이름을 클릭하면 자세한 사용자 구성을 볼 수 있어요. 이 뷰의 유용한 정보에는 사용자 UUID, 공통 ID (CI) 클러스터, 웹엑스 앱 클러스터, 통화 행동, 브로드웍스 계정 GUID가 포함돼요.
4. 이 정보를 다른 도구에서 사용하거나 Cisco 케이스에 첨부하려면 복사를 클릭하세요.

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

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

절차요

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

파트너 허브에서 사용자 로그 검색

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

절차요

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

   파트너 허브 옵션:

   1. 파트너 허브에 로그인해서 사용자의 고객 조직을 찾아보세요.
   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 세션 상태가 보여야 해요. (예를 들어, 다른 전화 서비스가 표시되는 경우, 사용자는 Cisco BroadWorks용 Webex를 사용하고 있지 않아요.) Webex Calling

   이 검증은 다음을 의미해요.

   • 클라이언트가 필요한 Webex 마이크로서비스를 성공적으로 트래버싱했어요.
   • 사용자가 성공적으로 인증했어요.
   • 당신의 브로드웍스 시스템에서 수명이 긴 JSON 웹 토큰을 클라이언트에 발급해요.
   • 클라이언트가 장치 프로필을 검색하고 브로드웍스에 등록했어요.

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

• Webex 데스크탑 클라이언트에서 특정 클라이언트 로그를 찾거나 사용자에게 로그를 보내도록 요청하려면 리소스 섹션을 참조하십시오. 도움이 필요하면 다음을 참조하십시오. Webex 앱 | 문제 신고.
• 모바일 클라이언트 사용자들에게 로그를 보내달라고 요청하면 파트너 허브나 헬프 데스크를 통해 받을 수 있어요.
  전송 로그는 무음이에요. 하지만 사용자가 피드백을 보내면 Webex 앱 데브옵스 팀에 전달돼요. Cisco에 후속 조치를 취하려면 사용자 피드백 번호를 기록해 두세요. 예를 들자면:

  

통화 환경 데이터 가져와

웹엑스 클라이언트 로그가 개인 식별 정보를 제거하도록 많이 편집됐어요. 문제를 발견한 후 같은 세션에서 클라이언트로부터 통화 환경 데이터를 내보내야 해요.

절차요

1. 클라이언트에서 도움말 > 상태 검사기를 클릭해요.
2. 데이터베이스 재설정을 선택해요. 그러면 클라이언트가 완전히 재설정되고 Webex 앱 로그인 화면이 로드돼요.

웹엑스가 브로드웍스에 등록해야 하는지 확인해

웹엑스 앱은 다음 정보를 확인하여 브로드웍스에 등록할지 여부를 결정해요.

• 브로드웍스 커넥터 사용자 자격.
• 조직과 사용자의 통화 행동.

사용자의 통화 행동과 커넥터 사용 권한 확인

1. 파트너 관리자 자격 증명으로 헬프 데스크에 로그인해요.
2. 사용자를 검색하세요.
3. 사용자를 클릭하고 통화 행동 항목 확인해. “Webex 전화 걸기”여야 해요.

   

4. 사용자 이름을 클릭하여 사용자 세부 정보 화면을 여세요.
5. 아래로 스크롤하여 권한 섹션을 찾고 브로드웍스 커넥터가 포함되어 있는지 확인하세요.

   

   시스코 브로드웍스용 웹엑스 사용자는 시스코 브로드웍스용 웹엑스를 사용하려는 경우 bc-sp 표준 자격이 없어야 해요. 이것은 시스코 매니지드 클라우드 통화 서비스를 통한 웹엑스 앱 콜링인 “Webex Calling(브로드클라우드)" 에 대한 자격이에요.

조직의 통화 행동을 확인해 보세요.

1. 파트너 관리자 자격 증명으로 헬프 데스크에 로그인해요.
2. 조직을 검색해 보세요.
3. 조직을 클릭하고 통화 행동 항목을 확인하세요. “Webex 전화 걸기”여야 해요.

사용자 프로비저닝 문제에 대한 PSLog를 분석해 보세요.

애플리케이션 서버의 PSLog를 사용하여 프로비저닝 브리지에 대한 HTTP POST 요청과 웹엑스의 응답을 확인하세요. 정상 작동 사례를 예로 들면 응답은 200 OK이고 몇 분 후에 웹엑스에서 사용자 (첫 번째 사용자인 경우 새 고객 조직) 가 생성된 것을 볼 수 있어요. 헬프 데스크에서 POST에 보이는 이메일 주소를 검색해서 확인할 수 있어요.

시작하기 전에

테스트 사용자와 플로우스루 프로비저닝을 시도하는 동안 애플리케이션 서버에서 PSLog를 수집해요 .

절차요

1. 먼저 HTTP 응답 코드를 확인해 보세요.
   • 200 OK 이외는 사용자 프로비저닝 실패예요.
   • 200 좋아요. 구독자 프로필에 관한 무언가가 프로비저닝 브리지의 Webex 서비스 업스트림에서 작동하지 않으면 여전히 실패를 의미할 수 있어요.
   • 400은 응답에 메시지 노드를 포함할 수 있어요. 프로비저닝 브리지가 구독자 프로필의 무언가를 처리하지 못했어요. 구독자 세부 정보에 문제가 있거나 템플릿 설정과 호환되지 않을 수 있어요.
   • 401은 AS에 입력한 프로비저닝 자격 증명이 파트너 허브의 템플릿에 입력한 것과 일치하지 않는다는 뜻이에요.
   • 403은 애플리케이션 서버에 뭔가 잘못 구성되어 있는 것일 수 있어요. 요청 대상을 확인하세요. IP 주소가 아니어야 하고 파트너 허브 템플릿에서 볼 수 있는 프로비저닝 브리지 URL이어야 해요.
   • 409는 제공된 구독자 프로필과 기존 웹엑스 데이터 간의 충돌을 나타냅니다. 그 이메일 주소를 가진 기존 사용자가 있을 수 있어요. 응답에 있는 메시지 확인해.
2. 또한 원본 HTTP POST에서 프로비저닝 실패의 원인이 될 수 있는 의심스러운 값이 있는지 확인할 수 있어요. POST에 구독자 프로필 XML 구조가 들어 있어요. 안에서 확인할 만한 유용한 노드는 다음과 같아요.
   • bwuserid: 브로드웍스에서 편집해야 할 경우 구독자 프로필을 찾을 때 사용하세요.
   • 그룹: 템플릿이 “서비스 제공자 모드”인 경우 소문자로 표시되고 파트너 허브에 표시되는 고객 조직의 이름이 됩니다.
   • ServiceProvider: 템플릿이 “엔터프라이즈 모드”인 경우 소문자로 표시되고 파트너 허브에 표시되는 고객 조직의 이름이 됩니다.
   • 기본 전화번호: 반드시 존재해야 해요. 그것 없이는 프로비저닝이 실패해요.
   • 이메일: 웹엑스의 사용자 ID가 돼요. 유효하고 Webex에서만 사용할 수 있는 것이어야 해요. 그렇지 않으면 프로비저닝이 실패해요.

     서비스 스탠자는 무시하세요. AS에서 만들고 웹엑스에서 수락은 하지만 사용하지는 않아요.

구독자 로그인 문제 해결하려면 XSP 로그를 분석하세요.

이 흐름은 브로드웍스 인증 모드를 설명해요. 인증 모드는 파트너 허브의 브로드웍스 템플릿에서 볼 수 있어요. https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726 에서 고객 템플릿 구성을 참조하십시오.

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

다음 토론에서는 로그인에 성공하기 위해 로그를 조사할 때 어떤 결과를 기대할 수 있는지 설명해요.

사용자는 클라이언트와 상호작용하고, 클라이언트는 Webex 서비스와 상호작용해요:

• 사용자가 Webex 앱에 이메일 주소를 제공해요 (다이어그램의 1개).
• CI는 이 사용자를 (UAP를 통해) 브로드웍스 암호를 입력하도록 리디렉션하는 것을 알고 있어요 (도표 2번).
• IDP 프록시가 XSP의 Xsi 인터페이스에 프로필 가져오기 요청을 제출해요.

톰캣 액세스_로그에서:

• 웹엑스에서 엑시액션 인터페이스 (도표 2.1) 로 가는 구독자 프로필에 대한 GET 요청을 찾아보세요. 웹엑스 사용자 ID가 있어요. 예를 들자면:

  GET /com.broadsoft.xsi-actions/v2.0/사용자/ webexuserid@example.com /프로필

XSI 액션 로그에서:

• 웹엑스에서 프로필 GET 요청을 찾아봐요 (도표 2.1). 웹엑스 사용자 ID가 있어요. 예를 들자면:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile 헤더에는 권한 부여가 포함돼요: 기본 및 사용자 에이전트: 브로드웍스팀스클라이언트

• 그러면 XSP는 브로드웍스에 대한 OCI-P 기본 인증 (Xsi를 통해 기본 인증을 수행하는 다른 애플리케이션과 마찬가지로 AuthenticationVerifyRequest 및 AuthenticationVerifyResponse) 을 수행하고 UserGetRequest와 ServiceProviderGetRequest를 사용하여 가입자 정보를 수집해요.
• 웹엑스에 대한 Xsi 응답에는 (브로드웍스) 사용자 ID 및 기타 세부 정보 (다이어그램의 2.2) 를 포함하는 XML 프로필 블록이 포함되어 있어요.

클라이언트와 웹엑스 서비스 상호작용:

• IDP 프록시는 브로드웍스에서 받은 사용자 프로필과 매칭하고 클라이언트에 SAML 어설션을 발행해요 (도표 2.3).
• 클라이언트가 SAML 어설션을 CI 토큰으로 교환해요 (도표 3장).
• 클라이언트가 로그인한 사용자에게 브로드웍스 커넥터 자격 (그림 4) 이 있는지 확인해요. 헬프 데스크에서 사용자 자격을 확인할 수 있어요.
• 클라이언트가 CI 토큰을 사용하여 IDP 프록시에 JSON 웹 토큰 (JWT) 을 요청해요 (그림 5).
• IDP 프록시는 CI에서 CI 토큰을 검증해요.
• IDP 프록시가 인증 서비스에 JWT를 요청해요.

인증 서비스 로그에서:

• 웹엑스에서 토큰 요청을 찾아보세요 (다이어그램에서 5.2). 예를 들어, http_bw_userid 헤더가 있는 GET /AuthService/Token을 찾아보세요.
• XSP는 제공된 사용자 ID가 브로드웍스 사용자 (도표 5.3) 에 해당하는지 확인하기 위해 OCI-P UserGetLoginInfoRequest를 해요. AuthService가 mTLS 연결 덕분에 웹엑스와 신뢰를 구축했으니 LLT를 발행할 수 있어요.
• LongLivedTokenManager - 토큰 생성, 제목: bwksUserId@example.com, 발행자: 브로드웍스... 그리고 트래킹 ID: CLIENT... 헤더를 사용하여 원래 요청과 연결할 수 있는 상태 코드=200에서 응답 (도표 5.4) 을 찾아보세요.

XSI 액션 로그에서:

• 클라이언트가 Xsi-Actions 인터페이스에 수명이 긴 토큰을 제시하여 장치 프로파일 (그림 6) 을 가져올 수 있어요. 예: GET /com.Broadsoft.xsi-actions/v2.0/user/bwkSuserID %40example.com/profile/device 헤더 인증 포함: 베어러 토큰 및 사용자 에이전트: WebExTeams (변형/버전)
• 엑시액션 인터페이스가 토큰을 인증 서비스 (루프백 인터페이스에 있도록 구성) 에 포스팅해요. 예를 들면: 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token GET의 트래킹ID: CLIENT... 헤더와 POST의 X-BROADSOFT-CORRELATI-ID: CLIENT... 헤더와 상관관계가 있을 수 있어요.

인증 서비스 로그에서:

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

• 상태 코드=200이에요. Xsi로 돌아가기

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

• 트래킹 ID 사용 시 상관관계: 클라이언트...

XSI 액션 로그에서:

• 클라이언트의 토큰을 검증한 인증 서비스로부터 200 확인을 받았으니, 엑시액션 애플리케이션이 이제 사용자 프라이머리와 SCA DeviceGetList 요청으로 OCI-P 요청을 보낸대요
• OCI-P 사용자 기본 및 액세스 장치 테이블 XML 구조를 포함하는 SCA 장치 GetList 응답을 수신해요.
• OCI-P 응답은 클라이언트에 대한 Xsi 응답으로 인코딩돼요. 디바이스 유형이 있는 AccessDevices XML 구조도 포함돼요. 예: 비즈니스 커뮤니케이터 — PC와 클라이언트가 장치 구성 파일을 검색할 수 있는 URL이에요.

클라이언트는 정상적으로 계속돼요:

• 장치 항목을 선택하고 DMS와 상호작용해서 장치 프로필을 가져와요 (그림 6번).
• DMS에서 구성으로 검색한 SBC를 통해 브로드웍스에 등록해요 (그림 7).

파트너 허브 문제

1.관리자가 고객 조직을 볼 수 없어요.

Webex에서 파트너 조직의 관리자로서, 당신은 전체 관리자 역할을 가져야 해요. 그 역할은 자신과 다른 사람에게 관리자 권한을 할당하는 것을 포함하여 파트너 조직을 관리하는 데 사용돼요. 고객 조직을 관리하려면 본인 (또는 다른 사람들에게) 영업 전체 관리자 역할 또는 영업 관리자 역할을 부여해야 해요. 자세한 내용은 컨트롤 허브에서 조직 계정 역할 할당을 참조하세요.

사용자 프로비저닝 문제예요

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

여러 기업이 서로 다른 클라우드 협업 서비스 (예: UC-one SaaS와 Cisco BroadWorks용 Webex for Cisco BroadWorks) 를 사용하는 경우 엔터프라이즈별로 프로비저닝 어댑터를 수정하기로 선택했을 수 있어요.

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

해당 엔터프라이즈의 통합 IM&P 구성이 Partner Hub의 고객 템플릿에 표시된 것과 정확히 일치하는지 확인하세요. 다음 설정이 일치해야 해요. 그렇지 않으면 기업 내 모든 사용자의 프로비저닝이 실패해요.

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

플로우 스루 프로비저닝을 사용하고 있고 일부/대부분의 사용자에게 프로비저닝이 작동한다고 가정할 때 적용돼요 (따라서 구성 문제는 배제할 수 있음). BroadWorks에서 통합 IM&P 오류 (예: “[오류 18215] 메시징 서버 프로비전 오류”, “[오류 18211] 메시징 서버와의 통신 오류” 같은 통합 IM&P 오류가 표시되면 다음과 같은 잠재적 원인을 조사해야 해요.

• 사용자 이메일 주소가 이미 CI일 수도 있어요. 헬프 데스크에서 사용자를 검색하여 이메일 주소가 이미 있는지 확인해 보세요. 헬프 데스크에서 데이터를 보는 것이 허용되지 않은 조직에 사용자가 있을 수 있기 때문에 이것이 반드시 결정적이지는 않아요.
• 사용자가 통합 IM&P 서비스를 할당받기 전에 독립적으로 Webex에 가입했어요. 이 경우 한 가지 옵션은 사용자가 당신이 제공하는 고객 조직의 일원이 될 수 있는 무료 계정을 삭제하도록 하는 거예요. 지침은 https://help.webex.com/5m4i4y 에 있어요
• 사용자의 프로필에 기본 전화번호가 지정되어 있지 않아요 (모든 Webex for Cisco BroadWorks 구독자는 기본 DID가 있어야 합니다). AS의 PSLog 분석에 관한 주제 보세요.

3.프로비저닝 브리지로 인한 사용자 프로비저닝 실패

통합 IM&P 할당 후 몇 분 안에 Control Hub에 사용자가 나타나지 않으면 프로비저닝 브리지 서비스의 응답 코드를 보세요. PSLog를 실행해서 HTTP 응답 코드를 봐요.

200 OK

200 OK 응답은 사용자가 성공적으로 프로비전되었다는 뜻은 아니에요.프로비전 서비스가 요청을 받고 해당 사용자 생성 요청을 업스트림 서비스에 성공적으로 제출했다는 뜻이에요. 프로비저닝 트랜잭션은 설계상 비동기식이에요. 서비스에서 200 OK로 응답해요. 사용자 생성 프로세스에 몇 분이 걸릴 수 있고 성능상의 이유로 동일한 사용자를 생성하라는 요청을 여러 번 받고 싶지 않기 때문이죠. 하지만 200 OK 응답 후 사용자가 결국 고객 조직에 나타나지 않는다면, 프로비저닝 서비스의 Webex 서비스 업스트림에서 사용자 생성이 실패했음을 의미할 수 있어요. 200 OK 응답을 받는 프로비저닝 실패를 에스컬레이션해야 해요.

400 잘못된 요청이에요

프로비저닝 서비스에서 이 응답을 일으킬 수 있는 잠재적 문제에 대한 자세한 내용이 있는 HTTP 응답을 확인해 보세요. 노드 몇 가지 예시:

• “레거시 프로비저닝 API를 사용하는 브로드웍스 이메일을 믿을 수 없어요.”실패한 사용자 제공 요청과 관련된 이메일 주소가 유효하지 않거나 잘못 입력되었는데 이메일 주소를 신뢰할 수 있다고 템플릿에 명시하셨어요. 브로드웍스에서 사용자 프로필, 특히 이메일 ID를 확인하세요.
• 데이터베이스에서 고객 조직을 찾을 수 없고 또한 새 조직 생성 플래그가 활성화되지 않았어요.” 이 실패한 프로비저닝 요청은 웹엑스에 새 고객 조직을 생성해야 하는데, 템플릿은 새로운 고객 조직이 생성되지 않도록 구성되어 있어요. Webex의 기존 고객과 일치하지 않는 이메일 도메인에 대해 새 조직을 허용하려면 Partner Hub에서 템플릿을 재구성하고 프로비저닝 요청을 다시 테스트할 수 있어요. 하지만 이 사용자를 위해 새 조직이 만들어질 것으로 예상하지 못한다면 이메일 주소 (특히 도메인 부분) 를 잘못 입력했을 수 있어요. 브로드웍스에서 사용자 이메일 ID를 확인해.

403 금지됐어요

구성을 수정하기 전까지는 프로비저닝 요청이 성공할 수 없어요. 이 경우 요청과 응답을 조사해야 해요. 예를 들어 조직의 적절한 프로비전 브리지 URL 대신 IP 주소가 프로비저닝 요청 대상으로 표시되면 (솔루션 가이드의 방화벽 구성 항목 참조) 애플리케이션 서버에 필수 패치 (ap373197) 가 없는 것일 수 있어요.

애플리케이션 서버에 필요한 패치가 모두 적용되었는지 확인하고 성공적인 플로우 스루 프로비저닝을 위해 관련 구성을 완료했는지 확인하세요.

409 갈등

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

4.사용자가 이미 CI에 있어요

HTTP POST 요청에서 구독자 이메일을 꺼내 헬프 데스크에서 검색해 보세요. 허용되지 않으면 사용자를 보지 못할 수도 있지만 사용자가 '자유' 단체에 속해 있다는 것도 볼 수 있어요. 예: “소비자”. 이 사용자에게 무료 계정을 삭제하도록 요청하거나 다른 이메일 주소를 사용하여 무료 계정을 제공할 수 있어요. https://help.webex.com/ndta402 봐요.

사용자 로그인 문제

1.사용자 활성화 포털이 로드되지 않아요.

일반적인 Cisco BroadWorks용 Webex 로그인 플로우에는 사용자가 비밀번호를 입력하는 사용자 활성화 포털이 포함돼요. 사용자가 Webex 앱 로그인 화면에서 이메일 주소를 입력한 후 이 포털이 로드되지 않는 경우가 있어요. 이 문제는 클라이언트 측이나 서비스 측에서 발생할 수 있어요. 클라이언트 쪽에서는 보통 클라이언트의 기본 브라우저가 서비스와 어떤 식으로든 호환되지 않아서 발생해요.

2.싱글 사인온 실패했어요

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

통화 구성 및 등록 문제

사용자가 Webex에서 프로비전되고 Webex 앱에 성공적으로 로그인하면 앱이 BroadWorks에 등록돼요. 다음은 예상 등록 순서와 그에 따른 정상 등록의 징후예요 (웨벡스 앱에서 본 결과).

1.등록 순서 예상돼요

1. 클라이언트가 XSI에 전화해서 장치 관리 토큰하고 DMS URL을 가져와요.
2. 클라이언트가 1단계에서 토큰을 제시해서 DMS에 장치 프로필을 요청해요.
3. 클라이언트가 장치 프로필을 읽고 SIP 자격 증명, 주소 및 포트를 검색해요.
4. 클라이언트가 3단계의 정보를 사용하여 SBC에 SIP 레지스터를 보낸대요.
5. SBC가 SIP 레지스터를 AS에 보낸대요 (SBC가 SIP 사용자를 아직 모르는 경우 SBC는 NS에서 검색을 수행하여 AS를 찾을 수 있어요.).

2.고객 등록 성공의 예상 신호들

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

웹엑스 앱 전화 서비스 탭 (예: Windows의 설정 > 전화 서비스, 기본 설정 > Mac의 전화 서비스) 에서, “SSO 세션: 로그인했습니다”라는 메시지는 앱이 성공적으로 등록되었음을 의미해요 (이 경우 BroadWorks에).

3.클라이언트에는 통화 아이콘이 없어요

대부분의 경우 이는 사용자가 올바른 라이선스/자격을 가지고 있지 않다는 뜻이에요.

등록이 실패했어요. Webex 앱 클라이언트가 BroadWorks에 등록에 실패하는 데에는 여러 가지 이유가 있어요.

4.같은 클라이언트로 여러 통화 서비스 테스트 중이에요

이 알려진 문제는 클라이언트가 서로 다른 콜백엔드를 바꿔서 생길 수 있어요. 대부분 (동일한) Webex App 클라이언트를 통해 제공되는 다양한 통화 서비스를 평가판 사용 중에 발생할 수 있어요. 클라이언트 데이터베이스 (링크) 를 재설정하여 이 문제를 해결할 수 있어요.

5.인증 서비스의 잘못된 구성

솔루션 가이드와 비교하여 인증 서비스를 호스팅하는 XSP를 확인하세요 (Cisco BroadWorks XSP용 Webex에서 서비스 구성 참조). 구체적으로:

• 한 XSP에서 생성한 RSA 키가 모든 XSP에 복사돼요
• 인증 서비스 URL이 모든 XSP의 웹 컨테이너에 제공되었고 파트너 허브의 클러스터에 올바르게 입력되었어요.
• 인증서에 의한 외부 인증이 구성되어 있어요:

  XSP_CLI/시스템/통신 유틸리티/기본 설정/외부 인증/인증서 인증 > 받기

  allowUserApp = false

  allowClientApp = true

• MTLS를 사용할 때, Webex 클라이언트 인증서를 XSP에 업로드해야 해요 (인증서는 브로드웍스 설정 페이지의 파트너 허브에서 받을 수 있어요).

6.브로드웍스 태그의 잘못된 구성

웹엑스 앱에 필요한 브로드웍스 태그를 구성했는지 확인하세요. 구성 태그에 대한 정보는 Cisco BroadWorks용 Webex 구성 가이드를 참조하십시오. 충돌이나 잘못된 값이 없는지 확인해 주세요. 구체적으로 말하자면, %SBC_ADDRESS_WXT% 태그는 웹엑스 앱 클라이언트의 SIP 등록 기관에 대한 SBC여야 해요.

7이에요.데스크톱 클라이언트가 SSO 연결 성공 후 전화 서비스 연결을 끊어요

이 문제는 같은 플랫폼 유형에서 같은 사용자가 여러 클라이언트에 로그인해서 발생할 수 있어요. 예를 들어, 사용자가 윈도우에서 Webex 앱에 성공적으로 로그인한 다음 다른 윈도우 시스템에서 Webex 앱에 로그인하면, 컴퓨터 중 하나에서 활성 SSO 세션만 활성화되어 있어요. 이것은 의도된 거예요. 이 문제를 꼭 해결해야 하는 경우, 같은 장치 유형의 인스턴스를 여러 개 갖도록 BroadWorks를 구성할 수 있어요. 단 인스턴스는 고유한 SIP 주소를 가져야 해요. 이 구성은 시스코 브로드웍스용 웹엑스의 범위를 벗어나요.

8.데스크톱 장치가 사용자를 위해 프로비전되지 않았어요

이 서명은 클라이언트 로그에 보여요.

[0x70000476b000] 브로드웍스 컨피그 다운로더.CPP:106 <Error>

OnAccess 장치 목록 성공: BWC:SCF: 구성 다운로드 - 장치 프로필 '비즈니스 커뮤니케이터 - PC'를 찾을 수 없어요.

9.인바운드 휴대폰 전화가 한 번 울리거나 받을 수 없어요

Webex 모바일로 걸려오는 인바운드 전화는 한 번만 울립니다. 그렇지 않으면 사용자가 인바운드 전화에 응답할 수 없어요. 같은 사용자의 다른 엔드포인트는 계속 울릴 수 있어요.

식별 방법이에요?

웨벡스 모바일 클라이언트 로그에서 푸시 콜 플로우의 XSI 오류 코드 101002를 찾아보세요. 예를 들자면:

응답 코드: 400

<callID>푸시 콜 정보 실패 처리하기: BWC: 내부: 푸시 콜: xsi 통화 ID 상태: xsi 오류 코드: 101002

<callID>이유:BWC:내부: 푸시 콜 닫기: id =, 이유 = 통화 포기됨으로 푸시 콜 종료 시도

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

추천 체크:

푸시가 배포된 ADP나 XSP에서 해당 사용자에 대해 LocateUser를 실행하세요.

<FQDN or IP address of NS Server>curl http: //:80/서블릿/로케이트유저?<BW userID @domain >URL=&반품 호환 XSP = 참&통화 요청 = 참'

예: 컬 'http://1.1.1.1:80/servlet/LocateUser?url= 9721112222@gmail.com &반품 호환 XSP = 참&통화 요청 = 참'

해결 방법: LocateUser가 사용자의 보조 AS를 반환하면 주 NS 서버에서 MigrateUserToDefaultNode.pl 스크립트를 실행하여 사용자를 클러스터의 주 애플리케이션 서버로 다시 마이그레이션하세요.

SSH를 통해 NS 서버에 로그인하고 /usr/local/broadworks/bw_base/bin 디렉토리로 가서 다음을 실행하세요: MigrateUserToDefaultNode.pl <hostingNE>

예: 사용자를 디폴트 Node.pl bwas1로 마이그레이션하세요

HostingNE 값을 구하려면, NS_CLI/시스템/디바이스/호스팅네> get을 실행하세요.

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

가능하면 트래픽이 적은 기간에 스크립트를 실행하세요. 하지만 일반적으로 영향을 받은 사용자의 서비스를 복원하기 위해 필요한 경우 언제든지 스크립트를 실행할 수 있어요.

스크립트는 한 명의 사용자만 실행할 수 없어요. LocateUser 출력에 나열된 모든 사용자를 마이그레이션해요. 스크립트를 실행할 수 없으면 영향을 받은 사용자를 BroadWorks에서 삭제하고 다시 빌드해서 사용자가 올바른 AS로 재빌드되도록 하세요.

사용자 장치에서 보조 AS로 보내는 모든 SIP 메시지가 사용자를 마이그레이션하게 할 수 있어요. 들어오는 요청이 보조 AS에 계속 도달하지 않는 한 사용자는 보통 기본 15분 후에 기본 AS로 롤백해요. 예를 들어 SBC가 AS1에 연결하지 못하고 보조 AS로 재귀하면 해당 사용자는 보조 AS로 전환할 수 있어요. 배포에 따라 다르지만, SBC에서 기본 AS에 도달하는 데 계속 문제가 생기면 단일 트렁크 그룹이나 사용자가 보조 AS에 고정된 상태로 남을 수 있어요.

자세한 내용은 다음 문서를 참조하세요.

• 섹션 3.4.5 애플리케이션 서버 사용자 롤백 기능 그리고 5.4.5 시스코 브로드웍스 리던던시 가이드 자동 롤백

• 시스코 브로드웍스 ASR 개선 기능 설명

9.전화 서비스 연결 끊겼어요.

사용자가 Webex 앱에 로그인한 후 전화 서비스 연결이 끊긴 것으로 표시되거나 사용자가 클라이언트를 사용하는 동안 전화 서비스 연결이 끊어지는 경우, 클라이언트 유형과 등록 흐름을 확인하세요.

윈도우 및 맥 클라이언트의 경우, Webex 앱은 SIP에 등록하고 사용자가 로그인하는 동안 활성 SIP 등록을 유지해요.

다음 사항을 확인해 주세요.

1. config-wxt.xml 다운로드가 성공했는지 확인해 주세요.

클라이언트 로그에서 구성/다운로드를 검색하세요.

다운로드 성공 결과는:

컨피그 다운로드 - 성공적으로 완료됐어요

로그에 다음 오류가 표시되면 AuthService 로그에서 토큰 관련 오류를 확인해 보세요.

구성다운로드 - 오류 코드 때문에 실패했어요: 1511

2. Webex 장치 프로필을 찾았는지 확인하세요.

클라이언트 로그에서 액세스 장치가 검색되고 used_value가 1인지 확인하세요. used_value가 0이면, 프라이머리 라인이 활성화되었는지 비활성화되었는지 확인하고 태그 값을 확인하세요. 자세한 내용은 브로드웍스용 Webex 구성 가이드의 섹션 6.1.44 기본 프로필을 참조하십시오.

로그 항목 예시:

:BWC:SCF: 구성 다운로드 - 액세스 장치 발견

:BWC: SCF: 구성 다운로드 - 액세스 장치: 장치 유형 = 비즈니스 커뮤니케이터 - PC, 장치 수준 = 그룹, 종료 허용=1, isDeviceOwner [has_value: 0, used_value: 1], HAS소유자 장치: 1, 엔드포인트 유형: 공유 통화 표시

:BWC:SCF: 구성 다운로드 - 액세스 장치: 장치 유형=연결 - 모바일, 장치 수준=그룹, 종료 허용=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, 엔드포인트 유형: 공유 통화 표시

:BWC:SCF: 구성 다운로드 - 액세스 장치: 장치 유형=연결 - 태블릿, 장치 수준=그룹, 종료 허용=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, 엔드포인트 유형: 공유 통화 표시

3. SIP 프록시 주소 확인할 때 DNS 실패 있는지 확인해 보세요.

SIP 프록시 검색에 대한 자세한 내용은 브로드웍스용 Webex 구성 가이드의 섹션 6.1.6 동적 SIP 프록시 검색을 참조하십시오.

성공적인 프록시 검색은 다음을 보여줘요.

프록시 검색 완료했어요, <number>결과 나왔어요

4. SIP 등록이 실패했는지 확인해 보세요.

로그에 m등록: TCP타임아웃 또는 이유: SIP, 원인=200, 텍스트="마지막=TCP-타임아웃"이 표시되는 경우, Webex 클라이언트가 SBC에 로우 레벨 TCP 연결을 설정할 수 없어요. 이 오류가 발생하면 SIP 등록이 완료되지 않아요. 사용자 네트워크에서 TCP가 차단되었는지 아니면 SBC가 TCP 연결을 거부하는지 확인해 보세요.

SIP 등록 요청이 거부되거나 응답을 받지 못하면 로그에서 레지스터 sip를 검색하고 SIP/2.0 200 OK가 반환되었는지 확인하세요. 반환되지 않으면 사용자 네트워크가 SIP를 차단하고 있는지 아니면 SBC가 요청을 거부하는지 확인해 보세요.

브로드웍스 관리자에서 사용자 > 유틸리티 > 등록으로 이동하여 Webex 클라이언트에 유효한 SIP 등록이 있는지 확인하세요.

안드로이드 및 iOS 모바일 클라이언트의 경우, Webex 앱은 전화를 걸거나 받을 때까지 SIP에 등록되지 않아요. 통화가 완료되면 등록이 제거돼요. 모바일 클라이언트가 푸시 알림에 등록해요.

모바일 클라이언트의 경우 다음 사항을 확인해 주세요.

1. 윈도우 및 맥 클라이언트에 대해 설명한 대로 config-wxt.xml 다운로드가 성공했는지 그리고 장치 프로필을 찾았는지 확인하세요.

2. 푸시 등록이 성공하는지 확인해 주세요.

Webex 로그에서 푸시 등록 상태를 찾아보세요.

온푸시 등록 상태 변경됨: :푸시 등록 상태 변경됨, 상태=미등록

온푸시 등록 상태 변경됨: :푸시 등록 상태 변경됨, 상태=등록됨

BroadWorks 관리자에서 사용자 > 유틸리티 > 푸시 알림 등록으로 이동하여 Webex 클라이언트에 유효한 푸시 등록이 있는지 확인하세요.

통화 설정 웹뷰 문제예요

1.셀프 케어 버튼/링크가 Webex 앱에 표시되지 않아요

이 문제의 다른 증상은 버튼/링크가 표시되는데 클릭하면 외부 브라우저가 열리는 경우예요.

• 필요한 클라이언트 구성 템플릿이 배포되고 CSW 태그가 제대로 설정되었는지 확인하세요. (시스코 브로드웍스용 웹엑스 솔루션 가이드의 통화 설정 웹뷰 섹션 참조).
• Webex 앱이 브로드웍스에서 전화를 걸도록 등록되었는지 확인하세요.
• 웨벡스 앱이 CSWV를 지원하는 최신 버전인지 확인해 보세요.

2.셀프 케어 버튼/링크를 클릭한 후 페이지가 비어 있거나 오류가 발생했어요

일반적으로 웨벡스 앱에서 이러한 동작은 브로드웍스 XSP의 CSWV 애플리케이션에 구성 또는 배포 문제가 있음을 나타냅니다. CSWV 로그, 액세스 로그, config-wxt.xml 저장소, 템플릿 파일 등 추가 조사를 위한 세부 정보를 수집한 다음 사례를 제기하세요.

도메인 클레임 문제

도메인 클레임에서 발생한 오류로 인해 사용자 등록 오류가 발생할 수 있어요. 도메인을 신청하기 전에 다음 사항을 이해하세요.

• 서비스 제공업체는 자신이 관리하는 고객 조직의 도메인을 주장해서는 안 돼요. 서비스 제공자 내부 조직에 있는 사용자의 도메인만 소유권을 주장해야 해요. 별도의 조직 (서비스 제공자가 관리하는 조직 포함) 에서 사용자의 도메인을 요청하면 사용자 인증 요청이 고객 조직이 아닌 서비스 제공업체를 통해 라우팅되기 때문에 고객 조직 사용자의 등록 오류가 발생할 수 있어요.
• 두 고객 조직 (회사 A와 회사 B) 이 같은 도메인을 공유하고 회사 A가 도메인을 소유한 경우, 사용자 인증 요청이 해당 도메인을 소유한 조직 (회사 A) 을 통해 라우팅되기 때문에 회사 B 사용자 등록이 실패할 수 있어요.

  도메인에 대한 소유권 주장이 잘못되어 클레임을 제거해야 하는 경우, 도메인 관리 Webex 문서를 참조해 주세요.

최종 사용자 오류 코드

다음 표에는 클라이언트 사용자 활성화 포털에서 볼 수 있는 최종 사용자 오류 코드가 요약되어 있어요.

디렉토리 동기화 오류 코드예요.

다음 오류 코드가 디렉토리 동기화에 적용돼요.