삼성 소프트웨어 멤버십 2012 상반기 신입회원 모집!

2011/12/16 17:09
삼성 소프트웨어 멤버십에서 2012년 상반기 신입회원 모집한다고 합니다! 전공 불문하고 IT 분야에 열정을 가지고있는 대학생, 대학원생을 신입회원으로 모집하고 있네요!! 회원활동 후 수료시 삼성전자 연구원으로 입사 할 수 있는 특전이 있다고 하는데, 도전해 볼만 하지 않나요?!



[삼성전자 소프트웨어멤버십 회원 선발 공고]

삼성소프트웨어멤버십에서 2012년도 상반기 신입회원을 선발 합니다.

1. 모집 요강
  □ 모집대상 : IT분야 연구개발에 ‘재능’과 ‘열정’있는 국내 정규 4년제 대학(원)생
  □ 해당지역 : 서울, 수원, 대전, 대구, 부산, 광주, 전주
  □ 접수방법 : 온라인 접수( www.secmem.org )
  □ 모집일정
    * 서류접수 : 2011.12.14 ~ 12.28 16:00 까지
    * 기술면접 : 2012. 1.10 ~ 2012. 1.13 예정 (추후 홈페이지 공지)
    * 합격자 발표 : 2012년 1월 말 예정

2. 지원 분야
  □ 기   술 : Software , Hardware, SoC, Robotics, Etc.
  □ Contents : Mobile Application, Mobile Widget, Mobile/Web Based Contents, Etc.
  □ UX : Information Architecture, User Research, UX Strategy, Auditory UI, 인간공학, Etc.
    * Contents, UX 분야는 서울/수원 지역에 한해 소수 선발 함
    * Contents 분야는 OCEAN(삼성 앱 개발센터)에서 활동 함
    * UX분야 AUI 신설 : Sound Design, Voice UI 등 Auditory UI 관련 전공자 신규 모집
    * 상기 관련 분야에 대해 본인이 직접(공동) 개발한 작품 시연 및 발표

3. 지원 자격
  □ IT 연구개발에 재능과 열정이 있는 자
  □ 정규 4년제 대학(원)생 (1~4학년, 석사)
  □ 전공 학과 불문
  □ 국내외 공모전 수상자 우대
  □ 대학 졸업 전 1년 이상 회원 활동이 가능한 자(대학 졸업과 동시에 수료)
    * Contents 분야는 1년 6개월 이상
    * UX 분야 학사 재학 중인 회원은 2년 이상, 석사 재학 중인 회원은 1년 이상

4. 선발 인원 : 약 ○○○명

5. 회원 혜택
  □ 연구개발 활동 및 환경 지원
  □ 회원 활동 수료 시 삼성전자 연구개발직 입사특전 부여
    ※ 보다 자세한 사항은 홈페이지( www.secmem.org ) 및 각 학교 취업경력개발센터와
       IT관련 학과 사무실에 비치되어 있는 홍보책자를 참조하세요.


[삼성소프트웨어멤버십은?]
삼성전자에서 대학생을 지원하는 IT 인재양성 기관이며,
IT분야에 열정과 재능을 가진 학생들의 연구개발 환경을 제공 합니다.
1년 이상의 활동과 평가를 거쳐 프로그램 수료 시 삼성전자 입사특전이 주어집니다.

▷▶▷삼성소프트웨어멤버십 홈페이지 바로가기
▷▶▷삼성소프트웨어멤버십 블로그 바로가기
▷▶▷삼성소프트웨어멤버십 트위터 바로가기
▷▶▷삼성소프트웨어멤버십 페이스북 바로가기






저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( Review ) 2012년 상반기 신입회원, SSM, 삼성 소프트웨어 멤버십, 삼성전자, 소멤, 신입회원 모집

안드로이드 GPS 상태체크

2011/12/04 18:39

지도를 비롯 위치정보를 이용한 서비스 개발시 유용한 팁.
 
GPS 연결여부를 체크 : 미연결시 연결설정 화면으로 이동 하겠는가? 다이얼로그 출력. 

다이얼로그로 부터 '수락' 입력받을 경우 GPS 설정 화면으로 이동.

 아래는 그 기능의 예제코드


@Override
     public void onCreate(Bundle savedInstanceState) {
         ...
         String context = Context.LOCATION_SERVICE;
         locationManager = (LocationManager)getSystemService(context);
         if(!locationManager.isProviderEnabled(LocationManager.GPS_PROVIDER)) {
            alertCheckGPS();
      }
         ...
     }
 
    private void alertCheckGPS() {
         AlertDialog.Builder builder = new AlertDialog.Builder(this);
         builder.setMessage("Your GPS is disabled! Would you like to enable it?")
                 .setCancelable(false)
                 .setPositiveButton("Enable GPS",
                         new DialogInterface.OnClickListener() {
                             public void onClick(DialogInterface dialog, int id) {
                                 moveConfigGPS();
                             }
                     })
                 .setNegativeButton("Do nothing",
                         new DialogInterface.OnClickListener() {
                             public void onClick(DialogInterface dialog, int id) {
                                 dialog.cancel();
                             }
                     });
         AlertDialog alert = builder.create();
         alert.show();
     }
 
    // GPS 설정화면으로 이동
     private void moveConfigGPS() {
         Intent gpsOptionsIntent = new Intent(android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS);
         startActivity(gpsOptionsIntent);
     }
 
저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 Android Dev Note/센서 GPS, GPS설정 이동, GPS세팅, 상태체크, 설정, 안드로이드

자료조사(8) - RTP (real Time Procotol)

2011/11/27 20:05

RTP(Real Time Protocol)

>> RFC 3550


☛ 개요

RTP는 오디오, 비디오 및 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 네트웍을 이용해서 전송하는 응용 서비스에 알맞은 단말-대-단말 네트웍 전송 기능을 제공한다.  RTP는 자원 예약을 수행하지 않으며, 따라서 적시 전달, 순차 전달과 같은 서비스 품질도 보장하지 않는다. RTP 데이터 전송 기능은 제어 프로토콜에 의해 확장되는데, RTCP라 불리우는 이 제어 프로토콜은 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 매체 식별 기능을 제공한다. RTP와 RTCP는 하위의 전송 및 네트웍 계층에 무관하게 설계되었다.
   RTP는 별개의 독립 계층으로 구현되기 보다는 특정 응용에서 요구되는 정보를 제공하여 프로토콜의 처리가 응용의 처리 과정으로 통합될 수 있도록 설계되었다. 따라서 기존의 프로토콜들과는 달리 RTP는 응용의 필요에 따라 헤더를 변경하거나 추가하여 응용에 맞는 프로토콜이 될 수 있도록 하는 일종의 맞춤형 프로토콜이다. 이 문서에서는 RTP를 이용할 수 있을 것으로 추정되는 모든 응용들이 공통적으로 필요로 할 기능들 만을 명시하고 있다. 따라서, 특정 응용 서비스에 필요한 RTP를 구현하기 위해서는 이 문서 이외에 RTP 페이로드의 종류와 형식을 정의하는 프로파일 문서(Profile Specification)와 페이로드의 전송 방법을 정의한 페이로드 형식 문서(Payload Format Specification)가 필요하다.

☛ 특징
- UDP상에서 실행
  UDP는 TCP에 비해 신뢰성이 낮은 반면, 더 빠르게 데이터를 전달함. 이러한 UDP의 특성을 이용하여 RTP가 등장하였다. 그래서, RTP는 그 자체로 QoS 보장이나 신뢰성을 제공하지 못한다.(RTCP를 통해 QoS를 보장)
- 송신자는 데이터 단위를 RTP 패킷으로 캡슐화한 후 그 패킷을 UDP 세그먼트로 캡슐화해서 IP에게 넘겨준다.
- RTP 세션 다중화
   효과적인 프로토콜 처리를 위해서 다중화 점의 수는 최소화되어져야 한다. RTP의 경우에 다중화는 목적지 전송 주소에 의해 수행된다.. 예를 들어 오디오와 비디오로 이루어지는 회의에서 각 매체는 자신만의 목적지 전송 주소를 가지는 독자의 RTP 세션으로 전송되어야 한다.
- 수신자는 UDP 세그먼트로부터 RTP 패킷을 추출한 후에 RTP 패킷으로부터 데이터 단위를 추출해서 디코딩 및 렌더링을 위해 미디어 플레이어에게 전달한다.
- RTP는 다른 3계층, 4계층 프로토콜과도 같이 사용이 가능하며,
  하위 프로토콜에 별로 의존하지 않음.

☛ RTP 패킷헤더 필드
 


-부하타입, 순서번호, 타임스탬프, 근원지식별자 필드가 있다.
1. 페이로드타입필드의 길이는 7비트이다. 오디오 스트림의 경우, 사용되는 오디오 인코딩타입을 타나내기 위해 사용한다. 만일 송신자가 세션 중간에 인코딩을 변경하면, 송신자는 수신자에게 페이로드 타입 필드를 사용해서 이 변경사항을 알려준다. 예컨대, 송신자는 오디오 품질을 향상시키거나 RTP스트림 비트율을 감소시키기 위해 인코딩을 변경하고자 할 수도 있다.
표 RTP에서 제공하는 오디오 페이로드 타입

 

페이로드 타입 번호
오디오 포맷
샘플링 비율
비율
0
PCM μ-law
8 kHz
64 kbps
1
1016
8 kHz
4.8 kbps
3
GSM
8 kHz
13 kbps
7
LPC
8 kHz
2.4 kbps
9
G.722
16 kHz
48-64 kbps
14
MPEG 오디오
90 kHz
-
15
G.728
8 kHz
16 kbps
   비디오 스트림의 경우에 페이로드 타입은 비디오 인코딩 타입을 나타내기 위해 사용된다. 이 때도 송신자    는 세션 중에 비디오 인코딩을 변경할 수 있다.
표 RTP에서 제공하는 비디오 페이로드 타입
페이로드 타입 번호
비디오 포맷
26
Motion JPEG
31
H.261
32
MPEG 1 비디오
33
MPEG 2 비디오
2. 순서번호필드의 길이는 16비트이다. 순서번호는 전송되는 RTP 패킷마다 하나씩 증가하며, 패킷 손실을 감지하고 패킷 순서를 회복하기 위해 수신자가 사용할 수 있다. 예를 들어, 만일 애플리케이션의 수신자가 순서번호 86과 89사이에 공백이 있는 RTP패킷 스트림을 수신하면, 수신자는 패킷 87과 88을 잃어버렸음을 알게 된다. 그러면 수신자는 손실된 데이터를 막기l 위해 시도할 수 있다.
3. 타임스탬프 필드의 길이는 32비트 이다. 이 필드는 RTP 데이터 패킷의 첫 번째 바이트의 샘플링 시점을 나타낸다. 수신자는 네트워크에 의해 만들어진 패킷 지터를 제거하고 수신자가 동기적인 재생을 가능하도록 타임스탬프를 사용할 수도 있다. 타임스탬프는 송신자 샘플링 클록으로부터 생성된다. 예를 들어, 오디오의 경우에는 타임스탬프의 클록은 각 샘플링 주기마다 하나 증가한다. 만일 오디오 애플리케이션이 160개의 인코딩된 샘플로 구성된 chunk를 생성한다면, 근원지가 활성일 때 타임스탬프는 각 RTP 세션마다 160씩 증가한다. 타임스탬프 클록은 근원지가 비활성일 때 조차도 일정 비율로 계속 증가한다.

 
그림 RTP layer

4. 동기근원지 식별자(SSRC): SSRC 필드의 길이는 32비트 이다. 이 필드는 RTP 스트림의 근원지를 식별한다, 대개, RTP 세션의 각 스트림은 상이한 SSRC를 갖는다. SSRC는 송신자의 IP 주소 대신에 새로운 스트림이 시작될 때 근원지에서 임의 할당한 숫자이다. 두 스트림이 동일한 SSRC를 할당받을 확률은 매우 작다. 만일 이런 일이 발생하면 두 근원지는 새로운 SSRC 값을 선택한다.



RTP로 소프트웨어 애플리케이션 개발방법
1. 애플리케이션 개발자가 RTP 캡슐화를 수행하는 송신자의 코드와 RTP 패킷을 풀어보는 수신자의 코드를 직접 작성해서 RTP를 추가하는 것.
2. 캡슐화 및 역캡슐화를 수행하는 기존 RTP 라이브러리와 자바 클래스들을 애플리케이션 개발자가 사용하는 것이다.

   예를들어, 음성을 전달하기 위해 RTP를 사용하는 것에 대해 생각해보자. 음성 데이터는 64kpbs의 PCM으로 인코딩된다고 가정하자. 또한 애플리케이션이 인코딩된 데이터를 20밀리초의 데이터 단위(즉, 한 데이터 단위에 160바이트)로 모은다고 가정하자. 송신자는 오디오 데이터의 각 데이터 단위 앞에 오디오 인코딩 종류, 순서번호, 타임스탬프 등을 가진 RTP 헤더를 덧붙인다. RTP 헤더는 보통 12바이트이다. 오디오 데이터 단위에 RTP 헤더를 덧붙여서 RTP 패킷을 구성한 후, UDP 소켓 인터페이스로 전송한다. 수신자의 애플리케이션은 소켓 인터페이스에서 RTP 패킷을 수신한 후, RTP 패킷에서 오디오 데이터 단위를 추출하고, 추출된 RTP 패킷의 헤더 필드를 살핀 후에 오디오 데이터 단위를 적절히 디코드 및 재생한다.
        페이로드 타입이나 순서번호, 타임스탬프를 제공하는 개인 기법 대신에, 애플리케이션이 RTP를 사용하면 훨씬 쉽게 다른 네트워킹 멀티미디어 애플리케이션을 통합할 수 있다. 예를 들어. 만일 두 회사에서 인터넷 폰 애플리케이션을 개발할 때 RTP를 사용한다면, 한 회사의 인터넷 폰 제품을 사용하는 사용자가 다른 회사의 인터넷 폰 제품을 사용하는 사용자와 통신 가능할 거라고 기대할 수 있다.
        RTP 자체가 시간에 맞춘 데이터 전달을 보장하거나 다른 서비스 품질 보장을 제공하는 기법을 지원하지 않는다는 것이다. 즉, RTP는 패킷 전달을 보장하거나 패킷 전달 순서를 보장하지 않는다. 실제로 RTP 캡슐화는 종단 시스템에서만 된다. 라우터는 RTP 패킷을 전달하는 IP 데이터그램과 RTP 패킷을 전달하지 않는 IP 데이터 그램을 구분하지 않는다.
        RTP는 각각의 근원지(예:마이크로폰, 카메라)에게 자신만의 RTP 패킷 스트림을 생성할 수 있도록 허용한다. 예를 들어, 두명의 참여자가 있는 화상회의의 경우, 두 개의 오디오 송신용 스트림(각 방향으로 하나의 스트림)과 두 개의 비디오 송신용 스트림(각 방향으로 하나의 스트림)등 총 네 개의 RTP 스트림이 만들어질 수 있다. 그러나 MPEG1이나 MPEG2 같은 대다수 많이 사용되는 인코딩 기법은 인코딩 과정에서 오디오와 비디오를 하나의 단일 스트림으로 합친다. 인코더에서 오디오와 비디오를 합치면 각 방향으로 하나의 스트림만 생성된다.
        RTP 패킷은 유니캐스트 애플리케이션에 한정되지 않는다. RTP 패킷은 일대다 EH는 다대다 멀티캐스트 트리로 전송될 수도 있다. 다대다 멀티캐스트 세션에 대해, 세션의 모든 송신자와 근원지는 RTP 스트림을 전송하는 데 있어서 일반적으로 동일한 멀티캐스트 그룹을 사용한다. 화상회의 애플리케이션에서 다수의 송신자들에 의해 전송되는 오디오, 비디오 스트림과 같이 함께 포함된 RTP 멀티캐스트 스트림들은 하나의 RTP 세션에 속하게 된다.
저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 수행 프로젝트 )/참여자주도형 정보공유 시스템 [2011.12~2012.02] RTP, rtp 구현, 실시간 스트리밍, 영상 스트리밍, 음성 스트리밍, 음성 전송

리눅스 압축 명령/방법/종류

2011/11/27 15:57

리눅스에서 많이 사용되는 압축파일로는 tar, gz, bz2, zip 등이 있다. 이들 각각은 나름대로의 고유한 압축방식을 가지고 있으며, 압축해제하는 방법 또한 다양하다.

그래픽 유저 인터페이스(GUI) 모드에서 리눅스를 사용하는 사람이라면 간단히 더블클릭으로 압축 관리 프로그램을 실행하여 압축 및 해제를 할 수 있지만, 텍스트 모드를 사용하는 사용자라면 이들 압축파일을 사용할 수 있는 명령들을 숙지하고 있을 필요가 있다.

오늘은 이러한 압축 파일들을 생성하고 압축해제하는 방법에 대해 알아보도록 하자.

 

 

 tar

tar은 엄밀히 말해서 압축방식은 아니다. 

일종의 묶음 파일로 이해하는 것이 좋을듯.

이 tar과 gzip을 같이 사용하는 경우 tar.gz (또는 tgz)라는 확장자를 사용함.

tar 로 묶고 푸는 방법은 다음과 같음.

 


- 압축 생성

  # tar cvf temp.tar temp/

    ; temp 디렉터리를 temp.tar 이라는 파일로 묶는다.

     (temp 디렉터리와 그 이하의 모든 파일 및 디렉터리)

 


- 압축 해제

  # tar xvf temp.tar

 

 

 

※ 옵션설명

  -c : (create) 압축 파일을 생성한다.

  -x : (extract) 압축 파일을 해제한다.

  -v : 압축파일이 생성(해제)되는 과정을 보여준다.

  -f : 압축파일 또는 Archive 장치를 사용한다.

※ tar 명령에서 옵션 앞에 붙는 "-" 기호는 붙여도 되고, 붙이지 않아도 된다.

※ gzip과 같이 압축된 파일의 경우 (tar.gz 또는 tgz) -z 옵션을 사용하여 한번에 처리할 수 있다.

 

 

 

