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

파트너가 채택할 수 있는 다양한 배포 모델을 설명하기 위해 TelSP라는 가상 Webex 파트너를 생각해 봅시다.

TelsP의 상위 사양 및 요구 사항은 다음과 같습니다.

• 파트너는 sip.telsp.com을 관리하는 모든 고객이 공유하는 최상위 도메인으로 사용할 계획이에요.

• 파트너가 sip.telsp.com을 소유하고 있고 DNS 인프라 및 인증 기관을 관리하고, DNS 주소를 관리하고, 이 도메인과 하위 도메인의 인증서에 서명할 수 있어요.

• 파트너는 최종 고객 간의 PSTN 액세스 공유를 위한 로컬 게이트웨이로 두 개의 개별 세션 경계 컨트롤러 (물리적 또는 가상) 를 배포할 수 있어요.

• 파트너는 물리적 사이트가 두 개 있고 두 사이트 모두 PSTN 연결을 공유해요.

  • 마이애미

  • 시카고

• 텔스피는 여기서 언급한 대로 CuSTA, CustB 두 고객을 대신해 로컬 게이트웨이를 운영해요.

원하는 시나리오는 아래 그림과 같이 파트너가 제공한 마이애미 게이트웨이와 시카고 게이트웨이를 사용하는 고객 모두에 대해 PSTN 시작/해지를 하는 거예요.

단순화된 배포 예시

다음의 간단한 예는 피어 인증서 ID로 단일 인증서로 여러 고객 트렁크를 지원하는 방법을 보여줍니다.

• 인증서 —sip.telsp.com

• 트렁크스

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• 피어 인증서 아이덴티티 —sip.telsp.com

• 결과예요

  • 단일 인증서가 사용돼요

  • 여러 고객 트렁크가 지원돼요

고객 위치를 트렁크 및 게이트웨이에 연결하기

다음 섹션은 위에서 설명한 배포에 대한 자세한 구성 매핑을 제공해요.

Webex Calling트렁크를 생성하고 여러 위치에서 트렁크를 공유할 수 있어요. 트렁크를 만들 때 트렁크를 위치와 연결하세요.

CuSta의 경우, 트렁크 세부 사항은 다음과 같아요.

그림은 고객 위치와 CuSTA 게이트웨이 및 트렁크의 연관성을 보여줘요.

이번 배포에서는 위치와 연결된 트렁크가 해당 위치의 기본 PSTN 연결이에요. 다른 트렁크는 특정 다이얼 플랜 입력을 위한 보조 PSTN 연결 또는 경로로 사용돼요. 1차 및 2차 PSTN 연결 관계 구현은 루트 그룹 개념을 통해 이루어져요. 자세한 내용은 컨트롤 허브 섹션의 게이트웨이 트렁크 구성 참조.

CustB의 경우, 다음 트렁크가 있는 비슷한 설정이 생성돼요.

그림은 고객 위치와 CustB의 게이트웨이 및 트렁크 연결을 보여 줘요.

그림은 세 번째 위치, 즉 뉴욕을 보여줘요. 나중에 추가해서 트렁크_시카고 트렁크를 주 PSTN 연결로 가리키면 돼요.

여러 트렁크를 공유하는 로컬 게이트웨이를 배포할 때 Cisco는 트렁크당 고유한 FQDN을 사용하도록 의무화했어요. 자세한 내용은 Webex 통화를 위한 트렁크, -라우트 그룹, 및 다이얼 플랜 구성을 참조하세요.

IP 주소와 트렁크당 잘 알려진 포트를 사용하는 것이 이상적인 선택이에요. 하지만 사이트당 게이트웨이당 주소 하나를 사용하려는 일부 파트너에게는 퍼블릭 IPv4 주소 조달이 어려울 수 있어요.

따라서 다음 중요한 포인터를 읽어보세요.

• 시스코는 트렁크당 IP 주소를 요구하지 않아요.

• 트렁크 주소는 고유 IP 주소 또는 다른 트렁크 간에 공유되는 주소로 확인될 수 있어요.

