Tech Log 🛠️

SDP(Session Description Protocol) 란?

- 세션 파라미터를 협상하는 프로토콜이다.

  SIP는 "요청과 응답" 모델이지만 , SDP는 "제안과 수락 모델이다.

  SDP는 보통 협상 내용을 SIP 메세지 바디에 포함되어 전달한다. 

  SIP의 INVITE 에 SDP의 offer 가 포함되어 있고, 200 OK에 SDP의 answer 가 포함되어 있다.

SDP 메세지 분석

-  SIP 와 다른 메세지 포맷이지만 텍스트 기반으로 협상이 이루어진다.

   (볼드체는 필수 파라미터)

• v=0 (SDP의 프토콜 버전)
• o=alice 2890844526 2890844526 IN IP4 atlanta.com (메세지를 생성한 주체)
• s= (세션 이름)
• c=IN IP4 10.1.3.33 (옵션)
• t=0 0 (타이밍)
• m=audio 49172 RTP/AVP 0
• a=rtpmap:0 PCMU/8000          

- m= , a= 에서 RTP가 사용할 (지원 가능한 모든)코덱 , IP주소 , 포트 넘버를 명기  

기본 SDP 협상의 이해

- 협상은 앨리스 - 밥 - 앨리스 - 밥 순으로 이루어진다.

먼저, 앨리스가 다음과 같은 협상을 제안한다.

v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

메세지를 분석해보면,

제안의 주체(o) 는 앨리스이고 단말의 주소는 "host.anywhere.com" 이다.

그리고 audio 하나와 video 두개의 코덱을 제안하였다.

1. PCMU 코덱 (49170 포트)

    - 별도의 언급이 없으므로 양방향 채널

2. H.261 코덱 (51372 포트) 

    - 별도의 언급이 없으므로 양방향 채널

3. MPEG 코덱 (53000 포트)

    - 별도의 언급이 없으므로 양방향 채널

이제 밥은 협상을 받아들인다.

v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000

여기서 주목해야할 점은 ,

m= video 0 RTP/AVP 에 대한 a= 값이 없다는 것이다.

즉 미디어 속성(a=)을 포함하지 않는다면 , 미디어 스트림이 개방되지 않는다.

만약 밥이 협상 변경을 원한다고 가정해보자

v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=recvonly

협상 변경 내용은 크게 두 가지가 있다.

1. PCMU 코덱의 포트를 49920 에서 65422 로 변경할  것을 요청

2. DTMF 처리를 위한 수신전용 채널 개방

밥의 협상 요청에 앨리스는 이렇게 응답한다.

v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=sendonly

밥이 제안한 내용대로 음성 채널 1개 , 영상 채널 2개 , 추가적으로 DTMF 처리를 위한 채널 한개를 추가로 오픈.

여기서 송신 전용으로 오픈 한 이유는 밥이 수신 전용으로 요청 했기 때문에 이것은 곧 앨리스에선 송신 전용으로 되기 때문이다.

지금까지는 여러 개의 코덱을 사용하는 경우이고, 또 다른 경우를 살펴보자

여러 개의 코덱 중에서 하나를 선택해야 하는 경우

- 전화 통화는 하나의 음성 코덱만을 사용한다.

  따라서 offer 에 있는 다양한 코덱 중에서 하나를 선택해야한다.

  협상은 앨리스 - 밥 - 앨리스 - 밥 순으로 이루어진다.

앨리스가 다수의 코덱을 제안한다.

v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactive

m 속성에 있는 0 4 18 은 선호 순위이다.

PCMU(G.711) , G.723 , G.729  세 개의 코덱을 제안했다.

코덱 협상 완료 전까지는 통신이 불가하므로 inactive

이제 밥이 하나의 코덱을 선택한다.

v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000 
a=rtpmap:4 G723/8000
a=inactive

요약을 해보면,

밥은 PCMU(G.711) , G.723 두 개의 코덱이 지원가능한데 0(PCMU), 4(G.723) 순으로 선호한다는 것이다.

 마찬가지로 inactive

다시 앨리스는 밥이 사용 가능한 코덱 중에서 하나를 고른다.

v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv

두번째 우선 순위인 G.723 을 선택하였지만 보통 첫번째 우선 순위를 사용한다.

