Chapter 5. SDP

SDP는 코덱협상과 같은 Capability Exchange를 수행하는 프로토콜로 SIP 뿐만 아니라 MGCP와 Megaco에서도 사용합니다. 기술적으로는 SIP와 SDP 프로토콜을 구분해서 사용하지만, SIP를 살펴볼 때 SDP는 자연스럽게 언급됩니다. SIP와 SDP는 어떤 관계에 있는 지 살펴보겠습니다. 


1.SDP의 개요
SDP는 Session Description Protocol 의 약어로 멀티미디어 세션 파라미터를 협상하는 프로토콜입니다. SDP는 RFC 2327을 개정한 RFC 4566으로 권고되었습니다. H.323에 대한 이해가 있으신 분들은 SDP가 H.323 프로토콜의 H.245와 비슷한 역할을 수행한다고 생각하면 됩니다.  


SIP를 요청과 응답 모델 (Request & Response Model)로 정의하였듯이 SDP는 제안과 수락 모델 (Offer & Answer Model) 로 정의합니다. SDP의 Offer / Answer Model로의 동작에 대해서는 RFC 3264 An Offer/Answer Model with the SDP 에서 자세히 설명되었습니다.    


SDP는 Capability를 협상하기 위해 기존의 호 처리 프로토콜을 이용합니다. 위의 그림에서 처럼 SDP는 SIP 메세지와 함께 전달됩니다. 
SIP INVITE 메세지에 SDP Offer가 포함되거나 200 OK 응답 메세지에 때 SDP Answer가 포함됩니다.  



2. SDP 메세지 분석
SDP는 멀티미디어를 전달하는 RTP 프로토콜에 대한 세부적인 내용을 협상합니다. SDP는 아래와 같이 SIP와 다른 메세지 포맷을 유지하지만, SIP와 같이 텍스트 기반으로 구성됩니다. 
 


v=0
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

각 라인의 의미는 다음과 같습니다.   

    • v=0 (필수)
      SDP 프로토콜의 버전을 표시합니다. SDP 버전은 0 입니다.

    • o=alice 2890844526 2890844526 IN IP4 atlanta.com (필수)
      SDP 메세지를 생성한 Owner/creator 를 표시합니다. 순서대로Username, Session-ID, Session Version, Network Type, Address Type, Unicast Address를 표시합니다.
       
    • s= (필수)
      세션 이름을 표시합니다. 

    • c=IN IP4 10.1.3.33 (옵션)
      순서대로Network Type, Address Type, Connection-Address를 나타내며 미디어의 주소를 정의합니다.  

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


SDP의 Capability Exchange를 주도하는 라인은 m= 와 a= 로 RTP가 사용할 코덱, IP 주소, 포트넘버가 자세히 명기됩니다. SDP 메세지를 생성하는 UA는 자신이 지원가능한 모든 코덱과 능력을 아래와 같이 명기합니다.    

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


    • 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=에 표시됩니다.
         
    • a= (미디어 속성)
      미디어 속성(attribute)을 정의합니다.  
         - a=rtpmap : payload type, encoding name/clock rate를 표시
         - a=ptime   : paket time으로 미디어 패킷 한 개가 포함한 시간 정보로 ms로 표시 (보통 20ms)
         - a=fmtp     : 미디어 포맷에 대한 파미미터를 정의   

    • a= (미디어의 방향)
      미디어 속성 뿐만 아니라 미디어 방향도 표시합니다. 미디어의 방향은 아래와 같이 4가지로 나타냅니다.  
          - a=sendrecv : 단말은 미디어를 송신 및 수신할 수 있음
          - a=recvonly : 단말은 수신만을 할 수 있으며 송신하지 않음
          - a=sendonly : 단말은 송신만을 할 수 있으며 수신하지 않음
          - a=inactive : 단말은 송신 및 수신을 할 수 없음 (Hold 버튼을 누를 경우)

      별도의 업급이 없을 경우에는 a=sendrecv로 설정되었다고 가정합니다. 미디어의 방향은 다양한 부가서비스 구현 시 유용합니다.  
        

    • a= (DTMF 협상)
      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가지를 송수신함)


