SIP 컨테이너

100 응답을 보냈을 때 SIP 컨테이너에서 CANCEL을 처리할 수 없음(이슈 번호 712)

설명

100 응답이 전송되었을 때 SIP 컨테이너가 CANCEL 요청을 처리할 수 없습니다.

해결 방법

원격측에서 INVITE 요청을 CANCEL(취소)할 수 있으므로 응용 프로그램은 1xx와 같은 임시 응답을 보내야 합니다.

SIP 세션과 HTTP 세션이 동일한 세션 만료 시간 모델을 적용하지 않음(이슈 번호 1180)

설명

SIP 세션의 세션 만료 모델이 HTTP 만료 시간 논리와 다릅니다. HTTP에서는 해당 HTTP 세션에서 새 HTTP 요청을 수신할 때마다 세션이 자동으로 연장되어 응용 프로그램의 제어를 벗어납니다.

반면, SIP 세션에서는 응용 프로그램이 SIP 컨테이너의 승인에 따라 SipApplicationSession(SAS) 기간으로 통제됩니다. 응용 프로그램은 setExpires 메소드를 사용하여 SAS의 만료 시기를 나타낼 수 있습니다. setExpires는 setExpires 메소드가 호출되는 시기를 기준으로 만료 시간을 정의합니다. 컨테이너는 setExpires에 표시된 기간을 수정, 거부 또는 승인할 수 있습니다. 세션이 무효화되지 않으면 setExpires로 정의한 시간에 sessionExpired 콜백이 수행됩니다. 이 콜백에서 응용 프로그램은 새 setExpires를 호출하여 SAS의 기간을 연장하고 컨테이너에 의한 수정, 거부 또는 승인을 따를 수 있습니다.

이러한 이유로, HTTP 세션에서 SipApplicationSession(SAS)과 동일한 만료 시간으로 시작하는 수렴형 응용 프로그램은 HTTP 세션에서 새 요청을 수신한 경우 HTTP 세션 전에 SAS 시간이 초과되는 것으로 나타납니다.

해결 방법

SIP 세션과 HTTP 세션의 서로 다른 만료 시간 처리 문제를 해결하는 가장 좋은 방법은 SAS 만료 시간을 충분히 하여 시작하는 것입니다. 여러 HTTP 요청을 포함하여 응용 프로그램 세션이 활성 상태로 있을 시간을 충분히 하십시오. 특히 마지막 프로토콜 하위 세션이 무효화될 때 SipApplicationSession이 무효화되는 invalidateWhenReady 어휘가 사용되는 경우 SAS 수명을 무한으로 설정할 수도 있습니다. SAS에 대한 초기 만료 시간은 배포 설명자에서 구성할 수 있습니다.

최대 총 기간을 미리 추정할 수 있으면, SAS가 만료될 때 SIP 세션과 HTTP 세션을 모두 무효화하는 것이 적절하므로, 추가 코드는 필요 없습니다. 최대 기간을 미리 추정할 수 없으면, 아래 코드 조각에 나타난 대로, SipApplicationSession이 만료될 때 이를 연장할 수 있습니다.

SipApplicationSessionListener 구현 시 다음과 같은 작업을 수행할 수 있습니다.

public void sessionExpired(SipApplicationSessionEvent sasEvent) {
                // check if the SAS needs to be extended first, if so:
		int granted = sasEvent.getApplicationSession().setExpires(2);
		if (granted <= 0) {
			System.out.println("extension rejected");
		} else if (granted < 2) {
			System.out.println("extension granted with lower value " + granted);
		} // else allowed 
	}

sessionExpired에 대한 컨테이너 콜백 후 SIP 세션이 활성 상태임(이슈 번호 1265)

설명

간혹 발생하는 문제입니다. SIP 컨테이너는 종종 세션이 제거되었음을 나타내는 NOTIFY에 대한 200과 해당 NOTIFY 수신 시 클라이언트가 보낸 SUBSCRIBE 간에 레이스 조건이 있을 때 481 호출/트랜잭션이 존재하지 않음 메시지 대신 500 서버 내부 오류 메시지로 응답합니다.

해결 방법

가입이 만료되기 훨씬 전에 클라이언트가 SUBSCRIBE를 새로 고쳐야 합니다.

Communications Server가 처음에 UAS로 작동한 후 프록시로 작동하고 NOP를 생성함(이슈 1432)

설명

INVITE 요청 수신 시, Communications Server는 먼저 UAS로 작동하고, 이 요청에 1XX로 회신한 다음 이 INVITE 요청을 다른 인스턴스로 프록시하여 200 OK로 회신합니다. 1xx는 내부 가상 분기를 만드는 반면, 200 메시지는 실제 분기를 만듭니다. B에서 200 OK 수신 시, 내부 가상 분기를 취소해야 합니다.

해결 방법

이 예외 추적은 가상 프록시 분기의 기능에 영향을 주지 않습니다.

getLastAccessedTime 메소드가 정확한 결과를 제공하지 않음(이슈 번호 1351)

설명

SIP 세션의 getLastAccessedTime 메소드가 정확한 결과를 제공하지 않습니다.

해결 방법

lastAccessedTime을 정확하게 추적해야 하는 응용 프로그램이 직접 이를 SipApplicationSession에 저장해야 합니다.

synchronized (sas) {
	Long last = (Long) sas.getAttribute("myLastAccessedTime");
	if (last == null) {last = 0};
	// do something with the last one
	// and...
	// set the new one.
	sas.setAttribute("myLastAccessedTime", System.currentTimeMillis());
}

SIP 수신기가 삭제된 후에도 특정 기간 동안 활성 상태로 유지됨(이슈 번호 1294)

설명

TCP 및 UDP 요청에 대해 구성된 SIP 수신기가 삭제된 후에도 특정 기간 동안 활성 상태로 유지됩니다. 수신기로 전송된 UDP 요청이 수신기로부터 응답을 수신할 수 있습니다.

해결 방법

알려진 해결 방법은 없습니다. 특정 기간이 지나면 SIP 수신기가 UDP 요청 수신을 중지합니다. 이 문제는 TCP 요청에 영향을 주지 않습니다.

Communications Server가 "<>" 없이 Contact 헤더를 수신할 때 예외가 발생함(이슈 번호 1489)

설명

Communications Server가 "<>" 없이 Contact 헤더를 수신할 때 예외가 발생합니다. SIP RFC 3261에 따르면 주소에 반드시 "<>"를 사용하지 않아도 되지만, 이 경우 다른 SIP 규격 장치와의 상호 운영성 문제가 발생할 수 있습니다.

해결 방법

Contact 헤더에 "<>"를 사용하십시오.

Communications Server가 잘못된 UUID 값에서 예외를 발생함(이슈 번호 1494)

설명

Communications Server가 400 잘못된 요청을 반환하는 대신 잘못된 UUID 값에서 예외를 발생시킵니다. UUID 값은 SIP 연락처 헤더의 sip.instance 값에 있습니다.

해결 방법

알려진 해결 방법은 없습니다.

Windows: 때때로 Communications Server에서 UDP 메시지를 수신하지 못함(ID 없음)

설명

이 문제는 Windows에서만 간헐적으로 나타납니다. Communications Server에서 UDP 메시지를 수신하지 못합니다.

해결 방법

다음 JVM 옵션을 다음과 같이 설정하고 Communications Server를 다시 시작하십시오.

org.jvnet.glassfish.comms.disableUDPSourcePort=true