본문 바로가기
SIP의 이해

[연재] SIP의 이해 2 - 시스코 CUCM SIP Trunking의 이해 (하편)

라인하트 2013. 12. 24. 11:13

메리 크리스마스^^
모든 IT 엔지니어분들이 성탄절에는 노트북을 켜지 않기를 바랍니다. 

오비이락입니다. 
크리스마스 이브에 연재의 마지막 글을 올리게 되었습니다.
 "SIP의 이해 2"를  SIP로 인해 고생하시는 UC 엔지니어들에게 크리스마스 선물로 대신합니다. ^^ 


시작하며
"SIP의 이해 2 - 시스코 CUCM SIP Trunking의 이해" 의 마지막편입니다. SIP 관련 장애의 대부분은 SDP의 코덱 협상 실패나 미디어를 위한 IP 주소 문제가 대부분입니다. 이 글을 통해 SDP를 수월하게 분석하고 SIP에 정통한 엔지니어가 되는 밑거름이 되길 기대합니다.  

이 글에서는 SDP 개요 및 음성 통화와 영상 통화 시의 SDP에 대해 자세히 살펴보겠습니다. 이 글을 읽기 전에 아래 글을 먼저 읽어보길 권합니다. 아래 글은 SDP 코덱 협상의 프로시져를 위주로 간략하게 설명한 것입니다. 

2009/01/19 - [SIP의 이해] - SIP의 이해 - 2.SDP (RFC 4566 & RFC 3264 )

2009/01/20 - [SIP의 이해] - SIP의 이해 - 3. Early Media in SDP (RFC 3959, RFC 3960)


SDP 요약 (RFC 4566)
SDP는 Session Description Protocol의 약어로 미디어의 속성을 정의하고, 단말간의 멀티미디어 세션과 관련된 미디어 타입 및 포맷을 협상합니다. SDP는 Offer/Answer Model로 협상하며 협상 방식에 따라 Early Offer와 Delayed Offer 두 가지 모델이 있습니다. Early Offer는 INVITE 에 SDP 메세지 바디를 포함하여 최초에 SDP 협상을 하는 것이며, Delayed Offer는 INVITE에 SDP 메세지 바디를 포함하지 않고 이 후 메세지에서 협상하는 것을 말합니다. 서비스 프로바이더와 SIP Trunk 연동 시 Early Offer가 선호하는 협상 방식입니다. 시스코 CUCM은 Delayed Offer를 기본으로 동작하며, 상황에 따라 Early Offer를 Trunk 별로 설정할 수 있습니다.  


음성 통화를 위한 SDP 메세지 분석 - 관련 SIP 헤더와  SDP 메세지
SIP 메세지 헤더의 Content-Type은 메세지 바디의 속성을 정의하고, Content-Length는 길이를 십진수로 표현합니다. 아래의 내용은 Content-tye은 SDP 이고 총 337 Byte로 구성되었음을 의미합니다. 

<SIP 헤더>

…..
Content-Type: application/sdp
Content-Length: 337


SDP 메세지 바디에는 SDP에 의해 제공된 미디어의 속성을 정의합니다. SDP의 각 라인은 필수 또는 옵션이지만, RFC 4566에 따라 각 라인의 순서는 반드시 지켜야 합니다.  


<SDP 메세지 바디>

v=0

o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.250

s=SIP Call

c=IN IP4 10.10.199.130

t=0 0

m=audio 16444 RTP/AVP 0 8 18 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=rtpmap:8 PCMA/8000

a=ptime:20

a=rtpmap:18 G729/8000

a=ptime:20

a=sendrecv

a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15


음성 통화를 위한 SDP 메세지 분석 - SDP 세션 속성
SDP 메세지의 세션 속성에 대해 정의한 5개 라인은 다음과 같습니다.

  • v= (필수)
    SDP 프로토콜의 버전(Version)으로 현재는 0 입니다.

  • o=  (필수)
    Origin으로 Username, Session-ID, Session Version, Network Type, Address Type, Unicast Address 를 표시

  • s= (필수)
    Session Name 을 표시

  • c= (옵션)
    Connection Data로 Network Type, Address Type, Connection-Address를 나타내며 미디어의 주소를 정의하므로 전화기의 주소라고 할 수 있습니다.

  • t= (필수)
    Timing으로 start-time과 stop-time을 표시합니다. 0 0 은 고정 세션을 의미합니다.

