SIP 애플리케이션 개발자의 런타임 고려사항
SIP(Session Initiation Protocol) 애플리케이션을 작성하는 경우 특정 제품 런타임 동작을 고려해야 합니다.
비SIP URI 설계를 허용하는 컨테이너
SIP
컨테이너가 애플리케이션에서 지원하는 URI(Uniform Resource Indicator) 설계를
확인할 수 없어서 요청 URI의 설계를 인지하지 못한 경우 해당 컨테이너는
메시지를 거부하지 못합니다. SIP 요소는 sip 또는 sips
이외의 설계로 구성된 요청 URI를 지원할 수 있습니다. 예를 들어 pres:
설계는 Presence Server라는 특별한 의미를 갖고 있지만 컨테이너는 이 의미를
인지하지 못합니다. 특정 설계를 허용하거나 거부하는 결정은 애플리케이션에서
내립니다. 사용 가능한 메커니즘을 사용하여 SIP 요소가 비SIP URI를 변환하면
RFC 2806 [9]의 tel URI 설계와 같이 SIP URI, SIPS URI 또는
기타 설계로 결정됩니다.
다중 컨테이너 환경에서 직접 요청
다중 컨테이너 환경(SIP 프록시 및 SIP 컨테이너)에서 애플리케이션이 원래 외부에서 전송한 후 나중에 수신하기로 한 요청을 전송하는 경우 맨 앞에 있는 load balancing 요소(다중 SIP 프록시의 경우 IP sprayer 또는 SIP 프록시가 하나만 있는 경우 해당 SIP 프록시)의 호스트 및 포트를 사용해야 합니다. 애플리케이션이 맨 앞에 있는 요소 대신 컨테이너의 호스트 이름을 사용하는 경우 장애가 발생하면 해당 요청이 유실될 수 있습니다.
예를 들어 애플리케이션이 INVITE 요청을 자체 애플리케이션으로 전송하지만 요청은 푸시된 Route 헤더를 통해 외부 계정 시스템에서 전달되어야 합니다. 애플리케이션은 장애 복구가 수행되었는지 확인하려면 INVITE 요청 URI를 맨 앞에 있는 요소의 호스트 및 포트로 설정해야 합니다. 요청은 푸시된 Route를 통해 계정 시스템으로 라우트된 후 앞에 있는 load balancing 요소를 처리하기 위해 다시 전송합니다.
세션 리스너 이벤트 호출
SipSessionListener 및 SipApplicationSessionListener 이벤트는 애플리케이션이 해당 세션 오브젝트를 요청하는 경우에만 호출됩니다. 애플리케이션에서 표 1에 표시된 메소드를 사용하여 이를 수행합니다.| 이벤트 | 방법 |
|---|---|
| SipSessionListener | getSession() |
| SipApplicationSessionListener | getApplicationSession() |