gzip (tar.gz 또는 tgz)

 

앞서 보았던 tar로 묶여진 파일을 다시 압축하는 방법으로 많이 사용되는 압축형태이다. gzip 명령으로 압축하고 gunzip 명령으로 압축을 해제한다.

 

- 압축 생성

  # gzip temp.tar

  위 명령을 사용하면 temp.tar.gz 이라는 파일이 생성된다.

 

- 압축 해제

  # gunzip temp.tar.gz

  # gzip -d temp.tar.gz

 

※ gzip 명령으로 압축을 해제하면, 그 전단계인 tar 묶음 형태로 압축이 풀리게 되므로 tar 명령으로 다시한번 묶음을 해제해야 한다.

최근에는 이러한 번거로운 과정을 줄이기 위해 tar 명령에서 tar 묶음 및 gzip 압축까지 모두 해제할 수 있는 옵션(-z)을 제공한다.

  # tar xzvf temp.tar.gz

 
 

 bzip2 (bz2)

gzip과 같이 최근 많이 사용되는 압축 형태로 tar.bz2 라는 확장자로 다루어진다.

역시 tar 묶음에 다시 압축을 가하는 형태이며, bzip2 전용 명령도 있으며, tar에서도 한번에 사용할 수 있는 옵션(-j)이 있다.

 

- 압축 생성

  # bzip2 -zkv temp.tar

 

- 압축 해제

  # bunzip2 temp.tar.bz2

 

※ bzip2 명령으로 압축을 해제하면, tar 명령을 다시 사용해야 하므로, 최근에는 tar에서 바로 해제하는 경우가 많다.

  # tar xjvf temp.tar.bz2



 zip

zip 파일은 Windows에서도 많이 사용되는 압축 형태로, 리눅스에서도 동일하게 사용할 수 있다.

 

- 압축 생성

  # zip -v temp.zip temp/*

    ; temp 디렉터리 이하의 모든 파일을 zip으로 압축한다.

 

- 압축 해제

  # unzip temp.zip

 

 

[Tip! Tip! Tip!]

리눅스에서는 Windows와 달리, 파일의 확장자에 큰 의미를 두지 않으므로, 압축파일 생성시 이름 및 확장자를 임의로 지정할 수도 있다.

그러나 사용자 간의 커뮤니케이션 및 인식의 통일을 위해 가급적 지정된 확장자를 사용하는 것이 좋다.

즉 압축파일 생성시 아래와 같은 일련의 규칙들을 준수해 줌으로써 쉽게 인식하고 혼란을 막아, 다른 사용자의 이해를 높일 수 있다.

 

[압축파일 확장자 명명 규칙]

- tar압축 : *.tar

- tar/gzip 압축 : *.tar.gz / *.tgz

- tar/bzip2 압축 : *.tar.bz2

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 Software Dev Note/리눅스 운영 & 프로그래밍 bzip2, gzip, Linux, tar, ZIP, 리눅스, 명령, 압축, 종류

우분투 JDK 설치하기

2011/11/25 17:30
# JDK 설치하기
  우분투에 JDK 설치 관련으로 인터넷을 뒤져보면 apt-get (sun-java...) 이나 시냅틱 패키지 관리자 ( openjdk-... )로 설치가 된다고들 
  하던데... 난 안되더라~ " ...설치할 수 있는 후보가 없습니다." 라는 친절한 응답만 받았다. 그리고 rpm, deb 패키지들도 뭔 의존성이 
  어쩌고 저쩌고...

  에휴~ 그래서 그냥 tar 패키지 받아서 직접 경로에 설치해버렸다. 아래 주소에 가면 x86용 tar 패키지를 받을 수 있을 것이다.

  http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html

@ 설치 환경

  - Ubuntu linux 10.04 LTS 2.6.32.34-generic
  - jdk-7-linux-i586.tar.gz

@ 설치 

$ sudo mkdir /usr/local/java                                                  # java 디렉토리 생성은 선택사항.
$ cd /usr/local/java
$ sudo cp ~/Downlaod/jdk-7-linux-i586.tar.gz .
$ sudo tar zxf jdk-7-linux-i586.tar.gz                                        # 압축이 풀리면 아마 jdk1.7.0 이 생성될 것이다.
                                                                                     
@ 설정

 에디터로 자신의 홈디렉토리의 .bashrc 파일을 편집한다.

$ cd                                                                                 # 홈디렉토리 이동
$ vim .bashrc

   // .bashrc 추가 내용
   export JAVA_HOME=/usr/local/java/jdk1.7.0
   export PATH=$PATH:$JAVA_HOME/bin
   export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib

$ source .bashrc
$ javac -version                                                                  # 받은 JDK 버전에 맞게 나오면 설치 완료.
$ java -version                                                                    


@ 참고 사항 

  1. 작업 환경에 eclipes 혹은 Android 개발환경이 이미 설치되어있다면 설치한 java ( 1.7.0 ) 명령어가 아닌 다른 java ( 1.7.0 이외 버전 )
      명령이 실행될 수도 있다는 것을 알아두기 바란다.

  2. 위 설정은 개인 계정에만 적용되는 설정이다.

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 Software Dev Note/리눅스 운영 & 프로그래밍 jdk, jdk설치, ubuntu, 우분투

  1. Blog Icon
    나그네

    감사합니다~

Ubuntu Vim 설치하기

2011/11/25 17:14
Ubuntu 를 처음 설치하면 일반 vi 에디터가 설치되어 있는데, 윈도우 텍스트 에디터에 익숙해진 나로써는
다소 사용하기가  불편했다.

그나마 윈도의 텍스트 에디터들과 유사하게 키입력을 먹는 Vim을 설치하기로 했다. 
또한 C코딩등의 작업을 편하게 하기위해 하이라이트 기능을 On시키기로 했다.

1. sudo apt-get install vim


2. 자신의 홈 디렉토리에 .vimrc 파일을 생성


set autoindent

set cindent

set smartindent

set nocompatible

set visualbell

set backspace=indent,eol,start

set history=50

set ruler

set showcmd

set incsearch

set tabstop=4

set shiftwidth=4

set number


if has("syntax")

syntax on

endif


잘 동작한다.
저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 Software Dev Note/리눅스 운영 & 프로그래밍 ubuntu, vim, vim설치, 우분투

자료조사(7) - RTP/RTCP 프로토콜 (실시간 통신 프로토콜)

2011/11/25 12:11

RTP/RTCP

 * 관련문서 : RFC 1889, RTP - A Transport Protocol for Real-time Applications

IETF AVT WG에서 작성한 인터넷 표준이다. RFC 1889는 실시간 응용 데이터
전송을 위한 트랜스포트 프로토콜인 RTP와 제어 정보를 전달하는 RTCP로 구성된다.


RTP (Real-time Transport Protocol)
 

RTP는 멀티캐스트 또는 유니캐스트상에서 음성, 화상, 또는 모의 데이터와 같은 실시간 데이터를 전송하는 응용에 적합한 단대 단 트랜스포트 기능을 제공한다.

그러나 RTP는 자원 예약에 대한 내용은 다루지는 않으며, 특히 적시 데이터 전송 (timely delivery), QoS 보장, 뒤바뀐 순서의 전송 방지와 같은 기능을 제공하지 않는다. 따라서 트랜스포트의 의미는 실시간 데이터의 특성에 중점을 두어 제정한 표준이라고 할 수 있다. RTP패킷은 UDP를 이용하여 전달된다.


RTP패킷 양식 그림


(그림 1) RTP 패킷 양식


그림은 RTP 패킷 형태이다. 헤더는 고정 크기를 가지며 멀티미디어 정보에 따라서 헤더 뒤에 특정 정보 및 데이터가 붙게 된다.

V는 버전 필드이며 최근 
버전은 2.0이다. P는 32비트 단위로 패킷을 구성하기 위해서 사용된다.

P값이 세팅되면 payload 부분이 아닌 패딩 옥테트들이 패킷의 끝에 포함됨을 의미한다. 

X비트가 세팅되면 정확하게 한 개의 화장 헤더가 고정 헤더 다음에 온다는 것을 가리킨다.

CC는 고정 헤더에서 CSRC identifier의 개수를 가리킨다.

CSRC는 
RTP mixer가 combined stream으로 만드는 데 기여한 RTP 패킷 스트림의 소스이다. 즉, RTP 패킷들은 망을 통해서 전달되면서 중간 시스템에서는 여러 소스로부터 온 RTP 패킷들을 받고 이들을 적절히 조합시켜서 새로운 형태의 RTP 패킷을 만들고 이를 다음 시스템으로 전달하는데, 이러한 기능을 수행하는 중간 시스템을 RTP mixer라 한다. 

M은 멀티미디어 정보에 대한 프레임 영역을 나타낸다. 즉 패킷 안에서 음성과 화상 정보 등을 구별하는데 사용한다.

PT 필드는 RFC 1890에서 정의된 
프로파일의 RTP payload 양식을 지칭하고 응용에 의해서 해석된다.
프로파일은 
payload type code를 payload format으로 지정되고 고정된 대응을 시킨 것이다. 즉, PT가 0이면 인코딩 방식의 오디오 정보이고 800Hz clock rate를 갖으며 오디오 채널 1개를 갖는 것을 가리킨다. 현재 33개의 payload type이 정의 되어 있다.

sequence number는 RTP 패킷이 송신될 때마다 1씩 증가한다. 수신측은 이 필드를 이용하여 패킷분실을 감지 하고 패킷 순서를 재저장한다.

timestamp 필드는 RTP 
패킷의 첫 번째 옥테트가 샘플링된 시점을 나타낸다. 그 샘플링 시점은 일정하게 증가하는 클럭으로부터 생성된다. 이것은 실시간 데이터의 동기화와 지터 계산에 이용된다.

SSRC 필드는 카메라 또는 마이크 등의 데이터 원천지의 식별자를 가리킨다.

CSRC 필드는 RTP 패킷이 중간 시스템에서 혼합될 경우에 그 소스들을 구별할 수 있는 식별자들을 가리킨다. 그러나 다중화(multiplexing)와 체크섬은 UDP(User Datagram Protocol)을 이용한다. 또한 여러 목적지로의 데이터전송은 하위 계층에서 제공해야 한다.



저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 수행 프로젝트 )/참여자주도형 정보공유 시스템 [2011.12~2012.02] RTCP, RTP, 실시간 통신 프로토콜

자료조사(6) - H.323 프로토콜 의 구조

2011/11/25 12:06

H.323 프로토콜을 구성하고 있는 여러 가지 관련 프로토콜의 구조에 대해 알아봅니다.


< 그림1 >


<그림1>은  H.323 프로토콜과 다른 프로토콜과의 관련성을 보여주고 있습니다.

H.323 프로토콜은 비디오와 보이스를 둘다 지원합니다.

(참고로 MGCP 는 보이스만 지원합니다.)


위 <그림1>처럼 H.323 에서 비디오 장비를 위한 코덱 으로는 H.261 과 H.263 이 정의 되어 있고 보이스를 위한 코덱 으로는 G. 시리즈의 코덱들이 있습니다.


여러분들이 잘 아시는 MPEG4 비디오 코덱이 H.263 코덱 입니다.

어쨌든 이러한 코덱들을 이용하는 미디어 스트림들은 RTP/RTCP 프로토콜을 이용하고 이것들은 UDP 프로토콜 기반에서 동작 합니다.


지금은 RTP 와 RTCP 프로토콜은 미디어 스트림이 전송될 때 사용되는 프로토콜이라고만 이해해 두십시오. 나중에 RTP와 RTCP 에 대해서도 자세히 다루겠습니다.


아래 <그림2>에서 보이듯이 미디어 스트림들은 다양한 코덱으로 인코딩 되며 RTP 프로토콜을 이용하여 전송 됩니다.



그림2 >

다시 <그림1> 보시면… T.120 프로토콜은 H.323 프로토콜내 에서 정의된 하나의 프로토콜입니다.

T.120 프로토콜은 데이터 공유를 지원하며 여러 유저들간의 실시간 통신을 위한 프로토콜 입니다.

대표적으로 T.120 프로토콜을 이용한 어플리케이션으로 마이크로소프트사의 화이트보드가 있습니다.

사용해 보신분들도 많으시겠지만 화이트보드를 이용하면 실시간으로 여러 사람의 PC 화면에 같은 자료를 공유하면서 회의를 하실수가 있습니다.

 

시스템 컨트롤 프로토콜로는 H.225, H.245, RAS 프로토콜이 있습니다.

H.225 ISDN Q.931 프로토콜처럼 콜의 생성과 유지, 종료를 관리하는 프로토콜 입니다.

H.323 프로토콜 마찬가지로 Q.931 프로토콜도 ITU-T 에서 발표한 프로토콜입니다.

그래서 실제로 H.225 프로토콜은 Q.931 프로토콜을 모태로 해서 만들어 졌고 매우 유사합니다.

 

다음으로 H.245 프로토콜은 콜에 참여한 단말 또는 게이트웨이간에 콜의 완성을 위해 필요한 코덱의 선택, RTP 위한 UDP 포트의 협의등 콜을 완성하기 위해 필요한 파라미터 값을 교환하기 위한 프로토콜 입니다.

 

마지막으로 RAS 프로토콜은 H.323 네트워크 내에서 게이트키퍼가 사용될 경우 각각의 단말이나 게이트웨이가 게이트키퍼와 통신을 사용되는 프로토콜 입니다.

 

위에서 언급한 시그널링 프로토콜 , H.225, H.245, RAS 프로토콜은 모두 TCP 프로토콜을 사용합니다.

, 보이스나 비디오 같은 미디어스트림은 UDP 프로토콜을 사용하고 콜을 만들기 위한 시그널 트래픽들은 안정적인 TCP 이용합니다.

 

내용을 토대로 예를 들어 보겠습니다.

<그림3> 참조 하십시오. 내용을 알기 쉽게 표현해 보았습니다

 

< 그림3 >

예를 들어 두대의 PC가 넷미팅 같은 H.323 어플리케이션을 가지고 Voice Over IP 콜을 한다고 가정하면…


두대의 PC 간의 콜 셋업은 H.225 프로토콜이 담당을하고 두대의 PC 간에 주고받을 보이스 트래픽을 위한 UDP 포트는 H.245 프로토콜을 통해 결정이 됩니다.


그리고 H.225 , H.245 프로토콜을 통해 만들어진 콜에 의해 전송되는 사람들의 목소리는 RTP,RTCP 프로토콜을 이용해 전송되게 됩니다.


오늘은 H.323 프로토콜을 구성하는 각각의 프로토콜의 개괄적인 성격과 전송프로토콜과의 관련성에 대하여 알아보았습니다.


출처 : http://blog.naver.com/PostView.nhn?blogId=mincloud1501&logNo=140012556932&redirect=Dlog&widgetTypeCall=true

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 수행 프로젝트 )/참여자주도형 정보공유 시스템 [2011.12~2012.02] h.323, RTCP, RTP, 프로토콜

자료조사(5) - 구글 토크 개발자 문서 (음성채팅 App)

2011/11/25 11:59

Google 토크 개발자 문서

We've provided the following documentation specifically for developers: 우리는 특별히 개발자를위한 다음과 같은 문서를 제공합니다 :

  • Google Talk and Open Communications : answers some basic questions about the protocol and codecs used by Google Talk, as well as future goals and federation. Google 토크 및 개방형 통신이 : 답변 프로토콜과 Google 토크뿐만 아니라, 미래의 목표와 연맹에서 사용되는 코덱에 대한 몇 가지 기본적인 질문.
  • libjingle : an open-source C++ library that you can use to build peer-to-peer applications for voice, video, or file-sharing. libjingle : 오픈 소스 C + 당신은 음성, 비디오 또는 파일 공유를위한 피어 - 투 - 피어 응용 프로그램을 구축하는 데 사용할 수있는 + 라이브러리입니다. The code handles both connection negotiation and data exchange. 코드가 연결 협상 및 데이터 교환을 모두 처리합니다.
  • Google Talk XMPP extensions : describes the non-standard XMPP extensions used by the Google Talk server. Google은 XMPP 확장 토크 : Google 토크 서버가 사용하는 비 표준 XMPP 확장을 설명합니다. If you build an XMPP client, you can listen for and use these extensions to provide greater functionality to your application. 당신은 XMPP 클라이언트를 빌드하는 경우에 대해 들어 귀하의 응용 프로그램에 더 많은 기능을 제공하기 위해 이러한 확장 기능을 사용할 수 있습니다.

What do you want to do? 당신은 어떻게할까요?

I want to build a client that connects to the Google Talk service 저는 Google 토크 서비스에 연결하는 클라이언트를 빌드하려면

  1. Read the overview page: Google Talk and Open Communications . : 개요 페이지 읽기 Google 토크 및 개방형 통신 .
  2. Implement the XMPP standards that apply to clients. 구현 XMPP 표준을 고객에게 적용됩니다.
  3. Implement the standard (proposed) Jingle extensions that you want your client to support. 표준 (제안) 구현 징글 확장 하여 고객 지원하려는 있습니다.
  4. Understand the non-standard XMPP extensions used by Google Talk . 이해 Google 토크에서 사용하는 비표준 XMPP 확장 .
  5. If you want to also support voice calls and/or file transfer, support libjingle . 당신은 또한 음성 통화 및 / 또는 파일 전송 지원 지원하려는 경우 libjingle을 .
  6. I want to understand the signaling for voice and video interoperability with the Google voice and video plugin. 내가 이해하고 싶어요 음성 및 영상 신호 상호 운용을위한 Google 음성 및 비디오 플러그인과 함께합니다.

I want to connect my service with the Google Talk service (federation) 저는 Google 토크 서비스 (연합) 내 서비스를 연결하려면

  1. Read the overview page: Google Talk and Open Communications . : 개요 페이지 읽기 Google 토크 및 개방형 통신 .
  2. Implement the XMPP standards that apply in server-to-server communications. 구현 XMPP 표준 서버 간 통신에 적용됩니다.
  3. Implement the standard (proposed) Jingle extensions that you want your service to support. 표준 (제안) 구현 징글 확장 하면 서비스를 지원하려는 있습니다.
  4. Understand non-standard XMPP extensions used by Google Talk . 이해 Google 토크에서 사용하는 비표준 XMPP 확장 .