• Cisco는 다음과 같은 이유로 로컬 게이트웨이에서 각 트렁크 연결을 고유한 IP 주소와 포트 조합으로 구성할 것을 권장해요.

  1. 트렁크당 별도의 TCP 연결 링크를 유지하면 트렁크당 최대 동시 통화 용량을 지원해요. 트렁크 간에 IP 주소와 포트 조합을 공유하면 통화 용량에 부정적인 영향을 미칠 수 있어요.

  2. 고객 간 네트워크 수준 격리 제공

  3. IP 주소로 분할된 고유 테넌트나 테넌트의 고유한 수신 포트로 격리가 제공되는 경우를 제외하고 세션 경계 컨트롤러는 일시적인 TCP 소켓 연결을 재사용하는 게 보통이에요.

  4. 테넌트 격리를 통한 트렁크당 연결 또는 연결은 특히 데이터 손실이 많은 네트워크 조건에서 더 나은 처리량을 제공해요. 따라서 한 고객의 트래픽은 다른 고객에게는 영향을 주지 않아요.

게이트웨이당 IP 주소: 트렁크 구성 및 권장 사항

계획을 위한 다양한 모델의 다음 예를 참조하세요.

모델 1: 트렁크당 고유 IP 주소

이 모델에서는 두 게이트웨이에서 호스팅되는 모든 트렁크가 고유한 IP 주소로 확인되고 각 트렁크는 같은 포트를 사용할 수도 있고 사용하지 않을 수도 있지만 이상적으로는 같은 포트를 사용해요.

정보를 표 형식으로 표현해요:

같은 모델에서는 파트너가 SRV 주소를 사용할 수 있어요. Webex Calling“_모금만 허용해요.피어 주소가 SRV 레코드인지 알아내는 서비스와 프로토콜 조합으로 _tcp”.

SRV 레코드가 어떻게 해결되는지 보여주는 예시예요

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

모델 2: 게이트웨이당 공유 IP, 고유 수신 포트

이 모델에서는 시카고 로컬 게이트웨이에 호스팅된 모든 트렁크는 같은 IP 주소로 확인되고 마이애미 로컬 게이트웨이에 호스팅되는 모든 트렁크는 다른 IP로 확인돼요. 하지만 같은 IP를 사용할 때 각 트렁크는 제어 허브의 FQDN을 사용하여 구성되고 고유한 포트로 구성돼요.

같은 모델에서 파트너는 SRV 주소를 사용해요. Webex Calling“_모금만 허용해요.피어 주소가 SRV 레코드인지 알아내는 서비스와 프로토콜 조합으로 _tcp”.

SRV 레코드가 어떻게 해결되는지 보여주는 또 다른 샘플은 다음과 같아요. 이 예에서는 IP 주소당 A 레코드가 1개예요. 하지만 포트는 주소마다 고유하며 SRV 주소를 오른쪽 포트에 연결하는 특정 DNS 구성을 통해 표현돼요.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.sip.telsp.com

nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com

SRV 기반 트렁크의 경우 피어 인증서 ID는 처음에 구성된 SRV 값으로 채워지며 동일한 검증 규칙에 따라 사용자 정의할 수 있어요.

파트너가 telsp.com하고 그 하위 도메인을 소유해요. 따라서 DNS 서버와 승인된 인증 기관이 서명한 인증서를 받는 기관은 파트너에 있어요.

• Cisco Webex파트너가 퍼블릭 도메인에 A 레코드를 포함하여 FQDN 또는 SRV 주소를 게시할 것으로 예상해요.

• Cisco Webex파트너가 이 문서에 나열된 인증 기관 중 하나를 사용할 것으로 예상해요.

FQDN이나 SRV를 사용하여 트렁크를 구성할 때:

• 각 트렁크에는 여전히 라우팅 및 식별을 위한 고유한 FQDN이 있어야 해요

• DNS 레코드 (A 레코드 또는 SRV) 는 올바르게 구성되고 확인 가능해야 해요

• 이 FQDN은 시그널링하고 라우팅에 사용돼요. 인증서 검증은 구성된 피어 인증서 ID에 대해 수행돼요. 기본값은 트렁크 FQDN 값이지만 파트너 소유의 공유 ID로 사용자 지정할 수 있어요.

  피어 인증서 ID 필드는 트렁크 FQDN에서 미리 채워지며 파트너 소유의 공유 도메인으로 재정의하여 여러 고객 트렁크에 단일 인증서를 사용할 수 있어요.

게이트웨이 설정해요

이 리소스를 사용하여 로컬 게이트웨이를 설정하세요.

Cisco CUBE를 설정하려면 다음 절차를 사용하세요. Cisco IOSXE에서 로컬 게이트웨이를 구성하세요 Webex Calling

승인된 타사 SBC를 설정할 수 있어요. 참조: 로컬 게이트웨이 시작하기

