Handoffs

애플리케이션에 통신 세션에 대한 소유자 권한이 있는 경우 애플리케이션은 소유권을 다른 애플리케이션에 전달하도록 선택할 수 있습니다. 핸드오프 작업은 일반적으로 통화의 미디어 형식을 변경할 수 있도록 하는 데 사용됩니다. 새 미디어 유형에 대한 우선 순위가 가장 높은 애플리케이션은 호출을 사용하고 처리해야 합니다. 미디어 유형 변경은 일반적으로 다음 이유 중 하나로 발생합니다.

사용자 명령: 애플리케이션은 사용자 인터페이스 또는 창 메시지를 통해 로컬 사용자가 미디어 형식을 변경하려고 한다는 것을 알게 됩니다. 예를 들어 사용자는 새 대상 애플리케이션(아직 소유자가 아님)에게 데이터 전송을 위한 기존 음성 호출을 가져오라고 말했습니다. 이제 대상 애플리케이션이 호출을 제어해야 합니다. 이 경우 현재 소유자는 소유자 수가 늘어나고 통화 제어를 포기합니다. 또는 사용자가 호출의 현재 소유자에게 새 미디어 형식을 처리할 수 있는 애플리케이션에 전달하도록 지시할 수 있습니다.

미디어 유형 변경: 서비스 공급자는 미디어 유형 변경을 검색할 수 있습니다. 예를 들어 로컬 애플리케이션은 발신자에게 녹음된 음성 메시지를 재생합니다. 이 메시지 중에 발신자는 자발적으로 팩스 통화 톤을 전송하기로 결정하고, 로컬 애플리케이션은 미디어 유형을 팩스로 변경하고 필요한 경우 팩스 애플리케이션에 통화를 전달하여 그에 따라 응답할 수 있습니다. 이 작업을 수행할 수 있는 또 다른 방법은 모니터링 애플리케이션이 미디어 형식 모니터링을 사용하도록 설정하는 것이며, 통화에서 관심이 있는 미디어 유형이 감지되면 통화 소유권을 요청할 수 있습니다. 이 메커니즘을 사용하면 모든 애플리케이션이 모든 미디어 유형에 대한 모든 호출을 모니터링할 필요가 없습니다.

원격 파티 명령: 원격 당사자는 로컬 애플리케이션이 원격 호출자의 DTMF 입력을 모니터링하는 경우와 같이 기존 호출 중에 미디어 형식의 변화를 대화형으로 나타낼 수 있습니다. 이 모니터링을 통해 호출자는 예를 들어 팩스를 보내려고 했음을 나타냅니다. 호출자가 로컬 애플리케이션을 제어할 수 있는 다른 방법은 다른 데이터 연결 및 ISDN 사용자-사용자 정보 메시지를 통해 수신된 명령을 사용하는 것입니다.

호출 핸드오프에는 다음 결과 중 하나가 있습니다.

• 호출은 다른 애플리케이션(SUCCESS)에 제공됩니다.
• 전달-끄기 애플리케이션 자체는 대상(TARGETSELF)입니다.
• 핸드오프가 실패합니다(TARGETNOTFOUND).

핸드오프 호출을 수신하는 애플리케이션에 이미 호출에 대한 호출 핸들이 있는 경우 이 이전 호출 핸들이 사용됩니다. 그렇지 않으면 새 호출 핸들이 만들어집니다. 두 경우 모두 애플리케이션은 호출에 대한 소유자 권한으로 끝납니다. 전달-끄기 애플리케이션이 대상 애플리케이션과 동일하지 않을 때마다 대상은 새 호출을 받은 것처럼 세션 상태 메시지의 핸드오프에 대해 알 수 있습니다.

현재 소유자 애플리케이션이 미디어 형식을 변경하라는 지시를 받으면 대상 미디어 형식에 사용되는 애플리케이션에 대한 호출을 전달합니다. 두 가지 유형의 통화 핸드오프는 Directed Handoffs 및 Media 형식 핸드오프에 설명되어 있습니다.

모든 서비스 공급자가 이 작업의 사용을 지원하는 것은 아닙니다.

TAPI 2.x: 간접 핸드오프를 위해 직접 핸드오프 또는 dwMediaMode가 하나의 미디어 형식으로 설정된 경우 lpszFileName이 애플리케이션 이름으로 설정된 lineHandoff를 참조하세요.

TAPI 3.x:ITBasicCallControl::HandoffDirect, ITBasicCallControl::HandoffIndirect를 참조하세요.

Directed Handoffs

