Webex Calling 플랫폼에는 프레미스 기반 로컬 게이트웨이가 연결하는 업그레이드된 클라우드 인프라가 포함됩니다. 이 업그레이드는 서비스를 향상하고 로컬 게이트웨이에 대해 다양한 새로운 기능을 사용할 수 있게 합니다.
이 새로운 인프라의 향상점에는 다음이 포함됩니다.
로컬 게이트웨이 등록당 최대 250개의 동시 세션을 허용하는 통화 처리 성능을 향상했습니다.
데스크 폰, Webex 앱 및 로컬 게이트웨이 간의 통화에 대해 Webex Calling 미디어 최적화의 사용을 지원합니다.
사양:
프록시 주소의 새로운 목록이 릴리즈되었습니다. 프록시 주소는 로컬 게이트웨이의 등록 과정 중에 Control Hub에서 가져온 후 게이트웨이를 등록하기 위해 로컬 게이트웨이의 테넌트 구성에 구성되는 고정 DNS 레코드입니다.
Webex Calling 클라우드 운영은 고객이 이전 프록시 주소를 사용하는 로컬 게이트웨이를 마이그레이션하도록 요청합니다. 세부 사항은 다음 섹션에 설명됩니다.
아래에 나열된 새로운 Webex Calling 프록시 주소 범위의 일부가 아닌 아웃바운드 프록시 주소가 로컬 게이트웨이에 있는 경우, 조직의 편의에 따라 수동으로 마이그레이션해야 합니다. Control Hub에 나열되는 주소는 아래 나타나는 새로운 주소 중의 하나입니다. 단, 현재 로컬 게이트웨이는 이전 주소로 구성되어 있으며, 마이그레이션을 요구할 수도 있습니다.
이 마이그레이션은 10~15분 이상 소요되지 않습니다. 단, 마이그레이션 중에 로컬 게이트웨이는 서비스에 영향을 미치는 클라우드에 등록됩니다. 따라서 유지관리 기간 동안 이 활동을 진행하는 것이 좋습니다.
US
캐나다
유럽
일본
호주
sy03.sipconnect-au.bcld.webex.com~sy14.sipconnect-au.bcld.webex.com
me03.sipconnect-au.bcld.webex.com~me14.sipconnect-au.bcld.webex.com
 |
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 | 아웃바운드 프록시 주소를 복사합니다.
 |
로컬 게이트웨이 구성을 업데이트하면 서비스에 영향을 미치고, 활동 중인 통화에 영향을 미칠 수도 있습니다.
아래 예제에서 테넌트 201은 Webex Calling으로 연결하는 테넌트입니다. 구성에 대해 올바른 테넌트를 입력합니다.
#show running-config | s voice class tenant 201
voice class tenant 201
registrar dns:lgw2.killarney.cisco.com scheme sips expires 240 refresh-ratio 50 tcp tls
credentials number TRUNK_GROUP_24740_LGU username TRUNK_GROUP_29959_LGU password 6 K]W]ZP`PSZRKWE^WXXIPG\^_adSTbLMHV realm BroadWorks
authentication username TRUNK_GROUP_29959_LGU password 7 xxxxxxxx realm BroadWorks
authentication username TRUNK_GROUP_29959_LGU password 6 xxxxxxxx realm 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
no pass-thru content custom-sdp
sip-profiles 201
outbound-proxy 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에 테스팅 통화를 실행하여 서비스를 테스트할 수 있습니다.