I want to write a chat bot 저는 채팅 로봇을 쓰고 싶어!

  1. Read the Google App Engine XMPP API docs for Java or Python . 를위한 Google 애플 리케이션 엔진 XMPP API 문서를 참조하십시오 자바 또는 파이썬 .

Google uses Open AIM for the AIM® in Gmail feature. Google은 사용하는 오픈 AIM을 위한 AIM ® Gmail의 기능 인치


출처 : http://translate.googleusercontent.com/translate_c?hl=ko&langpair=en%7Cko&rurl=translate.google.co.kr&twu=1&u=http://code.google.com/apis/talk/talk_developers_home.html&usg=ALkJrhjmHtJ7ty4BU1cphX9cwdziMDeU_A
저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 수행 프로젝트 )/참여자주도형 정보공유 시스템 [2011.12~2012.02]

자료조사(4) - VOIP 두번째

2011/11/25 11:56

개요

전화 산업은 가장 널리 퍼져 있는 기술입니다. 일반적인 전화기만큼이나 사람들에게 편안하고 친숙한 기술은 없습니다. 많은 기업체들이 사용자들에게서 그런 편안함과 친숙함을 빼앗지 않으면서도 음성(voice) 관련 비용을 줄일 수 있는 새로운 방법을 찾고 있습니다. 그러한 비용 절감은 데이터 네트워크와 음성(voice) 네트워크의 통합을 촉진시키고 있습니다. 데이터 네트워크와 음성(voice) 네트워크가 점점 더 많이 통합됨에 따라, 음성(voice) 네트워크의 품질과 신뢰도가 영향을 받지 않게 하려면 주의 깊게 설계하고 기획해야 합니다. 본 설명서에서는 패킷 텔레포니, 좀더 구체적으로 말하면 voice over IP를 가능하게 하는 여러 가지 기술에 대해 설명합니다. 설계와 관련된 문제들을 설명하고, voice, fax, H.323, voice over IP 등도 간단하게 다룹니다.

본 설명서는 음성(voice) 기술에 대한 전문적인 학습 자료가 아니라, 패킷 환경에서 사용되는 voice 기술에 대한 기본적인 이해를 돕기 위한 것입니다.

본 설명서에서 자주 사용되는 용어들

A-Law ─ 아날로그 신호와 디지털 신호 사이의 변환에서 사용되는 ITU-T 로가리즘 PCM (pulse code modulation) 표준 (G.711). 주로 유럽에서 사용됩니다.

Busy hour(폭주 시간대) ─ 통화량이 가장 많은 시간대. 전화 회사들이 네트워크를 특정한 용량으로 설계하는데 도움이 됩니다.

CoS(Class of service) ─ 다양한 종류의 트래픽 플로우를 하나의 범주로 분류하고 그 플로우에 대해 특정한 QoS(quality of service)를 적용하는 방식

CODEC(Coder-decoder) ─ 아날로그 음성을 디지털 비트 스트림으로 변환하고 디지털 비트 스트림을 아날로그 음성으로 변환합니다. 압축 유형(예를 들면, G.729 CODEC)을 가리키는데 사용할 수도 있습니다.

CRTP(Compressed Real-Time Transport Protocol) ─ RTP(Real-Time Transport Protocol) 헤더를 압축하는 표준. Delay (지연) - A 지점에서 B 지점까지 도달하는데 필요한 시간

DTMF(Dual tone multi frequency) 톤 감지 방식 ─ 다이얼링을 보다 쉽게 할 수 있도록 개발된 전자식 전화에서 사용하는 방식. 각 숫자는 여덟 가지 주파수에서 선택한 16 가지 사인파 쌍과 짝지어져 있습니다(예: 숫자 7은 852 Hz와 1209 Hz의 조합으로 정의됩니다)

Ear and mouth 또는 receive and transmit (E&M) ─ 사설 교환기(PBX) 사이의 트렁크 라인에서 일반적으로 사용되는 신호 처리 기법

Echo cancellation(에코 캔슬) ─ 에코를 라인에서 제거하는 프로세스. 에코는 일반적으로 전화망 배선의 임피던스 차이로 인해 발생합니다. 에코 캔슬러는 방금 보낸 음성의 샘플을 저장해 두었다가 그 음성이 뒤집혀서 반대 방향으로 되돌아오면 그 뒤집힌 신호에서 원래의 음성을 추출해 냅니다.

FXO(Foreign exchange office) ─ 일반적인 전화 송수화기를 흉내내는 인터페이스 (즉, 다이얼 톤을 보내 주는 다른 장치가 있어야 합니다)

FXS(Foreign exchange station) ─ PSTN (Public Switched Telephone Network)을 흉내내는 인터페이스. 일반 전화 송수화기로 다이얼 톤을 보내는 역할을 합니다.

Gatekeeper(게이트키퍼) ─ H.323 시스템의 옵션 장치. H.323 엔드포인트에 호출 제어 서비스를 제공합니다. 하나 이상의 게이트키퍼를 사용할 수 있습니다. 게이트키퍼 사이의 통신 방식은 지정되어 있지 않습니다. 게이트키퍼는 논리적으로는 엔드포인트에서 분리되어 있지만, 물리적으로는 터미널, MCU (multipoint conference unit), 게이트웨이, MC (multi point controller), 또는 그 외의 비 H.323 LAN 장치 등과 함께 설치됩니다.

Gateway(게이트웨이) ─ H.323 컨퍼런스의 옵션 요소. H.323 게이트웨이는 LAN 상의 H.323 터미널과 WAN 상의 다른 ITU 터미널 사이에서, 또는 다른 H.323 게이트웨이에 실시간 양방향 통신을 제공하는 LAN의 엔드포인트입니다. H.323 ─ 실시간 멀티미디어 애플리케이션을 위한 ITU-T 규격

Jitter(지터) ─ 패킷간 도착 시간의 편차

Latency(레이턴시) ─ 어떤 장치가 네트워크 액세스를 요청한 시점과 전송 허가를 받은 시점 사이의 시간. 레이턴시의 한 구성 요소. 종종 네트워크와 관련된 지연을 설명할 때 end-to-end 레이턴시가 사용됩니다.

MTU(Maximum transmission unit) ─ 특정 인터페이스가 전송하는 최대 패킷 크기. 바이트 단위로 표시됨.

MU-Law ─ (m law라고 표기하는 것이 올바름) 아날로그 신호와 디지털 신호 사이의 변환에서 사용되는 북미 로가리즘 PCM 표준 (ITU-T G.711에서 규정됨).

MCU(Multipoint control unit) ─ 셋 이상의 터미널과 게이트웨이가 멀티포인트 컨퍼런스에 참여할 수 있는 기능을 제공하는 LAN 상의 엔드포인트. 나중에 멀티포인트 컨퍼런스로 발전하게 되는 포인트-포인트 컨퍼런스의 두 터미널을 연결할 수도 있습니다. MCU는 일반적으로 H.231 MCU의 방식으로 작동하지만, 오디오 프로세서는 필수 요소는 아닙니다. MCU는 다음 두 부분으로 구성되어 있습니다.필수 요소인 멀티포인트 컨트롤러와 옵션 요소인 멀티포인트 프로세서(MP). 가장 단순한 경우, MP가 없이 MC로만 MCU를 구성할 수도 있습니다.

MC(Multipoint controller) ─ 멀티포인트 컨퍼런스에 참여하는 셋 이상의 터미널을 제어하는 LAN 상의 H.323 엔티티. 나중에 멀티포인트 컨퍼런스로 발전하게 되는 포인트-포인트 컨퍼런스의 두 터미널을 연결할 수도 있습니다. 공통 통신 레벨을 만들 수 있도록 모든 터미널에 대해 negotiation 기능을 제공하며, 누가 비디오를 멀티캐스팅하는가와 같은 컨퍼런스 리소스를 제어할 수도 있습니다. 오디오, 비디오, 데이터 등의 믹싱이나 스위칭을 하지 않습니다.

MP(Multipoint processor) ─ 멀티포인트 컨퍼런스에서 오디오, 비디오, 데이터스트림 등의 중앙 집중식 프로세싱 기능을 제공하는 LAN 상의 H.323 엔티티. MC의 제어를 받는 미디어 스트림에 대해 믹싱, 스위칭, 또는 그 외의 다른 프로세싱 기능을 제공합니다. 지원하는 컨퍼런스의 유형에 따라 단일 미디어 스트림이나 다중 미디어 스트림을 처리할 수 있습니다.

QoS(Quality of Service) ─ 특정한 응용 프로그램에 필요한 서비스 레벨을 가리키는 일반적인 용어

RAS(Registration/Admission/Status) ─ H.323 게이트키퍼와 게이트 사이의 통신을 위한 H.323 프로토콜

RTP(Real-Time Transport Protocol) ─ RFC 1889 - 스트림형 리얼타임 응용 프로그램을 위한 ITU-T H.323 규격의 일부

RSVP(Resource Reservation Protocol) ─ 특정한 트래픽 플로우에 대역폭과 레이턴시를 동적으로 할당하거나 보류할 수 있는 기능을 정의하는 프로토콜.

T.4 ─ 팩스 전송에서 페이지 이미지 데이터의 포맷 설정을 규정하는ITU-T 프로토콜

T.30 ─ 팩스 전송에서 capabilities negotiation 메시지와 같은 페이지 내용이 아닌 데이터의 포맷 설정을 규정하는 ITU-T Fax Session Control Protocol

T.120 ─ ITU-T H.323 규격에서, 데이터 공유 응용 프로그램(화이트보딩, 등)과 관련된 부분.

ToS(Type of Service) ─ IP 헤더에서 패킷의 서비스 레벨과 관련된 부분

VAD(Voice activity detection) ─ 음성(speech)와 사일런스(silence) 사이를 구분하는 기능. 패킷 방식 네트워크는 사일런스는 전송하지 않음으로써 VAD를 활용합니다.

Voice 기술 첫걸음

음성(voice) 기술을 사용한 지 벌써 백년이 넘었습니다. 처음으로 전화 통화를 한 이래로 음성 통신망은 많은 발전을 거듭했습니다. 현재 사용하는 많은 음성 통신 약어와 아키텍처는 이미 수십 년 전에 결정된 것들입니다. 표준 PSTN은 기본적으로 대형 회로 스위치형 네트워크입니다. 전화 통신망은 정말 연결되어 있지 않은 곳이 없습니다. 전화는 사용법이 간단하며, 의존할 수 있고, 생활 중에 깊숙히 스며들어 있습니다.

모든 대형 통신망이 마찬가지이지만, 번호 지정 방식은 가장 중요한 문제 중의 하나입니다. 북 아메리카에서는, NANP (North American Numbering Plan)가 사용됩니다. NANP는 지역 코드(area code), 전화국 코드(office code), 스테이션 코드로 구성되어 있습니다. 지역 코드는 지리적인 위치를 기준으로 지정되며, 전화국 코드는 특정한 교환기를 기준으로 할당되며, 스테이션 코드는 그 교환기의 특정한 한 부분을 가리키는 것입니다. 사용되는 포맷은 1Nxx-NXX-XXXX입니다. 여기서 N = 2 - 9이고 X = 0 - 9입니다. 이러한 번호 지정 방식은 일반적으로 국제 다이얼링 플랜을 다루는 ITU-T E.164 권고와 그 외의 다른 많은 권고에 일치합니다.

국제 호출 플랜의 경우, 각 국가에는 한 자리에서 세 자리까지의 국가 코드가 지정됩니다. 해당 국가의 다이얼링 플랜은 국가 코드 다음에 이어집니다.

음성(voice) 기술을 온전히 이해하려면, 아날로그/디지털 전송 및 신호 처리를 모두 이해해야 합니다. 사람의 말이나 귀에 들리는 모든 소리는 아날로그 형태로 되어 있습니다. 수십년 전까지는, 전화 통신망도 아날로그 인프라스트럭처에 기초해 있었습니다. 예를 들어, 초창기 아날로그 전화 통화의 구성 요소는 탄소 전화기, 배터리, 전자석, 그리고 진동판(irondiaphragm)이었습니다. 이러한 구성 요소들을 연결하면 음성을 전달하는 통로가 되었습니다. 사람들이 이야기를 나누는데 아날로그 통신이 이상적이기는 하지만, 아날로그 전송 방식은 견실하지도 않고 라인 노이즈에서 원음을 복구하는데 효율적이지도 않습니다. 아날로그 전송에서 증폭기를 통하여 신호를 증폭시켰던 초창기 전화 통신망에서는, 음성도 증폭되었지만 라인 노이즈도 함께 증폭 되었습니다. 이 라인 노이즈로 인하여 종종 연결 상태가 불안정해지곤 했습니다. 디지털 샘플은 1 비트와 제로 비트로 구성되어 있습니다.

디지털 샘플을 라인 노이즈에서 분리시키는 것은 훨씬 더 쉽습니다. 따라서, 신호를 재생할 때, 깨끗한 음을 그대로 유지시킬 수 있습니다. 이처럼 디지털 형태로 표현하는 것의 장점이 분명히 드러나자, 전화 통신망은 PCM (pulse code modulation)으로 발전하게 되었습니다. PCM은 아날로그 사운드를 초 당 8000 회 샘플링하여 각 샘플을 숫자 코드로 변환함으로써 아날로그 사운드를 디지털 형태로 변환합니다.Nyquist 공리에서는 원하는 최고 주파수의 두 배의 속도로 아날로그 신호를 샘플링하면, 그 신호를 다시 아날로그 형태로 정확하게 재구성할 수 있다고 설명합니다. 대부분의 음성 컨텐츠는 4000 Hz (4kHz) 이하이므로, 필요한 샘플링 속도는 초 당 8000 회(샘플링 사이 간격이 125 마이크로초)입니다. 샘플링된 파형은 개별적인 디지털 형태로 변환이 됩니다. 이 샘플은 샘플링을 한 순간의 파형의 진폭을 가리키는 코드로 표현이 됩니다. 전화 산업에서 PCM은 코드에 대해 8 비트를 사용하며 진폭이 낮은 신호에 더 많은 비트를 할당하는 알고리즘 압축 방식을 사용합니다. 전송 속도는 초당 8000 샘플 곱하기 샘플당 8 비트, 즉 초당 64,000 비트가 됩니다. 이것이 디지털 전화 통신에서 한 채널의 표준 전송 속도입니다

일반적으로 64-kbps PCM의 다음 두 가지 기본 변이형이 사용됩니다. 이 두 가지 방식은 모두 로가리즘 압축을 사용하여 8 비트로 12 비트에서 13 비트의 직선형 PCM 품질을 달성한다는 점에서 비슷하지만, 비교적 사소한 압축 세부 사항에서는 서로 차이가 있습니다. (mu-law가 로우 레벨 신호대 잡음비 성능에서 약간 더 낫습니다.) 그동안에는 국경선을 따라 사용하는 방식이 달랐습니다. 즉, 북 아메리카에서는 mu-law 변조 방식을 사용하고 유럽에서는 a-law 변조 방식을 사용했습니다. 장거리 전화를 할 때 mu-law와 a-law 사이의 변환을 하는데 필요한 것은 전부 mu-law를 사용하는 국가의 책임이라는 점에 반드시 유의해야 합니다.

종종 사용되는 또 다른 압축 방식은 ADPCM (adaptive differential pulse code modulation)입니다. 일반적으로 사용하는 ADPCM의 예로, ITU-T G.726은 4-비트 샘플을 사용하여 엔코딩을 하며, 전송 속도는 32kbps입니다.PCM과는 달리, 이 4 비트 방식은 음성의 진폭을 직접 엔코딩하는 것이 아니라 아주 초보적인 1차원적 예측 방식으로 진폭의 차이 그리고 진폭 변화율을 엔코딩합니다.

PCM과 ADPCM은 파형 자체의 중복적인 특성을 활용하는 “파형” CODEC (coder-decoders) 압축 기법의 예입니다. 음성 생성의 소스 특성에 대한 지식을 좀더 활용하는 새로운 압축 기법이 지난 10년에서 15년 동안 개발되었습니다. 이러한 기법은 원래의 음성 진동과 구강 형태을 단순하게 표현한 파라메트릭 정보만을 보내어 음성을 압축하는 신호 처리 기법을 사용합니다. 이렇게 하면 그 정보를 전송하는데 대역폭이 더 필요하게 됩니다. 이러한 기법들은 일반적으로 “소스” CODEC으로 함께 묶을 수 있으며, 그 중에는 LPC (linear predictive coding), CELP (code excited linear prediction), 및 MP-MLQ (multipulse, multilevelquantization) 등과 같은 변이형이 포함되어 있습니다.