대상 애플리케이션이 이름으로 원래 애플리케이션에 알려지면 전달된 핸드오프 가 발생합니다. 예를 들어 동일한 공급업체에서 작성한 애플리케이션 집합 중에서 이러한 상황이 발생합니다. 사용자는 일반적으로 전달된 핸드오프의 제어를 구성할 수 있습니다. 이러한 핸드오프를 사용하면 호출이 있는 줄을 연 경우 지정된 애플리케이션에 호출이 제공됩니다. 애플리케이션이 줄을 열 때 지정된 미디어 형식은 무시됩니다. 한 가지 일반적인 예는 음성 통화와 동일한 통화에서 팩스 전송이 뒤따르는 것입니다. 직접 전달은 다른 방법으로도 연결된 동일한 개발자의 애플리케이션에서 가장 자주 사용됩니다.

또한 전달된 핸드오프는 동일한 미디어 유형의 수신 호출을 기다리는 여러 애플리케이션을 중재하는 프로세스의 일부로 향후 버전에서 사용될 수 있으며, 미디어 형식이 아닌 데이터 링크 또는 상위 수준 프로토콜 검색을 기반으로 하는 호출을 처리하도록 애플리케이션을 선택할 수 있습니다. 사용의 예로는 원격 인수, 게시판, 원격 네트워크 액세스 및 원격 전자 메일 액세스와 같은 애플리케이션이 있는 들어오는 데이터 모뎀 라인이 동시에 호출을 기다리는 것입니다.

미디어 형식 핸드오프

미디어 유형 핸드오프는 새로운 대상 미디어 유형이 있을 때 발생합니다. 일반적으로 소유 애플리케이션이 호출에 필요한 미디어 형식이 없거나 변경하려고 할 때 발생합니다.

미디어 유형 UNKNOWN 비트가 있는 경우 미디어 종속 핸드오프 프로세스는 검색 프로세스일 수 있습니다. 우선 순위가 가장 높은 애플리케이션을 찾기 위해 미디어 유형을 순환하는 것은 소유 애플리케이션의 책임입니다. TAPI는 첫 번째 소유자를 찾기 위해 처음 들어오는 호출에서만 이 순환을 수행합니다. 핸드오프 작업에는 이 작업을 수행하지 않습니다. 그렇지 않으면 핸드오프는 애플리케이션에 대한 호출의 초기 할당과 거의 동일합니다. 차이점은 간접(미디어 형식) 핸드오프에 대해 하나의 미디어 형식만 설정할 수 있다는 점입니다.

단일 미디어 형식 비트만 지정할 수 있으므로 해당 미디어 형식에 대한 우선 순위가 가장 높은 애플리케이션에 호출이 제공됩니다. 그러나 핸드오프를 위해 둘 이상의 미디어 유형을 고려할 수 있습니다. 이 경우 전달 해제 애플리케이션은 가능한 미디어 형식의 가장 높은 우선 순위를 매개 변수로 지정해야 합니다.

미디어 형식 핸드오프를 수행할 때 애플리케이션이 UNKNOWN 비트를 지정하고 핸드오프가 실패하면 미디어 형식 결정을 수행할 수 있는 알 수 없는 애플리케이션이 현재 실행되고 있지 않습니다. 그런 다음 전달되는 애플리케이션은 다음으로 높은 미디어 유형에 대해 등록된 우선 순위가 가장 높은 애플리케이션에 호출을 전달하려고 시도해야 합니다.

수신 애플리케이션은 이제 호출을 담당합니다. 이제 호출의 실제 미디어 유형을 검색합니다. 애플리케이션이 통화의 미디어 형식을 처리할 수 있는 경우 해당 미디어 유형에 대해 등록된 우선 순위가 가장 높은 애플리케이션인지 확인해야 합니다. 이 경우 호출을 유지하고 정상적으로 처리합니다. 그렇지 않은 경우 해당 미디어 유형에 등록된 다른 애플리케이션에 대한 호출을 전달합니다.

그러나 해당 미디어 형식에 대한 프로브가 실패하면 애플리케이션이 다시 검색하여 나머지 미디어 모드 가능성을 시도합니다. 먼저 현재 미디어 형식 비트를 해제한 다음 다른 형식의 다른 핸드오프를 시도해야 합니다.

이 검색 및 전달 프로세스는 계속되며 나머지 미디어 유형은 하나씩 제거됩니다. 그 과정에서 애플리케이션 중 하나에서 처리하는 미디어 유형이 호출 중이고 핸드오프가 성공했음을 알 수 있습니다.

그러면 애플리케이션이 올바른 미디어 형식을 설정하고 다른 모든 미디어 형식 비트를 지워야 합니다. 이렇게 하면 다른 관심 있는 애플리케이션에 올바른 미디어 유형을 알 수 있습니다. 이러한 다른 애플리케이션은 통화의 미디어 유형이 변경되었다는 이벤트 알림 메시지를 받습니다.