Chapter 7. 가끔 보는 SIP Method


1. SIP 이벤트 처리
SIP 응용 서비스들은 주로 이벤트에 대한 통지 요청을 하고 이에 대한 응답을 받음으로써 진행됩니다. RFC 3265 SIP-Specitif Event Notification에 다음과 같은 SIP 응용 서비스에 대한 예가 있습니다. 


  • Automatic Callback Service (자동 콜백 서비스) 
    특정 단말의 상태정보를 알 수 있도록 호가 종료되었을 때, 상태 정보가 SIP 서비스로 통지(Notification)된다면, 바로 콜백이 이루어질 것입니다. 콜백 서비스는 상대방이 부재중이거나 통화중일 때 송신자가 콜백 서비스를 신청해 놓으면, 상대방의 상태 변화가 감지되자마자 자동으로 통화가 되도록 하는 것입니다. 

  • Buddy Lists (친구 목록) 
    버디 리스트에 등록된 친구 또는 동료의 상태정보가 실시간으로 통지되어 메신저와 같은 서비스를 편리하게 사용합니다.  

  • MWI (Message Waiting Indication) 
    음성사서함의 상태 변화 이벤트가 실시간으로 전화 또는 메신저에 통지되어 음성 사서함의 저장된 음성을 들을 수 있습니다. 

  • PINT (PSTN and Internet Internetworking) 
    PINT에서도 호 상태 정보를 통한 서비스가 가능합니다. PINT는 인터넷 응용을 요청하고 PSTN 전화서비스를 향상시키는 작업을 합니다. 인터넷 상의 응용 서비스가 PSTN과 원활하게 호를 처리할 수 있도록 지능망과 연동합니다. 

위의 SIP 응용 서비스는 UA의 Presence (상태정보)를 필요로 합니다. UA의 상태정보를 확인하기 위한 요청은 SUBSCRIBE 메쏘드입니다. SUBSCRIBE 메쏘드에 의한 이벤트 요청에 대한 처리 결과는 NOTIFY로 응답합니다.   


2. 등록 상태 머신(Regisration State Machine)

등록 상태를 이용한 SIP 이벤트는 SUBSCRIBE메쏘드로 요청하고, NOTIFY로 통지받습니다. 이에 대한 메쏘드를 이해하기 전에 등록 상태에 대해 좀더 살펴보기 위해 RFC 3680 SIP Event Package for Registrations에 설명한 등록 상태의 변화를 보겠습니다.




SIP에서 Registration (등록) 이란 Contact Address와 Address-of-record를 바인딩하는 것입니다. 여기서 Contact Address는 AoR에 의한 식별된 사용자에게 연결되기 위한 실제 단말의 주소입니다. User Agent는 SIP REGISTER 메쏘드로 등록을 수행하는 과정에서 등록 상태는 다음과 같이 표시됩니다.  


  • Init
    Address-of-record에 등록된 contact 이 없는 상태 즉, 도메인에 등록된 사용자이나 통화하기 위한 Contact 주소가 확보되지 않았음을 의미합니다.

  • Active 
    하나 이상의 Contact address가 바인딩된 상태입니다.

  • Terminated 
    더 이상의 Contact address가 존재하지 않는 상태로 바로 Init 상태로 전환됩니다.


여기서 짚고 넘어가야 할 부분은 등록 상태 정보와 사용자 상태 정보 (Presence)는 다르다는 것입니다.  사용자 상태 정보는 사용자가 지금 망에서 다른 사용자와 통화할 수 있는지에 초점을 둔 것이므로 사용자와 연결하기 위한 다수의 통신 수단를 나타내는 Contact address의 집합의 상태를 나타낸 것입니다. 등록 상태 정보는 사용자와 연결하기 위한 Contact address가 존재하는 지를 나타냅니다. 즉, 사용자 상태 정보를 알기 위해서는 등록 상태 정보라는 Raw 데이타가 필요합니다.  



3. SUBSCRIBE 메쏘드
SUBSCRIBE 메쏘드는 Subscriber가 특정 사용자의 현재의 상태와 상태 정보 업데이트를 요청하여 향후의 이벤트 발생 시에 통지해 줄 것을 요청하는 것입니다. SUBSCRIBE 메쏘드를 발행하는 UA를 Subscriber라 하고, NOTIFY로 응답하는 UA Registrar 서버를 Notifier라고 합니다.



등록 상태정보를 가장 많이 요청하는 것은 메신저 서버일 것입니다. 메신저 서버가 SIP Registrar 서버에게 상태정보를 요청하는 과정을 살펴보겠습니다.


  • SUBSCRIBE
    새롭게 추가된 Event 헤더는 요청하는 이벤트를 명시합니다. Event:reg 는 등록 상태 정보를 요청하는 이벤트입니다.   


    SUBSCRIBE sip:
    server19@atlanta.com SIP/2.0
    Via: SIP/2.0/TCP app_IM.atlanta.com;branch=z9hG4bKnashds7
    From: sip:app_IM.atlanta.com ;tag=123aa9
    To: sip:server19@atlanta.com
    Call-ID: 9987@app_IM.atlanta.com
    CSeq: 9887 SUBSCRIBE
    Contact: sip:app_IM.atlanta.com
    Event: reg
    Max-Forwards: 70
    Expires: 21600
    Accept: application/reginfo+xml

    Expires 헤더는 REGISTER 메쏘드에서 사용한 것처럼 요청의 유효기간을 명시하며 주기적인 업데이트가 필요합니다.
     유효 기간 만료 전에 같은 다이얼로그( 같은 Call-ID) 로 SUBSCRIBE를 주기적으로 생성해야 하며, 만일 Expires:0 로 설정되면 Unsubscribe를 요청하는 것입니다.

    SUBSRIBER는 app_IM.atlanta.com (IM 서버)가 21600 초 동안 등록 상태가 변할때마다 업데이트를 해줄 것을 요청하는 것입니다. 


  • 200 OK
    200 OK를 통해 Subsciber의 요청은 승인되었으며, 요청의 유효기간은  Expires:3600 입니다. 이는 Notifier가 3600초 동안만 Registration 상태 정보에 대해 통지하겠다는 의미입니다.

    SIP/2.0 200 OK
    Via: SIP/2.0/TCP app_IM.atlanta.com;branch=z9hG4bKnashds7 ;received=10.1.3.2
    From: sip:app_IM.atlanta.com ;tag=123aa9
    To: sip:server19@atlanta.com ;tag=xyzygg
    Call-ID: 9987@app_IM.atlanta.com
    CSeq: 9887 SUBSCRIBE
    Contact: sip:server19.atlanta.com
    Expires: 3600

 

