신C의 개발 노트

2016년 7월 6일 수요일

SIP 프로토토콜 흐름(RFC 3261)

SIP 프로토콜

opensips를 proxy로 PC에 설치하고, 안드로이드 SIP 어플 Linphone과 windows SIP어플 MicroSIP을 등록한 후 전화를 걸었을때 캡춰한 패킷을 중심으로 SIP 프로토콜 흐름을 설명했습니다. 대부분의 설명은 NExpert의 블로그글입니다.

2016년 7월 7일 신C

SIP Cilent, Proxy Server, SIP Server 전화통화 패킷캡춰

SIP User Agent Client, Alice: 192.168.1.26 (Linphone Android)

SIP Proxy: 192.168.1.17(opensips)

SIP User Agent Server, Bob: 192.168.1.114(MicroSIP)

82 INVITE : Client -> Proxy

RFC3261 Section 13.2.1

<Request-Line>

INVITE sip:bob@192.168.1.17 SIP/2.0

메세지의 첫 줄에는 Method와 메세지를 수신하는 최종 단말의 주소와 버전이 명기되므로 메세지가 생성된 목적을 확인할 수 있습니다.

- INVITE : 요청한 메쏘드

- sip:bob@biloxi.com : Request URI

- SIP/2.0: 버전

Request-URI는일반적으로는 To 필드의 URI값을 이용하여 표시합니다

Via: SIP/2.0/UDP 192.168.1.26:5060;branch=z9hG4bK.REGZV7F7H;rport

Via 헤더는 요청에 대한 응답을 위한 경로를 나타냅니다.

branch는 시공간에서 유일한 값을 가지며, 트랜잭션 식별자입니다. 트랜잭션은 호 설정 또는 호 종료와 같은 단위작업을 의미하며 User Agent 간에 생성됩니다

84 INVITE요청에서 보면 프록시서버에서 UAS에 전달할때 UAC의 Via와 proxy의 Via 두개가 순서대로 들어간다.

이 branch 값은 서버로 부터 OK를 받을 때까지 유지된다. Bye의 branch도 OK를 받을때까지 유지된다.

rport: 클라이언트가 서버에게 요청한 주소와 포트로 응답해주는 것을 요청(rfc3581)

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: sip:bob@192.168.1.17

SIP 메세지의 출발지와 목적지를 나타내지만, 실제 메세지의 라우팅에 사용되지 않으며 Display Name의 의미를 가집니다.

이 줄은 앨리스가 밥에게 세션 설립을 요청하는 다이얼로그라는 의미입니다.

From과 To 헤더는 현재 세션의 진행방향을 의미하는 것으로 현재 메세지의 발신자와 수신자를 의미하는 것이 아닙니다. 따라서 SIP INVITE 메세지의 응답인 200 OK에서 From 과 To 헤더의 내용이 바뀌지 않습니다. From과 To의 값이 엉뚱하게 적혀있어도 SIP 프로토콜이 진행되는 데는 문제가 없습니다만, 요즘에는 SIP 보안이 강화가 되면서 From 과 To 헤더가 잘못 명기되면 호가 진행되지 않기도 합니다.

CSeq: 20 INVITE

Commnad Sequence또는 Sequence Number는 정수와 메쏘드 이름으로 나타냅니다. 새로운 요청을 생성할 때마다 1씩 증가시킵니다. 이 요청에 대한 응답인200 OK에서도 같은 값을 확인할 수 있습니다.

하나의 요청과 응답은 같은 CSeq값을 가집니다.

Call-ID: ub5yOdNFB6

세션에 대한 global unique identifier로 사용하며, 호스트 네임 또는 IP address와 시간을 조합하여 생성됩니다. To/ From/ Call-ID가 결합으로 엘리스와 밥간의 Pee-to-peer SIP 관계를 정의합니다.

Call-ID가 같은면 하나의 다이얼로그로 인식하므로 세션의 설립과 종료사이의 모든 SIP 메세지는 동일한 Call-ID를 가집니다. SIP 호 분석 시에 다수의 호가 혼재되어 있어도 Call-ID를 기준으로 개별 호에 대한 분석이 가능합니다. 다이얼로그는 다수의 트랜잭션으로 이루질 수 있으므로 트랜잭션의 식별은 Via헤더의 branch 값으로 추적하고, 다이얼로그의 식별은 Call-ID와 From 및 To의 Tag로 추적합니다.

Max-Forwards: 70

시그널링 경로 상에 SIP 서버의 최대 홉 수를 나타냅니다. IP네트워크의 TTL (Time to Live)과 같습니다

Supported: replaces, outbound

지원하는 new option(extention)을 나열합니다. 엘리스는 replaces, outbound 가 지원됩니다.

이런 option tag가 사용되는 필드:Require (Section 20.32), Proxy-Require (Section 20.29), Supported (Section 20.37), Unsupported (Section 20.40).

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE

지원 가능한 메소드를 나열합니다. 이 필드가 없을 경우 아무것도 지원하지 않는다고 해석하면 안됩니다. ‘지원 가능한 메소드가 뭔지 모르는 구나’로 해석해야 합니다.(Section 20.5)

Content-Type: application/sdp

메세지 바디가 있을 경우 메세지 바디에 대한 설명입니다.applicaiton/sdp는 SIP 메세지 바디가 SDP 메세지로 구성되었다는 의미입니다.

Content-Length: 483

메세지 바디의 크기를 옥텟 (바이트)로 표시합니다. 메세지 바디가 483 바이트로 구성되었다는 의미입니다.

Contact: <sip:6983@192.168.1.26>;+sip.instance="<urn:uuid:b1a8c819-e39d-47f4-8d15-18cbefede1f1>"

SIP URI 포맷으로 되어 있으며, 요청을 보낸 사용자에 대한 직접적인 경로를 나타냅니다.