다음 지침에 따라 파트너 호스팅 게이트웨이를 설정하세요. 로컬 게이트웨이로 시작하세요

SBC 장치 관련 지침에 따라 각 트렁크를 설정하세요. Cisco CUBE 지침은 다음을 참조하세요. Cisco IOSXE에서 로컬 게이트웨이 구성 Webex Calling

이미지에 따라 트렁크에 들어오고 나가는 트래픽에 대해 음성 클래스, 다이얼 피어, 다이얼 피어 그룹을 설정하세요.

트렁크를 프로비전하는 동안 Control Hub는 트렁크 추가 페이지에서 피어 인증서 ID를 구성하는 옵션을 제공해요. 이 개선 사항은 파트너가 여러 고객 조직에서 단일 최상위 도메인을 구성하고 재사용할 수 있도록 하여 워크플로를 단순화해요. 이 접근 방식을 사용하면 고객 또는 트렁크별로 별도의 인증서가 필요하지 않아 운영 노력이 줄어들고 설정 프로세스가 단순해집니다.

Control Hub에서 트렁크를 구성할 때 모든 고객 조직에서 최상위 도메인에 단일 인증서를 사용할 수 있도록 피어 인증서 ID를 정의하세요. 인증서의 CN 또는 SAN에 이 최상위 도메인이 포함되어 있는지 확인하세요. 피어 인증서 ID의 경우 로컬 게이트웨이는 CN 또는 SAN에 파트너의 공유 도메인이 포함된 단일 인증서를 사용해요 (예: sip.telsp.com). 와일드카드 인증서 (예: *.sip.telsp.com) 는 지원되지 않아요. Webex Calling해당 값을 피어 인증서 ID로 명시적으로 구성된 모든 고객 트렁크에 대해 이 인증서를 수락해요. 인증서는 CN 또는 SAN에 정확히 구성된 피어 인증서 ID 값을 포함해야 해요. 이렇게 하면 개별 트렁크 FQDN에 대해 별도의 인증서나 CN/SAN 항목을 구성할 필요가 없어요.

도메인 확인 및 인증서 사용

도메인 인증이 인증서 사용과 어떻게 다른지 이해하는 게 중요해요.

• 도메인 확인 (고객당) —각 고객 조직은 DNS에 고유 TXT 레코드를 추가하여 도메인 (예: sip.telsp.com) 을 독립적으로 확인해야 해요. 이렇게 하면 파트너가 도메인을 소유하고 무단 사용을 방지할 수 있어요.

• 인증서 관리 (글로벌) —파트너의 최상위 도메인에 대해 발급한 단일 인증서를 피어 인증서 ID를 사용하여 모든 고객 트렁크에서 공유할 수 있어요. 고객당 또는 트렁크당 별도의 인증서를 유지할 필요가 없어요.

피어 인증서 아이덴티티 행동

피어 인증서 ID는 로컬 게이트웨이가 제시하는 Webex Calling 인증서에 필요한 ID를 정의해요.

구성 시:

• Webex Calling구성된 피어 인증서 ID를 인증서의 CN 또는 SAN과 일치시켜 인증서를 검증해요.

• 값이 일치하면 TLS 연결이 받아들여져요

• 값이 일치하지 않으면 연결이 거부돼요.

일치하는 피어 인증서 ID로 명시적으로 구성된 트렁크만 인증이 허용돼요.

인증서 검증만으로는 인증 중에 수행하는 유일한 검사가 아니에요. 구성된 피어 인증서 ID에 대해 인증서 CN 또는 SAN을 검증하는 것 외에도 트렁크 FQDN이 명시적으로 구성되고 컨트롤 허브의 일치하는 피어 인증서 ID와 연결되었는지 확인합니다. Webex Calling

피어 인증서 ID는 트렁크 FQDN/SRV 값으로 미리 채워져 있어요. 기본값을 유지하면 기존 트렁크별 인증서 동작은 변하지 않아요. 기존 인증서 기반 트렁크는 수정 없이 계속 작동해요. 원하는 속도로 새 트렁크나 기존 트렁크에 공유 피어 인증서 ID를 채택할 수 있고 두 모델 모두 공존할 수 있어요.

