SIP 애플리케이션 개발자를 위한 런타임 고려사항
SIP(Session Initiation Protocol) 애플리케이션 작성 시 특정 제품 런타임 동작을 고려해야 합니다.
컨테이너는 비-SIP URI 체계를 허용할 수 있습니다.
컨테이너가 애플리케이션에서 지원되는 URI 체계를 알 수 없기 때문에 요청 URI(Uniform Resource Indicator)에서 체계를 인식하지 않는 경우 SIP 컨테이너는 메시지를 거부하지 않습니다. SIP 요소는 sip 또는 sips가 아닌 체계가 있는 요청 URI를 지원할 수 있으며, 예를 들어 pres: 체계는 존재 서버에 대한 특정 의미가 있지만 컨테이너는 이를 인식하지 못합니다. 특정 체계를 허용하거나 또는 거부하는지 여부는 애플리케이션이 판별합니다. SIP 요소는 사용 가능한 메커니즘을 사용하여 비-SIP URI를 변환하여, RFC 2806 [9]의 tel URI 체계와 같은 SIP URI, SIPS URI 또는 다른 체계가 발생할 수 있습니다.

다중 컨테이너 환경에서 요청 지정
다중 컨테이너 환경(SIP 프록시 및 SIP 컨테이너)에서, 애플리케이션은 요청을 처음에 외부로 보내지만 나중에 수신하도록 계획된 경우 가장 전면의 로드 밸런스 요소(다중 SIP 프록시용 IP 스프레이어, 또는 하나만 존재하는 경우 SIP 프록시)의 호스트와 포트를 사용해야 합니다. 애플리케이션이 가장 전면 요소 대신 컨테이너의 호스트 이름을 사용하는 경우, 요청은 실패의 경우 유실될 수 있습니다.
예를 들어, 애플리케이션이 자체에 INVITE 요청을 보내지만 요청은 푸시된 라우트 헤더를 통해 외부 회계 시스템을 통해 전달해야 합니다. 애플리케이션은 INVITE 요청의 URI를 가장 전면 요소의 호스트와 포트로 설정해야 장애 복구가 발생합니다. 요청은 푸시된 라우트를 통해 회계 시스템으로 라우트된 다음, 프론트 로드 밸런스 요소로 다시 전송하여 처리합니다.
세션 리스너 이벤트 호출
애플리케이션이 해당 세션 오브젝트를 요청하는 경우에만 SipSessionListener 및 SipApplicationSessionListener 이벤트가 호출됩니다. 표 1에 표시된 애플리케이션 메소드에서 사용하여 이를 수행합니다.이벤트 | 메소드 |
---|---|
SipSessionListener | getSession() |
SipApplicationSessionListener | getApplicationSession() |