일반적으로 FQDN (Fully qualified domain name)나 IP주소를 선호합니다. Via 헤더 필드가 요청에 대한 응답 경로를 나타내고, Contact 헤더 필드는 미래의 요청을 보낼 경로를 말합니다.

예를 들어 proxy에서 UAS로 요청을 전달할 경우 Contact는 USC의 주소가 들어갑니다.

Contact URI: sip:6983@192.168.1.26, Contact parameter: +sip.instance=.....

User-Agent: LinphoneAndroid/3.1.1 (belle-sip/1.4.2)

요청한 UAC의 정보가 들어갑니다. alice는 Linephone Android 를 이용하고 있군요.(Section 20.41)

v=0

: SDP프로토콜 버젼(RFC 4566), 현재까지는 Version 0 이 전부다.

o=6983 3953 1190 IN IP4 192.168.1.26

:소유자/작성자 및 세션 식별
형식 o=<username><sess-id><sess-version><nettype><addrtype><unicast-address>

<username>: 로그인 이름, 공백이 들어가면 안됨.

<sess-id>: 세션 아이디, 전화기에서 랜덤하게 생성된다

<session-version>: 세션의 버젼넘버, 전화기에서 랜덤하게 생성된다.

<nettype>: 네트워크 타입, 예)IN-internet, <addrtype>: 주소체계 예) IP4, IP6

<unicast-address> 세션을 생성한 단말기의 주소, IP 또는 FQDN(fully qualified domain name)

s=Talk

:세션 이름

c=IN IP4 192.168.1.26

: 연결정보

형식: c=<nettype> <addrtype> <connection-address>

<nettype>: 네트워크 타입, 예)IN-internet,

<addrtype>: 주소체계 예) IP4, IP6

<connection-address>: 멀티캐스트는 TTL을 포함한 IP 주소, 예) 224.2.36.42/127

b=AS:380

: 대역폭 정보

형식 b=<bwtype>:<bandwidth>

<bwtype>: Bandwith 타입은 CT(conference total), AS(application specific), TIAS(Transport Independent Application Specific)로 설정할 수 있다.

TIAS: Transport Layer의 오버헤드를 고려하지 않은 대역폭으로 RTP만의 대역폭.

CT:컨퍼런스에서 사용될 최대 통합대역,

AS: 어플리케이션의 최대 사용 대역, TCP / UDP와 깉은 Transport Layer의 오버헤드를 고려한 대역폭으로 RTP/UDP/IP 의 대역폭

<bandwith>: kilobits per secnod 단위,

t=0 0

:세션이 활성화되는 시간

형식 t=<start-time>:<value>

세션의 시작, 마침 시간을 정한다. 만약 세션이 불규칙적으로 활성화되면, 여러개의 시간이 사용될 수 있다.

수화기를 들면 시작되므로 시작시간은 정해지지 않으므로 session start time은 0, 수화기를 놓을때 까지 통화가 되므로 session stop time도 0이다.

a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics

: 미디어 속성

형식 a=<attribute>:<value>

속성은 세션 레벨 이거나 미디어 레벨 또는 둘다 해당할 수 있다. 세션레벨 속성은 컨퍼런스에 적용되는 추가적인 정보를 알리기 위해 사용된다. 미디어 레벨 속성은 미디어 스트림 정보처럼 미디어관련된 정보를 기술한다.

m=audio 7076 RTP/AVP 96 97 98 99 0 8 101 100 102

: 미디어 이름 및 전송 주소

형식: m=<media> <port>/<number of ports> <proto> <fmt>

<media>: video, text 처럼 미디어 타입을 기술한다.

< port>: 미디어 스트림이 전송될 포트, 여러 포트를 기술할 수도 있다.

<proto>: 스트리밍을 위한 전송프로토콜, 예) RTP

<fmt>: 전송될 미디어 포맷, 예) PCMU, GSM 등.

a=rtpmap:96 opus/48000/2:

a=fmtp:96 useinbandfec=1:

a=rtpmap:97 SILK/16000:

a=rtpmap:98 speex/16000:

a=fmtp:98 vbr=on:

a=rtpmap:99 speex/8000:

a=fmtp:99 vbr=on:

a=rtpmap:101 telephone-event/48000:

a=rtpmap:100 telephone-event/16000:

a=rtpmap:102 telephone-event/8000:

:미디어 속성

사용자가 설정한 우선순위에 따라 코덱이 나열된다.

83 Giving a try : Proxy -> Client

RFC3261 Section 21.1.1
<Status-Line>

SIP/2.0 100 Giving a try

Via: SIP/2.0/UDP 192.168.1.26:5060;received=192.168.1.26;branch=z9hG4bK.REGZV7F7H;rport=5060

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: sip:bob@192.168.1.17

CSeq: 20 INVITE

Call-ID: ub5yOdNFB6

Server: OpenSIPS (2.2.0 (x86_64/linux))

Content-Length: 0

84 INVITE : Proxy -> Server

RFC3261 Section 13.2.1
<Request-Line>

INVITE sip:bob@192.168.1.114:55903;ob SIP/2.0

Record-Route: <sip:192.168.1.17;lr>

옵션 SIP 헤더로 SIP Message를 확인하려는 모든 SIP Proxy에 의해 삽입됩니다. SIP Proxy를 통해 경유되는 다이얼로그 (같은 Call-ID)에 대한 요청과 응답에 사용됩니다. 여러 대의 SIP Proxy를 경유해야 하는 경우에는 ","를 이용하여 계속 추가합니다.

예) Record-Route: server10.biloxi.com, bigbox3.atlanta.com

Via: SIP/2.0/UDP 192.168.1.17:5060;branch=z9hG4bK2891.db03d001.0

Via: SIP/2.0/UDP 192.168.1.26:5060;received=192.168.1.26;branch=z9hG4bK.REGZV7F7H;rport=5060

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: sip:bob@192.168.1.17

CSeq: 20 INVITE