3. RFC 3264의 기본 SDP 협상 (Offer / Answer Model)
RFC 3264 An Offer/ Answer Model Session Description Protocol 권고안에 나와 있는 10.1 Basic Exchange 부분을 살펴보면서 Offer / Answer 모델의 동작 방식을 살펴보겠습니다. 
  

    • 엘리스의 “Offer”
      엘리스는 한 개의 음성 스트림과 두 개의 영상 스트림을 제안합니다.

      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

      SDP의 Owner이자 Creator인 엘리스는 음성 스트림은 G.711 ulaw 코덱과 49170 UDP 포트를 사용하며, 영상 스트림은 H.261 코덱과 51372 UDP 포트를, 또 하나의 영상 스트림은 MPEG 코덱과 53000 UDP 포트를 사용한다고 제안합니다.
         
        
    • 밥의 “Answer” 

      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

      밥은 음성 스트림에 대해 G.711ulaw 코덱과 49920 UDP 포트를 사용하고, 첫번째 영상에 대한 미디어 속성(a=) 정의를 포함하지 않고, 두 번째 영상 스트림에 대해서만 미디어 속성을 포함하고 있습니다. 일반적으로 미디어 속성(a=)를 포함하지 않으면 미디어 스트림이 개방되지 않습니다.   


    • 밥의 협상 변경 요청 “Offer”
      밥은 Answer 후에 협상 내용의 변경을 요청합니다.  

      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

      밥은 음성 스트림에 대한 UDP 포트 넘버를 49920에서 65422로 변경하는 것과 DTMF 수신을 위한 (receive-only) 방법을 추가하였습니다. 일반적으로 DTMF 이벤트 처리를 위한 RTP Payload Type 110 입니다.


    • 앨리스의 “Answer”
      앨리스는 밥의 제안을 승인하고, 다음과 같이 응답합니다.

      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

      밥의 요청을 모두 수락합니다. 


4. RFC 3264의 One of N Codec Selection
IP Phone과 Gateway는 음성이나 영상 압축을 위해 DSP (Digital Signal DSP)라는 칩을 사용합니다. DSP는 다수의 코덱을 지원하지만, 한 번에 하나의 코덱만을 지원합니다. SDP Offer에 다수의 코덱을 전송하더라도 Answer에서는 하나의 코덱만을 선택할 수 있을 뿐입니다. 다수 코덱을 제안할 경우에 선택하는 방식에 대해 살펴보겠습니다.  

    • 앨리스의 “Offer”
      Offer의 Creator인 엘리스는 음성 스트림 하나를 제안하면서 자신의 DSP가 지원하는 G.711ulaw, G.723, G.729 코덱을 나열합니다. G.711ulaw가 가장 우선 순위가 높으며 코덱 협상 완료전까지는 미디어를 받아 들일 수 없으므로 미디어의 방향을 "a=inactive"로 합니다. 

      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


    • 밥의 “Answer”
      밥은 자신의 DSP가 G.711ulaw 와 G.723 코덱만을 지원하며, G.711ulaw를 우선적으로 선택합니다.    

      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


    • 앨리스의 "Offer"
      앨리스는 밥이 제안한 두 개의 코덱 모두를 지원할 수 있지만 G.723코덱을 선택하면서 "a=sendrecv" 로 양방향 통화 채널을 활성화 합니다. 일반적으로 우선순위가 높은 G.711ulaw를 선택하지만, 예제에서는 G.723을 선택하는 것을 가정합니다. 

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


    • 밥의 "Answer"
      밥은 앨리스가 제안한 G.711 코덱을 받아 들이고 a=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

처음 inactive 상태를 sendrecv로 전환하기 위해 4번에 걸친 Offer 와 Answer를 교환합니다. 일반적으로는 처음부터 a=sendrecv로 교환하고, 처음 제시되는 코덱이 우선순위가 높으므로 선택됩니다. 위의 과정은 Offer / Answer Model을 기반으로 설명드리는 것입니다만, 실제로는 INVITE with SDP로 제안이 되면 200 OK with SDP 또는 180 Ringing with SDP로 2 단계로 마무리됩니다. 



마치며
실제 SIP 패킷을 캡쳐해 보면 INVITE with SDP 뿐만 아니라 INVITE without SDP 메세지도 보입니다. SIP 표준은 두 경우를 모두 허용하고 있으므로 각각의 상황에 따른 SDP 협상 방식을 다음글에서 살펴보겠습니다. 




여담

2015년 새해에도 지치않는 블로깅을 다짐합니다. 쓰고 싶은 글은 많은 데 시간이 부족합니다.  





"다시쓰는 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 라인하트
TAG ,

