Meeting Server의 통화 라우팅 로직 이해

소개

이 문서에서는 여러 통화 라우팅 테이블에 나뉘어 있는 Cisco Meeting Server(CMS)(이전의 Acano 제품)의 통화 라우팅 로직에 대해 설명합니다. 이 문서에서는 이러한 통화 라우팅 테이블을 통해 통화가 취할 수 있는 여러 단계와 시나리오를 다룹니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• Cisco Meeting Server Call Bridge 구성 요소

사용되는 구성 요소

이 문서의 정보는 버전 2.3.x의 Cisco Meeting Server를 기반으로 합니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

CMS(Cisco Meeting Server)의 통화 라우팅 로직이란 무엇입니까?

CMS의 통화 라우팅에는 서로 다른 몇 가지 통화 라우팅 테이블이 포함되어 있습니다. 다운로드할 수 있는 순서도를 사용하면 CMS에 수신되는 각 통화에 대한 통화 라우팅 로직을 따를 수 있습니다. 이는 Cisco Meeting App(CMA - thick client 또는 WebRTC), Standard Session Initiation Protocol(SIP) 통화 또는 Microsoft SIP 통화 등 모든 유형의 통화에 유효합니다(달리 지정되지 않은 경우).

참고: 유일한 예외는 CMS에서 시작한 통화(TMS(TelePresence Management Suite) 예약 아웃바운드 통화의 경우 CMS에서 직접 또는 CMA 클라이언트가 콜아웃한 통화)이며, 이 경우 통화 전달 테이블이 우회됩니다.

다음은 CMS 내의 통화 경로 프로세스 순서입니다. 

1. 수신 통화 일치 테이블
2. 수신 통화 착신 전환 테이블
3. 아웃바운드 통화 테이블

각 테이블에 대해서는 문서의 뒷부분에서 보다 자세히 설명하며, 여기에는 의 관련 부분만 보여 주는 이미지가 포함됩니다.

참고: CMS는 도메인 라우팅을 기반으로 하여 URI(Uniform Resource Identifier)의 RHS(Right-Hand Side)를 기반으로 통화 라우팅만 수행합니다. CUCM(Cisco Unified Communications Manager)에서 DirectoryNumber 라우팅(경로 패턴)을 사용하는 것과 같이 URI의 LHS(Left-Hand Side)를 기반으로 하는 통화 라우팅 기능은 없습니다.

참고: 각 테이블은 우선순위 특성에 의해 설정된 순서가 지정된 목록입니다. 우선순위가 높을수록 먼저 매칭하려고 합니다. 일치하지 않으면 목록의 다음 규칙으로 진행합니다. 일반적인 경험으로, 더 구체적인 규칙보다 더 낮은 우선 순위를 더 많은 일반 규칙(예: 모든 도메인과 일치하는 *)에 지정합니다. 이렇게 하면 특정 규칙이 먼저 처리되고 좀 더 일반적인 규칙에 대한 대안이 생길 수 있습니다.

1단계. 수신 통화 일치 테이블

이 단계는 CMS가 인바운드 통화가 Cisco Meeting Server를 목적지로 하고 더 자세히 처리해야 하는지 또는 CMS가 통화를 상호 작용하고 미디어와 신호 처리를 모두 처리하는 에이전트(예: Skype 게이트웨이에서 표준 SIP 엔드포인트로 또는 그 반대로)인 다른 시스템을 목적지로 하는 통화인지 여부를 확인하는 첫 번째 단계입니다.

수신 URI의 도메인 부분이 수신 일치 테이블과 일치하는지 여부를 확인합니다. 일치하는 경우 이 전화 걸기 규칙 구성에 따라 통화를 공간, 사용자, IVR로 라우팅하거나 Lync 전화회의 조회(온-프레미스 또는 오프-프레미스)를 수행할 수 있습니다. 이 테이블에서는 와일드카드 도메인을 허용하지 않으므로 전체 일치가 필요합니다.