CELP, MP-MLQ, PCM, 및 ADPCM 코딩 방식은 ITU-T의 G-시리즈 권고에 표준화되어 있습니다. 텔레포니와 packet voice에서 가장 많이 사용하는 음성 코딩 표준에는 다음이 포함되어 있습니다.

  • G.711: 앞에서 약술한 64-kbps PCM 음성 코딩 기법을 규정하는 것으로, G.711 방식으로 엔코딩된 음성은 이미 공공 전화망에서 또는 PBX를 통하여 디지털 음성을 전달할 수 있는 포맷으로 되어 있습니다.
  • G.726: 40, 32, 24, 26 kbps의 ADPCM 코딩을 규정하는 것으로, ADPCM 음성도 packet voice와 공공 전화망이나 PBX 망 사이에서 서로 교환할 수 있습니다. 다만, 공공 전화망이나 PBX 망에 ADPCM 처리 기능이 있어야 합니다.
  • G.728: CELP 음성 압축 방식의 16-kbps 저-지연 변이형을 규정하는 것입니다. CELP 음성 코딩은 전화 통신망으로 또는 전화 통신망을 통하여 전달할 수 있도록 공공 텔레포니 포맷으로 코드 변환이 되어야 합니다.
  • G.729: 음성을 8-kbps 스트림으로 코딩할 수 있는 CELP 압축을 규정하는 것입니다. 이 표준의 두 가지 변이형(G.729와 G.729 Annex A)은 계산의 복잡성에서 크게 다르지만, 두 가지 모두 일반적으로 32-kbps ADPCM과 같은 수준의 음성 품질을 제공합니다.
  • G.723.1: 전체적인 H.324 계열 표준의 일부로서, 아주 낮은 비트 속도로 멀티미디어 서비스의 음성이나 다른 오디오 신호 요소들을 압축하는데 사용할 수 있는 압축 기법을 규정하는 것입니다. 이 종류의 코더에는 5.3 kbps와 6.3 kbps의 두 가지 비트 속도가 관련되어 있습니다. 6.3 kpbs의 비트 속도는 MP-MLP 기술에 기초한 것으로 품질이 더 뛰어나며, 5.3 kbps의 비트 속도는 CELP에 기초한 것으로, 품질이 양호하며 시스템 설계자들이 좀더 유연하게 설계할 수 있습니다.
CODEC이 주관적으로 튜닝이 된 압축 기법에 점점 더 의존하게 됨에 따라, 총 고조파 왜곡이나 신호대 잡음비와 같은 표준 지향적인 품질 측정값은 인식된 CODEC 품질과 상관 관계를 덜 가지게 됩니다. 음성 CODEC의 성능을 수량화할 수 있는 일반적인 벤치마크는 MOS (mean opinion score)입니다. 보이스 품질과 사운드는 일반적으로 청취자에 따라 기준이 달라지기 마련이므로, 광범위한 청취자와 샘플 재료를 구하는 것이 중요합니다. MOS 테스트는 각 음성 재료 샘플에 대해 1(나쁨)에서 5(우수함)까지의 등급을 매기는 청취자 그룹을 대상으로 시행됩니다. 그 다음에 그 점수의 평균을 내어 MOS 점수를 구합니다. MOS 테스트 방식은 특정한 CODEC이 다양한 배경 소음 수준과 반복적인 엔코딩과 디코딩 등과 같은 다양한 상황에서 얼마나 잘 작동하는지를 비교하는데 사용할 수도 있습니다. 그 다음에 이 데이터를 사용하여 다른 CODEC와 비교할 수 있습니다.

여러 ITU-T CODEC의 MOS 점수를 정리한 것이 표 1입니다. 표 1은 여러 대의 낮은 비트 속도의 코더와 표준 PCM 사이의 관계를 보여줍니다.

표 1 압축 방식 및 해당 MOS 점수
 
압축 방식  비트 속도(kbps)  프로세싱1(mips)  프레임 크기(단위) MOS 점수
G.711PCM  64  0.34 0.125  4.1 
G.726PCM  32  14 0.125  3.85
G.728 LD-CELP  16  33 0.625  3.61 
G.729 CS-ACELP  20  10 3.92
G.729x2 Encoding  8 20 10  3.27
G.729x3 Encoding  8 20  10  2.68
G.729a CS-ACELP  10.5  10  3.7
G.723.1 MP-MLQ  6.3 16  30  3.9 
G.723.1 ACELP  5.3  16  30  3.65

1. Texas Instruments 54 x DSPs를 위해 주어진 Mips 프로세싱 파워

요즘의 toll-quality 네트워크를 유지하는데 필요한 인프라스트럭처를 만들어서 관리하는 비용을 감안하면, 모든 통화를 낮은 비트 속도의 코더로 변환하여 인프라스턱처 비용을 절감하는 것이 더 쉽고 저렴해 보입니다. 하지만, 음성을 압축하는데는 단점이 있습니다. 표 1에 나오는 것처럼, 한 가지 주된 단점은 여러 번 코딩하고 디코딩하는 것으로 인한 신호 왜곡(탠덤 엔코딩(tandem encodings)이라고도 함)입니다. G.729 음성 신호를 여러 번 압축하는 경우, 탠덤 엔코딩을 세 번 하면, 그 신호는 MOS 3.92 (아주 좋음)에서 2.68 (정상적으로 사용할 수 없음)로 품질이 저하됩니다.

어떻게 낮은 비트 비율 코덱(예: G.726)으로 높은 MOS가 얻어지는지를 이해하려면 이 코덱이 어떻게 작동하는지를 알아야 합니다. 음성 패턴에 대한 연구는 음성 통화의 상당한 부분이 사일런트(silent) 상태이며, 음성이 튀어나오는 나머지 부분도 서로 상관 관계가 상당히 높으며 반복이 된다는 점을 보여 주었습니다. 이 연구를 이해하면 수학적인 모델을 사용하여 이전의 음성 샘플을 기초로 음성에서 나오는 다음 소리를 예측하는 방법으로 음성 패턴을 활용할 수 있습니다. 그리고, 코더 측과 디코더 측 모두에서 동일한 예측기 모델을 사용하면, 전송해야 하는 정보는 예측한 것과 실제로 음성에 포함된 것 사이의 차이 부분 뿐입니다. 32 kbps를 사용하는 G.726 (ADPCM)는 종종 toll quality 64-kbps PCM만큼이나 양호한 것으로 인정됩니다. 이런 종류의 코더를 사용하면, 4-kHz 음성 대역폭 내의 모든 신호는 디지털 신호로 변환하여 전송할 수 있습니다. 불행하게도, ADPCM에서 보다 낮은 비트 속도 (24, 16 kbps)를 사용하면 MOS 점수가 상당히 떨어지게 됩니다.

G.729나 G723.1에서처럼 더 낮은 비트 속도의 CODEC (아주 낮은 비트 속도의 코더로 알려져 있음) 정도로 점수가 떨어져도 사용할 만한 음성 품질을 유지하려면, “파형”, 즉 PCM 코딩을 포기해야 합니다. 프로세싱 성능 (digital signal processor [DSP])와 비용 (millions of intructions per second [mips])의 발전과 음성(voice) 기술 분야의 발전 덕분에 대규모 압축 음성(speech) 사용이 실현되었습니다. LPC나 다른 하이브리드 코더의 가장 흥미진진한 사실 중의 하나는 네트워크를 통하여 전송되는 것은 실제 음성이 아니라는 사실입니다. LPC는 성도(성대와 허파)를 신디사이즈하고 필터는 다른 요소들(입, 혀, 입술, 등)을 신디사이즈합니다. 소리나 진동은 필터로 보내져서, 합성된 음성이 되어 나옵니다. 이 시나리오는 PCM에 비해 필요한 비트 수에 있어서 크게 향상되었습니다. 예를 들어, LPC는 매 20 밀리초 단위로 합성, 즉 샘플링되는데, 이것은 동일한 20 밀리초 동안 160회 샘플링하는 PCM과 비교가 됩니다. 그렇기 때문에 동일한 시간에 LPC는 초 당 40 비트를 전송하는데 반해 표준형 PCM 코더는 초 당 1280 비트를 전송합니다. CELP와 같은 하이브리드 코더는 LPC 기술을 기초로 구축되었지만, 제 1세대 LPC 보코더에서 많은 로봇형 특성을 제거한 향상된 음성 분석 및 합성 기법을 추가한 것입니다. 하이브리드 코더에는 보다 복잡한 신디사이저가 필요했습니다. 이러한 신디사이저에는 일반적으로 매 20 밀리초 마다 갱신되는 8 내지 10 개의 주요 매개 변수들이 있습니다. 음성에 맞춘 최적 품질을 만들기 때문에, CELP는 music-on-hold와 같은 비 음성형 신호 전송에서는 상당히 품질이 저하됩니다.

이러한 새로운 코더에서는 설계 면에서 몇 가지 타협이 이루어졌습니다. 탠덤 엔코딩에 대해서는 이미 설명했지만, 코더 지연, 대역폭/품질 손실, 에코, 총 end-to-end 지연 등과 같은 아주 낮은 비트 속도의 코더를 중심으로 전개된 몇 가지 문제들에 대해서도 설명할 필요가 있습니다.

비록 8kbps로 음성 패킷을 압축하는 것이 이상적이지만, 이러한 대역폭을 위해서는 품질을 양보해야 합니다. 설계 기준에서 가장 중요한 것 중의 하나는 총 단방향 end-to-end 지연을 최소화시키는 것입니다. 이러한 총 지연은 150 밀리초에서 200 밀리초 이내이면 무난한 것으로 나타났습니다. 이 총 지연에는 CODEC에 의해 유발된 지연과 네트워크, 광속, 및 그 외의 요소들이 포함됩니다. 특정한 고객에게는 다소간에 약간의 지연이 필요하겠지만, 네트워크 지연은 어떻게든 처리가 가능한 것이며 CODEC에 의해 유발된 지연은 비교적 일정하다는 점을 이해할 필요가 있습니다.

지연(Delay)

요즘의 텔레포니 네트워크에는 본질적으로 다음 두 가지 종류의 지연이 존재합니다. 전달 지연(propagation delay)과 처리 지연(handling delay)입니다. 전달 지연은 광섬유나 구리를 사용하는 네트워크에서 광속에 의해 발생하는 지연입니다. 처리 지연은 일련화 지연(serialization delay)이라고도 하는데, 음성 경로를 따라 음성 정보를 처리하는 장치들에 의해 발생합니다.

진공 상태에서 광속은 초당 186,000 마일이며, 전자는 구리선에서 초당 100,000 마일을 이동합니다. 광섬유망을 따라 지구를 절반 정도(13,000 마일) 돌면 약 70 밀리초의 단방향 지연이 발생합니다. 이러한 지연을 인간의 귀로는 거의 인식할 수 없지만, 처리 지연이 전달 지연과 결합이 되면 음성 품질이 저하되는 것을 느낄 수 있게 됩니다. 처리 지연은 기존의 전화 통신망에도 영향을 줄 수 있지만, 패킷 방식 환경에서 더 큰 문제가 됩니다. 다음은 여러 가지 처리 지연, 및 그러한 처리 지연이 음성 품질에 어떤 영향을 주는가에 대한 해설입니다.

G.729에는 약 20 밀리초의 알고리즘상의 지연이 존재합니다. Cisco IOS ?voice over IP 제품에서, DSP는 매 10 밀리초마다 하나의 프레임을 생성합니다. 그 다음에 이러한 음성 프레임 중의 두 개를 하나의 패킷에 넣습니다. 따라서, 패킷 지연은 20 밀리초입니다. 하나의 패킷으로 몇 개의 프레임을 보낼 것인가는 벤더가 결정합니다. Cisco는 라우터 오버헤드를 줄이기 위하여 패킷 변환을 가능한한 DSP가 많이 담당하게 하였습니다. 예를 들어, RTP (Real-Time Transport Protocol) 헤더는 DSP에서 프레임에 들어가기 때문에 라우터가 그 일을 할 필요가 없습니다.

패킷 방식 네트워크에는 지연이 발생하는 다음과 같은 다른 요인들이 있습니다. 실제 패킷을 아웃풋 대기열로 옮기는데 필요한 시간, 및 대기열 지연. Cisco IOS 소프트웨어는 패킷을 옮기고 도착지를 결정하는 일을 상당히 잘 합니다. (다른 패킷 방식 솔루션 [PC 방식, 등]은 패킷 도착지를 결정하는 일이나 실제 패킷을 아웃풋 대기열로 옮기는 일을 잘 하지 못하기 때문에 이 점을 언급하는 것입니다.) 아웃풋 대기열의 실제 대기열 지연은 또 다른 지원 원인입니다. 가능하다면 그 네트워크에 가장 말맞는 대기열 처리 방식을 사용하여 이 요소를 10 밀리초 이하로 유지시켜야 합니다. 이 문제는 Quality of Service 항목에서 보다 자세히 설명합니다. 표 2는 다양한 종류의 CODEC에 의해 다양한 크기의 지연이 발생하는 것을 보여줍니다. 표 2 CODEC에서는 CODEC에 따라 지연의 양이 달라지는 것을 보여주고 있습니다.

표 2. CODEC에서 발생하는 지연
 
압축 방식  비트 속도 (kbps) 압축 지연 (ms)
G.711ADPCM  64  0.75
G.726PCM  32 1
G.728 LD-CELP  16  3-5
G.729 CS-ACELP  10
G.729a CS-ACELP  10
G.723.1 MP-MLQ  6.3  30 
G.723.1 ACELP  5.3  3

두 가지 다른 요소들도 지연에 영향을 줍니다. 절대 지연은 전화 통화의 기본 흐름에 간섭을 일으킬 수 있고, 지연 편차, 즉 지터도 음성 품질에 영향을 줍니다. 절대 지연은 전화 통화의 리듬, 즉 흐름에 중단을 일으킬 수 있으며, 그 지연이 크면 그 전화 통화가 CB와 비슷하게 됩니다.

즉 통화자들이 서로 번갈아가면서 이야기를 하고 한 통화자가 말이 끝나면 그냥 가만히 있는 것이 아니라 그에 해당하는 키워드를 붙이는 방식이 될 것입니다. 지터는 예정된 패킷 수신과 실제 패킷 수신 사이의 편차입니다. 음성 장치들은 음성을 자연스럽게 재생시켜주는 플레이아웃 버퍼를 설정하여 지터를 보정하고 음성 흐름이 끊어지지 않게 해야 합니다.

사용자의 입장에서 보면, 플레이아웃 제어를 설정하는 것은 상당히 간단합니다. RTP 캡슐화의 경우, adaptive(기본 설정) 플레이아웃 지연 모드를 선택할 수 있습니다. 명목 지연(nominal delay)이라고 하는 초기값을 (기본값은 60 msec) 지정해야 합니다. 최대 지연도 지정해야 합니다 (이 시나리오에서는 기본값을 200 msec로 하면 지리적인 연결 장치에서 G.729의 end-to-end 지연이 300 msec 이하가 되게 합니다. 300 msec 이하는 중요한 기준값입니다). 그렇게 하여 adaptive 플레이아웃 지연은 다음 두 가지 이유에서 이 값으로 한계를 정합니다. 첫번째로, 최대 지연은 지터 버퍼에 할당된 DSP 메모리 자원에 의해 제한을 받습니다. 현재의 펌웨어 릴리스에서, 이 메모리 자원은 64,000 CODEC의 경우 200 msec이고, 8000 CODEC의 경우 1360 msec입니다. 두번째로, 이 지연에서는 이 컴포넌트의 상한값을 설정할 수 있습니다. 많은 경우, 이 상한값은 end-to-end 지연의 주요 요인입니다. 많은 애플리케이션에서 임의의 큰 지연을 허용하는 것보다는 시스템이나 사용자가 통화를 종료하게 하는 것이 더 바람직합니다. 이 한계값 이상으로 지터에 수신된 데이터는 플레이아웃 통계에 버퍼 오버플로로 나타날 것입니다. 이상적인 값은 제로입니다. 이것은 설계 매개 변수이며, 현재는 2 msec로 설정되어 있습니다.

수신 지연(receive delay)은 지터 보정을 위한 플레이아웃 지연 및 플레이아웃 버퍼에서 프레임을 디코더로 보낸 후의 평균 예정 지연으로 구성됩니다. PCM과 ADPCM CODEC의 경우 5 msec로 설정하고 G.729 CODEC의 경우 10 msec로 설정하십시오. 엔드포인트에서 양쪽 끝에 있는 CODEC까지의 지연, 엔코더 지연, 패킷화 지연, 네트워크 지연의 일정 부분 등을 추가하면, 해당 연결의 end-to-end 지연이 나옵니다. 엔코더 지연에는 5 msec의 VAD (voice activity detection) 지연과 에코 취소를 위한 처리 시간이 포함됩니다. end-to-end 신호/데이터 경로, CODEC, 페이로드 크기 등을 알고 있다면 end-to-end 지연의 이러한 다른 구성 요소들을 올바로 추정하는 것은 어렵지 않다는 점에 유의해야 합니다. 예를 들어, 네트워크 지연의 고정 부분과 엔드포인트 연결 지연이 거의 제로에 가까운 acampus 네트워크의 경우, G.729 CODEC와 20 바이트의 페이로드 크기 (각각 10 msec인 두 프레임)를 사용하는 voice over IP 통화에서는 20 msec의 엔코더 지연과 20 msec의 패킷화 지연(두번째 프레임을 대기하는 지연)이 생기게 됩니다. 그렇기 때문에 수신 지연에 40 msec를 추가하면 end-to-end 지연의 상당히 정확한 추정값이 나옵니다. 이 예제에서, 경쟁하는 데이터 트래픽이 없다면, end-to-end 지연의 평균값은 대략 50 msec이고 범위는 45 msec에서 55 msec까지가 됩니다. 수신 지연의 경우, current, low-water mark, high-water mark 등의 통계값을 사용할 수 있습니다.

현재의 플레이아웃 지연의 time 창 내에서 데이터가 수신되지 않거나 데이터가 사라진다면, 이 시나리오에서는 플레이아웃 오류가 발생합니다. 사라진 데이터는 두 가지 유형의 오류, 즉 토크 스퍼트(talk spurt) 중간에 프레임이 사라지는 오류와 토크 스퍼트(talk spurt) 끝 무렵에 미스큐가 발생하는 오류의 원인이 됩니다. 사라진 데이터의 연속적인 지속 기간에 따라 다르지만, 사라진 프레임은 지나간 프레임들(보통 가장 마지막 프레임만)에서 예측한 값으로 대치되며, 같은 상황이 (예를 들면, 30 msec에서 50 msec 이상 동안) 지속되면 사일런스(silence)가 뒤에 붙여집니다. 이 시나리오를 은폐(concealment)라고 합니다. 버퍼 오버플로와 은폐(concealment) 통계값을 구할 수 있으며, 그러한 통계값은 오디오 품질에 미치는 네트워크의 영향을 잘 보여줍니다.

플레이아웃 조정