Call-ID: ub5yOdNFB6

Max-Forwards: 69

Supported: replaces, outbound

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE

Content-Type: application/sdp

Content-Length: 483

Contact: <sip:6983@192.168.1.26>;+sip.instance="<urn:uuid:b1a8c819-e39d-47f4-8d15-18cbefede1f1>"

User-Agent: LinphoneAndroid/3.1.1 (belle-sip/1.4.2)

v=0

o=6983 3953 1190 IN IP4 192.168.1.26

s=Talk

c=IN IP4 192.168.1.26

b=AS:380

t=0 0

a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics

m=audio 7076 RTP/AVP 96 97 98 99 0 8 101 100 102

a=rtpmap:96 opus/48000/2

a=fmtp:96 useinbandfec=1

a=rtpmap:97 SILK/16000

a=rtpmap:98 speex/16000

a=fmtp:98 vbr=on

a=rtpmap:99 speex/8000

a=fmtp:99 vbr=on

a=rtpmap:101 telephone-event/48000

a=rtpmap:100 telephone-event/16000

a=rtpmap:102 telephone-event/8000

85 Trying : Server -> Proxy

RFC3261 Section 21.1.1
<Status-Line>

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.1.17:5060;received=192.168.1.17;branch=z9hG4bK2891.db03d001.0

Via: SIP/2.0/UDP 192.168.1.26:5060;rport=5060;received=192.168.1.26;branch=z9hG4bK.REGZV7F7H

Record-Route: <sip:192.168.1.17;lr>

Call-ID: ub5yOdNFB6

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: <sip:bob@192.168.1.17>

CSeq: 20 INVITE

Content-Length: 0

86 Ringing : Server -> Proxy

RFC3261 Section 21.1.2
<Status-Line>

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 192.168.1.17:5060;received=192.168.1.17;branch=z9hG4bK2891.db03d001.0

Via: SIP/2.0/UDP 192.168.1.26:5060;rport=5060;received=192.168.1.26;branch=z9hG4bK.REGZV7F7H

Record-Route: <sip:192.168.1.17;lr>

Call-ID: ub5yOdNFB6

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

CSeq: 20 INVITE

Contact: "bob" <sip:bob@192.168.1.114:55903;ob>

Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS

Content-Length: 0

87 Ringing : Proxy -> Client

RFC3261 Section 21.1.2
<Status-Line>

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 192.168.1.26:5060;rport=5060;received=192.168.1.26;branch=z9hG4bK.REGZV7F7H

Record-Route: <sip:192.168.1.17;lr>

Call-ID: ub5yOdNFB6

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

CSeq: 20 INVITE

Contact: "bob" <sip:bob@192.168.1.114:55903;ob>

Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS

Content-Length: 0

전화를 받으면(수화기를 들면) OK method가 전송된다.

113 OK : Server -> Proxy

RFC3261 Section 21.2.1
<Status-Line>

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.1.17:5060;received=192.168.1.17;branch=z9hG4bK2891.db03d001.0

Via: SIP/2.0/UDP 192.168.1.26:5060;rport=5060;received=192.168.1.26;branch=z9hG4bK.REGZV7F7H

Record-Route: <sip:192.168.1.17;lr>

Call-ID: ub5yOdNFB6

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

CSeq: 20 INVITE

Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS

Contact: "bob" <sip:bob@192.168.1.114:55903;ob>

Supported: replaces, 100rel, timer, norefersub

Content-Type: application/sdp

Content-Length: 381

v=0

o=- 3676737565 3676737566 IN IP4 192.168.1.114

s=pjmedia

b=AS:84

t=0 0

a=X-nat:0

m=audio 4006 RTP/AVP 96 102

c=IN IP4 192.168.1.114

b=TIAS:64000

a=rtcp:4007 IN IP4 192.168.1.114

a=sendrecv

a=rtpmap:96 opus/48000/2

a=fmtp:96 maxplaybackrate=16000;sprop-maxcapturerate=16000;maxaveragebitrate=16000;useinbandfec=1

a=rtpmap:102 telephone-event/8000

a=fmtp:102 0-16

114 OK : Proxy -> Client

RFC3261 Section 21.2.1
<Status-Line>

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.1.26:5060;rport=5060;received=192.168.1.26;branch=z9hG4bK.REGZV7F7H

Record-Route: <sip:192.168.1.17;lr>

Call-ID: ub5yOdNFB6

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

CSeq: 20 INVITE

Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS

Contact: "bob" <sip:bob@192.168.1.114:55903;ob>

Supported: replaces, 100rel, timer, norefersub

Content-Type: application/sdp

Content-Length: 381

v=0

o=- 3676737565 3676737566 IN IP4 192.168.1.114

s=pjmedia

b=AS:84

t=0 0

a=X-nat:0

m=audio 4006 RTP/AVP 96 102

c=IN IP4 192.168.1.114

b=TIAS:64000

a=rtcp:4007 IN IP4 192.168.1.114

a=sendrecv

a=rtpmap:96 opus/48000/2

a=fmtp:96 maxplaybackrate=16000;sprop-maxcapturerate=16000;maxaveragebitrate=16000;useinbandfec=1

a=rtpmap:102 telephone-event/8000

a=fmtp:102 0-16

119 ACK : Client -> Proxy

RFC3261 Section 17.1.1.3

<Request-Line>

ACK sip:bob@192.168.1.114:55903;ob SIP/2.0

Via: SIP/2.0/UDP 192.168.1.26:5060;rport;branch=z9hG4bK.ckxiSqJN-

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

CSeq: 20 ACK

Call-ID: ub5yOdNFB6

Max-Forwards: 70

Route: <sip:192.168.1.17;lr>

User-Agent: LinphoneAndroid/3.1.1 (belle-sip/1.4.2)

120 ACK : Proxy -> Server

RFC3261 Section 17.1.1.3
<Request-Line>

ACK sip:bob@192.168.1.114:55903;ob SIP/2.0

