회의 서버에서 통화 라우팅 논리 이해

다운로드 옵션

PDF (353.4 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (230.9 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (268.5 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2021년 9월 30일

문서 ID:214744

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

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

사전 요구 사항

요구 사항

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

Cisco Meeting Server Call Bridge 구성 요소입니다.

사용되는 구성 요소

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

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

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

CMS의 통화 라우팅에는 여러 통화 라우팅 테이블이 포함됩니다. 다운로드할 수 있는 순서도를 사용하여 CMS에 도착하는 각 통화에 대한 통화 라우팅 논리를 따를 수 있습니다. 이는 모든 통화 유형에 유효합니다. Cisco Meeting App(CMA - Thick Client 또는 WebRTC), SIP(Standard Session Initiation Protocol) 통화 또는 Microsoft SIP 통화는 별도로 지정되지 않습니다.

참고: 단, 통화 착신 전환 테이블이 우회되는 CMS에서 시작한 통화(TMS(TelePresence Management Suite)에 직접 CMS 또는 CMA 클라이언트 통화 발신)에 대해서는 예외입니다.

이는 CMS 내에서 통화 경로 프로세스의 순서입니다.

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

각 테이블은 문서의 뒷부분에서 더 자세히 설명되며, 여기에는 의 관련 부분만 표시하는 이미지가 포함됩니다.

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

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

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

CallMatchingTable

이는 CMS가 인바운드 통화가 Cisco Meeting Server를 위한 목적인지, 추가 처리를 필요로 하는지 또는 CMS가 통화를 상호 작용하고 미디어 및 신호 처리를 모두 처리하는 에이전트인 다른 시스템을 위한 통화인지 여부를 결정하는 프로세스의 첫 단계입니다(예: Skype 게이트웨이가 표준 SIP 엔드포인트에 전화를 걸거나 그 반대로 통화를 합니다.

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

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

예를 들어, 호출 일치 테이블은 이미지에 표시됩니다. 이 테이블에는 Targets spaces 및 Targets users 옵션만 표시됩니다.

IncomingCallMatchingExample-cut

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

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

CallForwardingTable

통화가 수신 통화 일치 테이블의 규칙에 맞지 않거나 통화 진행(예: 사용자가 기존 공간 URI가 아니거나 잘못된 공간 URI로 전화를 건 경우)에 일치하는 항목이 없으면 통화 착신 전환 테이블이라는 두 번째 테이블을 통과합니다. 또한 도메인 기반이며 특정 도메인에 대한 통화를 구체적으로 차단하거나 특정 도메인에 대한 통화만 특별히 허용할 수 있습니다. 이 작업을 수행하려면 우선 순위가 높은 더 구체적인 규칙을 먼저 확인해야 합니다.

다음 예에서는 dummy.com에 대한 호출이 거부되고 tplab.local에 대한 호출이 전달되었음을 보여줍니다.

forward

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

참고: 이는 아웃바운드 통화를 할 수 있는 CMA 클라이언트(일반 클라이언트 및 WebRTC)에서 발생합니다(*Web App in 3.0은 아웃바운드 통화를 할 수 없고, Callbridge에서 CMS가 공간 소모). 마찬가지로, 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 예약 회의를 통해 시작된 CMS의 CMA 클라이언트 통화 또는 아웃바운드 통화의 경우 이벤트 로그에 수신 통화가 표시되지 않습니다. 통화는 즉시 아웃바운드 다이얼 플랜 테이블로 이동하며 통화 착신 전환 테이블에서 처리되지 않습니다.

통화 착신 전환 테이블에는 두 가지 다른 구성 옵션이 있습니다. 도메인 및 발신자 ID를 다시 작성합니다.

도메인 재작성

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

forward newany

예를 들어, 이 이미지의 컨피그레이션을 사용하면 도메인 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로 설정하여 통화 브리지의 특정 FQDN(정규화된 도메인 이름)으로 설정하는 것이 좋습니다. 이는 다음 라우팅 규칙 때문입니다.

Skype는 대화 상자 내의 새 트랜잭션(예: INVITE - 200 OK 후 ACK)을 CMS에서 수신한 200 OK에 지정된 연락처 헤더로 보냅니다. Skype에서 CMS로 인바운드 연결을 위해 Skype는 먼저 To 헤더에 ms-fe 헤더가 포함된 NEGOTIATE SIP 메시지를 보냅니다. 이 메시지는 INVITE의 200 OK 회신(동일한 TCP 채널을 사용함)에 연락처 헤더를 채우는 방법을 지정합니다.
Skype는 원래 INVITE의 보낸 사람 헤더에 새 대화 상자(콘텐츠 공유, 별도의 통화인 경우 또는 부재 중 통화의 경우 콜백)를 보냅니다.

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

발신자 ID

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

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

LocalContactandLocalFromDomain-cut

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

전달 규칙이 통과 시에 설정되었을 경우 이전 예와 마찬가지로 From 헤더에도 아무런 수정 사항이 없습니다(이 경우 전달 규칙에 통과 기능이 설정됨). CMS가 새 callLeg를 시작할 때 항상 연락처 헤더가 조정되므로 연락처 헤더가 자체에 추가되어야 합니다.

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

CallerID-table-cut

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

CallOutboundTable

다른 서버에 대한 통화를 다음과 같이 하는 통화 라우팅 로직의 마지막 테이블입니다.

수신 통화는 (수신 통화 일치 도메인에서) 로컬로 처리되지 않습니다.
CMS 공간(예: TMS 예약 회의(예: 또는 CMM(Cisco Meeting Manager)에서 발신 통화를 지시하는 경우 CMA 또는 API를 통해) 또는 CMA 클라이언트에서 발신 통화입니다.

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

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

Example-Outbound-Calls-cut

일반<match all domains> 규칙이 끝에 있고 SIP 프록시 없이 steven.lab의 도메인에 첫 번째 규칙이 입력되어 DNS SRV 레코드를 사용합니다.

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

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

Encryption 필드는 통화의 신호 처리가 암호화되어야 하는지 암호화되어야 하는지를 결정합니다. 그러나 Configuration(컨피그레이션) > Call Settings(통화 설정) 메뉴에 있는 대로 SIP 미디어 암호화 컨피그레이션에 설정된 미디어 암호화를 의미하지는 않습니다. 이 컨피그레이션에서는 암호화되지 않은 신호로의 대체 가능한 암호화 신호 처리를 사용하여 통화를 먼저 시도하려는 Auto를 선택할 수도 있습니다. 상대방이 암호화되거나 암호화되지 않은 경우, 폴백 프로세스로 인해 통화 설정이 지연되는 것을 방지하려면 이에 따라 정의하는 것이 좋습니다.

DNS 추적 및 SIP 추적이 세부 정보로 설정된 DNS 추적 및 SIP 추적을 사용하여 steven.lab에 대한 통화에 대한 로그 파일의 출력 예에는 Encryption이 Auto로 설정된 경우 쿼리되는 SRV 레코드 및 대체 메커니즘이 표시됩니다.

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당 아웃바운드 다이얼계획 규칙을 설정할 수 있습니다. 예를 들어, 특정 도메인에 대한 특정 통화 브리지에서 모든 통화를 내보내도록 하는 경우를 가정해보겠습니다(예: us.example.com으로 전화를 걸 때 미국 기반 서버에서 나가려는 경우). 그런 다음 미국 기반 통화 브리지 이외의 다른 통화 브리지가 미국 통화 브리지로 통화를 라우팅할 수 있도록 outboundDialPlanRules에 대한 API 컨피그레이션이 있는지 확인합니다(이 예의 경우).

OutboundDialPlanRule(US Callbridge용)

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

OutboundDialPlanRules(해당 통화를 허용해야 하는 미국 이외의 모든 통화 브리지의 경우)(callbridge당 1개 필요)

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

다음을 확인합니다.

현재 이 구성에 대해 사용 가능한 확인 절차가 없습니다.

문제 해결

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