플레이아웃 지연 조정과 다양한 통계값의 세부 사항을 소스 코드와 다음 참조 자료들에서 찾을 수 있습니다. 다음은 플레이아웃 지연 조정에 대한 간단한 해설입니다.

수신되는 패킷의 지연은 레퍼런스 지연을 기준으로 측정이 되며, 레퍼런스 지연은 가장 최근에 지나간 time 창 내의 최소 지연 패킷과 같습니다. 그런 패킷이 수신되면 가중치는 그에 비례하여 줄어듭니다. 이렇게 되는 이유는 500 패킷이나 1000 패킷 이전과 같이 오래 전에 발생한 절대 최소값으로 잠금 상태가 되는 것을 방지하기 위한 것입니다. 실제로는, 1000 패킷 이내의 좁은 최소 지연 내에 다수의 패킷이 수신됩니다. 수신 패킷에 현재의 레퍼런스보다 더 낮은 지연이 있고 패킷이 차례대로 도착이 되면, 레퍼런스 지연이 초기화됩니다

임의의 주어진 인스턴스에는 지터 버퍼의 실제 깊이인 변수(delay_Now)가 존재하며, 새로운 패킷이 도착하면 갱신되는 또 다른 변수 (delay_update)도 존재합니다. 이 시나리오에서는 지터 버퍼의 깊이가 시간이 경과함에 따라 원하는 방식으로 조절이 됩니다. 대부분의 경우 변수(delay_Now)는 토크 스퍼트(talk spurt)를 시작할 때 delay_update로 설정됩니다. 이 조절은 delay_update가 25 퍼센트 이상의 delay_Now에 의해 off 상태가 될 때에도 발생합니다. 바로 이 점이 VAD가 작동하지 않는 경우 뿐만 아니라 지터 특성이 급격하게 바뀌는 경우를 설명해 주는 것입니다. delay_Now가 delay_update에서 너무 많이 벗어나는 것도 바람직하지 않습니다.

수신되는 패킷의 지연이 delay_update의 50 퍼센트에서 75 퍼센트까지라면, 갱신할 필요가 없습니다. 이런 상황이 상당히 오래 지속된다면, 그 지연이 이 범위를 벗어나도록 레퍼런스 지연이 조절되며, delay_update는 새로운 값으로 고정이 될 때까지 조절이 될 것입니다. 단, delay_update가 최소 플레이아웃 지연과 동일한 경우는 예외입니다. 따라서, 조정이 발생하지 않는 것이 확실한 유일한 조건은 지터가 최소 플레이아웃 지연보다 작은 경우 뿐입니다.

Delay_update는 75 퍼센트에서 100 퍼센트의 지연 범위에서는 delay_update의 1/64의 비율로 상향 증가되며 100 퍼센트를 초과하는 지연의 경우에는 25 퍼센트의 아주 빠른 속도로 상향 증가됩니다. 현재의 지터 버퍼 깊이를 벗어나는 패킷의 수가 거의 없는 것 (대부분의 네트워크 변이형의 경우 1 퍼센트 미만)이 바람직하므로 상향 조정은 매우 공격적이라는 점은 분명합니다.

delay_update의 상향 조정은 최대 플레이아웃 지연에 의해 제한이 됩니다. delay_update의 하향 조정은 delay_update의 50 퍼센트 이항의 지연에 대해 이루어지며, 상향 조정에 비해 훨씬 더 느립니다. 시간 상수(time constant)는 200 패킷에서 300 패킷까지입니다. 이 시간 상수(time constant)는 20-msec 패킷 지속 기간의 경우 4 초에서 6초까지로 해석이 되며, 20-msec 패킷의 경우에는 대략 750 패킷, 즉 15 초로 해석이 되어, 네트워크 지터가 패킷 지속 기간 이하가 되면 최대 지연에서 최소 지연까지 충분히 수렴합니다. 예를 들어, 네트워크 트래픽이 없는 경우 100 msec의 초기 지연 (nominal_delay)에서 2 msec의 최소 지연까지 수렴하는데는 대략 여섯 링 사이클 (대략 15 sec의 active audio)이 걸립니다. 수렴의 비례증가형 특성 때문에, 훨씬 더 높은 값에서부터 수렴하는데 훨씬 더 오래 걸리지는 않습니다.

에코

기존의 장거리 전화망에서는, 일반적으로 에코가 4-선 네트워크 스위치에서 2-선 로컬 루프로 변환할 때의 임피던스 차이로 인해 발생합니다. 이야기를 할 때 수화기를 통해 자기 목소리를 듣는 것은 정상적이며 말하는 사람에게 안정감을 줍니다. 하지만, ~25 밀리초 이상 수화기에서 자기 목소리가 들리면 방해가 되며 대화를 멈추게 만들 수 있습니다. 일반적인 PSTN (Public Switched Telephone Network) 네트워크에서 에코는 에코 캔슬러로 제어하며 일반적인 반향점에서는 임피던스 차이를 철저하게 제어합니다. 요즘의 패킷 방식 네트워크에서, 에코 캔슬러는 낮은 비트 속도의 CODEC에 내장되며 각 DSP를 대상으로 작동이 됩니다. 에코 캔슬러가 작동하는 방식을 이해하려면, 에코가 어디에서 생기는지 먼저 이해해야 합니다.

예를 들어, 사용자 A가 사용자 B에게 이야기를 한다고 합시다. 사용자 A가 사용자 B에게 하는 말을 G라고 할 때, G에서 임피던스 차이가 발생하거나 기타 에코를 일으키는 환경이 되면, G는 사용자 A에게로 되돌아갑니다. 그러면 사용자 A는 실제로 말한지 몇 밀리초 후에 그 지연된 부분을 듣게 됩니다. 라인에서 에코를 없애기 위하여, 사용자 A가 통화를 하는 장치 (라우터 A)는 일정한 시간 동안 사용자 A의 음성의 인버스 이미지를 보관합니다. 이 인버스 이미지를 인버스 스피치(inverse speech), -G라고 합니다. 이 에코 캔슬러는 사용자 B에게서 수신되는 소리를 잘 듣고 인버스 스피치 -G를 제거하여 에코를 없앱니다.

에코 캔슬러는 설계에 따라 소외 에코 트레일이라고 하는 반사된 음성이 수신되는 것을 기다리는 총 시간에 의해 제한을 받습니다. 에코 트레일은 보통 32ms입니다. Cisco에는 16ms, 24ms, 32ms의 설정할 수 있는 에코 트레일이 있습니다.

신호 처리

요즘의 원격 통신 네트워크에서는 다양한 종류의 인-밴드(in-band) 신호 처리 방식과 아웃-오브-밴드(out-of-band) 신호 처리 방식이 사용됩니다. 일반적인 인-밴드 신호 처리 방식은 단일 주파수 톤이나 다중 주파수 톤을 사용하는 것입니다. 일반적인 아웃-오브-밴드(out-of-band) 신호 처리 방식은 호출 셋업을 위하여 D 채널을 사용하는 ISDN (Integrated Services Digital Network)입니다. 아웃-오브-밴드(out-of-band) 신호 처리란 정확하게 말해서 음성 대역폭을 벗어나는 신호 처리에 대해 별도의 채널을 사용하는 것입니다

또 다른 형태의 신호 처리 방식은 라인이 오프 후크 상태인지 온 후크 상태인지 판단한는 것입니다. 이렇게 하려면 일정한 수준의 서비스(즉, 다이얼 톤)이 필요합니다. 다음 두 가지 일반적인 방법은 사용자나 주거지를 기준으로 이 기본 신호를 제공합니다.

루프 스타트(loop start)와 그라운드 스타트(ground start). 루프 스타트는 현재까지는 일반적인 PSTN 엔드 루프 네트워크에서 신호 처리를 하는 가장 일반적인 기법입니다. 수화기를 들면, 전화 회사의 CO (central office)에서 전류를 끌어오는 회로가 닫히면서 상태 변화를 알려줍니다. 이러한 상태 변화는 일반적으로 CO에 다이얼 톤을 보내라는 신호 역할도 합니다. CO에서 수화기로 보내는 수신 호출 신호는 90 VAC에서 20-Hz나 25-Hz (북아메리카에서는 20 Hz이고 유럽에서는 25 Hz나 50 Hz) 신호를 일반적인 on/off 패턴으로 보내어 전화벨이 울리게 하는 방식으로 이루어집니다.

그라운드 스타트(ground start)는 온 후크나 오프 후크 신호를 CO나 다른 연결된 전화 장치(즉, privat branch exchange [PBX], 키 시스템)로 보내는 또 다른 신호 방식입니다. 그라운드 스타트(ground start)는 일반적으로 PBX 사이의 트렁크나 타이 라인에서 사용됩니다. 그라운드 스타트 방식 신호 처리는 접지 감지기와 전류 감지기를 사용합니다. 이 방식을 사용하면 네트워크가 호출음 신호에 관계없이 수신 호출의 오프 후크(seizure)를 표시할 수 있습니다.

자신의 환경에서 어느 신호 처리 방식이 가장 좋은지 판단하려면, 각 신호 처리 방식의 본질적인 caveat를 살펴 보아야 합니다. 이러한 신호 처리 방식들이 처리하려고 하는 문제는 소위 글래어(glare)라고 하는 것입니다. 이것은 양쪽 끝이 동시에 라인을 차지하려고 하는 상황을 가리킵니다. CO 장비의 구형 루프 스타트 인터페이스들은 모든 포트에서의 공통적인 cadence로 공통적인 호출음 생성기를 공유하는데 사용됩니다. cadence의 off 부분에서 포트를 선택했다면, 그 라인은 유휴 상태이고, 호출은 최대 2초 동안 대기할 것입니다. 그 2-초 동안, 다른쪽 끝은 인바운드 호출이 있음을 알지 못하고 호출을 하려고 시도했을 수도 있습니다.

그라운드 스타트는 CO (foreign exchange station [FXS]) 측에서 customer premises equipment (CPE) (foreign exchange office [FXO] PBX, KEY, 공중 전화 등)로 상대측의 연결 차단 상태를 명확하게 표시하여 글래어를 최소로 줄이기 위한 방식입니다.

요즘의 루프 스타트 라인은 calling party control (CPC)의 형태로 상대측 연결 차단 기능을 제공합니다. 이것을 이용하면 라인의 CO 측이 순간적으로 인터페이스의 전원을 차단하여 상대측이 호출을 종료시켰음을 표시할 수 있습니다. 루프 스타트에서도 “점유시 호출음(ringing on seize)” 기능으로 글래어를 최소로 줄일 수 있습니다

시스코의voice 시스템은 루프 스타트 모드에서 FXS 인터페이스에 CPC와 ringing on seize 기능을 제공합니다. 일반 사용자(FXO) 장비가 루프 스타트 모드에서 CPC를 지원하면, Cisco는 루프 스타트 모드를 사용할 것을 권합니다. 루프 스타트 모드 인터페이스가 공급하기 더 쉽(고 일반적으로 더 저렴)하기 때문입니다. 또한, 루프 스타트는 라인 극성에 민감하지 않은데 반해, 그라운드 스타트는 민감합니다. 설치할 때 그라운드 스타트 라인은 잘못 설치하기 훨씬 더 쉽고 바로잡기도 더 어렵습니다.

PBX나 다른 네트워크 간 텔레포니 스위치 (Lucent 5 ElectronicSwitching System [5ESS], Nortel DMS-100, 등등.) 사이에서 주로 사용되는 또 다른 신호 처리 기법은 E&M이라고 합니다. E&M은 일반적으로 ear and mouth나 receive and transmit를 가리킵니다. 다섯 가지 E&M 신호 처리 유형과 두 가지 배선 방식 (2-선 방식과 4-선 방식)이 있습니다. 표 3은 여러 가지 E&M 신호 처리 유형이 비슷하다는 점을 보여줍니다.

표 3 E&M 신호 처리
 
E&M 리드 신호 처리
유형 M 리드 E 리드 
오프 후크 온 후크  오프 후크  온 후크
배터리  접지  접지  개방
II 배터리  개방 접지  개방
III 루프 전류 접지  접지  개방
IV 접지  개방 접지  개방
V 접지  개방 접지  개방
SSDC5  접지 온  접지 오프 접지 온  접지 오프 

미국에서는 Type I과 Type II가 가장 일반적인 E&M 신호 처리 방식입니다. Type V는 미국에서 사용되며, 유럽에서 매우 일반적입니다. type V와 비슷한 SSDC5A는 온 후크 상태와 오프 후크 상태가 역방향이어서 fail-safe 동작이 가능하다는 점에서 다릅니다. 라인이 차단되면, 인터페이스는 기본적으로 오프 후크(통화중) 상태가 됩니다. 모든 유형 중에서, type II와 V만이 대칭이 됩니다(크로스오버 케이블로 직접 연결할 수 있습니다). SSDC5는 영국에서 가장 많이 볼 수 있습니다. Cisco 2600/3600 시리즈는 현재 2-선 시스템과 4-선 시스템을 활용하여 type I, II, III, V를 지원합니다.

E&M 배선도는 부록 A를 참조하십시오. 종종 사용되는 다른 신호 처리 기법은 delay, immediate, wink start 등입니다.Wink start는 발신 장치가 다이얼된 숫자를 보내기 전에 호출 대상 스위치에서 보내는 신호를 대기하는 인-밴드(in-band) 기법입니다. Wink start는 일반적으로 ISDN이나 Signaling System 7 (SS7)와 같은 메시지 중심 신호 처리 방식으로 제어되는 트렁크에서는 사용하지 않습니다.

팩스 첫걸음

패킷 방식 네트워크를 통한 팩스 전송을 설명하기 전에, 먼저 요즘의 PSTN을 통하여 팩스가 사용되는 방식을 설명해야 합니다. 요즘 흔히 사용되는 팩스 장치는 ITU 권고 T.30 프로토콜과 T.4 프로토콜을 구현한 것입니다. T.30 프로토콜은 capabilities negotiation을 위하여 사용되는 메시지와 같은 비 페이지 데이터의 포맷 설정을 규정합니다. T.4 프로토콜은 페이지 이미지 데이터의 포맷 설정을 규정합니다.

Fax over IP

Fax over IP 또는 다른 패킷화된 수단은 단순히 보다 유연성이 있는 방식으로 가용 대역폭을 활용하는 한 가지 방법일 뿐입니다. 이것은 실시간 팩스나 스토-앤-포워드 방식 팩스를 사용하는 방식입니다.

요즘의 PSTN에서, 팩스 장치는 전송(T.30 엔진)을 완벽하게 동기화시키고 페이지 단위로 negotiation합니다. 패킷 방식 네트워크에서 실시간 팩스를 사용하는 경우, T.30 엔진은 Cisco 라우터에 의해 분리되고 복조됩니다. Cisco 라우터는 팩스 장치를 속이고 패킷 방식 네트워크에 수반되는 지연을 허용할 수 있습니다.

패킷 방식 네트워크를 통한 팩스 전송에 대한 더 자세한 내용은, 부록 B를 참조하십시오. 다른 한 가지 팩스 전송 방식은 저장 후 전송(store-and-forward) 팩스라고 합니다. 이 기술은 패킷 방식 네트워크에서 피할 수 없는 대부분의 문제들을 처리할 수 있습니다. 이 솔루션을 구현하려면, 고객이 사용하는 특정한 방식에 따라 몇 초에서 몇 시간까지 팩스 지연을 받아들일 수 있어야 합니다.

팩스 전송 사용자들은 일반적으로 전송을 수신할 때 몇 분 정도의 지연을 느끼지 못합니다. 저장 후 전송 방식 팩스에서는 팩스 전송 내용을 저장했다가 일괄적으로 패킷 방식 네트워크를 통하여 전송할 수 있습니다. 이 방식에서는 PSTN 이용료를 내지 않을 수 있으며, 가장 비용이 적게 드는 팩스 라우팅 경로를 사용하여 팩스를 전송할 수 있습니다. 또한 팩스를 저장했다가 특정한 국가나 지방의 시외 통화 요금이 좀더 유리할 때 전송할 수도 있습니다. 이런 구성에서는 Cisco 라우터가 팩스를 속일 필요가 없기 때문에 팩스 기기에서 발생하는 문제가 줄어듭니다.

그림 1은 텍사스 주의 오스틴에서 런던 근처의 한 장소로 팩스를 전송하는 것을 보여줍니다. PBX는 패킷 방식 게이트웨이를 통하여 오스틴에 있는 팩스 게이트웨이로 팩스 전송물을 라우팅합니다. 팩스 게이트웨이는 그 팩스 전송에 응답한 후에 팩스를 저장합니다. 팩스 게이트웨이의 Least-Cost Routing 알고리즘은 팩스 게이트웨이에게 런던 팩스 게이트웨이로 보통 일반적인 네트워크 트래픽이 줄어드는 두 시간 뒤에 Simple Mail Transfer Protocol (SMTP) 전송을 보내라고 지시합니다. 런던의 팩스 게이트웨이는 SMTP 전송을 수신하면 Least-Cost Routing 알고리즘을 보고 팩스를 전송할 최적 시간을 결정합니다. 팩스를 전송하기 위하여, 팩스 게이트웨이는 Cisco 패킷 게이트웨이를 사용하여 로컬 PSTN 호출을 합니다. 런던의 팩스 게이트웨이는 팩스 전송이 성공적으로 끝났다는 확인 신호를 수신하면, 그 확인 신호를 오스틴의 팩스 게이트웨이로 보냅니다.

그림 1 스토-앤-포워드(Store-and-Forward) 팩스

H.323 첫걸음

H.323는 QoS (Quality of Service)를 보장하지 않는 근거리 통신망을 통하여 멀티미디어(음성, 비디오, 데이터)를 전송하는 것과 관련된 ITU-T 규정입니다. 이 패킷 방식 네트워크는 IP, IPX, 또는 다른 프로토콜일 수 있습니다. H.323은 다른 벤더의 H.323-호환 장비와 표준을 기초로 호환이 됩니다.