Via: SIP/2.0/UDP 192.168.1.17:5060;branch=z9hG4bK2891.db03d001.2

Via: SIP/2.0/UDP 192.168.1.26:5060;received=192.168.1.26;rport=5060;branch=z9hG4bK.ckxiSqJN-

From: <sip:6983@192.168.1.17>;tag=JtDxT530o

To: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

CSeq: 20 ACK

Call-ID: ub5yOdNFB6

Max-Forwards: 69

User-Agent: LinphoneAndroid/3.1.1 (belle-sip/1.4.2)

음성전송을 위한 RTP 세션이 시작되고, BYE method가 올때까지 지속된다.

485 BYE : Server -> Proxy

RFC3261 15.1.1
<Requrest-Line>

BYE sip:6983@192.168.1.26 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.114:55903;rport;branch=z9hG4bKPjdbdc963de20c4d52b471a2f18762a24f

Max-Forwards: 70

From: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

To: <sip:6983@192.168.1.17>;tag=JtDxT530o

Call-ID: ub5yOdNFB6

CSeq: 2505 BYE

Route: <sip:192.168.1.17;lr>

User-Agent: MicroSIP/3.12.1

Content-Length: 0

486 BYE : Proxy -> Client

RFC3261 15.1.1
<Request-Line>

BYE sip:6983@192.168.1.26 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.17:5060;branch=z9hG4bKfada.93f51355.0

Via: SIP/2.0/UDP 192.168.1.114:55903;received=192.168.1.114;rport=55903;branch=z9hG4bKPjdbdc963de20c4d52b471a2f18762a24f

Max-Forwards: 69

From: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

To: <sip:6983@192.168.1.17>;tag=JtDxT530o

Call-ID: ub5yOdNFB6

CSeq: 2505 BYE

User-Agent: MicroSIP/3.12.1

Content-Length: 0

493 OK : Client -> Proxy

RFC3261 Section 21.2.1
<Status-Line>

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 192.168.1.17:5060;branch=z9hG4bKfada.93f51355.0

Via: SIP/2.0/UDP 192.168.1.114:55903;received=192.168.1.114;rport=55903;branch=z9hG4bKPjdbdc963de20c4d52b471a2f18762a24f

From: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

To: <sip:6983@192.168.1.17>;tag=JtDxT530o

Call-ID: ub5yOdNFB6

CSeq: 2505 BYE

User-Agent: LinphoneAndroid/3.1.1 (belle-sip/1.4.2)

Supported: replaces, outbound

494 OK : Proxy -> Server

RFC3261 Section 21.2.1
<Status-Line>

SIP/2.0 200 Ok

Via: SIP/2.0/UDP 192.168.1.114:55903;received=192.168.1.114;rport=55903;branch=z9hG4bKPjdbdc963de20c4d52b471a2f18762a24f

From: <sip:bob@192.168.1.17>;tag=a42de3df101a4d4d92092d28a588aa10

To: <sip:6983@192.168.1.17>;tag=JtDxT530o

Call-ID: ub5yOdNFB6

CSeq: 2505 BYE

User-Agent: LinphoneAndroid/3.1.1 (belle-sip/1.4.2)

Supported: replaces, outbound

참조: [연재] 다시쓰는 SIP의 이해 - 7편 Chapter 3. SIP Method on RFC 3261

2016년 6월 30일 목요일

Opensips 설치 및 사용법

SIP proxy인 Opensips를 설치하고 UA(pjsua)와 연동하기위한 방법입니다.

2016년 6월 30일 신C

*Documents
http://www.opensips.org/Documentation/Manual-2-2

*source download
git clone https://github.com/OpenSIPS/opensips.git -b 2.2 opensips_2_2

* compile
make all && make install

* opensipctlrc 수정

9 ## your SIP domain
10 SIP_DOMAIN=myopensips.org // /etc/hosts 에 myopensips.org 등록.
11
12 ## chrooted directory
13 # $CHROOT_DIR="/path/to/chrooted/directory"
14
15 ## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE
16 ## by default none is loaded
17 # If you want to setup a database with opensipsdbctl, you must at least specify
18 # this parameter.
19 # DBENGINE=MYSQL
20 DBENGINE=DBTEXT
21
22 ## database port (PostgreSQL=5432 default; MYSQL=3306 default)
23 DBPORT=3306
24
25 ## database host
26 DBHOST=localhost
27
28 ## database name (for ORACLE this is TNS name)
29 DBNAME=opensips
30
31 # database path used by dbtext, db_berkeley, or sqlite
32 DB_PATH="/usr/local/etc/opensips/dbtext"
33
34 ## database read/write user
35 DBRWUSER=opensips
36
37 ## password for database read/write user
38 DBRWPW="opensipsrw"

* Create DB
1. Configuring DB Credentials
sudo /usr/local/etc/opensips/opensipsctlrc db_opensips
INFO: creating DBTEXT tables at: db_opensips ...
INFO: creating DBTEXT presence tables at: db_opensips ...
INFO: creating DBTEXT extra tables at: db_opensips ...

-ERROR: database engine not specified, please setup one in the config script
-> 환경파일에 접근권한이 없음, sudo로 수행할 것.

- DB 파일패스 설정 스크립트: /usr/local/lib64/opensips/opensipsctl/opensipsdbctl.dbtext
- DB 파일패스:/usr/local//share/opensips/dbtext/opensips/

*실행
- $opensips -l 192.168.1.17:5060
Listening on
udp: 127.0.0.1 [127.0.0.1]:5060
udp: 192.168.1.17 [192.168.1.17]:5060
Aliases:

- opensipsctl start|stop
- ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS start failed
- TODO: 왜 안될까??

*사용자 계정등록
등록된 사용자 보기: $opensipsctl ul show
등록된 사용자 제거: $opensipsctl ul rm user_name

