통신 시스템에서 초기 미디어를 용이하게 하는 것 document_id A220623053142

IETF RFC 3261에 의해 규정된 바와 같이, 세션 개시 프로토콜(SIP)은 IP 네트워크에서 하나 이상의 참여자와의 세션을 생성하고, 변경하며 종료하는 애플리케이션-층 제어 (시그널링) 프로토콜이다. 이러한 세션은 인터넷 전화 호출, 멀티미디어 분배, 및 멀티미디어 회의를 포함한다. SIP 초대는 참여자가 호환 가능한 미디어 유형의 세트에 도달하도록 하는 세션 운반 세션을 생성하는데 사용된다. SIP는 사용자의 현재 위치에 대한 요청을 라우팅하고, 서비스에 대해 사용자를 인증 및 승인하고, 공급자 호출-라우팅 정책을 구현하고, 사용자에게 특성을 제공하는 것을 돕기 위하여 프록시 서버라 칭해지는 요소를 사용한다. SIP는 또한 사용자가 프록시 서버에 의한 사용을 위해 자신들의 현재 위치를 업로딩하도록 하는 등록 기능을 제공한다. 소위 "애플리케이션 서버(ASs)는 어떤 기능을 구현하기 위하여 예를 들어, SIP 프록시 서버 내에서 또는 다른 장소의 호출 경로에서 제공될 수 있다. SIP는 여러 상이한 수송 프로토콜의 최상부에 있다. SIP는 세션 동안 사용될 미디어들 또는 미디어를 규정하기 위하여 세션 기술 프로토콜(SDP)을 사용한다. SIP 세션은 전형적으로 SIP INVITE 메시지를 어떤 SIP 어드레스에 전송하는 SIP 단말기에 의해 개시된다. 피호출 단말기가 초대를 수용하기를 희망한다고 가정하면, 피호출 단말기는 SIP 200 OK 메시지로 호출 단말기에 응답한다. 호출 단말기는 ACK 메시지를 피호출 단말기에 전송함으로써 200 OK 메시지의 수신에 응답한다. (피호출 단말기(SDP)를 포함한) 200 OK 메시지의 수신 시에, 호출 단말기는 피호출 단말기에 미디어를 전송하는 것을 개시할 수 있다. 피호출 단말기는 호출자의 SDP를 포함하는 INVITE의 수신 시에 미디어를 전송하기 시작할 수 있다. 3G 용어에 따른 사용자 장비(UE) 또는 사용자 에이전트 클라이언트(UAC)로서 칭해질 수 있는 호출 SIP 단말기가 호출을 개시할 때, AS는 SIP 제어 네트워크(이 네트워크는 3GPP에 의해 규정된 바와 같은 IP 멀티미디어 서브시스템일 수 있다) 내에서 INVITE 요청을 수신한다. 상기 요청을 이의 목적지에 전달하기 전(nb, AS는 서비스 시나리오에 따라 요청을 전달하지 않도록 선택할 수 있다), AS는 UAC에 어나운스먼트(announcement)를 플레이하기를 원할 수 있다. 이것을 행하기 위하여, SDP의 교환과 관련된 AS 및 UAC 사이의 초기 다이얼로그를 설정하는 것이 바람직하고, 어떤 사전조건의 만족도, 및 미디어 채널이 설정된다. AS는 18x 메시지(여기서, "x"는 임의의 적절한 값을 갖는다)에서 초기 미디어를 제공하기 위하여 자신의 의도를 시그널링하고, 18x는 적절한 SDP를 포함한다. AS가 다수의 18x 메시지를 전송할 수 있고, 이들 각각이 AS가 200 응답 메시지를 UAC로 전달하기 이전에, PRACK 메시지로 UAC에 의해 확인될 수 있다는 점에 주의하라. 어나운스먼트가 플레이될 때, AS는 세션 설정을 지속하기 위하여 INVITE 요청을 피호출 UE 또는 사용자 에이전트 서버(UAS)에 전달할 수 있다. 그 후, UAS는 또한 UAC와의 다이얼로그를 설정할 수 있다. 이 절차와 관련된 시그널링이 도1에 도시되어 있다. AS는 여전히 초기 미디어를 플레이하면서, 또는 (서비스에 따라) 미디어를 플레이하기 시작하기 전에, INVITE 요청을 전달할 것을 선택할 수 있다. AS는 응답(임시 또는 최종)이 피호출자로부터 수신될 때, 또는 미디어가 피호출자로부터 수신된다는 것을 검출할 때, 초기 미디어를 중지하는 것을 선택할 수 있다. 특정 서비스 구현 사양은 초기 미디어가 중단될 때를 규정하고, 필요하다면, 어느 부가적인 메커니즘이 미디어를 검출하는데 사용되어야 하는지를 규정할 것이다. 초기 미디어를 핸들링하는 이 방법에 따르면, AS로부터의 18x 임시 응답, 및 UAS로부터의 최종 응답(200(INVITE))이 세션 내에서 동일한 다이얼로그의 부분으로서 UAC에 의해 수신된다. AS는 18x 임시 응답에서 AS에 의해 전송된 태그를 정합시키기 위하여 UAS로부터의 응답 메시지에 수신된 To header 파라미터를 변경해야 한다. 또한, (SIP 메시지 내로 통합된) 요청이 AS로부터 UAC로부터 전송될 수 있기 때문에, AS는 UAC로 전달된 요청의 값이 아마도 AS로부터 UAC로 전송된 요청의 값보다 더 크다는 것을 보장하기 위하여 피호출 UE로부터 수신된 요청의 Cseq 값을 변경해야만 할 수 있다. AS는 또한 루트 세트 등(즉, SIP 메시지에 포함된 파라미터 세트)와 관련된 문제를 핸들링해야 할 것이다. 이러한 문제는 B2BUA(Back-to-Back User Agent)로서 동작하는 AS에 의해 해결될 수 있다. 처리되어야 하는 부가적인 문제는 UAC에 2개의 원격 SDP 응답: (AS에 의해 개시된) 초기 미디어에 대한 SDP, 및 UAS로부터의 SDP를 제공하는 것이 필요하다. SDP 응답은 동일한 INVITE 트랜잭션 내에서 (즉, 18x 메시지 내의 초기 미디어 SDP, 및 200 내의 UAS SDP를 전송함으로써) 변경되지 않을 수 있다. 이 문제점에 대한 2개의 상이한 해결책이 존재한다. 1. 200 OK가 전송된 후, UAS SDP를 제공하기 위하여 AS에 의해 UAC에 SIP UPDATE가 전송된다. UAS가 이전에 AS에 의해 UAC에 전송된 SDP에 대한 정보를 가지지 않기 때문에, AS는 이 UPDATE를 전송해야 한다. UPDATE(200) 응답은 UAC의 부분에 대한 변경된 SDP를 포함할 수 있다. 그러나, 그러한 경우에, UPDATE 트랜잭션을 개시한 것이 AS이기 때문에, UPDATE(200) 응답은 UAS에 직접 전달되지 않을 수 있다. 이 때문에, AS는 또한 UAS를 향해 별도의 UPDATE를 전송해야 할 것이다. UAS로부터 AS로 전송된 상기 UPDATE에 대한 200 응답은 또한 UAS에 대한 SDP의 변화를 포함할 수 있다. 다시 한번, 200 응답은 UAC에 직접 전달되지 않을 수 있고, UAC로의 또 다른 UPDATE가 필요로 된다. 이 절차의 최초 단계가 도2에 도시되어 있다. AS의 다중 중재 그 자체와 관련된 이 절차의 복잡도는 바람직하지 않다. 2. 제2 해결책은 "초기 미디어" 메커니즘에 의존한다. SIP 권장사항에 규정된 바와 같이, "초기 미디어"는 특정 세션이 피호출 사용자에 의해 수용되기 전에 교환되는 미디어(예를 들어, 오디오 및 비디오)와 관련된다. 다이얼로그 내에서, 초기 미디어는 UAS가 최종 응답을 발생시킬 때까지 최초 INVITE가 전송되는 순간으로부터 발생될 수 있다. 초기 미디어는 단방향성 또는 양방향성일 수 있고, 호출자, 피호출자, 또는 이들 둘 모두에 의해 발생될 수 있다. 피호출자에 의해 발생된 초기 미디어의 전형적인 예는 호출음 또는 어나운스먼트(예를 들어, 큐잉 상태)이다. 호출자에 의해 발생된 초기 미디어는 전형적으로 대화식 음성 응답(IVR) 시스템을 도출하기 위하여 음성 명령 또는 이중 톤 다중-주파수(DTMF) 톤으로 이루어진다. 기본적인 SIP 사양 RFC3261은 매우 간단한 초기 미디어 메커니즘만을 지원한다. RFC3959는 원래 제안을 확장하고, 그 제안이 구현될 때 발생할 수 있는 다수의 문제점을 극복한다. 용도는 AS가 초기 미디어로서 어나운스먼트를 플레이하도록 하기 위하여 IETF RFC3959에서 설명된 초기 세션 디스포지션(disposition)으로 이루어질 수 있다. 이 경우에, 2개의 별도의 SDP, 초기 다이얼로그를 위한 하나 및 UAS와의 다이얼로그를 위한 하나가 사용되며, 이 경우에, AS는 UAC에 초기 미디어를 제공하고, 상기 UAC는 수용 또는 거절을 선택할 수 있다. AS로부터 UAC에 전송된 초기 18x 메시지는 초기 다이얼로그용 SDP를 포함하는 반면, UAS로부터의 200 응답은 UAC 대 UAS 다이얼로그용 SDP를 포함한다. 초기 다이얼로그는 200 응답의 수신 시에 UAC에 의해 자동적으로 종료된다. 이 절차는 도3에 도시되어 있다. 네트워크 내의 다른 노드가 또한 초기 미디어를 전송하기를 원하는 이벤트에서 이 방법에 의한 문제점이 발생할 수 있다. 어느 경우든, 상기 방법은 사용자 단말기에서 RFC3959에 대한 지원을 필요로 한다는 단점을 갖는다.