IT & Mobile

S-CSCF에서 받은 호를 라우팅 하는 방법에는 3가지가 있지만

주로 1,2번 2가지가 스인다.

1. IFC (가입자 기반으로 동작)

  가입자 기반에도 2가지가 있는데

  A. 발신호: P-Asserted-Identity (없으면 From)을 기준으로 처리한다.

  B. 착신호: invite 옆에있는 R-URI (Request URI)를 기준으로 처리한다.

     기준이 바뀌면 동작이 재설정 되므로, P-A-I나 R-URI가 동일한 상태에서

     iFC가 순차적으로 처리되며, 따라서 iFC에는 우선순위(Priority)가 존재한다.

2. Prefix-Routing

  가입자랑 상관없이 특정번호 (예:1593408)의 경우

  지정한 서버로 포워딩 시킬 수 있다.

3. PSI-일반적으로는 외부에서 들어온 호를 I-CSCF에서 처리할 때 사용하지만

  S-CSCF에서도 사용 가능.

IMS에서는 PSI를 통해

외부에서 들어온 호를 I-CSCF에서 AS로 직접 포워딩 할 수 있다. (8.8장 )

3가지 방식이 있는데

1. 서브도메인 이용

2. Direct PSI trigger

3. Indiect PSI trigger

이 중 1,2번이 간단한 편인데

2번을 설명하면

I-CSCF에서 HSS로 LIR(Location info query) 및  LIA(Answer)를 통해

AS주소를 안 다음에 AS로 바로 라우팅 하는 것이다.

AS에서는 처리 후, 다시 I-CSCF로 호를 보내면

I-CSCF -> S-CSCF -> (T)AS 형태로 호가 이루어 진다. (확인 중)

그리고 WildCard(*) PSI 등록시에는

번호!.*!  형태로 느낌표 사이에 regex로 표현된다.

3. Indirect PSI trigger는

I-CSCF(HSS LIR) -> SCSCF (HSS SAR:레지확인 후 iFC 동작) -> AS로 호가 되는데

unregi된 서비스 번호에 대해서도 서비스가 가능한 장점이 있다.

단점은 PSI + iFC도 필요해서 다소 복잡하다.

ICID (IMS charging ID) :과금 ID

P-CSCF가 Regi 수신받으면 ICID 생성.  (11.12)

P-CSCF는  P-Charging-Vector헤더를 이용해 ICID를 S-CSCF로 전달.

S-CSCF는 받은 ICID를 저장. 하고 이를 이용한 과금 수행.

(12.7)

세션중에 P-CSCF는 추가적인 media-stream용 ICID생성. (PDP Context 연관부분)

IOI(Inter-Operator ID)도 과금에 사용됨.

-type2 : 주로 통신사 내부에서 이걸 사용함.

-type1:(p-cscf 와 s-cscf간 용도),   type3:로밍용.

발신쪽 S-CSCF가 P-Charging-Vector에 orig-ioi넣어놓으면,

착신쪽에서 orig-ioi를 제거하고 단말로 내려감(단말로는 과금정보 절대 안내려감)

대신 183이 단말에서 올라오면 다시 ICID,IOI등을 더해서  전달함.

SIP stack is process&Library for dealing with SIP.(Sessin Initiation Protocol)

Open Source SIP Stack for JAVA:

 -

1) PJSIP-JNI  which is java bindings for the C PJSIP library

2) JAIN-SIP  http://users.cis.fiu.edu/~ege/JAIN/

    https://github.com/Mobicents/jain-sip 

    https://jsip.ci.cloudbees.com/job/jsip/javadoc/ 

    http://www.oracle.com/technetwork/java/introduction-jain-sip-090386.html      (Oracle introduction)

    https://developer.opencloud.com/devportal/devportal/apis/jainsip/1.1/docs/index.html 

    http://www.worldlibrary.org/articles/mobicents 

    http://www.mobicents.org/products.html 

    RFC 3261 functionality and the following SIP extensions; the INFO method (RFC 2976), Reliability of provisional responses (RFC 3262), Event Notification Framework (RFC 3265), the UPDATE method (RFC 3311), the Reason Header (RFC 3326), the Message method (RFC 3428) defined for instant messaging and the REFER method (RFC 3515), Distributing Authoritative Name Servers via Shared Unicast Addresses (RFC 3581), the PUBLISH method (RFC3903).

   SDP API(JSR 141) is property of Dynamic Soft. => under JCP License