*pjsua실행시 등록을 위한 파라미터
--id sip:paul@192.168.1.17
--registrar sip:192.168.1.17
--proxy sip:192.168.1.17;lr :Route: <sip:192.168.1.17;lr> 로 전송된다.
--realm *
--username paul
--password 1234

잘 등록됐는 지 확인:
- $opensipsctl ul show paul
AOR:: paul
Contact:: sip:paul@192.168.1.11:5060;ob Q=
Expires:: 14
Callid:: 70e7b77c-3820-4176-aa4d-3726903b6db1
Cseq:: 57254
User-agent:: PJSUA v2.5 Linux-3.18/armv7l/glibc-2.22
State:: CS_NEW
Flags:: 0
Cflags::
Socket:: udp:192.168.1.17:5060
Methods:: 8063

*연동확인 한 UA: Linephone, microsip, pjsua

2016년 6월 21일 화요일

Amp Class

1. A 클래스 앰프

가장 기본적인 반도체의 증폭 개념을 그대로 사용한 방식으로써, 출력소자에 항상 바이어스 전류가 흐르며 가장 왜율이 적고 가장 좋은 선형의 출력을 갖기는 하지만 효율이 낮은 방식 입니다.

교류신호의 +, - 신호로 구성된 소스 신호를 인위적으로 모두 ‘+’ 로 인식시켜서 일괄 증폭하는 방식이고 이를 위해서는 소스 신호와 상관없이 + 로 들어올리는 바이어스(bias) 전압을 항상 걸어 놓게 되는데 이것은 +, - 신호를 별도로 증폭하는 트랜지스터의 구조적 한계를 극복하는 방식입니다.

특히 +, - 가 빈번히 교차하는 고역 쪽으로 갈수록 매끄러운 재생이 돋보인다는 장점이 있습니다.

즉, 원 신호의 찌그러짐이나 손상 없이 증폭이 된다는 것입니다.

그래서 항상 전압이 걸리는 설계로 발열이 매우 심하고 고출력으로 설계하기 어렵다는 단점이 있습니다. (B클래스의 1/4 수준)

예를들어 20W A클래스 앰프의 경우엔 스피커로 나가는 출력과 상관 없이 볼륨이 0인 상황에서도 앰프에 파워만 들어와 있으면 20W의 에너지가 그대로 방열판으로 나가게 됩니다.

2. B 클래스 앰프

위와 같이 A클래스 앰프의 발열 및 전력 소모가 큰 문제를 개선하기 위하여 에너지 효율을 중심으로 설계된 방식이 B클래스입니다.

효율을 중시한 보편적인 앰프의 증폭방식으로서 교류의 +, - 신호를 별도로 증폭한 다음 합쳐서 최종 출력하는 방식입니다. 소스 신호가 없으면 전류가 흐르지 않으며 신호가 유입되었을 때 작동을 하게됩니다.

+와 – 신호의 상호 전환시에 순간 다른 트랜지스터가 작동하는 방식이라서 A클래스 방식에 비해 스위칭 왜곡이 발생하기 쉽고 음질 저하의 단점이 있습니다.

3. AB 클래스 앰프

말그대로 A클래스와 B클래스의 장점을 절충한 방식입니다.

기본적으로는 +, - 신호를 별도로 증폭하는 B클래스 방식이지만, 바이어스 전압을 낮게 걸어서 특정 출력까지는 A클래스처럼 작동하게 합니다.

따라서 AB클래스는 그 설계 방식이 A클래스에 가까운지 B클래스에 가까운지에 따라서 AB1급 AB2급으로 세부 구분이 되기도 합니다.

시간이 갈수록 상당수의 앰프들이 이 방식을 채택하고 있어서 하이파이앰프에서 가장 흔한 방식이 되었으며, 발열 및 전력소모에서 유리한 프리앰프는 A클래스, 파워앰프는 AB클래스로 구성하여 설계되는 경우가 많습니다.

보통 A클래스 증폭이라고 하는 앰프도 자세히 살펴보면 AB클래스인 경우도 많다고 합니다.

4. D 클래스 앰프

스위칭 또는 PWM(Pulse Width Modulation) 앰프입니다.

PWM 이라는 변조 기술을 사용합니다. 변조는 일반적으로 입력 신호를 통신하기 좋은 형태로 변형시키는 것입니다.

이 방식은 스위칭 소자 들이 완전히 ON 또는 OFF 되어 출력 소자에서의 전력 손실을 크게 감소 시켜서 90 ~95%의 효율을 얻는 것이 가능하며, (A클래스의 경우 20%의 효율) 오디오 신호는 출력 소자를 구동하는 PWM 캐리어 신호를 변조시켜 종단에서 LPF로 고주파의 PWM 캐리어 주파수를 제거한다. (로우 패스 필터를 거치는 것으로 이해됩니다)

이때 필터를 거치게 되면서 주파수 대역에 따라 왜곡율이 다르게 적용되기 때문에 소리의 왜곡이 생길 수 있다는 점이 단점이 됩니다. 대신 효율이 좋기에 작은 공간의 설계로 큰 출력을 얻을 수 있기에 최근 유행되고 있는 PC-FI등의 좁은 공간에서의 니어필드 환경에서 매우 적합한 방식이라고 생각됩니다.

※ C급 증폭방식은 오디오용에는 사용되지 않고, 효율성이 극히 요구되는 경우에 사용되는 증폭 방식입니다. (무전기등..)

부족하지만 글을 읽고 도움이 되셨으면 좋겠습니다.

[출처]오디오 앰프 클래스 구분 (A클래스 / AB클래스 / B / D클래스..?)|작성자pianto

5. D 클래스 장단점

전력효율이 80%에도 미치지 못하는 클래스 AB 앰프 역시 모바일 기기에 적용되기에는 전력 소모가 너무 크다. 그 결과 등장한 것이 클래스 D 앰프. 클래스 D 앰프는 아날로그 입력을 증폭하여 역시 아날로그 출력을 제공하는 클래스 A, B, AB 앰프와 달리 디지털 출력을 제공한다.

