ABOUT ME

    -

    Today
    -
    Yesterday
    -
    Total
    -
    • [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 4 : SWe Core, 7단계로 나눠 commit하는 전체 명령
      Ribbon Communications/Session Border controller 2026. 9. 15. 14:09

      1편 · 전체 SOP와 실습 첨부 | 이전 편

      이번 편에서 할 일

      3편에서 만든 인증서를 SWe Core에 등록하고, SIPp client에서 들어온 호를 Edge로 TLS·SRTP로 내보내는 경로 전체를 만들겠습니다.

      이번 편의 핵심은 순서와 commit 단위입니다. 저는 처음에 인증서 이후의 설정을 한 파일로 모아 한 번에 commit하려 했습니다. 그런데 백엔드 참조 오류로 거부됐습니다. 그래서 설정을 7개 단계로 나누고, 단계마다 따로 commit했습니다. 이 방식으로 성공했고, 이 글의 명령은 그때 적용한 파일 내용 그대로입니다.

      Core는 EMA(GUI)가 아니라 CLI로만 적용했습니다. 그래서 이번 편에는 EMA 화면이 없고, 명령과 필드 표로 설명하겠습니다.

      시험 환경

      항목 값 비고
      장비 SBC SWe Core, VM 메모리 16GB 12.01.08R004 / vCPU 4
      CE 이름 vsbc1 인터페이스 명령의 ceName
      라우팅에 쓰는 시스템(게이트웨이) 이름 VSBCSYSTEM 라우트 키에 들어감
      패킷 포트 pkt0(SIPp client 쪽), pkt1(Edge 쪽) —
      적용 방식 CLI, 단계별 개별 commit —
      작업일 2026-09-15 —

      Core 설정 객체 연결도

      먼저 호가 Core 안에서 어떤 객체를 차례로 거치는지 한 줄로 보겠습니다.

      SIPp client(10.77.10.10) > zone FRESH_UAC의 sipSigPort 20(UDP 5060) > 트렁크 그룹 FRESH_TG_UAC > route(FRESH_TG_UAC에서 온 모든 번호) > routingLabel FRESH_TO_UAS > 트렁크 그룹 FRESH_TG_UAS + ipPeer FRESH_EDGE_TLS(edge.sbc.test) > zone FRESH_UAS의 sipSigPort 22(TLS) > Edge

      개념도(설계) — 화살표는 "참조한다"는 뜻입니다.

      [1단계]  pki certificate FRESH_CA (remote)      pki certificate FRESH_CORE (local)
                                                        ▲
[2단계]  packetServiceProfile FRESH_G711   tlsProfile FRESH_TLS ─┘
         packetServiceProfile FRESH_SRTP   ipSignalingProfile FRESH_TLS_IPSP
                 ▲                ▲                 ▲
[3단계]  zone FRESH_UAC(20)   zone FRESH_UAS(21) ──► dnsGroup FRESH_TLS_DNS (EDGE, CORE)
         ipInterfaceGroup FRESH_PKT0 (pkt0 10.77.10.1)
         ipInterfaceGroup FRESH_PKT1 (pkt1 10.77.20.1)
         zone FRESH_UAS ▸ ipPeer FRESH_EDGE_TLS (edge.sbc.test)
[4단계]  FRESH_UAC ▸ sipSigPort 20 ─► FRESH_PKT0           FRESH_UAS ▸ sipSigPort 22 ─► FRESH_PKT1, FRESH_TLS
[5단계]  FRESH_UAC ▸ sipTrunkGroup FRESH_TG_UAC ─► FRESH_PKT0, FRESH_G711
         FRESH_UAS ▸ sipTrunkGroup FRESH_TG_UAS ─► FRESH_PKT1, FRESH_TLS_IPSP, FRESH_SRTP
[6단계]  routingLabel FRESH_TO_UAS ─► FRESH_TG_UAS + FRESH_EDGE_TLS
[7단계]  route (FRESH_TG_UAC, VSBCSYSTEM, …) ─► FRESH_TO_UAS

      단계 순서는 이 그림의 아래에서 위로 향하는 참조를 따릅니다. 참조당하는 객체가 먼저 commit되어 있어야 참조하는 객체의 commit이 통과합니다.

      공통: 적용하는 방법

      어디서: Core CLI(admin)

      모든 단계는 같은 틀로 적용합니다.

      configure private
set ...        ← 단계별 명령
set ...
commit check
commit
exit
      • configure private로 설정 모드에 들어갑니다.
      • 해당 단계의 set 명령만 넣고 commit합니다.
      • commit이 성공하면 다음 단계로 넘어갑니다.
      • commit이 거부되면 다음 단계로 넘어가지 마세요. 실패한 후보 설정을 버리고(원인을 고친 뒤) 그 단계부터 다시 합니다.

      비밀번호가 들어가는 명령은 <CORE_P12_PASSWORD>로 표시했습니다. 여러분 환경의 값으로 바꿔 넣으세요.

      사전 작업: 인증서 파일을 Core로 옮기기

      3편의 ca.pem과 core.p12를 Core로 옮기면서 이름을 fresh-ca.pem, fresh-core.p12로 바꿨습니다. 1단계 명령의 fileName은 이 이름을 가리킵니다. 파일은 Core가 인증서를 import할 때 읽는 디렉터리에 있어야 합니다.

      파일 위치는 /opt/sonus/external이며 실제 이름은 fresh-ca.pem, fresh-core.p12입니다. 관리용 SSH 키를 사용하는 이 랩의 복사 예입니다. <SWE_SSH_KEY>는 자신의 관리 키 경로로 바꿉니다.

      scp -P 2024 -i <SWE_SSH_KEY> ./new-ca-output/public/ca.pem linuxadmin@192.168.56.101:/home/linuxadmin/fresh-ca.pem
scp -P 2024 -i <SWE_SSH_KEY> ./new-ca-output/secrets/tls/core.p12 linuxadmin@192.168.56.101:/home/linuxadmin/fresh-core.p12
ssh -p 2024 -i <SWE_SSH_KEY> linuxadmin@192.168.56.101

      Core OS 셸에서 다음 두 파일을 배치합니다.

      sudo install -m 600 /home/linuxadmin/fresh-ca.pem /opt/sonus/external/fresh-ca.pem
sudo install -m 600 /home/linuxadmin/fresh-core.p12 /opt/sonus/external/fresh-core.p12
      • 실패 시: 1단계 commit에서 파일을 찾지 못한다는 오류가 나면, 파일 위치와 이름의 대소문자부터 확인하세요.

      1단계: PKI 인증서 등록

      configure private
set system security pki certificate FRESH_CA fileName fresh-ca.pem type remote state enabled
set system security pki certificate FRESH_CORE fileName fresh-core.p12 passPhrase <CORE_P12_PASSWORD> type local state enabled
commit check
commit
exit
      객체 필드 값 이유
      FRESH_CA fileName fresh-ca.pem 3편 CA 인증서(공개)
      — type remote 상대(Edge) 인증서를 검증할 때 믿는 쪽 인증서
      — state enabled 등록과 동시에 사용
      FRESH_CORE fileName fresh-core.p12 Core 개인키+인증서+CA 체인
      — passPhrase <CORE_P12_PASSWORD> P12 암호(글에는 싣지 않음)
      — type local Core 자신이 제시하는 인증서
      — state enabled —

      왜 제일 먼저인가: 2단계의 TLS 프로파일이 FRESH_CORE를 이름으로 참조합니다. 인증서가 없으면 TLS 프로파일 commit이 통과할 수 없습니다.

      • 실패 시: 암호가 틀리거나 P12 포장 방식을 읽지 못하면 FRESH_CORE만 실패합니다. 3편 P12 포장 방식과 암호를 확인하세요.

      2단계: 미디어·TLS·시그널링 프로파일

      configure private
set profiles media packetServiceProfile FRESH_G711 codec codecEntry1 G711-DEFAULT
set profiles security tlsProfile FRESH_TLS allowedRoles clientandserver authClient true peerCertValidate true peerNameVerify enabled
set profiles security tlsProfile FRESH_TLS clientCertName FRESH_CORE serverCertName FRESH_CORE
set profiles security tlsProfile FRESH_TLS v1_0 disabled v1_1 disabled v1_2 enabled v1_3 disabled
set profiles security tlsProfile FRESH_TLS cipherSuite1 tls_ecdhe_rsa_with_aes_128_gcm_sha256
set profiles security tlsProfile FRESH_TLS handshakeTimer 15
set profiles signaling ipSignalingProfile FRESH_TLS_IPSP egressIpAttributes transport type1 tlsOverTcp type2 none type3 none type4 none
set profiles media packetServiceProfile FRESH_SRTP codec codecEntry1 G711-DEFAULT
set profiles media packetServiceProfile FRESH_SRTP secureRtpRtcp cryptoSuiteProfile DEFAULT
set profiles media packetServiceProfile FRESH_SRTP secureRtpRtcp flags enableSrtp enable allowFallback disable
set profiles media packetServiceProfile FRESH_SRTP rtcpOptions rtcp enable terminationForPassthrough enable
commit check
commit
exit

      TLS 프로파일 FRESH_TLS

      필드 값 이유
      allowedRoles clientandserver 정방향에서는 Core가 TLS client지만, Edge가 먼저 연결을 여는 경우엔 server가 될 수 있음
      authClient true Core가 server 역할일 때 상대에게도 인증서를 요구(상호 인증)
      peerCertValidate true 상대 인증서를 FRESH_CA 기준으로 검증
      peerNameVerify enabled 상대 인증서 이름이 트렁크 그룹의 tlsPeerName과 맞는지 검사. 이게 꺼져 있으면 "같은 CA가 발급한 아무 인증서"나 통과
      clientCertName FRESH_CORE client로 연결할 때 제시할 인증서
      serverCertName FRESH_CORE server로 받을 때 제시할 인증서
      v1_0 / v1_1 disabled 오래된 버전 차단
      v1_2 enabled 이 랩의 목표 버전
      v1_3 disabled 판정 기준을 TLS 1.2 하나로 고정
      cipherSuite1 tls_ecdhe_rsa_with_aes_128_gcm_sha256 Edge TLS Profile에 넣을 목록과 한 개로 똑같이 맞춤. 협상 결과가 이 값 하나로 정해지게
      handshakeTimer 15 Edge 쪽 Handshake Inactivity Timeout 15초와 같은 값

      IP 시그널링 프로파일 FRESH_TLS_IPSP

      필드 값 이유
      egressIpAttributes transport type1 tlsOverTcp Edge로 나가는 SIP 전송을 TLS로
      type2 ~ type4 none 다른 전송으로 대체되지 않게 TLS 하나만 허용

      패킷 서비스 프로파일 두 개

      프로파일 필드 값 이유
      FRESH_G711 codec codecEntry1 G711-DEFAULT SIPp client 구간. SIPp가 PCMU만 제안하므로 G.711
      FRESH_SRTP codec codecEntry1 G711-DEFAULT Edge 구간도 같은 코덱. 코덱 변환 요인을 없앰
      — secureRtpRtcp cryptoSuiteProfile DEFAULT 기본 crypto suite 프로파일 사용. 이번 시험의 SDP에서는 AES_CM_128_HMAC_SHA1_80으로 협상됨(7편)
      — secureRtpRtcp flags enableSrtp enable Edge 구간 미디어를 SRTP로
      — secureRtpRtcp flags allowFallback disable 평문 RTP로 물러서지 않게. fallback을 허용하면 호가 성공해도 SRTP 성공이라고 판정할 수 없음
      — rtcpOptions rtcp enable RTCP 사용
      — rtcpOptions terminationForPassthrough enable 실행한 구성 그대로 기재. 이 옵션의 효과는 이번에 따로 확인하지 않음

      RTCP 옵션 두 줄은 SRTP 프로파일과 함께 넣었습니다. 다만 이번 연재에서 RTCP 동작 자체를 따로 시험하거나 판독하지는 않았습니다. RTCP 처리를 켜는 설정이며 RTCP-XR 또는 MOS 측정을 의미하지 않습니다. DEFAULT를 참조한 실제 SDP offer/answer에서 AES_CM_128_HMAC_SHA1_80을 확인했습니다. 이 글은 DEFAULT의 전체 목록을 추정하지 않고 실제 협상된 값을 기준으로 판정합니다.

      • 실패 시: FRESH_CORE를 찾을 수 없다는 오류라면 1단계가 commit되지 않은 것입니다.

      3단계: zone·IP 인터페이스·DNS·IP 피어

      configure private
set addressContext default zone FRESH_UAC id 20
set addressContext default zone FRESH_UAS id 21
set addressContext default ipInterfaceGroup FRESH_PKT0 ipInterface FRESH_PKT0_V4 ceName vsbc1 portName pkt0 ipAddress 10.77.10.1 prefix 24 state enabled mode inService
set addressContext default ipInterfaceGroup FRESH_PKT1 ipInterface FRESH_PKT1_V4 ceName vsbc1 portName pkt1 ipAddress 10.77.20.1 prefix 24 state enabled mode inService
set addressContext default dnsGroup FRESH_TLS_DNS localRecord EDGE hostName edge.sbc.test
set addressContext default dnsGroup FRESH_TLS_DNS localRecord EDGE data 1 type a ipAddress 10.77.20.2
set addressContext default dnsGroup FRESH_TLS_DNS localRecord CORE hostName core.sbc.test
set addressContext default dnsGroup FRESH_TLS_DNS localRecord CORE data 1 type a ipAddress 10.77.20.1
set addressContext default zone FRESH_UAS dnsGroup FRESH_TLS_DNS
set addressContext default zone FRESH_UAS ipPeer FRESH_EDGE_TLS policy sip fqdn edge.sbc.test fqdnPort 5060
commit check
commit
exit

      zone

      객체 id 이유
      FRESH_UAC 20 SIPp client 쪽 구간. 다른 zone과 겹치지 않는 번호
      FRESH_UAS 21 Edge 쪽 구간. 평문 구간과 TLS 구간을 zone 단위로 분리

      IP 인터페이스

      필드 FRESH_PKT0_V4 FRESH_PKT1_V4 이유
      그룹 FRESH_PKT0 FRESH_PKT1 포트·트렁크 그룹이 그룹 이름으로 참조
      ceName vsbc1 vsbc1 이 Core의 CE 이름
      portName pkt0 pkt1 2편 결선도의 SIPp client 쪽 / Edge 쪽
      ipAddress / prefix 10.77.10.1 / 24 10.77.20.1 / 24 설계 주소
      state / mode enabled / inService enabled / inService 만들자마자 사용

      DNS 그룹 FRESH_TLS_DNS

      local record hostName data 1 이유
      EDGE edge.sbc.test A 10.77.20.2 ipPeer가 FQDN으로 Edge를 가리키므로 Core가 이 이름을 풀어야 함
      CORE core.sbc.test A 10.77.20.1 대칭으로 함께 등록. 정방향 호에서 이 레코드가 쓰였는지는 따로 확인하지 않음

      Core는 외부 DNS 서버에 묻지 않고 이 local record로 이름을 풉니다. 외부 DNS가 흔들려도 Core 쪽 이름 해석은 영향을 받지 않게 한 선택입니다. zone FRESH_UAS dnsGroup FRESH_TLS_DNS로 이 DNS 그룹을 Edge 쪽 zone에 붙였습니다.

      IP 피어 FRESH_EDGE_TLS

      필드 값 이유
      policy sip fqdn edge.sbc.test IP가 아니라 FQDN으로 지정. 인증서 이름과 같은 이름으로 목적지를 정함
      policy sip fqdnPort 5060 아래 <포트 5060과 5061> 절 참고
      • 실패 시: 인터페이스가 올라오지 않으면 portName과 실제 패킷 포트 결선(2편)이 맞는지 먼저 확인하세요.

      4단계: SIP 시그널링 포트

      configure private
set addressContext default zone FRESH_UAC sipSigPort 20 ipInterfaceGroupName FRESH_PKT0 ipAddressV4 10.77.10.1 portNumber 5060 transportProtocolsAllowed sip-udp state enabled mode inService
set addressContext default zone FRESH_UAS sipSigPort 22 ipInterfaceGroupName FRESH_PKT1 ipAddressV4 10.77.20.1 portNumber 5060 transportProtocolsAllowed sip-tls-tcp tlsProfileName FRESH_TLS state enabled mode inService
commit check
commit
exit
      필드 sipSigPort 20 (FRESH_UAC) sipSigPort 22 (FRESH_UAS) 이유
      ipInterfaceGroupName FRESH_PKT0 FRESH_PKT1 3단계 인터페이스 그룹
      ipAddressV4 10.77.10.1 10.77.20.1 그 그룹의 주소
      portNumber 5060 5060 아래 <포트 5060과 5061> 절 참고
      transportProtocolsAllowed sip-udp sip-tls-tcp SIPp 구간은 UDP만, Edge 구간은 TLS만 허용
      tlsProfileName (없음) FRESH_TLS TLS 포트에 2단계 TLS 프로파일 연결
      state / mode enabled / inService enabled / inService —

      포트 번호 20, 22는 zone 안에서 겹치지 않는 식별자일 뿐입니다. 특별한 의미는 없습니다.

      5단계: SIP 트렁크 그룹

      configure private
set addressContext default zone FRESH_UAC sipTrunkGroup FRESH_TG_UAC media mediaIpInterfaceGroupName FRESH_PKT0
set addressContext default zone FRESH_UAC sipTrunkGroup FRESH_TG_UAC ingressIpPrefix 10.77.10.10 32
set addressContext default zone FRESH_UAC sipTrunkGroup FRESH_TG_UAC policy media packetServiceProfile FRESH_G711
set addressContext default zone FRESH_UAC sipTrunkGroup FRESH_TG_UAC policy digitParameterHandling numberingPlan GENERIC_NUM_PLAN
set addressContext default zone FRESH_UAC sipTrunkGroup FRESH_TG_UAC state enabled mode inService
set addressContext default zone FRESH_UAS sipTrunkGroup FRESH_TG_UAS media mediaIpInterfaceGroupName FRESH_PKT1
set addressContext default zone FRESH_UAS sipTrunkGroup FRESH_TG_UAS policy digitParameterHandling numberingPlan GENERIC_NUM_PLAN
set addressContext default zone FRESH_UAS sipTrunkGroup FRESH_TG_UAS state enabled mode inService
set addressContext default zone FRESH_UAS sipTrunkGroup FRESH_TG_UAS ingressIpPrefix 10.77.20.2 32
set addressContext default zone FRESH_UAS sipTrunkGroup FRESH_TG_UAS policy signaling ipSignalingProfile FRESH_TLS_IPSP
set addressContext default zone FRESH_UAS sipTrunkGroup FRESH_TG_UAS policy media packetServiceProfile FRESH_SRTP
set addressContext default zone FRESH_UAS sipTrunkGroup FRESH_TG_UAS signaling tlsPeerName edge.sbc.test
commit check
commit
exit
      필드 FRESH_TG_UAC FRESH_TG_UAS 이유
      media mediaIpInterfaceGroupName FRESH_PKT0 FRESH_PKT1 미디어도 신호와 같은 쪽 인터페이스로
      ingressIpPrefix 10.77.10.10/32 10.77.20.2/32 이 주소에서 들어온 호를 이 트렁크 그룹으로 분류. /32로 딱 한 호스트만
      policy media packetServiceProfile FRESH_G711 FRESH_SRTP client 구간은 평문 RTP, Edge 구간은 SRTP 필수
      policy signaling ipSignalingProfile (기본값) FRESH_TLS_IPSP Edge로 나가는 신호를 TLS로
      policy digitParameterHandling numberingPlan GENERIC_NUM_PLAN GENERIC_NUM_PLAN 번호 계획은 기본 범용 계획. 번호 변환 규칙은 넣지 않음
      signaling tlsPeerName (없음) edge.sbc.test 2단계 peerNameVerify enabled가 비교할 기대 이름. Edge 인증서 SAN과 같아야 함
      state / mode enabled / inService enabled / inService —

      FRESH_TG_UAS의 명령 순서를 보면 state enabled가 프로파일 지정보다 앞에 있습니다. 같은 commit 안에서 함께 적용되므로 결과는 같습니다. 실행한 파일 순서를 그대로 옮겼습니다.

      • 실패 시: 호가 Core에 들어오자마자 거절되면, SIPp client의 출발지 주소가 ingressIpPrefix 10.77.10.10/32와 맞는지 먼저 확인하세요.

      6단계: 라우팅 레이블

      configure private
set global callRouting routingLabel FRESH_TO_UAS routingLabelRoute 1 trunkGroup FRESH_TG_UAS ipPeer FRESH_EDGE_TLS inService inService
commit check
commit
exit
      필드 값 이유
      레이블 FRESH_TO_UAS "Edge로 보낸다"는 목적지 묶음
      routingLabelRoute 1 목적지 후보 1번(이 랩은 하나뿐)
      trunkGroup FRESH_TG_UAS 5단계 Edge 쪽 트렁크 그룹
      ipPeer FRESH_EDGE_TLS 3단계 피어(edge.sbc.test)
      inService inService 바로 사용

      7단계: 라우트

      configure private
set global callRouting route trunkGroup FRESH_TG_UAC VSBCSYSTEM standard Sonus_NULL 1 all all ALL none Sonus_NULL routingLabel FRESH_TO_UAS
commit check
commit
exit

      라우트는 긴 키 뒤에 목적지 레이블이 붙는 구조입니다. 제가 의도한 뜻은 아래와 같습니다.

      순서 키 값 의도한 뜻
      1 trunkGroup 들어온 트렁크 그룹 기준으로 라우팅
      2 FRESH_TG_UAC 그 트렁크 그룹 이름
      3 VSBCSYSTEM 이 Core의 시스템(게이트웨이) 이름
      4 standard 표준 라우팅
      5 Sonus_NULL 착신 번호를 특정하지 않음(모든 번호)
      6 1 국가 코드
      7 all 모든 호 유형
      8 all 모든 번호 유형
      9 ALL 모든 시간대
      10 none 호 파라미터 필터 없음
      11 Sonus_NULL 착신 도메인 이름을 특정하지 않음
      → routingLabel FRESH_TO_UAS 6단계 레이블로 보냄

      정리하면 FRESH_TG_UAC로 들어온 호는 번호와 상관없이 전부 Edge로 보냅니다. Core에서는 2000번을 따로 걸러내지 않는다는 뜻입니다. 번호 검사는 Edge의 Transformation(^2000$)이 맡습니다(6편).

      왜 한 번에 commit하지 않았나

      방식 결과
      2~7단계를 하나로 합쳐 한 번에 commit 백엔드 참조 오류로 거부
      1 → 2 → 3 → 4 → 5 → 6 → 7단계를 각각 commit 모두 성공, 7편 통화 성공

      제가 이해한 이유는 이렇습니다. 한 트랜잭션 안에서 새로 만든 객체를 같은 트랜잭션의 다른 객체가 참조하면, 백엔드가 아직 반영되지 않은 객체를 찾지 못해 거부할 수 있습니다. 그래서 참조당하는 쪽을 먼저 commit하는 순서로 나눴습니다. 제 경우에는 이 7단계 분할로 해결됐습니다. 실제 작업에서는 프로파일·포트·트렁크 그룹 참조 오류를 만나 단계별 커밋으로 해결했습니다.

      포트 5060과 5061

      이번 구성에서 헷갈리기 쉬운 부분이 있습니다. 먼저 사실만 표로 정리하겠습니다.

      위치 설정한 값 출처
      Core sipSigPort 22(TLS) portNumber 5060 4단계 명령
      Core ipPeer FRESH_EDGE_TLS fqdnPort 5060 3단계 명령
      Edge Listen Port(TLS) 5061 6편 화면 11-edge-listeners.png
      Edge Signaling Group "FRESH Core TLS"의 Listen Port TLS-5061 하나 6편 화면 15-edge-core-sg.png

      Core 설정에는 portNumber/fqdnPort 5060을 사용했고, 실제 최초 호의 TCP 목적지는 10.77.20.2:5061이었습니다. Edge의 TLS Listen Port 5061과 일치합니다. 아래 실측 연결은 첫 호 PCAP에서 추출했습니다.

      10.77.20.1:54319  →  10.77.20.2:5061
ClientHello → ServerHello / CertificateRequest → Client Certificate / CertificateVerify

      이 글의 명령은 이 버전에서 검증한 값입니다. 다른 포트·버전에 일반적인 자동 보정 규칙으로 확대하지 말고 실제 TCP 목적지를 캡처에서 확인합니다.

      확인

      어디서: Core CLI(admin)

      각 단계 commit 뒤, 설정 모드에서 해당 계층을 show로 확인할 수 있습니다.

      configure private
show profiles security tlsProfile FRESH_TLS
show addressContext default zone FRESH_UAS
show global callRouting routingLabel FRESH_TO_UAS
exit
      확인 항목 기대값 실측값 판정 증적
      1~7단계 commit 모두 성공 모두 성공(단계별 개별 commit) 일치 —
      합친 commit — 참조 오류로 거부 (막혔던 지점) —
      번호 변환·메시지 조작 객체 없음 새 구성에 넣지 않음 일치 명령 전체
      Edge로 나가는 R-URI 번호 변환 없이 2000 2000 (Core 로그) 일치 7편
      착신 트렁크 그룹 SRTP fallback disable allowFallback disable 일치 2단계 명령
      TLS 상대 이름 edge.sbc.test tlsPeerName edge.sbc.test 일치 5단계 명령
      TLS 버전·암호군(실제 협상) TLS 1.2, 0xC02F TLS 1.2, 0xC02F 일치 7편 첫 호 핸드셰이크

      이 편만으로는 호가 된다고 말할 수 없습니다. Edge가 아직 구성되지 않았기 때문에, 이 시점에 Edge 쪽 TLS 연결이 실패하는 것은 정상입니다. 동작 확인은 Edge를 마친 뒤 7편에서 하겠습니다.

      막혔던 지점

      증상 인증서 이후 설정(프로파일부터 라우트까지)을 한 파일로 모아 한 번에 commit하자 거부됐습니다.

      원인 같은 commit 안에서 새로 만든 객체끼리 서로를 참조하면서 백엔드 참조 검사를 통과하지 못한 것으로 판단했습니다.

      조치 위 7단계로 나눠 단계마다 commit했습니다. 이후 모든 단계가 성공했습니다.

      정리

      SWe Core에 인증서, TLS·SRTP 프로파일, 인터페이스와 DNS, 시그널링 포트, 트렁크 그룹, 라우팅 레이블, 라우트를 7번의 commit으로 만들었습니다. Edge 쪽 트렁크 그룹에는 TLS 전용 전송, fallback 없는 SRTP, 상대 이름 edge.sbc.test 검증을 걸었습니다. 번호 변환과 메시지 조작은 넣지 않았습니다.

      다음 편에서는 SWe Edge WebUI로 넘어가서 인터페이스, 인증서, 상호 TLS 프로파일, SDES-SRTP 프로파일을 차례로 보겠습니다.

      1편 · 전체 SOP와 실습 첨부 | 이전 편

      저작자표시 (새창열림)

      'Ribbon Communications > Session Border controller' 카테고리의 다른 글

      [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 6 : SWe Edge ②, Signaling Group·SIP Server Table·Call Routing  (0) 2026.09.15
      [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 5 : SWe Edge ①, 인터페이스·인증서·상호 TLS·미디어 암호  (0) 2026.09.15
      [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 3 : 공인 도메인 없이, 사설 CA와 SAN 인증서 만들기  (0) 2026.09.15
      [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 2 : VirtualBox·Rocky·SIPp namespace·내부 DNS  (0) 2026.09.15
      [Ribbon SBC] Core–Edge TLS/SRTP Hands on - 1 : 구성도와 목적, 라이선스를 지키면서 초기화하기  (0) 2026.09.15

      관련글 관련글 더보기

      댓글

    Designed by Tistory.

    티스토리툴바