참고: 구성된 수신 통화 일치 도메인이 없는 경우 CMS는 callbridge에 연결된 SIP 또는 Lync 통화에서 모든 수신 URI를 수락합니다. CMA 클라이언트(WebRTC 또는 Thick Client)의 경우 통화를 수락하지만 올바른 스페이스 또는 사용자에게 자동으로 라우팅되지 않습니다. 따라서 CMA 클라이언트를 사용하여 이 경우 스페이스 또는 사용자에게 전화를 걸 때 올바른 도메인에 입력해야 합니다.

예를 들어, 이미지에 통화 일치 테이블이 표시됩니다(간결성을 위해 대상 공간 및 대상 사용자 옵션만 표시됨).

여기서 도메인은 클라이언트가 일반적으로 다이얼하는 acano.steven.lab으로 설정됩니다. 그러나 callbridge의 IP 주소(이 경우 10.48.54.160) 또는 callbridge의 FQDN(정규화된 도메인 이름)과 일치하는 테이블의 첫 번째 및 두 번째 대체 규칙(이 경우 acano1.acano.steven.lab)에 의해서만 특정 callbridge(클러스터의 경우)를 대상으로 하는 CUCM(또는 Expressway 검색 규칙)의 임시 통화 또는 특정 SIP 경로 패턴도 허용합니다.

2단계. 수신 통화 착신 전환 테이블

통화가 수신 통화 일치 테이블에 있는 규칙에 도달하지 않았거나 통화를 진행하기 위한 일치가 없는 경우(예: 사용자가 전화를 걸었거나 잘못된 공간 URI로 전화를 걸었음) 통화 착신 전환 테이블이라는 두 번째 테이블을 거칩니다. 또한 도메인 기반이며 특정 도메인에 대한 통화를 특별히 차단하거나 특정 도메인에 대한 통화만 특별히 허용할 수 있습니다. 이렇게 하려면 우선 순위가 더 높은 좀 더 구체적인 규칙을 두는 것이 중요하기 때문에 먼저 확인하게 된다.

다음 예에서는 dummy.com에 대한 호출은 거부되지만 tplab.local에 대한 호출은 전달됨을 보여 줍니다.

통화 착신 전환 테이블을 비워두면 CMS가 Skype와 SIP 참가자 간의 게이트웨이 역할을 하지 않는 상태가 됩니다. 예를 들어, 통화 착신 전환 규칙이 없기 때문입니다. 수신 통화의 도메인이 수신 통화 일치 테이블에 일치하지 않거나 도메인이 일치하지만 스페이스, 사용자 또는 IVR(또는 Skype 모임)에 일치하지 않는다고 가정할 경우 아웃바운드 통화 테이블과 관련하여 통화가 전달되지 않습니다.

참고: 이는 CMA 클라이언트(씩 클라이언트 및 WebRTC)가 아웃바운드 통화를 할 수 있는 경우에도 마찬가지입니다(*3.0의 Web App은 아웃바운드 통화를 할 수 없고 CMS에서 발신한 통화는 Callbridge에서 발신 가능). 마찬가지로, CMS의 아웃바운드 호출도 API를 통해 수행되는 경우(예: TMS 예약 컨퍼런스의 경우) 정상 작동합니다. 일반적으로 CMS 자체(CMS 직접 또는 CMA를 통해)에서 시작된 통화는 통화 착신 전환 로직을 따르지 않아야 합니다.

이벤트 로그에서 CMS가 SIP 및 Skype 통화의 게이트웨이 역할을 하는 경우를 예로 들어 강조 표시된 전달 메시지를 볼 수 있습니다. 그 직전에는 수신 통화와 그 이후의 발신 통화를 볼 수 있습니다.

2018-10-04  06:36:24.612  Info     call 788: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:36:24.624  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@any.com'
2018-10-04  06:36:24.625  Info     call 789: outgoing SIP call to "stejanss@any.com"

전달 테이블에 규칙 또는 거부 규칙이 없는 경우 이벤트 로그에 이 규칙이 명시적으로 표시되지 않습니다. SIP 통화가 일치하지 않았으며(모든 스페이스, 사용자, IVR 또는 Lync 모임) 아웃바운드 규칙 섹션으로 이동할 전달 규칙을 놓쳤다는(또는 거부하도록 설정되었다는) 알림만 제공합니다.