댓글을 달아 주세요

  1. 방랑자 2015.01.05 11:16 신고  댓글주소  수정/삭제  댓글쓰기

    글 잘봤습니다..ㅎㅎ

    개인적으로 궁금한게 있어서 질문하나 남기는데요..

    요즘 conference call에 대해 조사하고 있는데용...

    conference call을 구분하는 기준을 SIP INVITE 메시지 하나로 구분이 가능한건가요 ..?

    아니면 별도의 구분자가 있는지 궁금합니다..


  2. Favicon of http://www.fourd.kr BlogIcon Jinsu Kim 2015.01.08 09:07 신고  댓글주소  수정/삭제  댓글쓰기

    감사합니다.

    SDP에 대해서 공부하고 있었는데.. 너무너무 잘 설명을 해주셨네요.

    즐겨 찾기 해놔야겠어요. 감사합니다.

  3. Favicon of http://pchero21.com BlogIcon 탱이 2015.01.22 18:26 신고  댓글주소  수정/삭제  댓글쓰기

    항상 잘보고 있습니다. :)
    정말 쉽고 이해가 잘되네요.
    아래 사이트에 퍼가기 했습니다.

    http://wiki.pchero21.com/wiki/SIP_SDP

  4. DoubleSH 2015.02.06 11:50 신고  댓글주소  수정/삭제  댓글쓰기

    Cisco GW의 경우 아래와 같은 SDP 를 주는 것 같은데 어떤 의미인지 모르겠습니다.
    이렇게 SDP를 주고 DTMF를 SIP INFO 메세지로 주던데.. 맞는뜻인가요?
    제가 다루는 IP PBX가 inband DTMF 만 지원을 하는데 SIP INFO로 와서 인식이 안됩니다..

    어떻게 해결해야할까요

    v=0
    o=- 145455267 0 IN IP4 222.122.254.84
    s=Cisco SDP 0
    c=IN IP4 222.122.254.84
    t=0 0
    m=audio 18994 RTP/AVP 0 8 18 4 101
    a=rtpmap:101 X-NSE/8000
    a=fmtp:101 200-202
    a=X-sqn:0
    a=X-cap: 1 audio RTP/AVP 101
    a=X-cpar: a=rtpmap:101 X-NSE/8000
    a=X-cpar: a=fmtp:101 200-202
    a=X-cap: 2 image udptl t38

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

      inband DTMF는 음성처럼 톤에 대한 주파수만을 전달합니다. 만일 out-of-band로 협상되지 않을 경우에 기본 DTMF로 사용됩니다. 여기에서는 RFC 2833으로 협상을 하도록 하네요

      a=X-는 시스코장비만이 사용하는 제조사의 속성으로 다른 회사의 장비들은 무시하도록 만들면 됩니다.

      Gateway에서는 DTMF에 대한 세세한 설정이 가능하므로 확인해 보시구요 SIP INFO를 사용하지 않도록 설정하시면 어떨까요?

      가끔씩 두 가지가 같이 오는 버그가 있을 수 있곤 했습니다.

    • 바른생활 2015.02.14 22:11 신고  댓글주소  수정/삭제

      라인하트님 말씀대로 위 Invite SDP 상에서는 DTMF가 RFC2833으로 Nego 하겠다고 되어있네요. Cisco GW가 구형 AS5400 이면 DTMF를 두 번씩 (INFO 와 RFC2833) 보내는 버그가 있긴 합니다.

    • DoubleSH 2015.02.16 16:15 신고  댓글주소  수정/삭제

      a=rtpmap:101 X-NSE/8000 :: 이부분이 RFC2833 을 지칭하나요?
      저런식으로 보내고도 INFO 를 줬어요... 버그인건가 이게..

    • 바른생활 2015.02.16 17:01 신고  댓글주소  수정/삭제

      패킷을 가지고 계시다면 wireshark에서 filter에 rtpevent 입력하셔서 rfc2833 digit도 같이 들어오는지 확인 바랍니다. INFO는 SIP Proxy ip에서 보내올 것이고 RFC2833은 CIsco GW ip에서 들어옵니다. 두 가지 방법으로 동시에 보낸다는 건 어찌됐든 Bug입니다.

  5. DoubleSH 2015.02.10 17:47 신고  댓글주소  수정/삭제  댓글쓰기

    위에 써놓은 SDP 에는 RFC2833 이 없는거죠. telephone-events/8000 요게 없으니...

    한참 고민해봤는데 역시... KT가 참 당황스러운게 맞는 것 같네요.
    말씀하신것처럼 협상이 되지 않았음에도 불구하고 SIP INFO 를 던져주더라구요.
    제너 SIPproxy 밑에 TG가 총 2개인데 Cisco와 Newgrid 모두 DTMF 협상을 하지 않고
    무작정 INFO로 던져버려서 연동 때려치고 SBC 넣으라고 했습니다.

    아무리 생각해봐도 KT쪽 TG에서 RFC2833 으로 변환해서 보내주는게 맞는데,
    KT쪽 사람들을 설득할 자신이 없네요. 잘 알지도 못하는데다가
    워낙에 사용자가 맞춰라~ 라는 입장인듯 하니...

    제가 미국산 상용 올인원 솔루션 다루다보니 우리쪽을 수정하진 못하구요.ㅎㅎ
    개발자는 아니고, 엔지니어입니다..

    SIP는 참 좋은건데.. KT나 LG는 왜 지맘대로 노는걸까요..휴...

    • 바른생활 2015.02.14 21:58 신고  댓글주소  수정/삭제

      말씀하신대로 TG를 Cisco와 NewGrid를 경유했다면 IP to PSTN 또는 PSTN to IP Call로 보여지는데 Invite SDP에 DTMF 설정값이 없다면 제너 SIP Proxy는 TG에게 DTMF INFO 설정값을 보내줍니다. 그래서 TG는 SIP Proxy의 명령에 따라 PSTN에서 올라오는 DTMF는 INFO로 변환하여 SIP Proxy에게 보내줍니다.

  6. 구사면 황태자 2015.02.12 17:37 신고  댓글주소  수정/삭제  댓글쓰기

    항상 잘보고 있습니다. 사실어렵고?하지만 꾸준하게 몇번씩 일어보고 합니다.

    현재 단말에서 사용하는 전화기가 ars, 전국대표번호 15xx,16xx전화를 했을시 정상적으로

    호가터지면서 미디어까지를 열리지만, dtmf 먹히지 않는 현상이 발생을 합니다.

    v=0
    o=NEXCOS 48933373 1 IN IP4 1.255.17.118
    s=Nable_NTS_G3
    c=IN IP4 1.255.17.118
    t=0 0
    m=audio 23150 RTP/AVP 8 101
    a=rtpmap:8 PCMA/8000
    a=rtpmap:101 X-NSE/8000
    a=fmtp:101 200-202
    a=X-cap: 1 audio RTP/AVP 101
    a=X-cap: 2 image udptl t38
    a=sendrecv
    a=X-sqn:0
    a=X-cpar: a=rtpmap:101 X-NSE/8000
    a=X-cpar: a=fmtp:101 200-202

    위 메시지 상으로는 dtmf inabnd 인데,(통상적인터넷전화) inband 디지터를 눌르면, 혹시 이것을

    와이어샤크에서 payload 에서 디지터를 몇번으로 눌렀는지...

    아니면 발신/착시/ 어떤부분에서 디지터를 수집을 못한지 확인하는 방법도 있을까요?

    inbnad 는 숫자상으로 보이지가 않기때문에, 정확하게 원인을 찾기가 어렵네요...ㅠㅠ

    확시 sip paylode상에서 dtmf 수집을 할수있는 방법이 있는지 문의쫌드릴깨요....

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

      게이트웨이에서 디버그가 가능할 듯 생각됩니다.
      와이어 샤크에서는 g.711의 경우 수집된 패킷을 바탕으로 재생 가능하므로 디짓을 누르는 소리를 들을 수 있을 것입니다.

      와이어샤크 써본지도 오래군요.. 쩝..

    • DoubleSH 2015.02.13 11:06 신고  댓글주소  수정/삭제

      바로위에 저랑 비슷한 패킷을 받으셨네요ㅎㅎ
      SIP INFO 메시지로 오는지 확인하시고
      만약 inband 로 전달이 되었다면
      캡쳐된 rtp stream 을 재생해서 들어볼 수 있습니다

  7. 구사면 황태자 2015.02.16 11:19 신고  댓글주소  수정/삭제  댓글쓰기

    감사합니다.

    게이트웨이면, 어떻게 보면, 착신자측으로 착신자가 debug 쫌 불가능한편이고,

    발신자측에서 dtmf 타입의 inband 를 지디터를 수집을해야, 어떻게 보내고, 몇번을 눌렀지만, ars나 전국대표번호에서 dtmf가 맞지않아 수집이 않된다는 명확한 이유를 알수 있을것 같은데....

    rtp stream 밍에서는 분명 디지터가 있다는것은 확인가능하지만, 이게 몇번을 눌렀는지 확인이 불가능합니다.

    스마트폰 앱중에는 dtmf 음을 녹음하면, 숫자로 변환하는 프로그램이 있는것은 보았습니다.

    혹시 rtp stream 밍을 가지고 숫자로 변화하는 방법을 알수는 없을까요...

    사실 알칼텍 pbx 랑 ars 문제가 있어 해결할려고 하고 있습니다. 고수님들 방법을 가르쳐 주세요^^

    • DoubleSH 2015.02.16 15:20 신고  댓글주소  수정/삭제

      http://www.pas-products.de/dtmf_tone_decoder.html
      이런 툴을 이용해서 분석하셔야 되는 내용 같네요
      수집된 rtp stream을 Wireshark로 Play 하시면서
      Cooledit 같은 사운드툴로 스테레오믹스를 녹음하세요
      그걸 wav 파일로 저장한 뒤 분석하시면 될 듯합니다.

  8. 구산면황태자 2015.02.16 16:44 신고  댓글주소  수정/삭제  댓글쓰기

    감사합니다......

    rtp paylode 에 골든 wav 저장했어,, 확인하니 가능하네요.. 감사합니다....

    이젠 다 죽었어^^ ㅋㅋ 의문점은 계속 문의 드리겠습니다 ㅎ



티스토리 툴바