1. 유효한 구성 예시:

   • 인증서 CN —sip.telsp.com

   • 인증서 SAN —custa.sip.telsp.com

   • 피어 인증서 아이덴티티 —custa.sip.telsp.com

   • 트렁크 FQDN —trunk.miami.custa.sip.telsp.com

   결과 —피어 인증서 ID (custa.sip.telsp.com) 가 인증서의 SAN 값과 일치하고 트렁크 FQDN (트렁크.miami.custa.sip.telsp.com) 이 구성된 피어 인증서 ID의 하위 도메인이기 때문에 연결이 성공했어요.

2. 연결 실패 예시:

   • 인증서 CN —sip.telsp.com

   • 인증서 SAN —custa.sip.telsp.com

   • 피어 인증서 아이덴티티 —custb.sip.telsp.com

   • 트렁크 FQDN —trunk.miami.custb.sip.telsp.com

   결과 —피어 인증서 ID (custb.sip.telsp.com) 가 인증서의 CN 또는 SAN에 없어서 TLS 핸드셰이크에서 연결이 실패했어요. 트렁크 FQDN은 정확히 피어 인증서 ID의 하위 도메인인데 인증서에는 해당 ID가 없어요.

3. 잘못된 구성 예시:

   • 인증서 CN —sip.telsp.com

   • 인증서 SAN —custa.sip.telsp.com

   • 피어 인증서 아이덴티티 —custa.sip.telsp.com

   • 트렁크 FQDN —trunk.miami.custb.sip.telsp.com

   결과 —트렁크 FQDN (트렁크.miami.custb.sip.telsp.com) 이 구성된 피어 인증서 ID (custa.sip.telsp.com) 와 같지 않거나 하위 도메인이 아니기 때문에 컨트롤 허브가 저장 시 이 구성을 거부해요.

파트너 허브에서 CuSTA 또는 CustB용 컨트롤 허브를 시작하고 게이트웨이를 구성할 수 있어요. 각 고객에 맞게 구성하려면 이 절차를 사용하세요.

1. 트렁크 생성—각 파트너 공유 게이트웨이의 통화/통화 라우팅/트렁크 아래에 트렁크를 추가하세요. 트렁크를 설정하려면 트렁크, 경로 그룹, 다이얼 플랜 구성을 참조하세요. Webex Calling

2. 도메인 추가 및 확인 - 관리/조직 설정/도메인에서 트렁크를 만드는 데 사용되는 다음 도메인을 추가하고 확인하세요.

   CustomerB	CustomerC
   sip.telsp.com	sip.telsp.com

   도메인 추가 시 토큰이 생성되어 파트너 DNS 서버의 도메인 TXT 레코드에 저장돼요. 이 기록을 통해 Control Hub는 도메인 소유가 파트너인지 확인할 수 있어요. 자세한 내용은 도메인 관리를 참조하세요.

   공통 도메인은 각 고객의 검증에 사용돼요. 하지만 이 검증은 고객 조직 수준에서 이루어지므로 고객 조직마다 다른 토큰을 생성하여 검증에 사용하세요. 고객 조직 전체에서 단일 도메인이 사용되고 각 고객 조직은 동일한 도메인을 공유하는 경우에도 고유한 TXT 레코드를 사용하여 도메인을 독립적으로 확인해야 하기 때문이에요.

   피어 인증서 ID에는 도메인 인증만 필요해요. 고객 조직에 공유 도메인을 요구하지 마세요. 도메인은 한 조직에서만 소유권을 주장할 수 있고, 같은 도메인은 여러 조직에서 확인할 수 있어요.

3. FQDN으로 SBC 주소 설정하세요—

   마이애미 게이트웨이의 경우:

   파라미터	CustomerB	CustomerC
   위치	덴버	보스턴이에요
   트렁크 이름	트렁크_마이애미	트렁크_마이애미
   트렁크 타입	인증서 기반이에요	인증서 기반이에요
   장치 유형	예. Cisco Unified Border Element(또는 지원되는 다른 기기)	예. Cisco Unified Border Element(또는 지원되는 다른 기기)
   SBC 주소 유형이에요	FQDN	FQDN
   호스트 이름	LGW. 마이애미	LGW. 마이애미
   도메인	sip.telsp.com	sip.telsp.com
   포트	5061	5062
   FQDN	LGW.마이애미.CustomerB.sip.telsp.com:5061	LGW.마이애미.Customerc.sip.telsp.com:5062
   최대 동시 통화 수 (250-6500)	500	500

   시카고 게이트웨이의 경우:

   파라미터	CustomerB	CustomerC
   위치	디트로이트예요	댈러스
   트렁크 이름	트렁크_시카고	트렁크_시카고
   트렁크 타입	인증서 기반이에요	인증서 기반이에요
   장치 유형	예. Cisco Unified Border Element(또는 지원되는 다른 기기)	예. Cisco Unified Border Element(또는 지원되는 다른 기기)
   SBC 주소 유형이에요	FQDN	FQDN
   호스트 이름	LGW. 시카고	LGW. 시카고
   도메인	sip.telsp.com	sip.telsp.com
   포트	5061	5062
   FQDN	LGW.시카고.CustomerB.sip.telsp.com:5061	LGW.시카고.Customerc.sip.telsp.com:5062
   최대 동시 통화 수 (250-6500)	500	500

   • (선택 사항) 트렁크 이름은 고객 조직 간에 고유할 필요는 없어요. 같은 이름 (예: 트렁크_마이애미) 을 재사용하면 트렁크를 더 쉽게 추적할 수 있어요.

   • 특정 SBC에서는 동일한 포트 구성을 허용하는데 이 구성은 용량에 영향을 줄 수 있어요 . 따라서 다른 포트를 사용하세요.