sendrecv (양방향)으로 채널을 오픈한다.

밥은 다시 앨리스의 제안에 대해 수락한다,

v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv

양방향 통신으로 G.723 코덱을 사용하는 것으로 협상이 끝난다.

지금까지 SDP 메세지 분석 및 협상 과정을 알아보았다.

REGISTER의 개요

실제 SIP PROTOCOL에서는 SIP PROXY나 IP PBX를 이용해서 주소 매핑 테이블을 관리한다.

따라서 SIP 전화기가 RESISTER 메세지를 보내면  SIP RESISTAR 서버는 200 OK를 응답함으로써 등록이 진행된다.

SIP RESISTAR의 역할에 대해서는 전에 한번 다루었던 적이 있다.

https://cb036133.tistory.com/100

REGISTER의 과정

1. REGISTER 

REGISTER sip:server19.atlanta.com SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bk2l55n1
To: Alice <sip:alice@atlanta.com>
From: Alice <sip:alice@atlanta.com>;tag=283074
Call-ID:a84b4g96te10@pc33.atlanta.com
CSeq: 31862 REGISTER
Contact: <sip:alice@10.1.3.33>
Expires: 21600
Content-Length: 0

메세지를 보면 To와 From이 모두 앨리스로 동일하며 , requst uri 는 registrar 서버를 가리킨다.

Expires 헤더는 등록의 유효기간을 의미한다.

하지만 회사에서는 일반적으로 전화번호 하나당 하나의 전화기만 사용하지 않는다.

예를 들어, 앨리스란 사람이 세 대의 SIP 전화기를 사용한다고 가정해보자.

이때 사람(앨리스)을 구분하는 주소를 "Address-Of-Record(AOR)"  단말을 인식하는 주소를 Contact Address 라고 한다.

삽화에서 AOR은 "Bob@biloxi.com"이 될 것이며 Contact Address는 IP전화기나 PC소프트폰 등등의 주소가 될 것이다.

SIP Proxy의 역할은 AOR과 Contact Address 들을 바인딩하는 것이다.

만약 앨리스가 밥에게 전화를 걸었다고 하면 앨리스는 밥의 AOR만 알고 있는 것이므로 Contact Address 는 SIP Proxy가 바인딩 해주어야한다.

근데 이런 바인딩 정보는 언제 등록이 되는 걸까?

이것은 위에서 보았던 등록 과정 수행되는 데 아래의 200 OK 응답 메시지를 보면 알 수 있다.

2. 200 OK

SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bk2l55n1; received=10.1.3.33
To: Alice <sip:alice@atlanta.com>; tag=a 6c85e3
From: Alice <sip:alice@atlanta.com>;tag=283074
Call-ID:a84b4g96te10@pc33.atlanta.com
CSeq: 31862 REGISTER
Contact: <sip:alice@pc33.atlanta.com>
Contact: <sip:alice@cm9013.atlanta.com>
Service-Route: <sip:bigbox3.atlanta.com;lr>
Expires: 3600
Contact-Length: 0

응답 메세지를 보면 Expires 헤더가 3600으로 감소했으므로 앨리스의 전화기는 3600초 마다 등록을 갱신해야한다.

또한 이 재등록 매커니즘은 연결 확인을 위한 keepalive 기능도 수행하는데 , 이때문에 너무 잦지도 않으면서 keepalive를 수행할 수 있는 적당한 헤더값을 찾아야한다.

그리고 contact 헤더 두개와 Service Route 헤더가 새로 보인다.

이것은 각각 위에서 설명했던 AOR과 Contact Address이다

contatc 헤더값으로 미루어봤을 때 앨리스는 하나의 전화번호로 두개의 전화기를 쓰고 있다.

SIP Proxy  서버는 어떻게 알까?

등록을 하는 과정은 이제 알았다..  근데 우리가 한건 SIP Registar에 메세를 보낸 건데 Proxy의 서버 주소는 어떻게 알까?

크게 세가지 방법이 있다.

1. 서버 주소 직접 입력     

- 서버의 주소가 변경되거나 단말기의 수가 많아질 수록 굉장히 번거로워 짐

2. HTTP나 TFTP 같은 프로토콜 이용     

- 방화벽 환경에서는 사용 제한

