피드백을 보내 주셔서 감사합니다.
로컬 게이트웨이 마이그레이션
피드백이 있습니까?이 새로운 인프라의 향상점에는 다음이 포함됩니다.
-
로컬 게이트웨이 등록당 최대 250개의 동시 세션을 허용하는 통화 처리 성능을 향상했습니다.
-
데스크 폰, Webex 앱 및 로컬 게이트웨이 간의 통화에 대해 Webex Calling 미디어 최적화 의 사용을 지원합니다.
사양:
-
프록시 주소의 새로운 목록이 릴리즈되었습니다. 프록시 주소는 로컬 게이트웨이의 등록 과정 중에 Control Hub에서 가져온 후 게이트웨이를 등록하기 위해 로컬 게이트웨이의 테넌트 구성에 구성되는 고정 DNS 레코드입니다.
-
Webex Calling 클라우드 운영은 고객이 이전 프록시 주소를 사용하는 로컬 게이트웨이를 마이그레이션하도록 요청합니다. 세부 사항은 다음 섹션에 설명됩니다.
아래 나열된 새로운 Webex Calling 프록시 주소 범위의 일부가 아닌 아웃바운드 프록시 주소가 로컬 게이트웨이에 있는 경우, 조직의 편의에 따라 수동으로 마이그레이션합니다. Control Hub에 나열된 주소는 아래의 새로운 주소 중 하나입니다. 단, 현재 로컬 게이트웨이는 이전 주소로 구성되고 마이그레이션을 요구할 수도 있습니다.
이 마이그레이션은 10-15분 이상 소요되지 않습니다. 그러나 마이그레이션 중에 로컬 게이트웨이는 서비스에 영향을 미치는 클라우드에 다시 등록됩니다. 따라서 유지관리 기간 동안 이 활동을 진행하는 것이 좋습니다.
US
캐나다
유럽
일본
호주
싱가포르
2020년 12월 이후에 등록된 새로운 로컬 게이트웨이 장치는 이 인프라를 사용하도록 자동으로 설정되므로, 아무 작업도 필요하지 않습니다. 로컬 게이트웨이에 마이그레이션이 필요한지 확인하도록 상단의 목록을 참조하고, 필요한 경우엔 아래 안내에 따라 마이그레이션을 실행할 것을 권장합니다.
로컬 게이트웨이에 마이그레이션이 필요한지 알아보려면 로컬 게이트웨이 마이그레이션 시작하기 섹션을 참조하십시오.
Control Hub의 구성 화면(CUBE 구성 단계) 및 아웃바운드 프록시 주소는 조직의 위치 및 로컬 게이트웨이에 따라 다를 수 있습니다. 아래 표시된 단계에 나열된 세부 사항은 예제 전용입니다.
시작하기 전에
-
CUBE에서 액세스 제어 목록 업데이트—Webex Calling에 세션 경계 컨트롤러(SBC) IP 주소의 범위가 업데이트되었으며, 이는 Webex Calling에 연결하는 조직에 있는 모든 CUBE에서 신뢰할 수 있는 목록으로 적용되어야 할 수도 있습니다. Webex Calling 포트 참조 안내서에 있는 최신 IP 범위를 확인하여 이미 적용되었는지 확인한 후, 아직 적용되지 않았으면 Webex Calling에 로컬 게이트웨이 등록에 있는 1단계 아래에서 구성 단계를 참조하여 이 업데이트를 실행합니다. CUBE에서 최신의 "신뢰할 수 있는 IP 주소"를 유지하는 것은 필수 요구 사항이며, 업데이트되지 않는 경우엔 통화에 실패하게 됩니다.
-
외부 방화벽이 CUBE에서 해당 IP 주소에 연결하도록 허용하는지 확인하십시오. 외부 방화벽에서 CUBE가 연결할 수 있는 IP 주소를 필터링하는 경우, 로컬 게이트웨이가 클라우드에 연결할 수 있도록 이 주소도 업데이트해야 합니다. 자세한 정보는 포트 참조 정보 안내서를 참조하십시오.
-
CUBE의 신뢰 앵커가 참조 플랫폼 구성 수행의 5단계에 따라 업데이트되었는지 확인합니다.
Control Hub에서 새로운 아웃바운드 프록시 주소를 가져올 수 있습니다.
| 1 |
의 고객 보기에서
https://admin.webex.com
서비스로 이동하고 을 선택합니다. |
| 2 |
PSTN 연결을 선택한 후 로컬 게이트웨이 아래에서 편집을 클릭합니다. |
| 3 |
관리를 클릭하여 로컬 게이트웨이 구성에 액세스합니다. |
| 4 |
아웃바운드 프록시 주소를 복사합니다. 조직에 다수의 로컬 게이트웨이가 있는 경우, 다른 로컬 게이트웨이에 대해 상단의 작업을 실행할 때마다 Control Hub에서 다른 아웃바운드 프록시 주소를 확보하게 됩니다. 귀하가 구성하는 각 로컬 게이트웨이에 대해 Control Hub에서 특정 아웃바운드 프록시 주소를 복사했는지 확인하십시오. 특정 주소를 선택하는 것은 트래픽의 중복 및 로드 밸런싱을 위해 매우 중요합니다.  |
로컬 게이트웨이 구성을 업데이트하면 서비스에 영향을 미치고, 활동 중인 통화에 영향을 미칠 수도 있습니다.
아래 예제에서 테넌트 201은 Webex Calling으로 연결하는 테넌트입니다. 구성에 대해 올바른 테넌트를 입력합니다.
#running-config 표시 | s 음성 클래스 테넌트 201 음성 클래스 테넌트 201 등록자 dns:lgw2.killarney.cisco.com 체계 sips 만료 240 새로 고침 비율 50 tcp tls 자격 증명 번호 트렁크_그룹_2467년_LGU 사용자 이름 트렁크_그룹_분류: 29세기_LGU 암호 6 K]W]ZP`PSZRKWE^WXXIPG\^_adSTbLMHV 영역 BroadWorks 인증 사용자 이름 트렁크_그룹_분류: 29세기_LGU 비밀번호 7 xxxxxxxx 영역 BroadWorks 인증 사용자 이름 트렁크_그룹_분류: 29세기_LGU 비밀번호 6 xxxxxxxx 영역 lgw2.killarney.cisco.com sip-server dns:lgw2.killarney.cisco.com connection-reuse session transport tcp tls url sips error-passthru bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 pass-thru content custom-sdp sip-profiles 201 아웃바운드-프록시 dns:lgwrestest.killarney.cisco.com | 1 |
이제 로컬 게이트웨이는 등록을 Webex Calling에 드롭합니다. |
| 2 |
다음 명령어를 입력하여 로컬 게이트웨이가 Webex Calling에 등록되지 않았는지 확인합니다. |
| 3 |
Control Hub에서 복사한 새 주소를 사용하고, 상단에서 등록자 라인을 다시 추가합니다. 아래 예제에서 OBP는 로컬 게이트웨이는 새로운 OBP로 등록됩니다. |
| 4 |
다음 명령어를 사용하여 등록에 성공했는지 검증합니다. 이는 아래와 유사한 결과물을 제공합니다. |
다음에 수행할 작업
위와 동일한 단계를 따라 다른 로컬 게이트웨이를 업데이트합니다.
실패한 마이그레이션의 경우, 간단히 이전의 아웃바운드 프록시 주소를 다시 등록하면 됩니다. 서비스 되돌리기 및 복원에 대해서는 아래의 안내를 따르십시오.
voice class tenant 201 no registrar outbound-proxy dns:lgwrestest.killarney.cisco.com registrar dns:lgw2.killarney.cisco.com scheme sips expires 240 refresh-ratio 50 tcp tls ! -
되돌리는 경우, Control Hub에 있는 구성은 여전히 새로운 아웃바운드 프록시 주소를 표시합니다. 이는 예상된 작동입니다. 서비스는 이전의 아웃바운드 프록시 주소로 계속 작동하게 됩니다.
-
Control Hub에서 로컬 게이트웨이 마이그레이션 섹션에 있는 2단계를 올바르게 따르고 있으며, 새로운 아웃바운드 프록시에 대한 액세스를 방화벽에서 차단하고 있지 않은지 확인하십시오.
-
이 문제를 해결할 수 없는 경우, Cisco Webex Calling 고객 지원으로 문의하십시오.
마이그레이션 후에 서비스가 정상적으로 작동하는지 확인하는 것은 중요합니다. 마이그레이션을 완료한 후에 서비스를 테스트하십시오. Webex Calling 장치에서 전화 번호로 전화를 걸거나 Webex Calling에서 함께 사용되는 SBC에 테스팅 통화를 실행하여 서비스를 테스트할 수 있습니다.