3) MjSip        http://www.mjsip.org

4) javaforce   http://sourceforge.net/projects/javaforce/

5) jSIP          http://jsip.java.net  http://jsip.sourceforge.net/

6) openjsip    http://code.google.com/p/openjsip/

SIP Stack for C

1) reSIPRocate    http://www.resiprocate.org, http://svn.resiprocate.org/dox/ 

2) Spirent IMS SIP stack = Radvision SIP Stack.   REF-SITE

   - (Avaya m&a Radvision(2012),   spirent m&a Radvision Tech Biz Unit(2014) )

SIP is protocol like HTTP. while

IMS is telco System Architecture which uses SIP.

<SIP History>

1998년에 H.323 이 나오고  -( 최초로 RTP사용.)

1999년에 SIP가 나오면서 혼용되다가,  2008년경부터 본격 사용됨.
    -SIP는 1996년에 나온 HTTP1.0을 차용하여 Text-based로 정의.

2002년 RFC3261.

2012년에 8월(skt,lgt) 12월(kt) VoLTE 최초 상용화.

<IMS>

- 3G에서부터 HLR, 통화 등을 수용하기 위한 텔코의 시스템 구조로 발전.

      UNI: user to Network Interface (단말과 망 사이)

      NBI : North Border (AS 경계)

      NNI : Network to Network ( 타이통사간 경계)

- IFC Chaining을 통해서 호가 흘러가는 구조 임.(IFC를 S-CSCF가 HSS로부터 받아오는 게 핵심.)

- PSI 는 최종 서비스 혹은 trigger의 경우 최종 서비스로 바로가는 방법.  

  즉,IFC 는 체이닝이 되어야 효과를 발생하는 과정이고 차이가 큼..

-  ISC (IMS Service Control )Reference Point 임. 여기서 IFC가 처리됨.

RAVEL기반 로밍: VoLTE로밍의 대세

 - CMCC에서 밀고 있음.

s8hr로밍: simple해서 힘을 받고 있음.

IP Layer에서만 로밍하면 국내호 처리는 완료되며,

로컬호 처리가 이슈.

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를 보면 다음과 같다.

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도 필요)

단말이 IMS 시스템에서 서버에 등록을 하는 절차.

(VoLTE 통화를 위해서, 단말과 서버간의 사전 절차이다.

VoLTE는 데이타망과 유사한 통화전용LTE망  위에서 통화를 하는 것이므로, VoIP라고 볼 수도 있고,

기존의 CS망에서 통화하던게 발전한 것이므로 일반통화라고 볼 수도 있을 것 같은데.. 

아무래도 기본 통화로 상용되다 보니 VoIP라고 잘 부르진 않는다. )

1. 단말이 서버로 ID를 보낸다 (First Regi,  integrity_protected필드=no)

2. 서버(CSCF)에서 401 unAuthorized 응답을 보낸다

3. 단말이 401응답속의 nonce(challenge)필드 값을 이용해서 도전과제를 풀어서 올린다. (Second Regi, integrity_protected필드=yes)

4. 서버(CSCF)에서 200OK를 보낸다.

이 중에서 3번 항목을 살펴보면

단말의 SIM에는 PUID(고유ID: From필드에 사용), PRID(인증용 ID: userName 필드에사용) 및 key, ck(암호키), ik(변조체크 키) 가 있는데

3번의 과정에서는 ck,ik,nonce+ 이것들을 이용해서 계산된 결과가 올라간다.

서버는 이 결과가 원하는 답이 맞을 경우 Regi를 해 주게 된다.  

<인증 방식>

인증 방식에는 aka인증과 md5 인증이 있는데

요즘 단말들이 aka인지 md5인지를 결정하여 올려주는 관계로,  차이만 본다면

aka: 위에 언급한 것처럼 sim을 이용해서 인증.  nonce이용

md5: 좀 더 간단한 인증으로 nonce가 아니고 n-nonce 필드를 이용.