2018-10-04  06:47:12.482  Info     call 790: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:47:12.495  Info     call 790: ending; local teardown, destination URI not matched - not connected after 0:00

TMS 예약 회의를 통해 시작된 CMA 클라이언트 통화 또는 CMS의 아웃바운드 통화의 경우 이벤트 로그에 수신 통화가 표시되지 않습니다. 이 통화는 즉시 아웃바운드 다이얼 플랜 테이블로 이동하며 통화 착신 전환 테이블에서 처리되지 않습니다.

통화 착신 전환 테이블에는 다른 두 가지 컨피그레이션 옵션인 도메인 재작성과 발신자 ID 재작성이 있습니다.

도메인 재작성

이 옵션을 사용하면 인바운드 통화의 도메인을 다른 도메인으로 재작성하고 SIP Request-URI의 도메인 부분과 SIP 메시지의 To 헤더를 변경할 수 있습니다.

예를 들어, 이 이미지의 컨피그레이션에서는 도메인 any.com과의 인바운드 통화에 대한 이벤트 로그(SIP 추적이 활성화된 상태)가 여기에 표시되지만 수신 통화 일치 테이블(스페이스, 사용자, IVR 또는 Skype 전화회의)에는 일치되지 않습니다.

2018-10-04  07:02:24.818  Info     SIP trace: connection 0: incoming SIP TCP data from 10.48.36.215:56457 to 10.48.80.71:5060, size 1000:
2018-10-04  07:02:24.818  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-04  07:02:24.818  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bK53e4c4ce29394
2018-10-04  07:02:24.818  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=742103~ee545a46-516a-4de6-87d7-7b1f5a5b848a-26001856
2018-10-04  07:02:24.818  Info     SIP trace: To: <sip:stejanss@any.com>
..
2018-10-04  07:02:24.822  Info     call 797: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  07:02:24.834  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-04  07:02:24.835  Info     call 798: outgoing SIP call to "stejanss@newany.com"
..
2018-10-04  07:02:24.838  Info     SIP trace: connection 19: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:57854, size 3286:
2018-10-04  07:02:24.838  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-04  07:02:24.838  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bKefc98b81a2961b37aee24f03c2142d8e
2018-10-04  07:02:24.839  Info     SIP trace: Call-ID: 18644f28-e998-4032-a7df-75325e9d11b0
2018-10-04  07:02:24.839  Info     SIP trace: CSeq: 659590315 INVITE
2018-10-04  07:02:24.839  Info     SIP trace: Max-Forwards: 70
2018-10-04  07:02:24.839  Info     SIP trace: Contact: <sip:1060@10.48.80.71;transport=tcp>
2018-10-04  07:02:24.839  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-04  07:02:24.839  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=2aa2a49bba231a1b

이 착신 전환 통화 라인에는 수정된 내용이 표시됩니다. SIP 추적이 활성화되지 않은 경우에도 any.com이 newany.com으로 수정된 것으로 표시됩니다.

이 도메인 재작성의 가장 일반적인 용도는 CMS 클러스터와의 온프레미스 Lync 통합과 함께 제공됩니다. 여기서 아웃바운드 규칙의 연락처 헤더 및 보낸 사람 헤더를 Lync/Skype에서 callbridge 특정 FQDN(정규화된 도메인 이름)으로 설정하는 것이 좋습니다. 이는 다음과 같은 라우팅 규칙 때문입니다.

• Skype는 대화 상자(예: INVITE - 200 OK 후 ACK)의 새 거래를 CMS로부터 받은 200 OK에 지정된 연락처 헤더로 보냅니다. Skype에서 CMS로 인바운드 연결을 하는 경우, 먼저 To 헤더에 ms-fe 헤더가 포함된 협상 SIP 메시지를 보냅니다. 이 메시지는 연락처 헤더가 INVITE에 대한 200 OK 회신에 채워져야 하는 방법을 지정합니다(동일한 TCP 채널을 사용함)
• Skype는 원래 초대장의 발신 헤더로 새 대화 상자(예: 콘텐츠 공유, 별도의 통화인 경우 또는 부재 중 통화인 경우 콜백)를 보냅니다