클래스 A, B, AB 앰프의 경우 트랜지스터에 의해 신호 증폭이 이루어지지만, 클래스 D 앰프는 신호 증폭 소자로 FET가 사용된다. FET는 트랜지스터에 비해서 상대적으로 작동 효율이 좋기 때문에 클래스 D 앰프는 85% 이상의 전력 효율을 제공한다. 따라서 현재 대부분의 모바일 기기의 오디오 시스템에서는 클래스 D 앰프를 적용한다. 최근 반도체 업체들이 제공하는 클래스 D 오디오 앰프 중에는 전력 효율이 95%에 육박하는 제품도 있다.
내셔널세미컨덕터의 아시아태평양 마케팅 담당 헨리 궉(Henry Kwok) 매니저는 "현재 대부분의 업체들이 공급하고 있는 클래스 D 앰프는 클래스 AB 앰프와 비교하여 동일한 수준의 음질을 제공하고 있다"면서, "따라서 같은 음질을 얻는다면 전력 소모 측면에서 유리한 클래스 D 앰프를 모바일 기기에 사용하는 것이 전력 특성 상 효과적"이라고 설명했다.
다만 클래스 D 앰프의 경우 PWM 변환에 고주파 신호가 필요하기 때문에 EMI 문제가 발생하게 된다. 헨리 매니저는 "가격 조건이나 신호 왜곡, 노이즈 문제 등에 관해서는 클래스 AB 앰프가 클래스 D 앰프에 비해 아직은 이점이 있는 것도 사실"이라고 조언했다.
클래스 D 앰프의 EMI, 즉 노이즈 신호를 줄이기 위한 해법으로 대부분의 아날로그 업체들이 SS(Spread Spectrum) 기술을 제공하고 있다.

6. G 클래스

클래스 G 앰프는 여타 오디오 앰프들과 달리 입력되는 오디오 신호의 크기에 따라 앰프에 걸리는 바이어스 전압이 변화한다. 오디오 신호가 작을 때는 작은 전압, 오디오 신호가 클 때는 큰 전압이 걸리는 것이다. 이는 결국 오디오 신호에 따라서 전력 소모를 조절할 수 있다는 뜻이다.

클래스 D 앰프의 음질이 향상되었다고는 하지만 아날로그 신호를 디지털로 변환하는 것과 아날로그 신호를 증폭만 하는 것에는 분명 차이가 존재한다. 따라서 클래스 AB의 음질을 유지하면서, 클래스 D 앰프와 비슷한 전력 효율을 얻기 위한 앰프가 등장한 것인데, 클래스 G 앰프가 바로 그것이다.

7. W 클래스

'WM8900' 클래스 G 제품군을 공급하고 있으며, 클래스 G의 가변 전압 구현을 위해 필요한 듀얼 입력 전압을 싱글 입력 전압으로 변형시킨 클래스 W 제품군도 선보였다.

[출처]: http://nekorea.co.kr/article_view.asp?seno=5642

2015년 7월 9일 목요일

How To Gather Information About Partition Layouts

Ameer Dawood edited this page on 2 Jun 2013 · 7 revisions

Note: I have obtained the below information with great effort and difficulty. I value this information very much and thus am sharing this for other like minded developers to find.

Introduction

All Android devices use separate partitions for storing different parts of the entire system. The boot partition consists of the linux kernel, recovery partition contains the recovery binary, system partition contains the device's ROM, data partition contains all user data and cache partition contains some cache data including dalvik-cache. Partition layout files are used to determine where each specific partition, used for Android's internal tools and provide the data to tools like Online Nandroid. The linux kernel reveals this layout in different places at times, but not always. In some instances, if this layout is not revealed, Online Nandroid uses it's own manually created partition layout file at/system/partitionlayout4nandroid.

Example (/proc/partitions on a Google Nexus 4):

major minor #blocks name
179  0 15388672 mmcblk0
179  1    65536 mmcblk0p1
179  2      512 mmcblk0p2
179  3      512 mmcblk0p3
179  4     2048 mmcblk0p4
179  5      512 mmcblk0p5
179  6    22528 mmcblk0p6
179  7    22528 mmcblk0p7
179  8      780 mmcblk0p8
179  9      780 mmcblk0p9
179 10      780 mmcblk0p10
179 11      512 mmcblk0p11
179 12      512 mmcblk0p12
179 13      512 mmcblk0p13
179 14     2048 mmcblk0p14
179 15      512 mmcblk0p15
179 16      512 mmcblk0p16
179 17      512 mmcblk0p17
179 18      512 mmcblk0p18
179 19    16384 mmcblk0p19
179 20    16384 mmcblk0p20
179 21   860160 mmcblk0p21
179 22   573440 mmcblk0p22
179 23 13798400 mmcblk0p23
179 24      512 mmcblk0p24
179 25      495 mmcblk0p25

MTD Based Devices

MTD (Memory Technology Device) based devices have /proc/mtd populated with the partition layout, by the linux kernel. Thus, no specific partition layout file is required by Online Nandroid, on MTD based devices.

Example (/proc/mtd on a Sony Ericsson Xperia Pro):

dev:    size   erasesize  name
mtd0: 19000000 00020000 "system"
mtd1: 00600000 00020000 "appslog"
mtd2: 06580000 00020000 "cache"
mtd3: 1a400000 00020000 "userdata"
mtd4: 00c80000 00020000 "boot"

Note: Some buggy kernels may not populate /proc/mtd properly. In most such cases, the underlying MTD partitions would also not be revealed by the kernel, thus proving a workaround partition layout virtually useless.

EMMC Based Devices