SDP 세션 속성을 통해서는 단말이 사용할 IP 주소와 포트를 확인합니다. 


음성 통화를 위한 SDP 메세지 분석 - SDP 미디어 속성
SDP Media 속성을 통해 UA간에 사용할 미디어 채널의 코덱과 DTMF 등을 협상합니다. 

  • m= (미디어 설명)
    Media Description으로 Media, Port, Protocol, Format 등의 정의를 표시합니다. 
    - Media는 audio, video, text, application, message로 표시
    - Port는 미디어가 전송될 Transport port를 표시
    - Protocol은 UDP, RTP/AVP, RTP/SAVP로 표시하며, AVP는 Audio VIdeo Profile의 약자 
    - Format은 미디어의 포맷을 서브필드 (a=)로 표시함을 의미 

    여기에 Payload Type 0 8 18의 순서는 코덱협상의 우선순위를 나타내며, Payload Type 101은 DTMF 이벤트를 정의합니다.   


  • a= (미디어 속성)
    attribute로 미디어 속성을 라인별로 정의하며, 관련된 파라미터는 아래와 같습니다. 
    - a=rtpmap: 은 payload type, encoding name/clock rate를 표시
    - a=ptime: 은 paket time으로 미디어 패킷 한 개가 포함한 시간 정보로 ms로 표시 (보통 20ms)
    - a=fmtp: 는 미디어 포맷에 대한 파미미터를 정의 
     
    여기서 m= 에서 명시한 Payload Type의 상세 설명은 아래와 같이 a=  라인에 표시됩니다.  

    - a=rtpmap:0 PCMU/8000
    - a=rtpmap:8 PCMA/8000
    - a=rtpmap:18 G729/8000
    - a=rtpmap:101 telephone-event/8000


  • a= (미디어의 방향)
    a= 라인은 미디어 속성을 정의할 뿐만 아니라 미디어 방향을 표시합니다. 미디어의 방향은 아래와 같이 4가지로 나타낼 수 있습니다. 

    - a=sendrecv : 단말은 미디어를 송신 및 수신할 수 있음
    - a=recvonly : 단말은 수신만을 할 수 있으며 송신하지 않음 
    - a=sendonly : 단말은 송신만을 할 수 있으며 수신하지 않음
    - a=inactive : 단말은 송신 및 수신을 할 수 없음 (Hold 버튼을 누를 경우)

    기본적으로 통신은 양방향이므로 별도의 업급이 없을 경우에는 a=sendrecv로 설정되었다고 가정합니다. 미디어의 방향은 다양한 부가서비스 구현 시 유용합니다. 대표적인 부가 기능으로는     링백톤을 서버로 부터 받거나 전화기에서 Hold 버튼을 누를 경우입니다.  


  • a= (DTMF 협상)
    추가적으로 a= 라인으로 DTMF 전달에 관한 협상도 진행합니다.  

    - a=rtpmap:101 telephone-event.8000  (RFC 2833에 의한 In-band DTMF를 의미)
    -     a=fmtp 101 0-15 (DTMF Tone은 0,1,2,3,4,5,6,7,8,9,0,*,#,A,B,C,D 총 15가지를 송수신함)


음성 통화를 위한 SDP 메세지 분석 - 응답 (Response)
Early Offer 또는 Delayed Offer에 상관없이 통신 단말 한 쪽에서 SDP  Offer 가 위와 같이 진행되었다고 가정할 경우에 이에 대한 응답에서는 기존의 Offer에 포함된 코덱 가운데 우선 순위를 가지고 응답합니다.  

<SDP 메세지 바디>

v=0

o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.251

s=SIP Call

c=IN IP4 10.10.199.179

t=0 0

m=audio 28668 RTP/AVP 18 101

a=rtpmap:18 G729/8000

a=ptime:20

a=sendrecv

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

 
위의 SDP 메세지에서  m= 라인에서 페리로드 타입(Payload Type) 18 101로 Answer(응답)하였으므로 G.729 코덱과 In-band DTMF를 이용할 것임을 표시하였습니다.  


영상 통화를 위한 SDP 메세지 분석
음성 코덱 협상은 영상에 비해 상대적으로 단순합니다. 영상 코덱 협상을 따라가기 어려운 이유는 영상 코덱 협상은 음성 코덱 협상과 달리 송수신 코덱을 비대칭적으로 협상하기 때문입니다. 영상 코덱은 CPU에 대한 의존도가 높아서 단말에 따라 성능의 차이가 크고, 디코딩보다 엔코딩시에 더 많은 자원을 소모합니다. 즉 디스플레이에 표시하는 해상도가 더 높은 것이 일반적입니다.  

영상회의 코덱의 협상은 자신의 엔코딩 능력에 대한 Offer / Answer 가 아닌 자신의 디코딩 능력에 대한 Offer / Answer 입니다. 



위의 그림에서 보듯이 영상 통화는 위의 그림과 같이 다수의 미디어 채널을 협상합니다. 음성 송수신을 위한 Audio 채널, 영상 송수신을 위한 Main VIdeo 채널, 문서 공유를 위한 Slide Video 및 제어를 위한 BFCP (Binary Floor Control Protocol) 채널, 원격 카메라 제어를 위한 FECC (Far End Camera Control) 채널 등입니다. 

아래처럼 SDP Offer는 다수의 오디오 속성과 영상 속성을 포함하므로 상당히 많은 라인을 포함하므로 각 라인의 순서를 지키는 것이 중요합니다. 음성 채널에 대한 협상을 위에서 살펴보았으므로 아래의 오디오 부분은 쉽게 파악할 수 있겠지만, 영상 코덱 부분은 너무 많아서 혼란스러울 것입니다.   

<Offer 중인 SDP메세지 바디>

v=0

o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6

s=SIP Call

b=TIAS:6000000

b=AS:6000

t=0 0

m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101

c=IN IP4 10.58.9.86

b=TIAS:64000

a=rtpmap:102 MP4A-LATM/90000

a=fmtp:102 bitrate=64000;profile-level-id=24;object=23

a=rtpmap:103 MP4A-LATM/90000

a=fmtp:103 bitrate=56000;profile-level-id=24;object=23

a=rtpmap:104 MP4A-LATM/90000

a=fmtp:104 bitrate=48000;profile-level-id=24;object=23

a=rtpmap:9 G722/8000

a=ptime:20

a=rtpmap:105 G7221/16000

a=fmtp:105 bitrate=32000

a=rtpmap:106 G7221/16000

a=fmtp:106 bitrate=24000

a=rtpmap:0 PCMU/8000

a=ptime:20

a=rtpmap:8 PCMA/8000

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

m=video 16446 RTP/AVP 97 98 99 34 31

c=IN IP4 10.58.9.86

b=TIAS:6000000

a=label:11

a=rtpmap:97 H264/90000

a=fmtp:97 profile-level-id=428016;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000

a=rtpmap:98 H264/90000

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000

a=rtpmap:99 H263-1998/90000

a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1

a=rtpmap:34 H263/90000

a=fmtp:34 QCIF=1;CIF=1;CIF4=1

a=rtpmap:31 H261/90000

a=fmtp:31 CIF=1;QCIF=1

a=content:main

a=rtcp-fb:* nack pli

a=rtcp-fb:* ccm tmmbr

m=video 16448 RTP/AVP 97 98 99 34 31

c=IN IP4 10.58.9.86

b=TIAS:6000000

a=label:12

a=rtpmap:97 H264/90000

a=fmtp:97 profile-level-id=428016;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000

a=rtpmap:98 H264/90000

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000

a=rtpmap:99 H263-1998/90000

a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1

a=rtpmap:34 H263/90000

a=fmtp:34 QCIF=1;CIF=1;CIF4=1

a=rtpmap:31 H261/90000

a=fmtp:31 CIF=1;QCIF=1

a=content:slides

a=rtcp-fb:* nack pli

a=rtcp-fb:* ccm tmmbr

m=application 5070 UDP/BFCP *

c=IN IP4 10.58.9.86

a=floorctrl:c-s

a=floorid:2 mstrm:12

a=confid:1

a=userid:8

m=application 16450 RTP/AVP 107

c=IN IP4 10.58.9.86

a=rtpmap:107 H224/0


위의 SDP 메세지를 미디어 채널별로 분리해서 살펴볼 것입니다. 아래에서 영상회의 미디어 채널 협상 시에 새롭게 추가된 부분은 굵은 글씨로 표시 하였습니다.  


<SDP 메세지 바디>

v=0

o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6

s=SIP Call

b=TIAS:6000000

b=AS:6000

t=0 0


m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101

c=IN IP4 10.58.9.86

b=TIAS:64000

m=video 16446 RTP/AVP 98 99

c=IN IP4 10.58.9.86

b=TIAS:6000000

a=rtpmap:98 H264/90000

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000

a=rtpmap:99 H263-1998/90000

a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1

a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm tmmbr


  • b= (bandwidth 속성)
    단말이 최대 지원할 수 있는 대역폭을 표시한 것입니다. 위의 SDP 메세지에서 세션 속성을 정의하는 곳에 b= 라인과 미디어 속성을 정의하는 곳에 b= 라인 두 가지가 있습니다. 세션 레벨에서의 b= 라인은 세션 전체에 대한 요구 대역폭을 정의하고,  미디어 레벨에서의 b= 라인은 각 미디어 채널별 요구 대역폭을 정의합니다. b= 라인의 Modifier는 최대 대역폭의 의미를 구체화하는 것으로 다음과 같습니다. 

    - <TIAS> : Transport Independent Application Specific 으로 bit/sec로 표시
                     TIAS는 Transport Layer의 오버헤드를 고려하지 않은 대역폭으로 RTP만의 대역폭
    - <AS> : Application Specific bandwidth로 kbps로 표시
                  TCP / UDP와 깉은 Transport Layer의 오버헤드를 고려한 대역폭으로 RTP/UDP/IP 의 대역폭
    - <CT> : Conference Total 로 kbps로 표시
                  다자간 회의 세션을 사용할 경우 최대 대역폭

    CUCM에서 대역폭 Modifier에 대한 설정은 SIP Profile에서 결정합니다. 기본값은 TIAS and AS 입니다. 
     

    또한, 세션 속성에서의 대역폭 설정은 실제 CUCM의 Region 설정에서 결정합니다. 


    위의 SDP Offer를 기준으로 다시 정리하면,  세션 레벨의 "b=TIAS:6000000"와 "b=AS:6000"으로 표시되었으므로 수신되는 모든 미디어 채널의 최대 대역폭은 6Mbps입니다. 음성 채널의 최대 대역폭은 64kbps이고, 각 영상 채널의 최대 대역폭은 6Mbps입니다. 


  • m=video 
    "m=audio" 라인의 설명은 생략하고, "m=video" 라인에 대해서 살펴보겠습니다. 아래는 각 영상 코덱별로 단락을 구분지어서 표시한 것입니다. 최우선 순위 영상 코덱은 Payload Type 98인 H.264이며, 그 다음 순위의 영상 코덱은 Payload Type 99인 H.263이라고 정의 되어 있으며, 이 값은 UA가 수신할 수 있는 코덱의 범위를 나타낸 것입니다.   

    m=video 16446 RTP/AVP 98 99

    c=IN IP4 10.58.9.86

    b=TIAS:6000000 

    a=rtpmap:98 H264/90000

    a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000


    a=    rtpmap:99 H263-1998/90000

    a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1




  • a=rtpmap:98 H264/90000
    a=fmtp:98 profile-level-id=428016 ............
    "a=ftpmap:98 H264/90000"은 H.264 코덱과 샘플링은 90000 Hz로 한다는 의미를 표시한 것이고, 상세한 미디어 포맷은  a=fmtp 라인에 명시되어 있습니다. H.264의 협상은 매우 복잡하므로 대부분을 생략하고 가장 의미있는 Profile-level-id를 위주로 살펴보겠습니다. .

    profile-level-id는 단말이 지원하는 최소한 Features/Capability Set인 H.264 프로파일을 정의하는 파라미터입니다.  이 파라미터 이후의 값은 기본 프로파일을 기준으로 더 지원할 수 있는 최대값을 세부적으로 명시한 것입니다. H.264는 약 21개의 프로파일과 해상도 및 프레임수를 기준으로 하는 레벨로 정의되어 있습니다. Profile-level-ID의  앞의 4자리로 H.264 프로파일을 나타내고, 뒤의 2 자리로 레벨인 해상도를 표시합니다. 여기서 SDP Offer의  "profile-level-id=428016"에서  4280은 H.264 Baseline Profile을 의미하고, 뒤의 16진수인 16을 십진수로 환산하면 22이므로 H.264 프로파일 레벨은 2.2가 됩니다. Level 2.2는 352*480@30fps를 의미합니다. 이는 단순히 최소값이고 이 SDP Offer의 최대값은 뒤의 파라미터에서 명시하고 있습니다. 

    나머지 파라미터는 생략합니다.   


  • a=rtcp-fb:* nack pli
    a=rtcp-fb:* ccm tmmbr
    RTCP는 패킷 손실이나 네트워크 혼잡에 대한 정보를 Sender Report 또는 Receiver Report를 통해 송수신합니다.  RTCP에 대한 협상으로 네트워크 혼잡(Network Congestion) 이나 패킷 손실 (Packet Loss)가 발생할 경우 UA는 Video rate adaption 으로 저 해상도로 전환합니다. 됩니다. 

    RTCP에 대한 세부 협상 내용을 알 필요는 없으므로 살짝만 살펴보겠습니다. 

    - rtcp-fb:* : Offer된 모든 코덱에 대한 RTCP FeedBack
    - nack : Negative ACKnowledgement (하나 이상의 RTP 패킷 손실을 가리킴)
    - PLI : Packet Loss Indicator
    - ccm : RTCP Feedback 메세지를 이용한 codec control을 지원
    - tmmbr : Temporary Maximum Media Stream Bit Rate Request/Notification을 지원


정리하면, 음성 채널은 동일한 코덱을 쓰도록 협상되지만, 영상 채널은 서로 다른 코덱으로 협상됩므로 양 단말은 동일한 H.264를 선택하였더라도 세부 항목은 다를 수 있습니다.  


문서공유를 위한 BFCP 
BFCP는 Binary Floor Control Protocol의 약자로 영상회의간에 자원 공유를 위한 접근 제어를 하는 프로토콜입니다. BFCP는 RFC 4582 BFCP와 RFC 4583 SDP format for BFCP에 정의되어 있으며, 기본적으로 두 개의 채널을 협상합니다. 하나는 공유된 자원을 공유하기 위한 미디어 채널과 제어를 위한 채널입니다. 

먼저 공유된 문서나 데스크탑 화면을 공유하기 위한 영상 채널 협상에 대해 살펴보겠습니다. 위의 SDP Offer에는 두 개의 m=video 라인으로 보아 두 개의 영상 채널을 협상합니다. 각 영상채널의 쓰임새를 알기 쉽게 a=content: 와 a=label:로 표시됩니다. 아래의 SDP 내용에서 첫번째 단락의 영상 채널은 Main Video Stream을 전달하며, 라벨은 11로 정의하고, 두 번째 단락의 영상 채널은  Slides VIdeo Stream (데스크탑 공유 스트림)을 전달하며 라벨은 12로 정의합니다.  

m=video 16446 RTP/AVP 97 98 99 34 31

c=IN IP4 10.58.9.86

b=TIAS:6000000

a=label:11
a=content:main

m=video 16448 RTP/AVP 97 98 99 34 31

c=IN IP4 10.58.9.86

b=TIAS:6000000

a=label:12
a=content:slides


두 개 채널의 용도가 정의 되었으므로 BFCP는 Slides Video Stream을 전달하는 라벨 12번을 이용한다는 것을 설명하는 것이 아래의 라인입니다.  a=floorid:2 mstrm:12라고 되어 있으므로 라벨 12번과 매핑됩니다. 


m=application 5070 UDP/BFCP *
c=IN IP4 10.58.9.86
a=floorctrl:c-s

a=floorid:2 mstrm:12

a=confid:1

a=userid:8


각각에 대한 설명은 다음과 같습니다.

  • confid : Common Conference ID 

  • userid  : User ID 

  • floorctrl : c-only는 Client Only, s-only는 Server Only, c-s는 모두의 의미


이에 대한 응답은 각 영상 채널에 대한 Label과 Content가 동일하게 전송되는 것을 확인하면 됩니다. 


원격 카메라 제어를 위한 FECC
FECC는 사용자가 영상 소스나 카메라를 제어하도록 하는 것으로 RTP UDP채널에서 H.224 패킷에 H.281 프레임에 기반한 단순 프로토콜입니다. 요새 ITU와 친하지 않아서 무슨 말인지 모르겠지만, H.281은 A Far End Camera Control For Video-Conferences using H.224"이며, H.224는 "A real time control protocol"입니다. 그리고, H.224에 관한 RTP Payload Format을 위한 MIME Type 등록에 관한 권고안이 RFC 4573 입니다.

어쨌든 FECC를 위한 채널은 아래 3개 라인으로 협상됩니다. 

m=application 16450 RTP/AVP 107
c= IN IP4 10.58.9.86
a=rtpmap:107 H224/0

FECC 채널은 m=application으로 표시되고 페이로드 타입은 107 입니다. 미디어 속성은H.224에 기반하여 FECC 메세지를 전송합니다.. 

위와 같이 Offer가 진행될 경우 상대방은 아래와 같이 응답할 것입니다.  

m=application 2352 RTP/AVP 107  

c=IN IP4 10.58.9.222
a=rtpmap:107 H224/0



협상 완료
지금까지 하나 하나 구분해서 보았지만, 전체적으로는 아래 그림과 같이 필요한 채널들을 모두 협상하였습니다. 이제 다시 SDP Offer 전체를 다시 보시기 바랍니다. 처음에는 매우 난해했던 메세지가 쉽게 눈에 들어올 것입니다. ^^



마치며
지금까지 SIP / SDP 메세지 분석을 통해 시스코 CUCM SIP Trunking에 대해 살펴보았습니다. 다음에는 CUCM과 CUCM간에 SIP Trunk를 구성한 후에 전화기의 부가 서비스가 어떻게 동작하는 지를 Call Flow를 기반으로 살펴보도록 하겠습니다. 

이 연재를 상중하로 나누었더니 다음편은 지하편으로 해야 겠네요.. ㅋㅋ


연재의 다른 글
SIP 관련 글들은 오른쪽 탭의 "SIP의 이해" 카테고리에 모두 포함되어 있으며, "SIP의 이해 2"는 아래에 링크를 통해 다시 살펴 보시기 바랍니다.


2013/12/19 - [SIP의 이해] - [연재] SIP의 이해 2 - 시스코 CUCM SIP Trunking의 이해 (상편)

2013/12/23 - [SIP의 이해] - [연재] SIP의 이해 2 - 시스코 CUCM SIP Trunking의 이해 (중편)

2013/12/24 - [SIP의 이해] - [연재] SIP의 이해 2 - 시스코 CUCM SIP Trunking의 이해 (하편)

라인하트 유씨누스(UCnus) (CCIEV #18487)  --------------------------------------
ucwana@gmail.com (라인하트의 구글 이메일) 
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항) 
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스) 
http://groups.google.com/group/ucforum (UC를 공부하는 사람들이 모인 구글 구룹스) 
세상을 이롭게 하는 기술을 지향합니다. ________________________________________________________



저작자표시 비영리

'SIP의 이해' Related Articles

티스토리툴바