도메인을 재작성할 때 Lync 통화의 콜백과 관련이 있습니다. 누락된 INVITE의 From 헤더는 통화가 발신되는 특정 callbridge를 가리킵니다. 그런 다음 Lync에서 callbridge FQDN과 일치하는 SIP 요청 URI가 있는 새 요청(INVITE)을 보냅니다. 그런 다음 이러한 재작성 규칙을 통해 SIP 도메인으로 변환됩니다. 통화가 전달되면 SIP 엔드포인트가 등록된 CUCM 또는 Expressway-C에 대한 아웃바운드 규칙을 사용합니다.

발신자 ID

여기에는 전달 규칙에 설정할 수 있는 두 가지 옵션이 있습니다. 이를 통과하도록 설정한 다음 아웃바운드 INVITE의 From 헤더에서 수정하지 않거나 시스템이 아웃바운드 규칙에 따라 From 헤더를 수정할 수 있도록 하는 다이얼 플랜을 사용하도록 설정합니다. 이 설정은 SIP 요청 URI 및 아웃바운드 INVITE의 To 헤더와 관련된 도메인 재작성 여부에 관계없이 적용됩니다.

예를 들어, 이전과 동일한 통화가 수행되었지만 이제 newany.com에 대한 아웃바운드 다이얼 플랜 규칙이 있습니다(수신 통화 착신 전환 테이블에서 다시 쓴 후). Lync 유형 통화(예: 추가 SIP 헤더로서 Ms-Conversation-ID)로 설정됩니다. Lync 통화에 대해 앞에서 설명한 것처럼 Local From 도메인(및 Local Contact Domain)이 callbridge FQDN을 가리키도록 채워집니다. 그러면 아웃바운드 SIP INVITE의 From 및 Contact 헤더의 변경 사항이 반영됩니다. 이미지에 표시된 대로 동일한 값으로 채워지며 요구 사항에 따라 개별적으로 선택할 수 있습니다.

2018-10-12  09:09:24.488  Info     SIP trace: connection 28: incoming SIP TCP data from 10.48.36.215:44460 to 10.48.80.71:5060, size 1000:
2018-10-12  09:09:24.489  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-12  09:09:24.489  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bKf4a230ec178e
2018-10-12  09:09:24.489  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=118288~ee545a46-516a-4de6-87d7-7b1f5a5b848a-32900729
2018-10-12  09:09:24.489  Info     SIP trace: To: <sip:stejanss@any.com>
2018-10-12  09:09:24.489  Info     SIP trace: Call-ID: 81e67f80-bc0164c4-f2c6-d724300a@10.48.36.215

2018-10-12  09:09:24.494  Info     call 803: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-12  09:09:24.506  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-12  09:09:24.507  Info     call 804: outgoing SIP call to "stejanss@newany.com" (Lync)

2018-10-12  09:09:24.507  Info     SIP trace: connection 33: allocated for outgoing connection to 10.48.36.46:5060
2018-10-12  09:09:24.508  Info     SIP trace: connection 33: outgoing connection successful, 10.48.80.71:39782 to 10.48.36.46:5060
2018-10-12  09:09:24.510  Info     SIP trace: connection 33: outgoing SIP TCP data to 10.48.36.46:5060 from 10.48.80.71:39782, size 2971:
2018-10-12  09:09:24.510  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-12  09:09:24.510  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bK15bdde97ab641b586f162187cfdd98b5
2018-10-12  09:09:24.510  Info     SIP trace: Call-ID: c366ddaf-e602-4fa5-b1d6-2e16ec08534a
2018-10-12  09:09:24.510  Info     SIP trace: CSeq: 1498747095 INVITE
2018-10-12  09:09:24.510  Info     SIP trace: Max-Forwards: 70
2018-10-12  09:09:24.510  Info     SIP trace: Contact: <sip:1060@callbridgefqdn.any.com;transport=tcp>
2018-10-12  09:09:24.510  Info     SIP trace: Ms-Conversation-ID: 3P5Hu8grR1GGDF1BSMZAmw==
2018-10-12  09:09:24.510  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-12  09:09:24.510  Info     SIP trace: From: "EX60 Steven" <sip:1060@callbridgefqdn.any.com>;tag=fb4ae780677e9d9b

