> Tommy Note :: 'SIP' 카테고리의 글 목록

달력

4

« 2024/4 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30

'SIP'에 해당되는 글 2

  1. 2015.11.20 SIP 내부 교육
  2. 2015.09.10 [SIP] Disconnect Cause Code
2015. 11. 20. 11:07

SIP 내부 교육 SIP2015. 11. 20. 11:07

* SIP 구성 요소

UA = UAC + UAS

UAC (User Agent Client)

UAS (User Agent Server)

Register - UA가 등록하는 서버

Redirect Server - SIP 접속 요청 메세지를 보내온 UA 또는 Proxy 서버에게  재 전송해야 하는 새로운 주소를 알림

Proxy Server - 메세지 Relay 서버


* H.323과 SIP의 비교

- H.323 <-> SIP + SDP

- H.225 <-> SIP

- H.245 <-> SDP


* basic call flow

- invite

- 180 ringing / 200 ok

- ack

- 세션 연결

- bye

- 200 ok


* dialog - 연속성을 갖고 있는 종단간의 관계

, trancation - 한쌍의 Request와 Response


* B2BUA - Back to Back User Agent

각각의 Dialog를 형성하여 다양한 기능을 함 -> 다양한 부가서비스(컬러링, IVR등) 코덱변환 등

기본적으로 Dialog를 수정 할 수는 없다. Proxy 서버 구조에서는...


* 기본 메쏘드

INVITE - 멀티미디어 세션에 참가시키기 위한 서비스 또는 사용자를 초대하기위한 매쏘드 

ACK - INVITE 메쏘드에 대한 최종 응답인 200 OK를 수신했음을 통지하기 위한 매쏘드

BYE - 기존의 세션을 종료하기 위한 매쏘드

CANCEL - 최종 응답 200 OK를 받기 전에 기존의 요청을 취소하기 위한 메쏘드

OPTIONS - 서버의 Capability 를 요청하기 위한 매쏘드

REGISTER - User Agent가 Registrar Server에 등록하기 위한 매쏘드

INFO (RFC 2976)  -기존의 설립된 세션 또는 다이얼로그 내에서 추가적인 정보를 전송하기 위한 매쏘드

PRACK (RFC 3262) - UAC (User Agent Client)가 임시적으로 Response를 승인하기위한 매쏘드 

SUBSCRIBE (RFC 3265) -특정 이벤트를 살펴보기 위해 원격노드에 요청하기 위한 매쏘드 

NOTIFY (RFC 3265) - 특정 이벤트 발생 시 응답하기 위한 매쏘드 

UPDATE (RFC 3311)  - 세션 설정 파라미터를 업데이트하기 위한 매쏘드 

MESSAGE (RFC 3428)  - 채팅과 같은 단문 메세지를 (IM, Instant Messaging)을 전달하기 위한 매쏘드

REFEER (RFC 3515) - 호전환 (Call Transfer)과 같이 UA가 지금 통신 중인 UA 이외의 또 다른 UA와 통신하기 위한 매쏘드 

PUBLISH (RFC 3903) - Presence Server에 UA의 상태정보를 전송하기 위한 매쏘드



* SIP Response

1XX - information

2XX - success

3XX - redirection

4XX - client error

5XX - server error

6xx - Global failure


* VIA

거쳐가는 곳을 모두 표시

예를 들어 Proxy 서버가 있으면, 

A가 B에게 보낼때 첫번째 A가 VIA를 하나 쓰고,

중간에 Proxy가 받으면 자신의 VIA를 위에 쓴다.

그리고 나서 B가 200 OK를 보낼때 맨 위에 VIA를 타겟으로 보내고 

이걸 받은 Proxy가 자신의 VIA를 벗겨 내고 바로 아래의 VIA를 타겟으로 보낸다.


* ACK

- 기본은 Contact를 보고 가기 때문에 End to End로 통신한다.

  하지만 RFC 3261 부터 모든 시그널을 Proxy로 경유 시키겠다는 이론이 나옴

  왜냐면 사업자는 계속해서 모니터링이 필요 하니깡...

  이걸 하려면 Invite에 Record-Route를 삽입하면 된다.

  그러게 되면 End to End간에 ACK를 주고 받는게 아니라. Proxy를 통해서 ACK를 주고 받게 된다.


* SIP Redirect 방식

- A가 SIP Redirect 서버에게 invite를 보내면, 

302 메세지에 B의 위치 정보만 알려주고, 이걸 받은 A는 다시 B에게 invite를 직접 보내게 된다.

(노텔의 5.5 버전까지는 이 방식을 사용 함)


* SDP (Session Description Protocol)

- Early Offer (Invite에 SDP가 있는 경우)

노텔과 어바이어는 무조건 이며, 옵션은 없다 다면 delay offer를 처리 함

- Delay Offer (Invite에 SDP가 없는 경우)

시스코는 기본적으로 delay offer이고 옵션 조정 가능


* 180이 없는 경우는 ??

- IVR이나 자동 응답기 같은 것 


* Media Clipping

- UAC는 ACK 전달 후에 Media가 열린다. 

- RTP는 Signal 보다도 빠르다.

- B가 받아서 응답해서 말할 때 A한테 앞에 말한 부분이 짤리는 현상


* Early Media

- Media Clipping 의 이슈를 해결하기 위해서

- SDP를 ACK가 아닌 180/183에 보낸다.

- SDP Offer / Answer 협상 전에 Media 채널이 필요한 경우 (컬러링, Remote Ring Back Tone)

- Reqular Media (이건 일반적으로 ACK에 SDP 를 가지고 협상하는 경우를 말함)


* PRACK

- 180이나, 183에 대한 메세지를 잘 받았는지 확인 하고 싶을 때...

- response 메세지를 정확하게 받았는지 확인하고 싶을 때 보낸다.

- invite라면 200 ok 를 받겠지만 180은 A가 B에게 보내는 거니까 

   그거에 대한 응답은 안오니까 잘 받았는지 확인이 필요할 때 그 때 사용 한다.


 * Transfer - Re Invite

- 홀드 시키기 위해서 reinvite를 보낸다.


* DTMF

- in-band

- RFC 2833 (duration을 전달할 수 있는 방식)


101 telephony 

- SIP Info 








:
Posted by 부다투더리
2015. 9. 10. 10:25

[SIP] Disconnect Cause Code SIP2015. 9. 10. 10:25

SIP 메시지에서 콜이 끊어진 경우 코드 번호


16 –> Normal Call Clearing

38 –> Network Connectivity Error

47 –> Resource Error

65 –> Codec Negotiation Error


[상세코드]

http://www.cisco.com/c/en/us/td/docs/ios/voice/monitor/configuration/guide/12_4/vt_12_4_book/vt_ccodes_debug.html#wp1007443


:
Posted by 부다투더리