H.323 밑에는 H.323 터미널, H.323 MCU, H.323 게이트웨이, H.323 게이트키퍼 등이 있습니다. QoS의 유형을 지정하는 것은 H.323의 범위에 속하지 않습니다. H.323은 LAN을 통한 멀티미디어 통신을 위한 터미널, 장비, 서비스 등을 규정합니다. H.323-호환 터미널은 음성을 전달하는데 필요하며, 비디오와 데이터 전달은 선택적입니다.

Cisco 2600/3600은 H.323 게이트웨이 역할을 하며, 게이트키퍼의 일부 기능을 대신 수행할 수 있습니다. H.323 게이트키퍼는 주소 해석, 사용 권한 통제, 대역폭 관리, 영역 관리 등을 수행하는데 필요합니다. H.323 게이트웨이는 IP 세계와 PSTN, H.320 터미널, V.70 터미널, H.324 터미널, 및 기타 음성 터미널 사이의 게이트 역할을 합니다.

H.323 프로토콜은 오디오, 비디오, 데이터 애플리케이션, 시스템 제어 기능 등으로 구성되어 있습니다. 권장 오디오 CODEC에는 G.711, G.722, G.723, G.723.1, G.728, G.729 등이 포함됩니다. 더 좋은 CODEC가 개발되면, 지정되는 CODEC를 시장이 결정할 것입니다. 현재 voice over IP 포럼에서는 그 애플리케이션을 위하여 G.723.1을 추천하였습니다. 권장 비디오 CODEC에는 H.261과 H.263이 포함됩니다. 데이터 컨퍼런싱은 워크그룹 공동 작업과 같은 애플리케이션에 대해 T.120 규격을 활용합니다.

H.323 터미널에 필요한 다른 구성 요소들에는 H.245, H225.0, RAS (Registration/Admission/Status), 및 RTCP (RTP/RTPControl Protocol) 등이 포함됩니다.

H.245, H.225.0, RAS 등은 시스템 제어 장치로 알려져 있습니다. H.245 제어 채널은 capabilities exchange, 수신측의 모드 설정, 논리적 채널 신호 처리, 및 제어와 표시 등을 위한 신뢰할 수 있는 인-밴드 전송 기능을 제공합니다. TCP는 voice over IP가 신뢰할 수 있는 전송 기능을 제공하는데 사용됩니다. H.245를 이용하면 H.323 장치들이 다른 H.323 장치들에게 그 기능을 제공할 수 있습니다. 이러한 capabilities 중의 일부에는 사용 가능한 CODEC를 지정하는 것이 포함됩니다. 이 시나리오는 negotiation이 아니며 그 capabilities에 나오는 특정한 CODEC를 반드시 사용해야 하는 것도 아니라는 점을 기억해야 합니다.

H.225.0은 q.931의 축소 버전을 활용하여 두 개의 H.323 엔드포인트 사이의 연결을 설정합니다. RAS는 H.323이 H.323 게이트키퍼 게이트웨이와 통신하는데 사용됩니다. 게이트키퍼가 H.323 네트워크에 필요한 것은 아니지만, H.323 네트워크에 있다면 사용해야 합니다. The H.323 권고는 게이트키퍼가 존재해야 하는 위치를 지정하지 않습니다. 각 벤더는 게이트키퍼 기능을 어디에 넣어야 하는지 결정해야 합니다.

RTP와 RTCP는 H.323 규정에 규정되어 있습니다. H.323 호출 셋업과 제어 프로세스가 완료된 후에, 오디오 패킷과 비디오 패킷은 UDP (User Datagram Protocol)를 통하여 보내집니다(표 4) 참조. 스트림형 오디오와 비디오를 지원하기 위하여, 이 규격은 RTP 헤더를 요청합니다. RTP 헤더에는 타임 스탬프와 시퀀스 번호가 들어 잇으므로, 수신 장치는 패킷을 동기화하여 연속적인 사운드 스트림을 재생함으로써 지터와 레이턴시를 제거하는데 필요한만큼 버퍼 처리를 할 수 잇습니다.

RTP 규정은 RTP 서버가 짝수 포트 번호를 사용할 것을 규정하며, RTCP는 그 다음 사용할 수 있는 홀수 번호를 사용할 것을 규정합니다.

RTP를 제어하는데 사용되는 RTCP는 신뢰성 정보를 수집하고 주기적으로 이 정보를 세션 참여자들에게 전달합니다. RTCP는 RTP가 사용하는 세션 대역폭의 5 퍼센트 이상을 사용할 수 없습니다.

표 4 UDP 포트 번호
 
시작 번호  끝 번호  애플리케이션 우선 순위 
16383  지정되지 않음 가장 낮음
16384 32767  오디오 가장 높음
32768 49151  화이트보드  중간
49152  65535  비디오 낮음

Packet Voice

음성, 팩스, H.323 등에대해서 설명했으므로, 이제 다른 종류의packet voice 애플리케이션, legalities, 및 이러한 차세대 텔레포니 네트워크를 최적 음성 품질을 내도록 설계하는 법 등을 설명하겠습니다. 이러한 네트워크를 셋업하는 방법을 온전히 이해하려면, 애플리케이션들을 이해해야 하며, 특정한 네트워크를 설계할 때 인식해야 할 caveat와 legalities도 이해해야 합니다.

많은 국가들에서는 voice over IP가 텔레포니 서비스를 제공하는 방식을 근본적으로 바꾸었기 때문에 voice over IP에 상당히 관심을 가지고 있습니다. 파키스탄과 대만과 같은 일부 국가들은 로컬 전화 회사와의 경쟁을 우려하여 IP 텔레포니를 완전히 금지시켰습니다. 미국에서는, 현까지는 Federal CommunicationsCommission에서 아무런 지시도 없지만, LATA (local access and transport area) 바운더리를 우회하여 법률의 “정신”을 파괴하지 못하도록 특정한 시스템 구성은 피해야 합니다. 1996년 8월에 FCC가 인터넷 텔레포니를 규제해야 하는가라는 질문에 대해 FCC의 회장 Reed Hundt는 이렇게 대답했습니다.

“우리는 로컬 전화 시장을 개방하여 경쟁하게 만드는 규칙을 만들어야 하며, 본인은 FCC가 금년 8월에 그렇게 하기를 바랍니다. 하지만 우리가 만들어야 하는지 확신이 서지 않는 다른 규칙들도 있습니다, 라고 Hundt는 말합니다.

“FCC는 미국의 Carriers’ Telecommunications Association으로부터 인터넷 폰 소프트웨어 판매를 규제해달라는 요청을 받았습니다. 그 소프트웨어 프로바이더들이 원격 통신에 적용되는 규칙을 준수하지 않기 때문입니다.

“본인은 이 시점에서 올바른 대답은 소프트웨어 프로바이더들을 규제하는 것이 아니라 인터넷 텔레포니에 기존의 서킷 스위치 음성 전화 사업자들에게 적용되는 동일한 규칙을 적용하게 하는 것이라고 확신합니다. 인터넷에서, 음성 트래픽은 단순히 특정한 종류의 데이터에 불과하며, 그 데이터에 기존의 규제 항목을 적용하는 것은 생산적이 아니며 의미가 없습니다.

“더 중요한 점은, 새로운 테크놀로지에 낡은 규칙을 적용시킬 방법을 찾아서는 안된다는 점입니다. 그보다는, 새로운 테크놀로지가 정말 더 좋은 것이라면 시장에서 활발하게 성장할 수 있도록 낡은 규칙을 고치려고 노력해야 합니다. “인터넷 텔레포니는 기존의 서킷 스위치 방식 음성 텔레포니에 대한 시기적절한 경쟁력이 있는 대안이 될만한 자격이 충분히 있습니다. 무엇보다도, 셀룰러 산업계의 성장이 보여주는 것처럼, 사람들은 다른 이익을 위해서는 상당한 수준의 품질을 희생시킬 의사가 있습니다. 셀룰러의 경우, 장점은 사실상 어느 곳에서든지 전화를 걸 수 있다는 점입니다. 인터넷 텔레포니의 경우에는, 엄청나게 저렴한 가격이 장점입니다. 이 점은 국제 전화와 같은 경우에 특히 그러합니다.”

회장 Hundt와 FCC가 현재까지는 패킷 텔레포니와 관련하여 특정한 규제를 하지 않았지만, 미국 내에서는 어느 정도의 규제가 필요합니다. 대부분의 국가에서, 원격 통신은 정부 기관이나 “텔레포니 관할 기관”에 의해 규제를 받습니다. 패킷 텔레포니 네트워크를 사용하기 전에, 항상 각 국가별로 패킷이 통과하게 되는 텔레포니 네트워크가 어느 것인지 확인하는 것이 좋습니다. 다음은 패킷 방식 네트워크를 설계하는 일반 규칙 목록입니다. 이 규칙들은 언제든지 변경될 수 있으며, 패킷 텔레포니 네트워크를 채택하기 전에 특정한 규제 사항을 조사해야 합니다.

  • 텔레포니 관할 영역 내에서는, 기업체가 자기 영역 내에서 자체 음성 호출 기능을 지원하기 위하여 패킷 텔레포니를 채택하는 것은 거의 항상 정당합니다. 이 경험상의 법칙에는 회사 직원들, 회사의 계약자들, 이 회사와 밀접한 관계가 있는 다른 회사의 직원들 등으로 구성되는 “사용자 그룹” 내에서만 통화해야 한다는 조건이 붙습니다.
  • IP 텔레포니를 통한 기업체간 통화는 이 기업체들이 밀접한 사업상의 관계가 있고 통화가 사용자 그룹 내에서만 이루어진다면 일반적으로 허용이 됩니다.
  • 특정한 애플리케이션에서는, PSTN에서 시작하여 packet voice 네트워크를 경유하여 호출 대상 사용자 그룹이나 기업체의 한 구성원에게 연결되는 것은 일반적으로 허용이 됩니다. 단, “텔레포니 관할 영역” 경계선을 넘지 말아야 합니다. (즉 그 통화는 다른 나라로 넘어가서는 안됩니다).
  • 패킷 텔레포니 네트워크가 공공 네트워크 전화를 다른 공공 네트워크 전화에 연결하는데 사용되는 경우, packet voice 프로바이더는 일반적으로 전화 사업자로 간주되며, 따라서 그 텔레포니 관할 기관의 규제와 제한을 받게 됩니다.
  • 그 호출의 발신지가 PC용 애플리케이션(NetMeeting)이었다면, 일부 텔레포니 관할 기관은 이 시나리오를 비-텔레포니 형태로 간주하며, 따라서 그 통화가 모종의 게이트웨이를 통하여 공중망으로 넘어온다고 해도 규제 대상이 되지 않습니다. 이 시나리오는 변경될 가능성이 있으므로, 이런 종류의 네트워크를 채택하기 전에 그 점을 조사해 보아야 합니다.
이전의 규칙들과 권고를 고려하여, 기업체들은 기존의 리스 회선, PBX-PBX 연결 라인 등을 합법적으로 사용할 수 있는 모든 경우에 packet voice 네트워크를 채택할 수 있습니다. 따라서, tie-line 네트워크를 모델로 사용하여 패킷 텔레포니 네트워크를 설계하고 채용하는 것이 좋습니다.

애플리케이션

패킷 텔레포니를 추진시키는 주요 요소 중의 하나는 비용 절감입니다. 현재, 대부분의 기업체의 IS 예산은 변동이 없는데, 기업의 통신/인프라스트럭처 비용은 급속하게 증가하고 있습니다. 기업체들은 가능한 모든 경우에 돈을 절약하는 방법을 찾아야 합니다. 기업체들이 이처럼 예산과 싸우는 방법 중의 하나는 음성 네트워크와 데이터 네트워크를 통합하는 것입니다. 두 개의 네트워크를 별도로 운영하는 것은 더 이상 재정면이나 기술적인 면으로 의미가 없습니다. 데이터/음성 통합을 실제로 고려하고 있는 기업체들은 이 두 가지 네트워크를 통합함으로써 이루어지는 가능한 비용 절감을 보여주는 연구 조사를 수행했습니다. 데이터/음성 통합을 달성하려는 기업체들에게는 많은 대안이 있습니다. 기업체들이 선택할 수 있는 대안 중에는 voice over Frame Relay, voice over ATM (Asynchronous Transfer Mode), voice over IP 등이 있습니다. 이 모든 대안들은 음성/데이터 통합과 관련된 특정한 문제들에 대해 특정한 솔루션을 제시하고 있습니다.

톨 바이패스

Toll bypass는 기업체들이 voice over IP 네트워크를 채용하기 위하여 찾고 있는 가장 일반적인 애플리케이션입니다. Toll bypass를 이용하면 기업체들이 현재 PBX-PBX 네트워크를 중계하는 tie line을 교체할 수 있으며 기존의 데이터 인프라스트럭처를 통하여 음성 호출을 라우팅할 수 있습니다(그림 2 참조). 기업체들은 또한 voice over IP를 사용하여 원격 사무실에 있는 비교적 작은 키 시스템을 교체하면서 동시에 비교적 큰 음성 관련 필요가 존재하는 사이트에서는 보다 밀도가 큰 voice over IP 장비를 계속 사용할 수 있습니다. voice over IP를 사용하는 것의 또 다른 장점은 사무실 간에 실시간 팩스 릴레이를 사용할 수 있다는 점입니다. 연구 조사에 따르면 장거리 통화의 대부분은 팩스 트래픽이라고 합니다. 사실, 일본으로 연결되는 장거리 통화의 60 퍼센트가 팩스입니다

그림 2 대기업체의 Toll Bypass

차세대 텔레포니 캐리어

현재, 대부분의 ISP (Internet service providers) 들은 각 일반 가입자들에게 한 달에 겨우 20 달러씩 받으면서 이윤을 남겨야 하는 문제에 직면하고 있습니다. 또한, 제한된 수의 기업 클라이언트만이 비교적 높은 이윤을 남길 수 있습니다. ISP들은 새로운 가입자들을 확보하면서 동시에 유료 서비스를 추가할 수 있는 방법을 찾아야 합니다. 많은 서비스 프로바이더들은 voice over IP를 기초로 텔레포니 서비스를 제공하면서 기존의 인프라스트럭처를 활용할 계획을 세우고 있습니다. (많은 ISP들이 이미 그렇게 하고 있습니다) 그렇게 할 만한 충분한 이유가 있습니다. 음성 관련 시장이 1 조 달러 산업이며 국내 장거리 시장은 7000억 분입니다. 한 ISP가 분당 7.25 센트에 시장의 0.1 퍼센트만 차지하고 있다고 해도, 상당한 수입을 올릴 수 있습니다.

대부분의 ISP들은 이미 상당한 자본을 투자하여 고속 IP 인프라스트럭처를 구축했습니다. QoS 특성을 채용하여 다양한 레벨의 서비스를 창출할 수 있다면, 이러한 서비스 레벨을 기초로 새로운 애플리케이션을 판매할 수 있습니다. 지금까지는, 이러한 새로운 서비스 중에서 가장 흥미를 끄는 것이 음성입니다.

예를 들어, 캘리포니아에 있는 집에서 보스톤에 계신 할머니께 전화를 하려고 한다고 가정해 봅시다. 할머니가 테크놀로지 전문가라면 Microsoft Netmeeting를 사용하여 인터넷 채팅을 즐길 수 있겠지만, 일반적인 할머니라면 기존의 전화 통신망을 사용해야 합니다. 다른 방법이 있습니까? 패킷화된 텔레포니 서비스를 제공하는 ISP가 있다면, 다음 두 가지 방법으로 그 네트워크를 액세스할 수 있습니다.

첫번째는, 기존의 다이얼업 연결 장치를 사용하여 H.323-호환 애플리케이션 (Microsoft Netmeeting, 그림 3 참조)을 시작한 다음, 그 ISP의 게이트웨이를 사용하라고 지시할 수 있습니다. ISP는 사용자의 신원을 확인한 다음, packet voice 게이트웨이 액세스 권한을 부여하여 할머니에게 전화 통화를 할 수 있게 마련합니다. 할머니는 당신이 패킷화된 음성 전화를 걸고 있다는 것을 알 수 없습니다. 일반적인 전화를 사용하여 통화를 하기 때문입니다.

ISP가 패킷화된 voice 서비스를 제공할 수 있는 또 한 가지 방법은 1 800 COLLECT와 비슷한 800-번 서비스를 제공하는 것입니다. 사용자가 요금 납부 계정을 가지고 있거나 x 분 동안의 통화를 할 수 있는 카드를 사용하면 됩니다. 800 번을 돌리고, 액세스 코드를 입력하면, 패킷화된 음성 통신망을 이용할 수 있습니다.

이 두 가지 시나리오 모두, ISP가 일반 전화 통신 사업과 관련된 모든 법규와 제한 규정의 적용을 받는 차세대 텔레포니 기업이 된다는 점에 반드시 유의해야 합니다.

차세대 콜센터와 기타 유익한 애플리케이션

오레곤 주에서 웹을 검색하고 있다고 가정해 봅시다. 플로리다 주의 어떤 회사에서 흥미있는 무엇인가를 보게 되었다고 합시다. 제품을 구입하고 싶은데, 구입하기 전에 질문할 것이 하나 있습니다. 그런데, 웹 페이지에서는 그 질문에 대답해 주지 않습니다. 이 작은 회사에서는 800 번 서비스를 제공하지 않습니다. 그렇다고, 지금 다이얼업 연결을 끊고 싶지는 않습니다. 하지만 그 회사의 웹 페이지의 버튼을 하나 누르면 Netmeeting 애플리케이션이 실행되면서 고객 지원 담당 직원에게 곧바로 연결이 된다면 어떻겠습니까? 이 담당 직원은 질문에 대답을 해 주고 주문을 받을 것입니다. 말다툼할 필요도 없고, 소란을 피울 일도 없으며, 소비자와 회사가 모두 만족할 수 있습니다. 그 기업체는 800 번 전화 관련 비용을 절감할 수 있고 이용자는 오레곤에서 플로리다까지 전화를 걸 필요가 없으니까 시간과 돈이 모두 절약됩니다.