마치며

SIP Subscriber 와 SIP Reffer메쏘드에 의해 요청된 이벤트에 대한 응답은 Notify로 이루어 집니다. 다음 장에서는 Notify에 대해 살펴보겠씁니다.





"다시쓰는 SIP의 이해" 연재의 다른 글  


2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 22편 Chapter 8. RTP의 이해


2015/07/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 21편 Chapter 7. 가끔 보는 SIP Method


2015/07/08 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 20편 Chapter 7. 가끔 보는 SIP Method


2015/05/20 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 19편 Chapter 7. 가끔 보는 SIP Method


2015/05/18 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 18편 Chapter 7. 가끔 보는 SIP Method


2015/05/07 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 17편 Chapter 6. SIP Method


2015/02/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 16편 Chapter 6. SIP Method


2015/02/23 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 15편 Chapter 6. SIP Method


2015/02/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 14편 Chapter 6. SIP Method

2015/01/30 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 13편 Chaper 5.SDP


2015/01/29 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 12편 Chapter 5. SDP


2015/01/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 11편 Chapter 5. SDP


2014/12/09 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 10편 Chapter 4. SIP Response


2014/12/04 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 9편 Chapter 3. SIP Method on RFC 3261


2014/12/03 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 8편 Chapter 3. SIP Method on RFC 3261


2014/12/02 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261


2014/11/26 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 6편 Chapter 2. SIP Overview


2014/11/21 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 5편 Chapter 2. SIP Overview


2014/11/19 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 4편 Chapter 1. VoIP의 이해 (3)


2014/11/11 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 3편 Chapter 1. VoIP의 이해 (2)


2014/11/05 - [SIP의 이해] - [연재] 다시쓰는 SIP의 이해 - 2편 Chapter 1. VoIP의 이해 (1)




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



저작자 표시 비영리
신고
Posted by 라인하트

댓글을 달아 주세요

  1. 윤준호 2015.10.22 16:41 신고  댓글주소  수정/삭제  댓글쓰기

    인터넷 검색하다 들어왔네요... 궁금한게 있어 글 남깁니다.

    제가 하나도 모른다는 전제하에 답변 부탁드립니다.

    질문1. SIP Session 중 직역하여 세션이라고하였는데 세션을 우리나라말로 표현 또는 엔지니어분들이 주로 사용하는 우리나라 표현이 있나요?

    질문2. 교환망에서의 Concurrent Call 의 의미?

    질문3. IMS System 또는 IP Telephony에서의 동시통화란?

    간단한 답변이라도 좋습니다....

  2. Favicon of http://www.nexpert.net BlogIcon 라인하트 2015.10.22 18:39 신고  댓글주소  수정/삭제  댓글쓰기

    질문 1의 답변 : 세션
    질문 2의 답변 : 동시호 (만일 하나의 IP PBX에서 3명이 통화중이면 Concurrent Call은 3개이구요. 한명이 전화 끝으면 2개)
    질문 3의 답변 : 동시호수는 IP PBX가 얼마나 많은 SIP 세션을 처리하는 가를 의미합니다. 사실 장비에서 한 통화를 3분 정도로 감안할 때 3분 동안 계속 호가 들어와도 부하가 심하지 않습니다. 가장 부하가 심한 것이 CPS (Call per Sec)입니다. 초당 처리할 수 있는 호의 수가 중요하죠.. 전화가 연결되고 나면 세션내의 트래픽은 BYE 요청이 있을 때까지 놀게 됩니다. 음성은 IP PBX나 IMS를 경유하지 않으니까요

  3. 윤준호 2015.10.23 10:20 신고  댓글주소  수정/삭제  댓글쓰기

    답변 감사드립니다. 여기에 질문드리기 좀 너무 쉬운 질문이라 민망하네요...

    마지막으로 한가지 더 질문드려도 될까요??

    1. '동시통화 200호(Concurrent Call :200)' 라고하면 '호(Call)'는 음성통화를 말하는 것으로 IMS or IP-PBX 에 등록된 200명이 동시에 음성통화가 가능하다는 것인가요??

    • Favicon of http://www.nexpert.net BlogIcon 라인하트 2015.10.26 16:09 신고  댓글주소  수정/삭제

      네.. 그렇죠..
      대부분의 IP PBX와 IMS는 호를 직접 처리하지 않고, 시그널링만 처리하므로 동시호 자체가 별로 의미가 없죠.. 게이트웨이나 기타 실제 RTP를 처리하는 장비들에게 의미가 있습니다.



티스토리 툴바