3.  DHCP (Dynamic Host Configuration Protocol) 를 이용     

- 가장 이상적 , 전화기를 부팅할 때 IP 주소와 Proxy 및 기타 주소들을 받아온다.

그리고 위의 응답 메세지에서도 Proxy 서버의 주소를 알 수가 있다.Proxy 서버의 주소는 Service - Route 라는

이름의 헤더(bigbox3.atlanta.com;lr)로 전달된다.

SIP(Session Initiation Protocol)의 개요

SIP의 등장 배경
- H.323의 단점을 극복 하기 위해
- H.323은 제약이 많음

SIP는 세션 설정 프로토콜이며 크게 5개의 세션이 있음
1. 다자간 회의
2. 음성 전화 
3. 영상 전화
4. 이벤트 신청 및 통지
5. 상태 정보 배포

SIP는 TCP, UDP를 사용할 수 있지만 현재는 TCP를 더 많이 사용

SIP 메세지는 SIP 헤더(메세지 바디의 종류)와 메시지 바디(옵션 필드)로 구성

SIP컴포넌트

SIP컴포넌트들은 통신에서 호를 생성/종료하기 위한 기능들은 직접 구현한다.

UA

- UAC(세션 시작)

- UAS(호를 종단)

- UA끼리 직접 연결하거나 리다이렉트 서버, 프록시를 통해 연결한다.

- 호의 상태를 실시간으로 관리한다.

SIP Proxy 

- 호를 종단하지 않고 릴레이해준다.

SIP Gateway

- PSTN전화망과 IP 네트워크를 연결해준다.

SIP에서는 별도의 서버가 IP 주소 매핑 테이블을 가지고 전화기의 정보들을 업데이트한다.

서버를 기능에 따라 3가지로 분류할 수 있다.

1. Registrar Server

    - 전화기로부터 SIP REGISTER 메세지를 받아 상태 정보를 생성/업데이트한다.

2. Proxy

    - 전화기로부터 수신한 접속 요청 메세지를 추가/변경 

    - 메세지 전달 , 과금 정보 등을 생성

3. Redirect Server

    - 메세지를 전송한 UAC에게 3xx redirect 메세지를 보냄으로써 목적지를 알려준다.

B2BUA

- SIP PROXY 로 구성된 IP PBX는 대용량 처리를 하는데는 유용하지만 부가 기능과 서로 다른 프로토콜을 연동하기에는 부족하다

  (SIP는 UA가 보낸 메세지 전체를  수정할 순 없고 일부만 수정 가능함)   

  따라서 기업에서는 이러한 단점들 때문에 B2BUA로 IP 프록시를 구현하는 경우가 많다.

B2BUA의 구성

- B2BUA는 착신 전화기와 발신 전화기의 IP PBX를 각각 만들어주고 두 개의 다이얼로그를 생성한다.

  이렇게하면 메세지의 헤더와 바디 부분을 변경할 수 있고, 프로토콜간 연동도 용이해진다.

일반적인 기업 : B2BUA 사용 (부가 기능 개발)

통신사업자 : SIP PROXY 사용 (대용량 처리)

기본적인 SIP CALL FLOW의 이해

SIP는  요청/응답 기반의 프로토콜이기 때문에 세션에 대한 제어 요청과 응답으로 트랜잭션을 진행한다.요청에는 14개(기본 6개,부가 기능 8개)의 메서드가 정의되어있고 , 응답에는 3개의 응답이 있다.

1. SIP Proxy 가 없는 경우

     - 앨리스가 밥의 IP를 안다고 가정한다.

만약 앨리스가 밥에게 전화를 거는 상황을 예로 들어보면 , 크게 3가지의 필수 과정이 포함된다.

호(CALL) 설립 절차

1. INVITE : 세션에 참가를 요청

INVITE sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

from ,to 헤더를 통해 앨리스가 밥에게 통화를 시도했다는 것을 알 수 있다.

Via 헤더를 통해 응답을 받는 주소를 명시하고 있다.

CSeq는 314159번이며 , 같은 다이얼로그 내에서 이 번호는 유지된다.

2. 200 OK : 참가 요청 승인 

SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/sdp
Content-Length: 131

같은 다이얼로그 이므로 CSeq는 그대로 유지된다.