물론, 이런 애플리케이션이 모두 쓸모가 있으려면, 그런 서비스 레벨이 있어야 하고 품질에 대해 설정된 예상치가 있어야 합니다. packet voice 네트워크를 사용하면, 소비자들이 만족할 만한 음성 품질을 유지하면서 많은 비용을 절감할 수 있다는 점을 알게 됩니다. 예를 들어, 소비자들이 이동 전화를 사용할 때 품질이 좀 떨어지기는 하지만 어디서든 전화를 걸 수 있기만 하다면 기꺼이 요금을 더 지불합니다. 패킷 텔레포니 산업이 직면하고 있는 문제는 IP 방식 텔레포니와 관련된 형편없는 품질에 대한 인식입니다. 이러한 인식을 만들어낸 진정한 범인은 현재의 인터넷 애플리케이션과 PC 방식 I-폰 애플리케이션에 QoS가 없다는 점입니다. 고객들은 잘 설계된 음성 라우터와 연결된 QoS 네트워크가 있으면 높은 수준의 음성 품질을 제공할 수 있다는 점을 볼 수 있어야 합니다.

너트와 볼트

실제 시스템 분석 이제 Cisco의 voice over IP 시스템을 살펴봅시다. 2-선 루프에서 아날로그 전화로 음성 패킷을 처리하여 완전히 패킷화된 음성 샘플을 만들어내는 경로를 볼 수 있습니다. 뿐만 아니라, Cisco가 VAD (voice activity detection), H.323 negotiation, call setup 등을 처리하는 방식도 볼 수 있습니다.

packet voice 전화 호출을 Cisco IOS voice over IP 라우터를 통하여 연결하는 일반적인 순서는 다음과 같습니다. 이 예는 특정한 call flow가 아니라 packet voice 네트워크를 통하여 전화 호출을 하면 어떤 일이 진행되는지를 포괄적으로 보여주는 것입니다. 2 명의 통화자가 관련된 음성 호출의 일반적인 흐름은 모든 경우에 동일하며, 일반적으로 다음 순서대로 진행됩니다.

1. 사용자가 수화기를 들고 로컬 루프가 연결된 장치(예를 들면, PBX, PSTN CO 스위치, 또는 Cisco 라우터의 신호 처리 애플리케이션) 등으로 오프 후크 상태 신호를 보냅니다.

2. 세션 애플리케이션이 다이얼 톤을 보내고 사용자가 전화 번호를 다이얼할 때까지 기다립니다.

3. 사용자가 번호를 다이얼하면, 세션 애플리케이션이 그 번호를 차례대로 기억합니다 .

4. 번호가 다이얼 플랜 맵퍼를 통하여 IP 호스트로 맵핑이 되고, IP 호스트는 수신 전화 번호로 직접 연결하거나 PBX로 연결을 합니다. 이 연결은 호출을 완료하는 것으로 끝납니다.

5. 세션 애플리케이션이 세션 프로토콜(H.323 - 그림 3 참조)을 실행하여 IP 네트워크 상에서 각 방향으로 전송 채널과 수신 채널을 설정합니다. 그 동안에, 호출된 측에 관련된 PBX가 있다면, 수신 전화 번호 호출을 완료하는 것으로 끝납니다.

6. RSVP (Resource Reservation Protocol)를 사용하고 있다면, IP 네트워크를 통하여 원하는 QoS를 달성할 수 있도록 RSVP 예약을 합니다.

7. voice CODECs/compressors/decompressors 등이 양쪽 끝에서 켜지고, 대화는 RTP/UDP/IP를 프로토콜 스택으로 사용하여 진행됩니다.

8. 모든 호출 진행 표시와 기타 인밴드(in-band)로 전달할 수 있는 신호들(예를 들면, 원격 전화 호출 신호, 라인 통화중 신호, 등)은 end-to-end 오디오 채널이 설정되자마자 음성 경로에서 차단됩니다. 음성 인터페이스를 통하여 감지할 수 있는 모든 신호 처리 (예를 들면, 호출이 완료된 후의 인밴드 DTMF [dual tone multifrequency] 숫자)는 어느 한쪽 끝에서 세션 애플리케이션에 의해 포착이 되어 RTCP APP 확장 메커니즘을 사용하여 RTCP로 캡슐화되어 IP 네트워크를 통하여 전달됩니다.

9. 어느 한쪽 끝이 끊어지면, RSVP 예약이 해제(RSVP가 사용되는 경우)되고, 세션이 끝나며, 상대측 끝은 다른 오프 후크 신호를 대기하면서 유휴 상태로 들어갑니다.

다이얼 플랜 맵퍼가 수신 전화 번호에 도달하는데 필요한 IP 주소를 판단할 때, 세션이 호출됩니다. 이 세션은 임의의 프로토콜을 호출할 수 있지만, Cisco IOS 소프트웨어의 경우에는, H.323이 현재 세션 애플리케이션입니다. 그림 3은 H.323 세션을 구성하기 위해 취하는 단계들을 분해해 놓은 것입니다.

그림 3 H.323 세션

초기 TCP 연결은 일반적으로 H.323 세션의 H.222 부분을 negotiation하는 포트 1720에서 이루어집니다. H.323 세션의 H.225 부분에서, H.323 세션의 H.245 부분에 해당하는 TCP 포트 번호는 다시 호출하는 장치로 전달됩니다. H.323 세션의 H.245 부분에서, RTP 주소와 RTCP 주소는 호출하는 장치와 호출받는 장치 사이에서 전달됩니다. 사용되는 RTP 주소는 16384 더하기 호출하는 장치에서 사용할 수 있는 채널의 크기의 네 배의 범위 이내가 됩니다. H.225와 H.245 세션의 모든 부분이 완료된 후에, 오디오는 RTP/UDP/IP를 통하여 스트림 처리됩니다.

연구에 따르면, 전화 통화의 50 퍼센트 이상이 폐기된 대역폭으로 구성될 수 있다고 합니다. 아무도 이야기를 하지 않기 때문입니다. 기존의 PSTN 네트워크는 전화 통화 당 64-kbps 채널 전체를 할애해야 하지만, 패킷화된 음성은 음성이 없는 상태가 감지되면 패킷 전송을 멈추어 사일런스(silence) 상태를 활용할 수 있습니다.

그림 4에 나오는 것처럼, VAD는 음성의 강도(dB 단위)를 감지하여 음성 패킷화를 차단할 시기를 결정하는 일을 합니다. VAD에는 음성이 끝난 시점과 음성이 시작한 시점을 결정하고 음성과 배경 소음을 구분해야 한다는 문제가 근본적으로 내재되어 있습니다.

그림 4 음성 감지

일반적으로 음성 진폭이 떨어지는 것이 VAD에 감지되면, VAD는 음성 패킷화를 멈출 때까지 일정 시간 동안 기다립니다. 이 지정된 시간을 hangover라고 하며, 일반적으로 200 ms입니다. VAD와 관련된 또 다른 근본적인 문제는 음성이 시작된 때를 감지하는 것입니다. 일반적으로 문장의 첫 머리는 잘려나가게 됩니다. 이 형상을 선두음 클리핑(front-end speech clipping)이라고 합니다.

보이스 튜닝

ITU-T에는 특정한 기능이 부족한 음성 네트워크를 기획할 수 있도록 마련된 권고들이 있습니다. ITU-T 권고 G.113은 다양한 시나리오에서 기대할 수 있는 음성의 품질을 알려 주는 여러 가지 요소들을 다룹니다. ITU-T는 이러한 요소들을 다음과 같은 총 손상값(total impairment value)이라고 하는 숫자값으로 만듭니다.

총 손상값 Itot는 개별적인 손상 요소들의 합계입니다.

Itot = Io + Iq + Idte + Idd + Ie

여기서

Io는 최적 상태가 아닌 총 라우드니스 등급에 의해 발생하는 손상을 가리킵니다. 1
Iq는 PCM 방식 수량화 왜곡 현상에 의해 발생하는 손상을 가리킵니다. 1
Idte는 대화자 에코에 의해 발생하는 손상을 가리킵니다. 2
Idd는 긴 단방향 전송 시간에 의해 발생하는 음성 통신 장애를 가리킵니다. 2
Ie는 연결에 사용되는 특수한 장비, 특히 비-파형 낮은 비트 속도 CODEC에 의해 발생하는 전송 손상을 가리킵니다.
음성 튜닝의 주 요점은 먼저 레이턴시, 지터, 총 지연 등을 처리할 수 있도록 네트워크를 설계하는 것입니다. 또한, 음성 네트워크를 기획할 때, 손실도 고려해야 합니다.

음성 네트워크에 설계시에 내장시켜야 하는 또 다른 요소는 손실입니다. 텔레포니 환경에서, 음성 품질을 유지하려면 일정한 수준의 손실을 내장시켜야 합니다.

EIA/TIA-464는 포트 사이에 설정되는 손실이 있어야 한다는 점을 규정합니다. 손실 관련 요건을 인터페이스마다 차이가 있으며, 일부 인터페이스는 FCC 요건에 맞는 미리 지정된 손실로 환경 설정이 되어 있습니다.

전화 통신 산업계는 다음 두 가지 방식으로 아날로그 인터페이스에서 레벨을 조정하고 있습니다.

  • TLP (Transmission-level point) - 채널 뱅크와 같은 트렁킹 장비에서 대체로 사용하는 용어로 의미는 다음과 같습니다.
    • 0 dB TLP 이 라인은 정격 손실이 0 dBm입니다.
    • -3 dB TLP 이 라인은 정격 손실이-3 dBm입니다.
    • +3 dB TLP 이 라인은 정격 손실이 +3 dBm입니다.


      1 Io 와 Iq 는 음성과 관련하여 동시에 발생하는 손상에 의해 발생합니다.
      2 Idte 와 Idd 음성 신호와 관련하여 지연되는 것으로 보이는 손상에 의해 발생합니다.
       

  • Gain/pad - 신호를 다시 0 dBm (정격 손실)으로 돌아가게 하려면 라인에 얼마나 gain이나 감쇠를 추가해야 하는지를 가리킵니다. 즉,
    • 0 dB gain 감쇠 없음. 라인이 0 dBm 상태입니다
    • -3 dB pad 또는-3 dB gain 3 dB의 감쇠. 라인은 +3 dBm hot입니다.
    • -3 dB gain 또는-3 dB pad 3 dB 증폭. 라인은 -3 dBm weak입니다.
Cisco 2600/3600 voice over IP 아날로그 인터페이스는 gain 방식을 사용합니다. 다른 인터페이스들 (FXO, FXS, E&M)은 Cisco IOS 코드에 내장되어 있는 다른 기본 레벨을 사용합니다. 이러한 기본 레벨은 Cisco IOS CLI (command-line interface)를 사용하여 조절할 수 있습니다. 이 값들이 그 안에 있지만, show 명령을 사용해도 해당 인터페이스의 실제 아웃풋이 나타나지는 않습니다(예를 들어, FXSTLP 아웃풋은 그 인터페이스에 대해 -3 dB로 설정되어 있지만, show 명령을 사용하면 0 dB가 기준점으로 나타납니다). 다양한 인터페이스의 내장된 값은 다음과 같습니다.

FXS_TLP_INGAIN 0

FXS_TLP_OUTGAIN (-3)

FXO_TLP_INGAIN 0

FXO_TLP_OUTGAIN (-3)

E&M_TLP_INGAIN 0

애플리케이션에 따라 다르지만, 이 값들은 최대 음성 품질이 가능하도록 조정해야 합니다. 보통, 이것은 PBX에 연결되어 있으면, PBX가 필요에 따라 gain이나 감쇠를 수정할 수 있게 해야 하지만, Cisco 2600/3600이 PBX처럼 작동한다면, 필요에 따라 gain이나 감쇠를 수정하도록 Cisco IOS 라우터를 환경 설정해야 함을 의미합니다.

FXS_TLP_INGAIN 0

FXS_TLP_OUTGAIN (-6)

FXO_TLP_INGAIN (-2)

FXO_TLP_OUTGAIN (-3)

E&M_TLP_INGAIN 0

E&M_TLP_OUTGAIN 0

아날로그 네트워크에서, 호출을 시작하는 스위치는 트렁크 연결의 전송 측과 수신측에 2 dB의 손실을 삽입해야 합니다. 호출을 종료하는 스위치는 전송 트렁크와 수신 트렁크 모두에 2 dB의 손실을 삽입해야 합니다. 이 시나리오에서는 연결 장치에 총 4 dB의 end-to-end 손실을 설정합니다.

대부분의 텔레포니 네트워크에서 일반적인 end-to-end 손실을 계산하는 공식이 있습니다. 이러한 공식은 다양한 텔레포니 안내서에서 알아낼 수 있습니다. Cisco 2600/3600에서는 특정한 음성 부분에서 인풋/아웃풋 gain과 감쇠를 조정하여 수신된 gain이 적절한 수준으로 조정이 되게 할 수 있습니다. 호출이 PSTN을 통과할 때, 음성 레벨을 여러 dB씩 감쇠시킬 수 있습니다. Cisco 2600/3600에서는 Cisco IOS 소프트웨어 CLI를 통하여 gain을 적절한 레벨로 조정할 수 있습니다.

아웃풋 감쇠는 FXS 포트가 PBX에 연결되어 있지 않을 때에만 설정해야 합니다. 그런 경우, 아웃풋 감쇠는 6 dB로 설정해야 합니다. gain을 적절하게 조정할 수 있는 가장 좋은 방법은 레퍼런스 -Db 값을 생성할 수 있는 톤 생성기를 사용하는 것입니다. 이러한 레퍼런스 톤을 생성하는데 가장 흔히 사용되는 장치 중의 하나가 Metro Tel MT-139. 톤 생성기가 없다면, 일반적인 송수화기를 사용할 수 있습니다. 대부분의 일반 송수화기에서는 하나의 DTMF 숫자를 사용하면 -6 dB 톤이 생성되고, 두 개의 숫자를 사용하면 -3 dB 톤이 생성됩니다.

라우터에서 gain을 설정할 때 이것이 가장 효과적인 방법이라는 점을 기억하시기 바랍니다. Cisco 2600/3600에서는 특정한 포트에 -6 dB 에서 14 dB의 손실이 발생할 수 있습니다. 14 dB이상의 손실이 필요하다면, 14 dB를 입력해야 합니다. 또한, 이러한 손실은 포트 별로 발생하므로 각 인터페이스 (E&M, FXO, FXS)를 각각 독립적으로 설정할 수 있다는 점을 기억해야 합니다.

한 가지 예 (시나리오 1)는 FXO가 IP 네트워크를 통하여 다른 FXO 인터페이스에 연결되어 있는 경우입니다. 이 FXO 인터페이스들은 PSTN이나 PBX에 직접 연결시킬 수 있습니다. 그림 5에 나오는 것처럼, 라우터 A의 FXO 포트의 인풋 gain은 전화 A에서 나오는 감쇠가 단지 2 dB로 줄어들 수 있도록 조정해야 합니다. 라우터 B의 FXO 포트의 gain은 조정해서는 안됩니다. gain 조정은 PBX에서 해야 합니다. PBX가 gain을 조정할 수 없다면, gain은 시스코 라우터에서 조정해야 합니다.

그림 5 PBX와 PSTN을 통한 FXO-FXO 연결

참고: 시작하기 전에, 그 I/O (input/output) gain과 감쇠가 Cisco 2600/3600에서 0 dB로 설정되어 있는지 확인하십시오.

단계 1. PSTN을 통하여 라우터 A (호출하는 장치)로 호출을 할 수 있도록 테스트 장치 (Metro Tel MT-139)를 연결하십시오. 호출은 그곳에서 시작하여 IP를 통하여 라우터 B로 전달됩니다.

단계 2. 라우터 B (호출받는 장치)에 연결된 PBX의 아날로그 인터페이스에 테스트 장치를 연결하십시오.

단계 3. 테스트 장치 A를 1044 Hz-AT-0 dB 톤을 보내도록 설정하여 그 톤을 테스트 장치가 수신하게 하십시오. 테스트 장치를 구할 수 없다면, 참고를 참조하십시오.

단계 4. 라우터 A에서, “show call active voice”라고 입력하십시오. 전화 통화를 끊으십시오. 이 값이 -2 dbm이 아니라면, 그 포트에서 인풋 gain을 조정해야 합니다. 예를 들어, InSignalLevel에 의해 표시되는 값은 -1입니다. 그 포트의 gain 인풋을 -1로 변경하면, 그 결과는 -2 dB의 순 손실이 될 것입니다. InSignalLevel이 표시하는 값이 -16 dBm 이하라면, 그 포트의 gain 인풋을 설정할 수 있는 최대 gain인14 dB로 변경하십시오.

단계 5. gain이 가능한한 -2 dB에 가까워질 때까지 앞의 단계들을 반복하십시오. 환경 설정 내용을 저장하십시오.

단계 6. 라운터 B가 PBX에 연결되어 있으므로, PBX는 필요에 따라 gain/감쇠를 조정할 수 있습니다. (참고: 어떤 PBX들은 일정한 신호 레벨이 마련되어야 합니다. 그런 경우, 그 PBX 관련 권장 사항에 따라 레벨을 조정하십시오.)

시나리오 2에는 송수화기에 직접 FXS 인터페이스로 연결된 라우터가 관련되어 있습니 다. 그 다음에 두번째 라우터가 FXO 포트에서 PSTN으로 직접 연결됩니다. 그림 6에 나오는 것처럼, FXO 포트는 시나리오 1과 동일하게 설정해야 합니다 (즉, 라우터의 디 지털 인풋 gain을 조정하여 전화 A에서 라우터 A의 FXO 포트로 전달되는 전송 손실 이 2 dB가 되게 하십시오). FXO에서의 디지털 아웃풋 감쇠는 제로로 설정해야 합니다. FXO 인터페이스가 PSTN이 아니라 PBX에 직접 연결되어 있다면, 시나리오 1에서와 동일한 프로시저를 사용할 것입니다.

그림 6 PSTN을 통한 FXO-FXS 연결

