-
[Ribbon SBC] Core–Edge TLS/SRTP Hands on - 6 : SWe Edge ②, Signaling Group·SIP Server Table·Call RoutingRibbon Communications/Session Border controller 2026. 9. 15. 14:10
이번 편에서 할 일
5편에서 만든 부품을 호 경로로 잇겠습니다. 이번 편이 끝나면 Core에서 TLS로 들어온
2000번 호가 Edge를 지나 SIPp server로 UDP로 나갈 수 있습니다.적용 방식은 5편과 같습니다. REST API와 WebUI 폼 제출을 스크립트로 넣었고, 스크린샷은 적용 뒤 WebUI에서 찍었습니다. 캡처 시각은 Edge 화면 기준 2026-09-15 04:09입니다.
시험 환경
항목 값 비고 장비 SBC SWe Edge (Device Name SWeEdge)13.1.0 build 43 / vCPU 2 적용 방식 REST API + WebUI 폼 스크립트 화면은 적용 후 캡처 작업일 2026-09-15 — 연결 흐름 먼저 보기
정방향(시험한 방향)의 흐름을 한 줄로 쓰면 이렇습니다.
Core(10.77.20.1, TLS) > Listen Port TLS 5061 > Signaling Group FRESH Core TLS(ID 1) > Call Routing Table FRESH route 2000(ID 201) > Transformation FRESH match 2000(
^2000$→2000) > Signaling Group FRESH SIPp server(ID 2) > SIP Server Table FRESH 10.77.30.10(ID 202, UDP 5060) > SIPp server예를 들어 Core가 R-URI 사용자 부분
2000으로 INVITE를 보내면, Edge는 Called Address/Number가 정확히2000인지 봅니다. 맞으면 번호를2000그대로 두고 SIPp server 쪽 Signaling Group으로 보냅니다.20001이나12000처럼 정확히 일치하지 않는 번호는 이 규칙을 통과하지 못합니다.Edge 설정 객체 연결도(설계, 이름은 실측 화면 표기)
┌─ Listen Port ID 2: TLS 5061, TLS Profile 201 SG 1 "FRESH Core TLS" ───┼─ Media List 201 "FRESH PCMU SRTP" Federated 10.77.20.1/32 ├─ SIP Server Table 201 "FRESH core.sbc.test" (TLS 5061) ← 역방향용 └─ Call Routing Table 201 "FRESH route 2000" └─ Entry 1: Transformation 201 "FRESH match 2000" → SG 2 ┌─ Listen Port ID 1: UDP 5060 SG 2 "FRESH SIPp server" ┼─ Media List 1 "Default Media List" Federated 10.77.30.10/32├─ SIP Server Table 202 "FRESH 10.77.30.10" (UDP 5060) ← 정방향 목적지 └─ Call Routing Table 202 "FRESH route 1000" └─ Entry 1: Transformation 202 "FRESH match 1000" → SG 1 ← 역방향(미시험)적용 순서는 참조 관계를 따릅니다.
- Listen Port
- 빈 Call Routing Table · Transformation · SIP Server Table
- Signaling Group
- Call Routing Table 안의 Route Entry
Route Entry는 목적지 Signaling Group을 가리키므로 Signaling Group보다 뒤에 만들었습니다.
사전 조건
- [ ] 5편: TLS Profile 201, Media List 201, 인터페이스
Ethernet 1·Ethernet 2 - [ ] 4편: Core가
edge.sbc.test로 TLS 호를 내보내도록 구성됨
1. Listen Port
어디서: Edge WebUI — Settings 탭 > Protocols > SIP 아래 Listen Port, 화면 제목 Listen Port Table (WebUI 폼 제출)
Edge WebUI Listen Port Table. UDP 5060 TLS Profile N/A가 ID 1, TLS 5061 TLS Profile 201이 ID 2로 표시됨
화면 열 ID 1 ID 2 이유 Protocol UDP TLS SIPp server 구간은 UDP, Core 구간은 TLS Port 5060 5061 SIP 관례 포트. TLS는 5061 TLS Profile ID N/A 201 TLS 포트에만 5편의 상호 인증 프로파일 연결 폼에 넣은 값은 이렇습니다.
- ID 1:
ListenProtocol=1,ListenPort=5060,TLSProfileID=0 - ID 2:
ListenProtocol=4,ListenPort=5061,TLSProfileID=201
화면과 맞춰 보면 프로토콜 코드 1이 UDP, 4가 TLS로 표시됩니다.
부분 초기화 뒤에는 UDP 5060이 기본으로 있지 않았습니다. 그래서 ID 1도 직접 만들어야 했습니다. 초기화한 장비라면 이 목록부터 확인해 주세요.
- 실패 시: 6편 끝에서 Signaling Group 상태가 Up이 아니면, 여기서 해당 Listen Port가 만들어졌는지와 TLS Profile ID가 201인지 확인하세요.
2. SIP Server Table 두 개
어디서: Edge REST API —
PUT sipservertable/201,PUT sipservertable/202, 각 테이블에sipserver/1항목SIP Server Table은 "이 Signaling Group이 호를 내보낼 상대"를 적는 곳입니다.
REST 필드 테이블 201 항목 1 테이블 202 항목 1 이유 테이블 DescriptionFRESH core.sbc.test FRESH 10.77.30.10 — Hostcore.sbc.test10.77.30.10 Core는 FQDN(인증서 이름과 일치), SIPp server는 IP DomainName(빈 값) (빈 값) — Port5061 5060 상대가 받는 포트 Protocol4 (TLS) 1 (UDP) Listen Port 화면과 같은 코드 체계 TLSProfileID201 0 Core로 나갈 때만 상호 인증 TLS Monitor0 0 적용한 구성 그대로 기재. 이 랩은 호 시험만 보므로 상대 감시 관련 값을 켜지 않음 KeepAliveFrequency/RecoverFrequency0 / 0 0 / 0 위와 같음 테이블 Sequence11항목 한 개 정방향 시험에서 실제로 쓰이는 것은 테이블 202(SIPp server)입니다. 테이블 201은 Edge가 Core로 호를 내보내는 역방향(
1000번)용이고, 이번에 시험하지 않았습니다.3. Call Routing Table 뼈대와 Transformation
어디서: Edge REST API —
PUT routingtable/201·202,PUT transformationtable/201·202, 각transformationentry/1화면: Settings > Call Routing > Transformation > FRESH match 2000Call Routing Table은 먼저 빈 테이블로 만듭니다. Signaling Group이 테이블 번호를 참조해야 하기 때문입니다. 안의 Route Entry는 5절에서 넣습니다.
REST 리소스 Descriptionroutingtable/201FRESH route 2000 routingtable/202FRESH route 1000 transformationtable/201FRESH match 2000 transformationtable/202FRESH match 1000 
Edge WebUI Transformation 테이블 FRESH match 2000. Input Field Type Called Address/Number, Input Field Value ^2000$, Output Field Value 2000, Match Type Mandatory (Must Match) 항목 한 건
화면 열 화면에 보이는 값 REST 필드 = 값 이유 Input Field Type Called Address/Number (스키마 기본값) 착신 번호로 판단 Input Field Value ^2000$InputFieldValue=^2000$정규식. ^와$로 앞뒤를 막아 정확히 2000만 일치Output Field Type Called Address/Number (스키마 기본값) 착신 번호에 결과를 씀 Output Field Value 2000OutputFieldValue=2000번호를 바꾸지 않음 Match Type Mandatory (Must Match) (스키마 기본값) 일치하지 않으면 이 라우트를 쓰지 않음 Description Match 2000 Description= Match 2000— Primary Key 1 — — "2000을 2000으로 바꾸는" 규칙이라 의미가 없어 보일 수 있습니다. 이 규칙의 역할은 번호 변환이 아니라 문지기입니다. Core는 4편 라우트에서 번호를 가리지 않고 전부 Edge로 보냅니다. Edge가 여기서 시험 번호 하나만 통과시키는 구조입니다.
테이블 202(
^1000$→1000)도 같은 형태로 만들었습니다. 역방향용이며 시험하지 않았습니다.4. Signaling Group 두 개
어디서: Edge WebUI — Settings > Signaling Groups, REST
PUT sipsg/1,PUT sipsg/2
Edge WebUI Signaling Group Table. SIP 타입의 FRESH Core TLS(ID 1)와 FRESH SIPp server(ID 2) 두 그룹이 모두 Service Status Up으로 표시됨
Edge WebUI Signaling Group 상세 화면(FRESH Core TLS). Service Status Up, Supported Audio Modes에 DSP, Listen Port에 TLS-5061, Federated IP/FQDN에 10.77.20.1 / 255.255.255.255가 보임
화면 필드 REST 필드 SG 1 "FRESH Core TLS" SG 2 "FRESH SIPp server" 이유 Description DescriptionFRESH Core TLS FRESH SIPp server — No. of Channels Channels5 5 시험은 한 번에 1호. 여유분 Call Routing Table RouteTableID201 (FRESH route 2000) 202 (FRESH route 1000) 이 SG로 들어온 호에 쓸 라우팅 테이블 SIP Server Table ServerClusterId201 (core.sbc.test) 202 (10.77.30.10) 이 SG로 내보낼 상대 Media List ID MediaConfigID201 (FRESH PCMU SRTP) 1 (Default Media List) Core 구간만 SRTP Listen Port SIPListenProtocolPortList2 → 화면 TLS-50611 → UDP 5060 5편 Media List 안내대로 SRTP SG는 TLS 포트만 Federated IP/FQDN RemoteHosts/RemoteMasks10.77.20.1 / 255.255.255.255 10.77.30.10 / 255.255.255.255 이 주소에서 온 신호만 이 SG로 받음. /32로 한 호스트만 Signaling/Media Source IP NetInterfaceSignalingEthernet 1-1Ethernet 2-1Core 쪽 / SIPp server 쪽 인터페이스 Supported Audio Modes RTPProxyMode,RTPDirectMode등 = 0화면에 DSP 표시 (SG 2 상세 화면 없음) 모든 proxy/direct 모드를 끔 → Edge가 DSP로 미디어를 처리 SIP Mode MonitorBasic Call (3) Basic Call (3) 등록 바인딩 대신 SIP Server Table을 사용 SG 1의 실제 선택값은 Call Routing Table=
FRESH route 2000, SIP Server Table=FRESH core.sbc.test, Media List ID=FRESH PCMU SRTP, SIP Mode=Basic Call입니다. SG 2는FRESH route 1000,FRESH 10.77.30.10, 기본 Media List를 사용합니다.
SIPp server 측 Signaling Group 상세
REST로 SG를 만들 때 한 가지 주의할 점이 있었습니다. 스키마 기본값에는 포트를 개별로 지정하는 예전 방식의 필드(
Protocol_…,ListenPort_…,TLSProfileID_…,LocalIP_…)가 들어 있습니다. 이번에는 이 필드들을 요청에서 빼고, Listen Port 목록 참조(SIPListenProtocolPortList)만 넘겼습니다. 두 방식이 섞이지 않게 하려는 선택입니다.Supported Audio Modes가 DSP라는 점도 기억해 두세요. 저는 Core 쪽은 SRTP, SIPp server 쪽은 평문 RTP로 Edge에서 미디어를 나누려고 proxy/direct 모드를 모두 끄고 DSP로 두었습니다. 이렇게 Edge가 미디어를 직접 처리하는 구성에서는 7편에서 볼 구간별 패킷 수가 1:1로 똑같지 않을 수 있습니다.
5. Route Entry
어디서: Edge REST API —
PUT routingtable/201/routingentry/1,PUT routingtable/202/routingentry/1화면: Settings > Call Routing > Call Routing Table > FRESH route 2000
Edge WebUI Call Routing Table FRESH route 2000. Priority 1, Transformation Table FRESH match 2000, Destination Type Standard, First Signaling Group (SIP) FRESH SIPp server, Description FRESH test route, Fork Call No 항목 한 건
화면 열 화면에 보이는 값 REST 필드 = 값 이유 Admin State 스크린샷 참고 ConfigIEState= 1활성 Priority 1 (기본값) 항목이 하나뿐 Transformation Table FRESH match 2000 TransformationTable= 2013절의 문지기 규칙 Destination Type Standard (기본값) 일반 SG로 보냄 First Signaling Group (SIP) FRESH SIPp server SignalingGroupList= 2SIPp server 쪽으로 Description FRESH test route Description= FRESH test route— Fork Call No (기본값) 한 곳으로만 (화면 열 없음) — MediaMode= 0적용한 구성 그대로 기재 테이블 Sequence— 1— 테이블 202(FRESH route 1000)에도 같은 형태로
TransformationTable=202,SignalingGroupList=1(FRESH Core TLS) 항목을 넣었습니다.역방향(1000)은 구성만 했습니다
구성 요소 정방향 2000 (Core → Edge → SIPp server) 역방향 1000 (SIPp server → Edge → Core) 들어오는 SG SG 1 FRESH Core TLS SG 2 FRESH SIPp server Call Routing Table 201 FRESH route 2000 202 FRESH route 1000 Transformation 201 ^2000$202 ^1000$나가는 SG SG 2 SG 1 나가는 SIP Server 202 10.77.30.10 UDP 5060 201 core.sbc.test TLS 5061 시험 여부 시험함(7편) 시험하지 않음 역방향을 실제로 쓰려면 Core에도 Edge에서 들어오는 호를 받아 SIPp client로 보내는 라우팅이 필요합니다. 그런데 4편 Core 구성에는 그 라우트가 없습니다. 게다가 SIPp client 쪽 착신 시나리오도 이번에 준비하지 않았습니다. 그러니 역방향은 "Edge 쪽 틀만 있다" 정도로 이해해 주세요.
Core ↔ Edge 대응표
양쪽 이름·포트·검증 값이 서로 맞는지 한 표로 모았습니다.
항목 Core (4편) Edge (5·6편) 맞는가 Core → Edge 목적지 ipPeer edge.sbc.test,fqdnPort 5060Listen Port TLS 5061, SG 1 Listen Port TLS-5061 호는 성립. 실제 TCP 목적지 10.77.20.2:5061 확인 상대 주소 허용 FRESH_TG_UASingressIpPrefix 10.77.20.2/32SG 1 Federated 10.77.20.1/32 서로 상대 주소 상대 이름 tlsPeerName edge.sbc.test인증서 CN edge.sbc.test같음 Edge가 보는 Core 이름 인증서 CN core.sbc.testSIP Server 201 Host core.sbc.test, Hostscore.sbc.test=10.77.20.1같음 TLS 프로파일 FRESH_TLSTLS Profile 201 5편 표에서 대조 SRTP FRESH_SRTP필수Media List 201 → SDES-SRTP 201 필수 같은 방향 번호 라우트: 번호 무관 → Edge Transformation ^2000$Edge가 번호를 거름 Edge 쪽 상태 확인
어디서: Edge WebUI — Settings > Signaling Groups
14번 화면에서 두 Signaling Group 모두 Service Status: Up입니다. 15번 상세 화면에서도 FRESH Core TLS가
Service Status Up으로 보입니다.확인 항목 기대값 실측값(2026-09-15 04:09 화면) 판정 증적 Listen Port UDP 5060(ID 1), TLS 5061 + Profile 201(ID 2) 같음 일치 11-edge-listeners.pngSG 1 FRESH Core TLS 상태 Up Up 일치 14,15SG 2 FRESH SIPp server 상태 Up Up 일치 14SG 1 Listen Port TLS-5061만 TLS-5061 일치 15SG 1 Federated IP 10.77.20.1 / 255.255.255.255 같음 일치 15Route Entry(2000) FRESH match 2000 → FRESH SIPp server 같음 일치 16Transformation(2000) ^2000$→2000, Mandatory같음 일치 17역방향(1000) 호 — 미시험 — — 이 화면들은 첫 번째 시험 호(Edge 시각 04:02경) 뒤, 두 번째 시험 호(04:10경) 앞에 찍었습니다. 그래서 "호 이전에 SG가 Up이었는지"를 보여 주는 화면은 아닙니다. 대신 두 번째 호 직전의 상태를 보여 줍니다. Core와 Edge 사이 TLS 연결이 호 없이 먼저 맺어지는지도 이번에 따로 확인하지 않았습니다.
- 실패 시: SG가 Up이 아니면 Listen Port(1절), 인터페이스(5편 1절), Federated IP 순서로 보세요.
정리
Edge에 Listen Port 두 개, SIP Server Table 두 개, Signaling Group 두 개, Call Routing Table과 Transformation을 넣었습니다. 그 결과 Core에서 TLS로 들어온
2000번이 SIPp server로 UDP로 나가는 경로가 생겼습니다. Core 쪽 SG는 TLS-5061만 받고, SRTP 필수 Media List를 씁니다. 역방향1000번은 틀만 넣었고 시험하지 않았습니다.이제 두 SBC가 모두 준비됐습니다. 다음 편에서는 5초짜리 통화를 실제로 걸고, TLS·SDP·wire 미디어·end-to-end 결과를 각각 증적으로 판독하겠습니다.
'Ribbon Communications > Session Border controller' 카테고리의 다른 글