여기서 주목해야할 점은 From , to 헤더가 바뀌지 않고 그대로 유지된다는 것인데, 이것을 통해 From , to 헤더는 출발지 목적지가 아닌 방향성을 나타낸다고 볼 수 있다.

Via 헤더의 received 필드를 추가하여 메시지를 받은 정보(앨리스)를 명시하고 있다.

3. ACK : 승인 확인 (ACK는 따로 ACK가 나가지 않는다.)

ACK sip:bob@192.168.10.20 SIP/2.0 
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 ACK
Content-Length: 0

Received 필드는 지워졌으며 CSeq 를 통해 200 OK에 대한 ACK임을 확인할 수 있다.

하지만 실제 통신에서는 두 가지 프로시저가 추가된다.

4. 100 TRYING : INVITE 를 받고 요청을 정상적으로 수신했음을 알림 

5. 180 RINGING : 송신 측에게 링백톤을 전송

호 종료 절차

1. BYE : 상대방이 전화기를 내려놓는다.

BYE sip:alice@10.1.3.33 SIP/2.0 
Via: SIP/2.0/TCP 192.168.10.20;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Alice <sip:alice@atlanta.com>;tag=1928301774
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 231 BYE
Content-Length: 0

밥이 앨리스에게 요청을 상황이므로 새로운 다이얼로그이다. 그렇기 때문에 CSeq는 새로운 값을 받는다.

2. 200 OK : BYE 요청에 대한 응답

SIP/2.0 200 OK 
Via: SIP/2.0/TCP 192.168.10.20 
To: Alice <sip:alice@atlanta.com>;tag=1928301774
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf 
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 231 BYE
Content-Length: 0

CSeq를 통해 BYE 요청에 대한 응답임을 알 수 있다.

2. SIP Proxy 를 경유하는 경우

     - 앨리스는 밥의 IP를 모르고 SIP Proxy를 경유한다고 가정한다.

1. INVITE (앨리스 -> 프록시)

INVITE sip:bob@biloxi.com/TCP SIP/2.0 
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

앨리스는 INVITE 메세지를 프록시 서버로 전송한다.

2. INVITE (프록시 -> 밥)

INVITE sip:bob@192.168.10.20/TCP       SIP/2.0
Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776asdhds;received=10.1.3.33
Max-Forwards: 69
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

프록시 서버는 밥의 URI로 메세지를 전송하는데 Via 헤더가 추가된 것을 볼 수 있다.

이것은 밥의 응답이 서버를 경유하기 위함이며 이렇게 함으로써 호의 진행 상황을 알 수 있다.

서버를 하나 경우했으므로 Max-Fowards 는 70에서 69로 감소되었다.

3. 200OK (밥 -> 프록시)

SIP/2.0 200 OK
Via: SIP/2.0/TCP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1        
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID:a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/sdp
Content-Length: 131

Via헤더에는 각각 서버의 주소와 앨리스의 주소가 Received 필드에 추가되있다.

4. 200OK (프록시 -> 앨리스)

SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bKnashds8;received=10.1.3.33
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Content-Type: application/sdp
Content-Length: 131

프록시는 자신이 추가했던 Via 헤더를 지운 후 다시 앨리스에게 메세지를 전달한다.

5. ACK

ACK 이후 부터는 프록시를 거치지 않고 메세지를 전달하는데 이렇게 되면 프록시는 호의 진행 상황을 알 수 없고 

부가 기능 또한 개발이 불가능하다.

따라서 모든 메세지가 프록시 서버를 경유하도록 하는 방법이 필요한데 후에 기술할 Record - Route 헤더와 Route 헤더를

사용한다.

VoIP의 등장

기존 전화망은 사용시간과 거리에 따른 종량제여서 많은 요금이 부과됐지만 인터넷 망을 이용한 통신은 정액제로 운영되기 때문에

상대적으로 요금에 대한 부담이 적었다.

따라서 CBN의 전화 시스템을 PBN에서 동작시키는 방법에 대한 표준화가 진행되었으며 여러 기업이 이 표준에 맞게 시스템들을 개발하였다.

초창기에는 VoATM , VoFR , VoIP 등 다양한 방법이 있었지만 현재는 VoIP만 사용한다.

