IT & Mobile

GC(Garbage Collection)에는 serial방식과 Parallel방식이 있는데

single thread (32bit window)등 특수환경에서만 serial방식이 쓰이고, 대부분 Parallel 방식이 쓰인다.

serial방식의 경우, 어플리케이션을 freezing시켜 버린다.

GC의 중요한 2가지 기능별 분류:

CMS GC(concurrent-mark-sweep) :

  - 동시에 여러Thread를 이용해서 mark하고 sweep.

  - 일반적으로 STW(Stop-The-World)를 유발하지 않지만 아래2가지 경우 STW 발생가능..

       a. Initial Root 마킹

       b. 동작중에 앱의 heap 상태 변경으로 재구동 필요시

G1 GC(Garbage first Collector - JDK1.7u4 에서 4GB 이상 heap을 우선처리하기 위해 등장 함) 

 - JDK1.8u20 에서는 string dup제거 로직도 추가됨

추가로,

Java8에선 PermGen (class 메타데이타 저장소)가 없어짐. OOM을 많이 유발하던 부분임.

참고사이트:

CMS GC의 버그는 1.7에서 해결되었으며, 
G1 GC의 버그는 1.8에서 해결됨. :  슬라이드 30페이지

USIM = SIM + UICC

참고사이트

Public User ID: 국제적으로 통용하기 위한 ID로서, 공용ID인 만큼, 명함이나 출판물에 찍어서 교환해도 되는 고유Id이다.

tel Uri 혹은 Sip Uri로 표시한다. 

- tel:+821012345678

- sip:john.doe@ims.korea.com

Private User ID: 통신사 내에서 쓰기위한 용도이다.

< Puid와 Prid의 관계 >

PuID는 폰마다 하나씩 존재해야 하지만,

PrID는 하나를 만들어 여러개의 폰에 공용으로 사용할 수 있다.

PrID는 sip:joe@mytelecom.com 형태로 쓰면 된다.

<GRUU>

폰을 위해 GRUU(Grobally Routable User agent URI)를 사용할 수 있으며

GRUU를 여러개 만들어서 폰하나에 GRUU 2개를 할당할 수도 있다.

즉 Phone1- GRUU1  - Puid1

               - GRUU2  - Puid2 

    Phone2 - GRUU3  /

와 같은 형태로   다대다 매핑이 가능하다.

IMS의 기본 Invite Flow를 보면 다음과 같다.

CentOS 6.3을

커널 2.6.32-279에서 2.6.32-358.14.1 로 update해보았다.

일단 binary를 받을 수 있는 URL은

-기본 버전:  http://vault.centos.org/6.4/os/x86_64/Packages/    kernel-xx-.14.1.el6.x86_64.rpm

-update 버전:  http://vault.centos.org/6.4/updates/x86_64/Packages/    kernel-xx.el6.x86_64.rpm

최초에 기본버전이 나오고 마이너 update버전이 나오게 되므로

보통 update버전을 많이 설치하는 것으로 보인다.

kernel은 간단하게 rpm -ivh xx.rpm으로 설치가 된다.

하지만 dependecy문제가 발생하게 되므로

1. kernel-firmware-xx.xx 먼저설치

2. kernel-devel-xx.xx 설치

3. kernel rpm 설치.. 옵션을   --nodeps를 주면 dependency없이 설치 가능.

참고 사이트:

서버가 접속이 안될 경우를 대비해

HP에서는 ILO (Integrated Light Out) 기능을 제공 한다.

독립적인 Ethernet포트를 이용해

OS에서 사용하는 것과 다른 IP어드레스와 user/비번을 제공한다.

1. ssh 터미널로  초기접속하게되면 아래와 같은 커서가 뜨게 된다.

=====================================

</>hpiLO-> 

2. 웹브라우저로 https://서버IP  로 접속하면

  웹기반 GUI가 제공된다.

  ==> 접속후 보통 Remote Console (IRC)로 파워 on/off,  OS설치, keyboard 입력 등의 작업을 한다.
       IRC를 뛰우면 OS 로그인 prompt가 기본적으로 뜨고.. 상단메뉴에  PowerSwitch / Virtual Drives / Keyboard 가 존재한다.

User_Guide는 여기클릭

Call Transfer에는 다음과 같은 3가지 종류가 있다.

1. Blind Transfer

   - 제 3자 상태의 확인 없이 무조건 돌려주기

2. UnScreened Transfer

  - 제3자에게 통화를 해보고 신호가 가는지 확인해서 돌려주기

3. Screened Transfer

  - 제 3자와 통화를 직접해서 돌려주겠다고 말까지 한 후, 돌려주기.

<구현 방식>

1. Blind  Transfer

   - IP-PBX가 REFER메시지를 처리하는 방식이 일반적인 것 같고, 

    A단말에서 REFER를 처리하는 방법도 있다.(단말이 REFER지원해야 함)

2. (Un)Screened Transfer

   - IP-PBX가 INVITE(with REPLACES)를 보내는 방법도 있고

     IP-PBX에서 ReINVITE만을 사용하는 방식도 있다.