단계 1. 라우터 B가 FXS 인터페이스에서 6 dB의 아웃풋 감쇠를 제공하도록 설정되어 있는지 확인하십시오. (FXS 인터페이스는 3 dB의 감쇠로 하드 코딩되어 있으므로, Cisco IOS CLI를 통하여 설정해야 하는 감쇠는 3 Db 뿐입니다.)

단계 2. 라우터 A를 통하여 라우터 B로 연결이 되도록 테스트 장치를 연결하십시오.

단계 3. 라운터 A에서 라우터 B로 테스트 호출을 하십시오. 라우터 A에 연결된 테스트 장치가 0 dB에서 1004-Hz 톤을 보내도록 설정하십시오.

단계 4. 라우터 A에서 “show call active voice”라고 입력하십시오. 전화 호출을 끊으십시오. 이 값은 -2 dB이어야 합니다. 이 값이 -2 dBm이 아니라면, 그 포트에서 인풋 gain을 조정해야 합니다. 예를 들어, InSignalLevel이 표시하는 값이 -1이라고 합시다. 그 포트의 gain 인풋을 -1로 변경하면, 그 결과는 -2 dB의 순 손실이 될 것입니다. InSignalLevel이 표시하는 값이 -16 dBm 이하라면, 그 포트의 gain 인풋을 설정할 수 있는 최대 gain인 14 dB로 변경하십시오.

단계 5. 인풋 gain이 가능한한 -2 dB에 가까운지 확인하고 필요하다면 단계 3과 4를 반복하여 gain을 조정하십시오.

단계 6. 환경 설정 내용을 저장하십시오.

참고: E&M 인터페이스를 환경 설정할 때, 시나리오 1과 2에서 설명한 방법대로 해야 합니다. 다음 아웃풋은 시나리오 1에서 나오는 “show running”과 show call active voice입니다. 인풋 gain을 수정한 후에 InSignalLevel이 바뀐 것에 유의하십시오.

라우터 A 환경 설정 실행(gain 변경전)

hostname Router A
!
!
dial-peer voice 9 voip
destination-pattern +9
session target ipv4:10.1.1.1
!
dial-peer voice 8 pots
destination-pattern +8
port 1/0/0
!
!
voice-port 1/0/0
!
voice-port 1/0/1
!
end

라우터 A Show Call Active Voice의 일부(gain 변경전)

OutSignalLevel=-18
InSignalLevel=-22

라우터 A 환경 설정 실행(gain 변경후)

hostname Router A
!
dial-peer voice 9 voip
destination-pattern +9
session target ipv4:10.1.1.1
!
dial-peer voice 8 pots
destination-pattern +8
port 1/0/0
!
!
voice-port 1/0/0
input gain 14
!
voice-port 1/0/1
!
end

라우터 A Show Call Active Voice(gain 변경후)

OutSignalLevel=-18
InSignalLevel=-8

라우터 B 환경 설정 실행(gain 변경전)

hostname Router B
!
dial-peer voice 9 pots
destination-pattern +9
port 1/1/0
!
dial-peer voice 8 voip
destination-pattern +8
session target ipv4:11.1.1.1
!
!
voice-port 1/1/0
!
voice-port 1/1/1
!
end

라우터 B Show Call Active Voice의 일부(gain 변경전)

OutSignalLevel=-27
InSignalLevel=-14

라우터 B 환경 설정 실행(gain 변경후)

hostname Router B
!
dial-peer voice 9 pots
destination-pattern +9
port 1/1/0
!
dial-peer voice 8 voip
destination-pattern +8
session target ipv4:163.179.16.94
!
voice-port 1/1/0
input gain 12
!
voice-port 1/1/1
!
end

라우터 B Show Call Active Voice(gain 변경후)

OutSignalLevel=-27
InSignalLevel=-2 

 

업데이트 1999년 9월 30일

All contents copyright (C) 1992--1999 Cisco Systems Inc. Important notices. 

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 수행 프로젝트 )/참여자주도형 정보공유 시스템 [2011.12~2012.02] VoIP

자료조사(3) - VOIP

2011/11/25 11:36
VOIP(Voice Over IP)라는 것은 용어 해석그대로 IP를 통하여 사람의 보이스를 전달하는 것

환경 구성 
 - 리눅스 머신 (HUINS PXA255보드에서 작동하는 커널2.4x버젼)
 - HP의 PDA
 
역할  
 - HUINS PXA255보드는 PDA끼리의 연결을 위한 중앙서버역할
 - PDA는 VOIP를 위한 클라이언트 즉 단말기의 역할

설명
PDA자체의 CPU가 성능이 그리 좋지는 않다.
초창기에 OGG인코딩을 스트리밍하여 전송양을 줄여보려 했으나, 이는 오히려 인코딩/디코딩시에
시간이 더욱 소모되어 저사양의 PDA에서는 오히려 해가 될거라 판단했다.
그래서 RAW정보 자체를 그대로 전송하기로 결정하였다.
제한조건은 다음과 같다.
VOIP상에서 홀펀칭(STUN이라고도 불리운다.) 을 구현하려 했으나 실패한 관계로, PDA는 GLOBAL IP를 갖는다(모든단말), 혹은 모든단말이 같은 AP에 접속하여 같은 WAN-IP를 공유하는 라우터내에서 NAT로 등록된다라는 가정이다.

이런 가정하에 LOW LEVEL 함수를 통한 음성 정보 수집에 들어갔다. 기본적인 구성은
Visual C++ 6.0 Bible에 수록된 음성과 관련된 파트를 참조하여 작성을 하였다.

음성을 녹음받은후 데이터를 전송한다.
이 데이터는 메모리에 다중버퍼에 저장되고 이 버퍼에 데이터가 채워졌을경우 재생을 시작한다.

가장중요한건 지금부터다.

재생을 함에 있어 일반적으로 겪는 문제는 "뽂뽂뽁뽁....."거리는 소리가 들림에 있다.
버퍼링 사이즈를 무제한으로 길게 하면되지만 이는 현실적인 도피일뿐 근본적 해결이 아니다.

재생버퍼는 0.4초정조만을 재생하게끔 되어있기때문에 다음데이터를 불러올때 연결되지못해
끊기는 소리가 들림으로인해 뽂뽂거리는 소리가 들리는것이 원인이다.

이를 해결하기 위해서는 재생시에 더블버퍼링을 구현하여야한다.

C#으로 VOIP를 작성해본 사람이라면 C#이 내부적으로 다 처리해줌으로써 손쉽게 구현했었을것이다.(소스는 웹에 널리고 널렸다.)
하지만 C++로 직접 로우레벨 함수를 통해 제어하려다보니 이런것들도 일일이 다 컨트롤해야한다.


간단히 소개하자면,
재생버퍼에 다음재생할 부분을 미리 넣어둔다.
그리고 다음에 그 부분을 재생하는 것이 원칙이다.
이렇게하며 더블버퍼링이 구현되어 연속적으로 부드러운 음성재생이 가능하다.

방법은 이해했지만, 실질적으로 구현함에 있어 뜻대로 잘 구현이 되지 않을것

이로써 기본적 기능은 구현이 될것이다.
버퍼링 사이즈및 비트레이트 역시 전송딜레이에 큰 영향을 미친다. 우리팀은 이를 실험적 시도를 통하여 딜레이가 0.3초 정도밖에 되지않는 voip구현에 성공하였다. 이수치는 공개하지않겠다.

두번째는 서버측 기능이다.
클라이언트는 비정상 종료할수도있고, 정상종료할 수도있다.
이로인해, 서버는 리스트관리를 타이트하게 할 필요가있다.
이로인해 우리는 클라이언트에서 주기적인 Alive msg를 전송하고, 이 Alive msg가 도착하면
다음 Alive msg 전송시간까지 라이프 타임을 얻게한다. 이 라이프 타임이 다 소모되어 0이될때까지
Alive msg가 전송되지 않는다면 비정상 종료된 것이므로 강제로 리스트해제 등록을 해제하고 관련 리소스를 모두 해제하는 것이 우리가 구현한 중요부분이다.
이는 익셉션 핸들링을 서버에서도 처리해줌으로써 안정적인 작동을 가능하게 해주는 대목이다.

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 수행 프로젝트 )/참여자주도형 정보공유 시스템 [2011.12~2012.02] VoIP

  1. 제 글을 퍼가셨네요...ㅎㅎㅎ 재미난 주제로 작업하시는거 부럽습니다. ^^
    화이팅입니다..

  2. 안녕하세요 ~
    Sense.J님 포스팅 덕분에 작업하던거 잘 진행 되었었습니다.^^

    ps. 출처는 표기했지만 허락을 받고 퍼가지 않아서 죄송스럽습니다.
    혹시라도 언짢으셨다면 사과 드립니다. (혹시 글 삭제를 원하신다면 말씀해주세요 !)

  3. 자세한 내용도 없던 포스팅이었는데요..ㅎㅎㅎ 그냥 제글을 퍼가시는 분도 계셔서 기쁜마음에 달았던 글입니다...^^ 잘되셨다니 축하드립니다. ㅎㅎ^^

자료조사(2) - 안드로이드의 오디오를 녹음하는 세 가지 방법

2011/11/25 11:31

1. Mediarecorder
API문서: http://developer.android.com/reference/android/media/MediaRecorder.html
사용법: http://developer.android.com/guide/topics/media/index.html


Mediarecorder는 그 이름을 보면 알 수 있듯이, media를 record한다. audio는 마이크를 통해 녹음하여 sdcard에 그 파일을 저장한다. 녹음된 audio의 포맷은 MPEG4, RAW AMR, 3GP가 있다.


<장점>
1) 사용이 쉽다
2) 오디오를 압축된 포맷으로 녹음한다.
3) 전화 소리를 녹음할 수 있다 (수신, 송신 측 모두)
4) 음성 인식을 녹음을 할 수 있다.


<단점>
1) 오디오 버퍼에 접근할 수 없다.
2) 녹음된 오디오를 처리하기가 어렵다 – 왜냐하면 이미 압축된 포맷으로 녹음되었기 때문에.
3) sampling rate를 바꿀 수 없다.
4) recording을 어떻게 발생시킬 지를 거의 컨트롤할 수 없다. (very little or no control)


2. Audiorecord
API 문서: http://developer.android.com/reference/android/media/AudioRecord.html
사용법: http://hashspeaks.wordpress.com/2009/06/18/audiorecord-part-4/


Audiorecord API는 Mediarecorder의 제한을 극복하기 위한 구글의 공식적인 API다. 녹음되는 Audio는 이후의 processing을 위해서 버퍼에 저장된다. Audiorecord의 녹음 방법과 Audio처리 방법은 자바의 방법이다.


<장점>
1) 오디오 녹음을 MONO와 STEREO 중 선택 가능하다.
2) sample size, sample rate, buffersize 등 다양한 오디오 레코딩 속성을 설정할 수 있다.
3) 녹음된 audio는 버퍼를 통해 제공된다.


<단점>
1) Buffer 다루기가 어렵다. 만약 이게 무슨 일을 하는 지 알지 못한다면, 만든 파일을 잃어버릴지도..


3. Audiorecord: native interface
A LITTLE BIT HELP : http://hashspeaks.wordpress.com/2009/04/18/audiorecord-in-android-part-2/
사용법:- ( Coming soon... how to build using NDK, sample code and how to use this API )

 native interface는 C/C++ 라이브러리를 적용한 API를 제공한다. 이 라이브러리들은 JNI를 통해 자바 액티비티로 호출 가능하다. 이 interface를 사용한 프로그램은 NDK를 통해 컴파일되고 JNI를 통해 안드로이드 애플리케이션으로 사용된다.


저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 수행 프로젝트 )/참여자주도형 정보공유 시스템 [2011.12~2012.02] audiorecorder, mediarecorder, 녹음, 안드로이드

  1. Blog Icon
    devPCY

    안녕하세요^^ 일단 같은 멤버십 회원이시기에 너무 반갑습니다~
    제가 이번에 음성인식과 보이스 레코딩을 같이 구현하려고 하는데
    Mediarecorder를 이용하면 동시에 구현이 가능하다는 이 포스팅을 보구 막 개발을 해봤어요~
    근데 자꾸 죽는게, 혹시 쓰레드로 Mediarecorder를 돌리면 죽지 않을까요??

  2. 반갑습니다 ^^
    제가 mediarecorder를 이용해서 음성인식과 보이스레코딩을 같이 구현해 본 경험이 없어서 이쪽 노하우가 없습니다 ^^;
    죽는 이유를 정확히 파악해야 해결할텐데 , 별도의 쓰레드로 돌리기만 해서 해결 될 문제인지 모르겠네요..

  3. Blog Icon
    ㄱ나니

    좋은 정보 잘 정리하셔서 도움이 많이 되었습니다. ^^

이번 과제 컨셉을 구현하기 위한 자료조사 (1)

2011/11/25 02:08

1. 안드로이드에서 PC로 음성을 실시간 전송?
 - 폰의 마이크로부터 음성 데이터를 얻음
 - 음성 데이터를 오디오코덱으로 인코딩
 - 서버와 소켓통신.(UDP) 방화벽이 있을 경우 어떻게 통신하는지 예외 처리 
 - 압축한 데이터를 패킷(RTP)으로 나누어 보낸다
 - 받은 패킷을 디코딩/재생
 - 소실 될 수 있는 데이터에 대해 Jitter 보정을


2. 안드로이드 SDK의 AudioRecord를 사용하여 일정 시간마다 PCM데이터를 획득하는 방법

:: 단서 ::
 - "AudioRecordInstance.read()라는 함수로 PCM데이터를 획득 할 수 있다. "
 - * 그런데, while문 돌려서 계속해서 read를 호출하니 일정한 FrameSize 만큼 계속 획득이 되긴 하나,
      획득하는 시간이 일정하지 않다.
 - 8Khz 샘플링 레이트로 프레임사이즈를 160으로 잡았을때
   8000/160 = 50 이므로 1초에 50번을 획득해야 되니, read() 함수는 20ms마다 호출이 되어야된다.
   그러나 실질적으로 20 ms인 주기를 정확히 맞추기가 힘들다!

   로그를 중간 중간 삽입해 보니 어떤건 1ms마다 호출할때도 존재하고
   또 다른건 120ms 마다 호출할 때도 있고 너무 들쭉날쭉이 심하다

 - (왜?)

 - 리스너가 있다. 리스너를 통해서 실행 -> 계속적인 콜백 효과 -> 역시 들쭉 거림 -> while문 보다는 변동폭이 작다 but 들쭉거린다 문제
 
- 그나마 가장 효율이 높았던 건 while 문으로 돌리면서
  과거 실행시간 vs 현재 실행시간 비교 sleep을 주는 정도로 트릭을 쓴게 3ms 차이 내외로 왔다갔다함
 
:: 결론 :: 
 - 아직 답을 찾는중.
.
.


3. AudioRecord, AudioTrack dalay를 줄이면서 실시간으로 처리하는 방법
 - (폰 - 폰)의 통화 기능을 구현 
 - 폰1(녹음,재생) <--- 전송 ----> 폰2(녹음,재생)

 - AudioRecord, AudioTrack, DatagramSocket  => 사용

:: 문제 ::
- AudioRecord로 녹음시, read()함수를 반복적으로 사용할경우, 빠르게 동작하지 않는다!

:: 문제원인 추측 ::
- (하드웨어를 직접접근해서 그런지...?) 
========================================

byte[] recordBuffer = new byte[1024*5]; 


while(true){

   int offset=0;

   int readSize=1024;

   while(true){

       readByte = audioRecord.read(recordBuffer, offset, readSize);    

       offset+=readByte;     

     

       if(offset+1024>recordBuffer.length) readSize = recordBuffer.length-offset;

       if(readByte<=0 || readSize<=0) break;    

      } 


   try {Thread.sleep(200);} 

   catch (InterruptedException e){ e.printStackTrace(); } 

 } 
=========================================
 
 :: 0.2초에 1024*5byte씩 딱딱 뽑아내고 싶은데 중간중간에 제대로 read를 못하게 됩니다

=>OnRecordPositionUpdateListener를 사용하게 되면 이문제는 해결할수 있나요? 아니면 어떤방법이 있을까요? ::

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 수행 프로젝트 )/참여자주도형 정보공유 시스템 [2011.12~2012.02]

[컨셉] PDF 문서를 활용한 소셜 스터디

2011/11/25 01:48


Main Idea
 - 태블릿에서 PDF 문서에 자유롭게 메모를 한다. 종이에 펜과 포스트잇으로 메모를 하듯.
 - 메모한 내용을 다른사람과 공유한다.
 - 메모를 하나의 PDF 문서에 여러사람과 동시에 한다.
 - 원격지의 여러 사람들과 하나의 PDF 문서에서 현재 보는 화면을 공유하면서 스터디를 진행한다!
 - 스터디 진행자 1명, 나머지는 참여자 => 진행자는 번갈아가면서
 - 현재 스터디를 진행하는 진행자는 원격지의 참여자들에게 음성으로 의견을 전달할 수 있다.

 
 
저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 수행 프로젝트 )/참여자주도형 정보공유 시스템 [2011.12~2012.02]

2족 로봇. PETMAN

2011/11/18 21:44



미국 군수업체에서 개발한 2족로봇 PETMAN입니다.

2족로봇이 이정도로 발전 했다니 정말 대단 합니다.

언뜻 보기에 기분나쁜 킬링머신처럼 보이지만 이 로봇은 미군이 착용할 특수 의류를 테스트 하려는 목적으로 만들어 졌다고 합니다.
 
스스로 균형잡고 걷기에 웅크려 앉기 심지어 푸쉬업까지 합니다.
 
현실적 테스트조건을 제공하기 위해 의류내부의 온도 습기 땀을 통제함으로써 인간 생리학을 시뮬레이트 한다는 것이 보스톤의 설명이라고합니다.

아래는 그 동영상 입니다!




저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Dev고양이 = ( 잡설록 ) 2족 로봇, 2족 로봇 종결자, 2족로봇, Petman, robot, 보스톤 다이나믹스