Voice Gateway (음성 게이트웨이)

- PSTN과 IP(이기종 망)을 연동하는 장비

- 이더넷 인터페이스 , PSTN 인터페이스

트렁크 게이트웨이

- PBX와 연결하기 위한 E1 트렁크를 집적하는 음성 게이트웨이

아날로그 게이트웨이

-  PBX가 없는 경우 , 아날로그 전화기 및 팩스 지원

- 별도의 시그널링 방법 사용

FXS

- 전화망 모사 인터페이스로 기존의 전화기 또는 팩스 연결

FXO

- 전화기 모사 인터페이스

E&M

- 아날로그 트렁크 방식, 구형 PBX와 PBX 간의 연결에 사용

*기능적인 차이로 동시에 구현할 수 있다. -> 물리적으로 한 장비로 만들 수 있다.

Vocie Gateway 초기 망 구성

가입자망은 PSTN 방식으로 이루어져 있으며 PSTN 과 인터넷망을 연결하기 위해 음성 게이트웨이를 사용하였다.

하지만 VG를 사용한 VoIP는 출시 당시 QOS 미보장으로 인해 음질이 떨어진다는 단점이 있었다.

VOIP 등장 이전 전화망의 구현 방식과 작동 원리를 탐구하고 VOIP의 특징에 대해 알아본다.

PSTN 

- 대형 회로 스위치형 네트워크

- 구성요소

   1. 전화기, RJ-11

   2. IDF

       - 전화기들의 스위치를 중계한다. 

   3. MDF

       - 주로 빌딩이나 구내 통신실에 위치하며 IDF가 모임

   4. PBX

        - 스위치 교환 시스템이며 MDF 들이 모임

   5. E1 트렁크

        - PBX 끼리의 연결을 위한 규격

   6. Tandem Switch

        - 교환기와 교환기끼리의 연결을 위해 사용한다.

과거 전화망을 이용한 통신 방식

- 과거에는 MDF 단자함과 전화 교환기를 수작업으로 연결해주었으며,

  이때 전화기와 포트의 매핑 정보는 선번장으로 관리해주었다.

이때 규모가 큰 통신 시스템은 PBX 라는 방식을 사용하였다.

PBX

- IDF 에서 전화기의 스위치를 중계한다.

- MDF에서 IDF 들이 모이고 이렇게 모인 MDF들이 PBX에 모인다.

- PBX는 크게 네 가지의 구성요소가 있다.

  1. 내선카드

      - 가입자 회선을 수용한다.

      - PBX의 크기를 결정한다. 

      - 내선카드의 수는 얼마만큼의 라인을 수용할 수 있는지를 결정한다.

  2. 스위칭

      - 내선 카드에 연결된 라인들을 스위칭해준다.

      - 전화기와 전화기를 연결한다.

  3. 제어부

       - PBX를 관리 제어한다.

  4. 트렁크 카드

       - 지역 전화국에 연결할 때 사용한다.

       - PBX 와 PBX 를 연결한다.

다이얼링

                                                                       Pulse Dialing        VS        Tone Dialing

Pulse Dialing

- 전송된 각 신호에 따라 펄스를 발생시키며 다이얼링을 실행한다.

단점 

1. 지연이 길다.

2. 노이즈에 취약

Tone Dialing

- 두 가지 톤을 동시에 사용하며 다이얼링을 실행한다.(DTMF)

- 잡음에 대한 민감도 낮다

E1 트렁크

국내 표준으로 사용되는 표준이다.PBX간 혹은 전화국 간 연결에 사용된다.

32개의 채널이 있지만 0번채널과 16번 채널을 제외하고 30개만 사용 가능하다.0번 :프레이밍 정보16번: 시그널링 정보

E.164 주소 체계

ITU-T 

국제 통신에 사용하는 번호의 최대 자릿수 12자리로 규정

CC : 국가 코드 (두 자리)

AN : 지역번호 (두자리 or 세자리)

LN : 국번호 (세자리 or 네자리)

SN : 가입자 번호 (네자리)

전화를 걸 때마다 모든 번호를 누르지 않는 이유

-  전화번호 시스템이 계층적으로 이루어져 있고,

   해당 번호를 관장하는 PBX 내에서 스위칭이 되기 때문이다.