전달 규칙이 통과(pass through)로 설정된 경우, 이전 예제와 마찬가지로 시작(From) 헤더에는 수정이 없습니다(이 경우 통과(pass through)는 전달 규칙에 설정됨). CMS가 새 callLeg를 시작할 때 Contact 헤더는 항상 조정되므로 Contact 헤더를 자신에 추가해야 합니다.

발신자 ID와 로컬 연락처 도메인과 로컬 발신 도메인의 다른 조합을 사용할 수 있습니다. 아웃바운드 SIP INVITE의 From 헤더는 인바운드 통화가 usera@from.com의 From 헤더로 CMS에 입력되는 테이블에 표시된 대로 구성됩니다.

3단계. 아웃바운드 통화 테이블

이 표는 통화를 다른 서버로 내보내는 통화 라우팅 논리의 마지막 테이블입니다.

• 수신 통화는 (수신 통화 일치 도메인에서) 로컬로 처리되지 않습니다.
• CMS 공간(예: TMS 예약 미팅 또는 CMM(Cisco Meeting Manager) 명령 아웃바운드 통화의 경우 CMA 또는 API를 통해) 또는 CMA 클라이언트에서 아웃바운드 통화를 수행합니다.

그림에서 논리는 비교적 쉽다는 것을 알 수 있다. 테이블에 항목이 전혀 없는 경우, 여전히 아웃바운드 통화를 허용하지만 CMS 서버가 SIP 요청 URI에 설명된 대로 특정 도메인에 대한 SIP SRV 레코드(_sip._tcp / _sip._tcp / _sip._udp)를 확인할 수 있다고 가정합니다. 테이블이 비어 있지 않지만 전화를 건 도메인에 대한 일치 항목이 없는 경우 동일한 DNS 조회 논리가 수행됩니다. 도메인에 일치하는 항목이 있으면 해당 특정 규칙의 논리를 따릅니다. 이와 관련하여 CMA에서 발신 전화를 차단하거나 TMS 또는 CMM을 통해 발신 전화를 차단하려면 두 가지 방법을 사용할 수 있습니다. DNS SRV 레코드가 없거나(또는 CMS에서 확인할 수 없음) 해당 통화를 통화 제어(예: CUCM 또는 Expressway)로 라우팅하고 통화를 차단합니다.

이 그림에서는 아웃바운드 통화 테이블의 예를 보여 줍니다.

끝에 일반 <match all domains> 규칙이 있고 SIP Proxy가 없는 steven.lab의 도메인에 대한 첫 번째 규칙이 채워진 상태로 사용됩니다(따라서 DNS SRV 레코드가 사용됨).

이 목록은 우선 순위가 더 높은 목록으로 가장 먼저 다루어집니다. Behavior(동작)가 Stop(중지)으로 설정된 규칙을 일치시키는 경우, 해당 일치 이후의 나머지 테이블을 통해 통화가 진행되지 않으며, 예를 들어 SIP Proxy가 통화를 라우팅하지 못한 경우 통화가 실패합니다. 이 설정을 Continue(계속)로 설정하면 클러스터의 다른 경로 또는 다른 노드로의 대체를 허용할 수 있습니다. 예를 들어, 동일한 도메인에 대한 각 규칙에 대해 다른 SIP 프록시를 지정할 수 있습니다. 

로컬 연락처 도메인 및 로컬 발신 도메인의 설정은 수신 통화 착신 전환 테이블의 이전 섹션에서 다룹니다. 트렁크 유형을 사용하면 수신 시스템에 따라 표준 SIP, Lync 또는 Avaya의 통화 유형을 지정할 수 있습니다.

Encryption 필드는 통화의 신호 처리가 암호화되지 않아야 하는지 여부를 결정합니다. 그러나 이는 Configuration(컨피그레이션) > Call Settings(통화 설정) 메뉴에 있는 SIP 미디어 암호화 컨피그레이션에 설정된 것과 같은 미디어 암호화를 의미하지는 않습니다. 이 컨피그레이션에서는 Auto(자동)를 선택하여 암호화되지 않은 신호로의 폴백이 가능한 암호화된 신호로 먼저 통화를 시도하는 옵션도 있습니다. 다른 쪽이 암호화되었거나 암호화되지 않은 것을 미리 알고 있는 경우, 폴백 프로세스로 인해 통화 설정이 지연되지 않도록 적절하게 정의하는 것이 좋습니다.