Few EMMC (Embedded MultiMedia Card) based devices have /proc/emmc populated with the partition layout, by the linux kernel. In this case, no specific patch file is required by Online Nandroid. However, this practice is not followed in later devices. Thus, these require patch files. A partition layout file is very similar to /proc/mtd or /proc/emmcgenerated by linux kernel. It follows the same format and the same header.

Gathering information to produce a partition layout file is trivial. It is sometimes revealed somewhere under the /sys/devices by linux kernel. But this is not always the case. ROM and kernel developers, would, most of the time, figure this out and share this information in development threads on forums like XDA. Other times, it is easiest to obtain a copy of recovery.fstab used by stock, CWM, TWRP and other recoveries. This file is present in the recovery ramdisk and thus can be obtained from someone who has physical access to the device. Alternatively, this file is available at device repositories on Github and other places. A simple search on Google for android_device_oem_device, where oem is the name of device manufacturer such as samsung, sony, motorola,lge..., and device is the code name / technical name of the device such as mako forGoogle Nexus 4 and m0 for Samsung Galaxy S III. In addition a PIT file or a scatter file for the specific device can also be used for deducing the partition layout.

Example (Partition Layout file on an HTC Sensation XL):

dev:       size      erasesize  name
mmcblk0p1: 0001f4 000000 "unknown"
mmcblk0p2: 000040 000000 "unknown"
mmcblk0p3: 001194 000000 "unknown"
mmcblk0p4: 000001 000000 "unknown"
mmcblk0p5: 007530 000000 "unknown"
mmcblk0p6: 0030d4 000000 "unknown"
mmcblk0p7: 000800 000000 "unknown"
mmcblk0p8: 000c00 000000 "unknown"
mmcblk0p9: 000800 000000 "unknown"
mmcblk0p10: 000400 000000 "unknown"
mmcblk0p11: 000400 000000 "unknown"
mmcblk0p12: 00222f 000000 "unknown"
mmcblk0p13: 000c00 000000 "unknown"
mmcblk0p14: 000c00 000000 "unknown"
mmcblk0p15: 000400 000000 "unknown"
mmcblk0p16: 0022fd 000000 "unknown"
mmcblk0p17: 000100 000000 "unknown"
mmcblk0p18: 000400 000000 "unknown"
mmcblk0p19: 000800 000000 "unknown"
mmcblk0p20: 000500 000000 "unknown"
mmcblk0p21: 0021fd 000000 "recovery"
mmcblk0p22: 001000 000000 "boot"
mmcblk0p23: 000100 000000 "unknown"
mmcblk0p24: 007bff 000000 "unknown"
mmcblk0p25: 0fffff 000000 "unknown"
mmcblk0p26: 000c00 000000 "unknown"
mmcblk0p27: 000c00 000000 "unknown"
mmcblk0p28: 0067fe 000000 "misc"
mmcblk0p29: 407fff 000000 "userdata"
mmcblk0p30: 08ffff 000000 "cache"
mmcblk0p31: 007eff 000000 "unknown"
mmcblk0p32: 000103 000000 "unknown"
mmcblk0p33: 8e4ffc 000000 "emmc"

MTK Based Devices

On devices based on MTK (MediaTek) chipsets, a file at /proc/dumchar_info is populated with the partition layout, by the linux kernel. This file, however is not similar to/proc/mtd, /proc/emmc and partition layout files used by Online Nandroid. Since MTK devices use the uboot mechanism, partitions including boot and recovery, are not revealed as separate partitions, but rather accessed sequencially by size and start parameters. The dumchar_info file has this size and start parameters specified in it. This file has some other major differences in partition naming such as the boot partition is named bootimg instead of boot, data partition is named usrdata instead ofuserdata, system partition is named android instead of system and internal sd card is named fat instead emmc. Online Nandroid (since v8.0) has built-in support for MTK based devices, thus does not require separate partition layout files on MTK based devices.

Example (/proc/dumchar_info on a Star N9770 Dual Core - MT6577):

Part_Name    Size               StartAddr         Type   MapTo
preloader    0x0000000000040000 0x0000000000000000   2   /dev/misc-sd
dsp_bl       0x00000000005c0000 0x0000000000040000   2   /dev/misc-sd
mbr          0x0000000000004000 0x0000000000000000   2   /dev/block/mmcblk0
ebr1         0x0000000000004000 0x0000000000004000   2   /dev/block/mmcblk0p1
pmt          0x0000000000400000 0x0000000000008000   2   /dev/block/mmcblk0
nvram        0x0000000000500000 0x0000000000408000   2   /dev/block/mmcblk0
seccfg       0x0000000000020000 0x0000000000908000   2   /dev/block/mmcblk0
uboot        0x0000000000060000 0x0000000000928000   2   /dev/block/mmcblk0
bootimg      0x0000000000600000 0x0000000000988000   2   /dev/block/mmcblk0
recovery     0x0000000000600000 0x0000000000f88000   2   /dev/block/mmcblk0
sec_ro       0x0000000000600000 0x0000000001588000   2   /dev/block/mmcblk0p2
misc         0x0000000000060000 0x0000000001b88000   2   /dev/block/mmcblk0
logo         0x0000000000300000 0x0000000001be8000   2   /dev/block/mmcblk0
expdb        0x0000000000200000 0x0000000001ee8000   2   /dev/block/mmcblk0
android      0x0000000020100000 0x00000000020e8000   2   /dev/block/mmcblk0p3
cache        0x0000000020100000 0x00000000221e8000   2   /dev/block/mmcblk0p4
usrdata      0x0000000020100000 0x00000000422e8000   2   /dev/block/mmcblk0p5
fat          0x00000000854f8000 0x00000000623e8000   2   /dev/block/mmcblk0p6
bmtpool      0x0000000001500000 0x00000000ff9f00a8   2   /dev/block/mmcblk0
Part_Name:Partition name you should open;
Size:size of partition
StartAddr:Start Address of partition;
Type:Type of partition(MTD=1,EMMC=2)
MapTo:actual device you operate