<Invite with REPLACES 예제>

         Alice          Alice                             Parking
        phone1         phone2            Bob               Place
        |               |                 |                   |
        |<===============================>|                   |
        |               |                 |                   |
        |        Alice transfers Bob to Parking Place         |
        |               |                 |                   |
        |------------REFER/200----------->|    *1    *2       |
        |<--NOTIFY/200 (trying)-----------|--INVITE/200/ACK-->|
        |<--NOTIFY/200 (success)----------|<=================>|
        |------------BYE/200------------->|                   |
        |               |                 |                   |
        |               |                 |                   |
        |  Alice later retrieves call from another phone      |
        |               |                 |                   |
        |            *3 |-INV w/Replaces->|                   |
        |               |<--200-----------|                   |
        |               |---ACK---------->|----BYE/200------->|
        |               |<===============>|                   |
        |               |                 |                   |


   Message *1: Bob-> Parking Place

   INVITE sip:parkingplace@example.org SIP/2.0
   To: <sip:parkingplace@example.org>
   From: <sip:bob@example.org>;tag=7743
   Call-ID: 425928@bobster.example.org
   CSeq: 1 INVITE
   Contact: <sip:bob@bobster.example.org>
   Referred-By: <sip:alice@phone1.example.org>

   Message *2: Parking Place -> Bob

   SIP/2.0 200 OK
   To: <sip:parkingplace@example.org>;tag=6472
   From: <sip:bob@example.org>;tag=7743
   Call-ID: 425928@bobster.example.org
   CSeq: 1 INVITE
   Contact: <sip:parkplace@monopoly.example.org>

   Message *3: Alice@phone2 -> Bob

   INVITE sip:bob@bobster.example.org
   To: <sip:bob@example.org>
   From: <sip:alice@phone2.example.org>;tag=8983
   Call-ID: 09870@phone2.example.org
   CSeq: 1 INVITE
   Contact: <sip:alice@phone2.example.org>
   Require: replaces
   Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472

<SIP 메시지 포맷>

INVITE <sip:Request URI> 

Via:

Route: 처음에는 UE가 P-CSCF 주소를 넣음.<1차 경유지>  

    나중에는 UE가 Record-Route에서 읽은 걸 여기다 넣어 줌. 

        (요즘 다 Loose Route 방식임)

<Route 방식 비교>

Strict Route: <RFC2543>

  Requset-URI가 항상 next-hop을 지니는 방식으로 매번 Request-URI를 overwrite하게 됨. 

  따라서,  진짜 Request-URI는 마지막 Route에 적어줘야 함.

Loose Route:  <RFC3261>

  Request-URI는 항상 그대로 이며, 

  최상 Route로 무조건 전달.  ==> Request-URI가 다음 목적지가 아니라는 점에서 큰 변화였음.

(Strict Route를 Loose Route로 바꾸는건 backword compatibility 유지하기에는 오버헤드가 큼)

<통화 중 HOLD> 

 hold기능이 볼때마다 헤깔려서, 잊지 않기 위해서 정리해 보면

A-B단말이 통화중에

1.A가 invite(sendOnly)를 올리면   MS(미디어서버)가 이를 받아  B로 invite(sendOnly)를 보내고

   2. B는 invite(recvOnley)로 응답.

 3. MS가 A로 recvOnly응답

최종적으로는 A는 MS에다가 말하는 구조가 되고

MS는 B로 음악(hold음)을 틀 수 있는 구조로 된다.

<Bearer open>

BS(Bearer Service) 오픈:  P-CSCF가 P_CRF로 요청하면   P_CRF가 AccesS GW의 BS Manager를 통해

단말의 BS Manager같 통신해서 IP-CANnectivity가 연결됨. 

<Invite의 각종 필드>

-Privacy: id  이면 발신자표시 금지,  로서 P-Asserted-Identity ( P-CSCF 에서 세팅 )를 상대 단말로 보낼 수 없다

-일반적으로 Reinvite는 to태그가 달라야.. 미디어갱신이 됨  (최근 많이 사용되는 아프로텍 단말은 제외)

Via : Response가 정확하게 trace-back되도록 지나간 경로를 그대로 기록. - 히스토리라서 CSCF들 다기록.

Record-Route : Request가 빠르게 따라가도록 Route경로를 기록.

       CSCF들은 Via와 Record-Route를 같이 add함. (I-CSCF는 Via만 기록. Record-Route는 제외..
       I-CSCF는 서치만 하고 서치가 끝난게 실제 기록된 Route임.)

Serivce-Route: REGI된 S-CSCF를  S-CSCF가 직접 200 OK에 적어 줌.  (UE가 기록해 뒀다가 Invite시에 Route에 직접 이용한다는데.. 
                   P-CSCF가 자기주소를 기록하는 Path와 반대 )

Contact: UE간 직접 SIP 접근하기 위함.  ( SDP의 C[커넥션 IP]과 차이점은 없나? - 같겠지만 미디어는 주로 C를 사용할 듯.  )

            그 외에도 callee audio/video카파 및,  I-CSI ,   temp- GRUU ,  IARI(MMTel-ICSI)
            ㅁ ICSI (IMS - Communication Service Identification),  IARI (IMS-Application Reference Indentification),  

Accept-Contact: 발신자의 Preference. 

ICSI가 P-Preferred-Service헤더에 있을 경우,  S-CSCF가 이걸 P-Asserted-Service로 치환.

I-CSCF는 LIR(diameter Location Info Request)을 통해 HSS를 직접 조회.      (HSS가 2개이상인 경우에는 SLF도 필요)

list of Open File.  특정파일을 access하고 있는 프로세서들을 나열한다.

예)

$lsof mylogfile

$lsof /proc