DNS 추적 및 SIP 추적이 detailed로 설정된 steven.lab으로의 통화에 대한 로그 파일의 출력 예는 쿼리된 SRV 레코드 및 암호화가 Auto로 설정된 경우의 폴백 메커니즘을 보여줍니다.

2018-10-12  11:25:16.168  Info     call 821: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss@any.com"
2018-10-12  11:25:16.179  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@steven.lab'
2018-10-12  11:25:16.180  Info     call 822: outgoing SIP call to "stejanss@steven.lab"

2018-10-12  11:25:16.180  Info     DNS trace: resolving "steven.lab" (SRV "_sips._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 using 10.48.36.215:5061
2018-10-12  11:25:16.181  Info     SIP trace: connection 45: allocated for outgoing encrypted connection to 10.48.36.215:5061
2018-10-12  11:25:16.201  Info     handshake error 336151576 on outgoing connection 45 to 10.48.36.215:5061 from 10.48.80.71:54864
2018-10-12  11:25:16.201  Info     SIP trace: connection 45: shutting down...

2018-10-12  11:25:16.201  Info     call 822: falling back to unencrypted control connection...

2018-10-12  11:25:16.201  Info     DNS trace: resolving "steven.lab" (SRV "_sip._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 using 10.48.36.215:5060
2018-10-12  11:25:16.202  Info     SIP trace: connection 46: allocated for outgoing connection to 10.48.36.215:5060
2018-10-12  11:25:16.203  Info     SIP trace: connection 46: outgoing connection successful, 10.48.80.71:59776 to 10.48.36.215:5060
2018-10-12  11:25:16.205  Info     SIP trace: connection 46: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:59776, size 3290:
2018-10-12  11:25:16.205  Info     SIP trace: INVITE sip:stejanss@steven.lab SIP/2.0

참고: 여러 callbridge가 있는 클러스터링된 환경의 경우 API를 통해 구성하고 API 객체에서 callbridge ID(또는 callbridgeGroup ID)를 지정할 때 callbridge당 아웃바운드 dialplan 규칙을 설정할 수 있습니다. 예를 들어 모든 통화가 특정 도메인에 대한 특정 callbridge에서 외부로 나가도록 한다고 가정합니다(예: us.example.com으로 전화를 걸 때 미국 기반 서버에서 외부로 나가도록 설정됨). 그런 다음 아웃바운드DialPlanRules에 대한 API 컨피그레이션이 있어야 합니다. 그러면 US 기반 콜브리지가 아닌 다른 콜브리지에서도 US 콜브리지로 통화를 라우팅할 수 있습니다(이 예제의 경우).

OutboundDialPlanRule(US callbridge용)

• 도메인 = us.example.com
• sipProxy = <DNS SRV/IP를 사용하는 경우 비어 있음, 수동으로 설정하는 경우 FQDN>
• 범위 = callbridge
• callbridge = <UScallbridge-ID>

OutboundDialPlanRules(해당 통화를 허용해야 하는 모든 비US callbridge의 경우)(callbridge당 하나씩 필요)

• 도메인 = us.example.com
• sipProxy = <IP-or-FQDN-of-US-Callbridge>
• 범위 = callbridge
• callbridge = <non-US-callbridge-ID>

다음을 확인합니다. 

현재 이 설정에 사용 가능한 확인 절차는 없습니다.

문제 해결 

현재 이 구성에 사용할 수 있는 특정 문제 해결 정보가 없습니다.

관련 정보

• 기술 지원 및 문서 − Cisco Systems
• 협업 솔루션 분석기 툴 
• CMS 문서

---

참고: 컨피그레이션 예는 다음 가이드를 참조하십시오.

• CMS 구성 및 통합 단일 통합 가이드
• Cisco Meeting Server 및 CUCM 구성 설명서