Very interesting from looking at your partition layout I can see that that /dev/block/mmcblk0 contains your recovery partition. However it appears /dev/block/mmcblk0 is a combined partition that also contains many critical parts of the phones file system such u-boot, /boot, and other bootloader related components. I would recommend running the following commands as root from either ADB shell:

Code:

cd /dev/block/platform

Then from the platform directory list the contents of the directory with the "ls" command. Once you have done that you should see a platform name (Or multiple platform names) for example on my Verizon Galaxy S3 it shows:

Code:

msm_sdcc.1
msm_sdcc.3

Cd into each of the platform directories (Or if there is only one platform directory "cd" into that) and list the contents of the platform directory using the "ls" command and look to see if it list a directory "by-name". If the platform directory your in contains the "by-name" folder run the following command:

Code:

ls -l /dev/block/platform/{platform directory name here}/by-name

If that command returns an output take note of the the block number that contains the recovery partition.

Another suggestion would be to run the following command to try and isolate the recovery.img from the larger /dev/block/mmcblk0 contents:

Code:

dd if=/dev/block/mmcblk0 of=mnt/sdcard/recovery.img bs=1 skip=6291456 count=8257536

(bs: block size in bytes, skip: start offset of mmcblk0, seek: start offset of recovery.img)

Additionally you could try dumping the whole /dev/block/mmcblk0 partition using the command:

Code:

cat /dev/block/mmcblk0 > /mnt/sdcard/recovery.img

Let me know how the above commands work out for you

dd command explain:

http://wiki.linuxquestions.org/wiki/Some_dd_examples

For emmc at least (and SD?) there are hidden "secure" areas. These are generally used for u-boot and other low-level boot mechanisms.
If dd can't see them, it's because the OS doesn't expose them through the device file used to access them (eg, /dev/mmcblk0). It's not a shortcoming of dd, as such.
A lot of embedded devices use these secure areas to do boot before the host operating system even gets a chance to look at the device. There'll be level 1 and level 2 boot loaders that eventually load up u-boot, which then bootstraps the host OS's kernel. After that, the host OS generally doesn't even see the "hidden" areas. That's due to honouring some part of the spec for accessing these "secure" media devices, I think. Part of that is the ARM's TrustZone (IIRC) mechanism to give confidence that the boot sequence hasn't been tampered with.
Another way that the physical contents of the flash can be hidden is if the device does stuff like wear levelling or other hardware/firmware-based mechanism for dealing with bad blocks or the like. You'd need some sort of microscope and minuscule test probes to forensically examine what's actually stored in each memory cell (or just convince the controller to give you raw access).
If you really want to write something into the secure/hidden/separated boot block of eMMC, you need to unlock it first.

CODE: SELECT ALL: sudo su - # echo 0 > /sys/block/mmcblk0boot0/force_ro # dd if=/root/boot0.img of=/dev/mmcblk0boot0

But your board/eMMC will not boot if the written u-boot binary is not correct

2015년 7월 8일 수요일

안드로이드 장치를 리눅스에서 인식하지 못할 때

$ adb devices를 쳤을 때,

???? 이러면서 디바이스의 권한이 없다고 하는 경우가 있습니다.

이 때는 디바이스를 인식하고 있지 못하는 겁니다. 그러나, 리눅스가 어떤 존재입니까. 하면 다 됩니다. 그것도 텍스트 파일로 설정 고친다는 좋은 특성이 있죠.

$ lsusb

Bus 002 Device 017: ID 0461:4d15 Primax Electronics, Ltd Dell Optical Mouse

Bus 002 Device 014: ID 05c6:9025 Qualcomm, Inc.

Bus 002 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

Bus 002 Device 005: ID 413c:2003 Dell Computer Corp. Keyboard

Bus 002 Device 003: ID 1a40:0101 TERMINUS TECHNOLOGY INC.

Bus 002 Device 002: ID 8087:0020

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 013: ID 04e8:685e Samsung Electronics Co., Ltd

Bus 001 Device 004: ID 05ac:1293 Apple, Inc.

Bus 001 Device 002: ID 8087:0020

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

해보면 뭐가 많습니다.

위의 퀄컴은 사용하고 있는 개발보드, 아래는 갤S2입니다. 둘다 인식을 못해서, 인식 시키려구요.

자, 파일을 새로 만들어 줍니다.

$ sudo vi /etc/udev/rules.d/ii-android.rules

(사실 ii-android.rules 아니고 99-였는데;)

이름이야 어찌되었던 하여튼 거기

SUBSYSTEMS=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="685e", MODE="0666"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="05c6", ATTRS{idProduct}=="9025", MODE="0666"

라고 적습니다. 그냥, 색깔 맞춰서 적어주시면 됩니다. 설명도 적당히 되어있네요. (idVendor! idProduct!)

그리고선

adb kill-server

sudo adb start-server

adb devices

해보시면 제대로 출력되는걸 보실 수 있습니다.

그리고 기타 등등 adb 명령에 대한 것들은

(영문)

http://developer.android.com/guide/developing/tools/adb.html

(블루아이님 정리, 한글)

http://blog.naver.com/PostView.nhn?blogId=blueeye2424&logNo=70116985833

참고 하시면 되겠습니다.

원문: http://tenisland.tistory.com/ ( by narguts)

2015년 7월 7일 화요일

Linux Kernel 분석 사이트

LXR: http://lxr.free-electrons.com/
The Linux kernel Andries Brouwer (2003-02-01)
임베디드 시스템 엔지니어를 위한 리눅스 커널 분석 (2002)
Documentation on memory management
- Understanding the Linux Virtual Memory Manager, online book by Mel Gorman.
- What every programmer should know about memory, article series by Ulrich Drepper, parts one, two, three, four, five.
- Ars technica ram guide, article series by Jon "Hannibal" Stokes, parts one, two, three, Cacheing, Bandwidth and Latency.