4. 피어 인증서 아이덴티티—

   • 접두사 —접두사는 선택사항이에요. 도메인에만 피어 인증서 ID를 설정하려면 비워 두세요. 이것이 이 기사에서 사용된 공유 인증서 모델이에요 (피어 인증서 ID—sip.telsp.com, 모든 고객 트렁크 포함). 선택적으로 접두사를 입력하여 더 구체적인 인증서 ID를 정의하세요 (예: 접두사: CustomerB, 도메인: 고객별 인증서의 경우 CustomerB.sip.telsp.com). 트렁크 FQDN 자체는 SBC 주소 호스트 이름 및 도메인 필드로 정의된 상태로 유지되며 결과 피어 인증서 ID와 같거나 하위 도메인이어야 해요.

     예시:

     접두사—고객 B

     도메인—SIP.telsp.com

     결과—CustomerB.sip.telsp.com

   • 도메인: 고객 조직에서 확인된 도메인 목록에서 도메인을 선택해요. 결과로 나오는 피어 인증서 ID (접두사+도메인) 는 SBC가 제시하는 인증서의 CN 또는 SAN과 일치해야 해요. Webex Calling이 값을 사용하여 TLS 연결을 인증해요.

     

     트렁크 FQDN이 구성된 피어 인증서 ID 아래에 있지 않기 때문에 컨트롤 허브가 저장 시 이 구성을 거부해요.

     피어 인증서 ID가 SBC에서 제공한 인증서의 CN 또는 SAN과 일치하지 않으면 TLS 연결이 Webex Calling 거부되고 트렁크 설정에 실패해요.

5. 트렁크 사용—다음과 같은 이유로 트렁크 위치를 임의로 선택하세요.

   • PSTN 연결로 어느 위치에서나 트렁크를 사용할 수 있어요.

   • 루트 그룹을 통해 트렁크에 접근할 수 있어요.

   • 모든 다이얼 플랜에서 트렁크를 사용할 수 있어요.

6. 트렁크 정의와 관련 위치 보기:

   

   이 트렁크를 사용하여 경로 그룹을 만들 수 있어요. 이미지에는 rg_miami_chicago라는 라우트 그룹이 정의되어 있는데, 이 라우트는 트렁크_마이애미 트렁크로 통화를 기본 옵션으로, 트렁크_시카고 트렁크에 대한 통화를 보조 옵션으로 라우팅해요.

   

   트렁크_시카고 트렁크에 대한 통화를 기본 옵션으로, 트렁크_마이애미 트렁크에 대한 통화를 보조 옵션으로 라우팅하는 두 번째 경로 그룹 rg_chicago_miami를 정의할 수 있어요.

7. 정의된 트렁크와 라우트 그룹을 이제 각 위치의 통화 연결 PSTN 옵션에서 사용할 수 있어요. 이미지에서 덴버 위치를 보세요.

   

8. 다이얼 플랜 정의에서 트렁크와 라우트 그룹을 사용할 수 있어요. 예를 들어 시카고에 있는 고객의 사내 번호 범위는 이미지의 rg_chicago_ami 경로 그룹 (모든 지점) 으로 종료되도록 분할돼요.

   

   

API로 대규모 제공

다수의 고객 조직을 관리하는 파트너는 UI 대신 API를 사용하여 대규모로 도메인을 프로비전할 수 있어요.

• 도메인 확인

• 콜 라우팅