네트워크 품질을 더 잘 인식할 수 있도록 사용자가 통화 전에 속도 측정을 수행하고 통화 중 네트워크 품질과 연결 상태를 모니터링하며, 해당 UI 인터페이스 상호작용과 알림을 제공할 것을 권장합니다. 이렇게 하면 사용자가 현재 네트워크 품질을 알고 네트워크 설정을 적시에 조정하여 최적의 통화 효과를 달성할 수 있습니다.
통화 전 네트워크 속도을 측정하세요
일반 사용자는 네트워크 상황을 인지하기 어렵기 때문에, 현재 네트워크 품질을 평가하고 통화의 최적 효과를 위해 네트워크를 적시에 조정할 수 있도록 통화 전 속도 측정을 수행할 것을 권장합니다.
속도 측정의 원리는 SDK가 서버 노드에 일부 탐색 패킷을 전송한 후 회신 패킷의 품질을 통계하고, 측정 결과를 콜백 인터페이스를 통해 통보해줍니다.아래 그림과 같습니다.
통화 전 속도 측정의 장점
속도 측정 결과는 SDK의 서버 선택 전략을 최적화하는 데 사용되므로, 최적의 서버를 선택할 수 있도록 사용자의 첫 통화 전에 한 번 속도 측정을 수행할 것을 권장합니다.
테스트 결과가 매우 좋지 않다면, 사용자에게 더 나은 네트워크 환경을 선택하도록 눈에 띄는 UI로 안내할 수 있습니다.
startSpeedTest 속도 측정
Android
iOS
Windows
//네트워크 속도 측정을 시작하는 예제 코드, sdkAppId와 UserSig가 필요합니다. (받은 방법은 기본 기능 참조하세요)
평가 알고리즘으로 측정된 네트워크 품질은 loss가 낮을수록, rtt가 작을수록 점수가 높아집니다.
upLostRate
업로드 패킷의 손실률
범위는 [0 - 1.0]이며, 예를 들어 0.3은 서버에 10개의 데이터 패킷을 전송할 때 3개가 중간에 손실될 수 있음을 나타냅니다.
downLostRate
다운로드 패킷의 손실률
범위는 [0 - 1.0]이며, 예를 들어 0.2는 서버에서 10개의 데이터 패킷을 수신할 때 2개가 중간에 손실될 수 있음을 나타냅니다.
rtt
네트워크 지연
SDK와 서버 간의 왕복에 소요되는 시간을 나타내며, 이 값은 작을수록 좋으며 일반적인 수치는 10ms - 100ms 에 있습니다.
availableUpBandwidth
업로드 대역폭
예상 업로드 대역폭의 단위는 kbps이며 -1은 유효하지 않은 값을 의미합니다
availableDownBandwidth
다운로드 대역폭
예상 다운로드 대역폭의 단위는 kbps이고 -1은 유효하지 않은 값을 의미합니다
도구 속도의 측정
인터페이스 호출 방식으로 네트워크 속도 측정을 원하지 않는 경우, Real-Time Communication Engine (RTC Engine)은 데스크톱용 네트워크 속도 측정 도구 프로그램을 제공하여 상세한 네트워크 품질 정보를 신속하게 확인할 수 있도록 해줍니다. 사용자는 자신의 플랫폼에 따라 다음 프로그램을 선택하여 다운로드할 수 있습니다. 이 프로그램은 빠른 테스트와 지속적인 테스트 두 가지 옵션을 제공합니다:
MTR은 네트워크 테스트 도구이고 클라이언트에서 RTC Engine 노드까지의 패킷 손실률과 지연 시간을 탐지할 수 있으며, 라우팅의 각 홉에 대한 구체적인 정보를 확인할 수 있습니다.
UDP Loss
클라이언트에서 RTC Engine 노드까지의 UDP 패킷 손실률
UDP RTT
클라이언트에서 RTC Engine 노드까지의 UDP 지연 시간
Local RTT
클라이언트에서 로컬 게이트웨이까지의 지연 시간
Upload
예상 업로드 대역폭
Download
예상 다운로드 대역폭
주의:
영상 통화 중에는 통화 품질에 영향을 줄 수 있으니 테스트하지 마십시오.
속도 측정 자체로 인해 일정량의 데이터가 소모되어 극소량의 추가 요금이 발생할 수 있습니다(기본적으로 무시할 수 있는 수준).
통화 중의 네트워크 모니터링
사용자가 통화 중 발생할 수 있는 네트워크 변동을 더 명확하게 인지할 수 있도록 통화 화면에 해당 UI 알림을 추가하는 것이 좋습니다. 특히 네트워크 상태가 좋지 않을 때 알림을 통해 사용자가 변화를 감지하고 네트워크 상황을 개선하기 위해 적절히 대처할 수 있도록 해야 합니다.
onNetworkQuality 로컬 네트워크 품질의 모니터링
네트워크 품질에 대한 onNetworkQuality 콜백 이벤트는 2초마다 현재 네트워크 품질을 보고하며, 매개변수로 localQuality와 remoteQuality 두 부분을 포함합니다.
localQuality: 현재 네트워크 품질을 나타내며, Excellent, Good, Poor, Bad, VeryBad, Down의 6개 등급으로 구분됩니다.
remoteQuality: 원격 사용자의 네트워크 품질을 나타내며, 이는 배열로 각 요소는 하나의 원격 사용자 네트워크 품질을 나타냅니다.
Quality
명칭
설명
0
Unknown
감지되지 않음
1
Excellent
현재 네트워크 상태가 매우 좋습니다.
2
Good
현재 네트워크 상태가 비교적 좋습니다
3
Poor
현재 네트워크 상태가 보통입니다
4
Bad
현재 네트워크 상태가 좋지 않아서 뚜렷한 끊김 및 통화 지연이 발생할 수 있습니다.
5
VeryBad
현재 네트워크 상태가 매우 나쁩니다. RTC Engine이 간신히 연결을 유지할 수 있지만 통신 품질은 보장할 수 없습니다.
6
Down
현재 네트워크가 RTC Engine의 최소 요구 사항을 충족하지 않아 정상적인 음성 및 영상 통화를 할 수 없습니다.
네트워크 품질(onNetworkQuality)을 모니터링하고 화면에 해당 알림을 표시하면 됩니다.
Android
iOS&Mac
Windows
// onNetworkQuality 콜백을 모니터링하여 현재 네트워크 상태 변화를 감지합니다.
printf("SDK has not yet sensed the current network quality.");
break;
case TRTCQuality_Excellent:
printf("The current network is very good.");
break;
case TRTCQuality_Good:
printf("The current network is good.");
break;
case TRTCQuality_Poor:
printf("The current network quality barely meets the demand.");
break;
case TRTCQuality_Bad:
printf("The current network is poor, and there may be significant freezes and call delays.");
break;
case TRTCQuality_Vbad:
printf("The current network is very poor, the communication quality cannot be guaranteed");
break;
case TRTCQuality_Down:
printf("The current network does not meet the minimum requirements.");
break;
default:
break;
}
// Get the network quality of remote users
for(int i =0; i < remote_quality_count;++i){
printf("remote user : = %s, quality = %d", remote_quality[i].userId, remote_quality[i].quality);
}
}
onStatistics 전체 네트워크 품질의 모니터링
onStatistics 통계 콜백 이벤트는 2초마다 한 번씩 발생하여 SDK 내부의 오디오/ 비디오 및 네트워크 관련 전문 기술 지표를 알립니다. 이 정보는 TRTCStatistics에 모두 나열되어 있습니다.
비디오 통계 정보: 비디오의 해상도(resolution), 프레임 속도(FPS) 및 비트레이트(bitrate) 등의 정보.
오디오 통계 정보: 오디오의 샘플링 레이트(samplerate), 채널(channel) 및 비트레이트(bitrate) 등의 정보.
네트워크 통계 정보: SDK와 클라우드 간의 한번 왕복에(SDK > Cloud > SDK) 네트워크 소요 시간(rtt), 패킷 손실률(loss), 업로드 트래픽(sentBytes) 및 다운로드 트래픽(receivedBytes) 등의 정보.
열거형
설명
appCpu
현재 앱의 CPU 사용률, 단위 (%), Android 8.0 이상에서는 지원되지 않음.
downLoss
클라우드에서 SDK로의 다운링크 패킷 손실률, 단위 (%).
해당 수치가 작을수록 좋으며, downLoss가 0%인 경우 다운링크의 네트워크 품질이 매우 좋음을 의미하며 클라우드에서 수신한 데이터 패킷이 기본적으로 손실되지 않습니다.
downLoss가 30%인 경우 클라우드에서 SDK로 전송되는 오디오 및 비디오 데이터 패킷의 30%가 전송 링크에서 손실됨을 의미합니다.
gatewayRtt
SDK에서 로컬 라우터까지의 왕복 지연 시간이며 단위 ms입니다. 해당 수치는 SDK에서 네트워크 패킷을 로컬 라우터 게이트웨이로 전송한 후, 게이트웨이에서 다시 SDK로 네트워크 패킷을 되돌려 보내는 총 소요 시간을 나타내며, 즉 "SDK > 게이트웨이 > SDK"를 거치는 네트워크 패킷의 총 소요 시간을 의미합니다.
해당 수치가 작을수록 좋습니다.gatewayRtt < 50ms인 경우 낮은 오디오 및 비디오 통화 지연을 의미하며, gatewayRtt > 200ms인 경우 높은 오디오 및 비디오 통화 지연을 의미합니다.
네트워크 유형이 셀룰러 네트워크인 경우 해당 값은 무효입니다.
localArray
로컬 오디오 및 비디오에 대한 통계 정보.
로컬에는 3개의 오디오/비디오 스트림(고화질 메인 화면, 저화질 서브 화면 및 보조 스트림 화면)이 있을 수 있으므로 로컬 오디오/비디오 통계 정보는 한 배열입니다.
receiveBytes
총 수신 바이트 수(시그널링 데이터 및 오디오/비디오 데이터 포함)의 단위는 바이트(Bytes)입니다.
remoteArray
원격 오디오 및 비디오에 대한 통계 정보.
동시에 여러 원격 사용자가 있을 수 있고, 각 원격 사용자도 동시에 여러 오디오/비디오 스트림(예: 고화질 대형 화면, 저화질 소형 화면, 보조 스트림 화면)을 가질 수 있으므로, 원격 오디오 및 비디오에 대한 통계 정보는 한 배열입니다.
rtt
SDK에서 클라우드까지의 왕복에 대한 지연 시간(단위: ms)입니다. 이 수치는 SDK에서 네트워크 패킷을 클라우드로 전송하고, 다시 클라우드에서 SDK로 회신하는 총 소요 시간을 나타내며, 즉 "SDK > 클라우드 > SDK" 경로를 거치는 네트워크 패킷의 총 소요 시간입니다.
해당 수치가 작을수록 좋습니다. rtt < 50ms인 경우 낮은 오디오 및 비디오 통화 지연을 의미하며, rtt > 200ms인 경우 높은 오디오 및 비디오 통화 지연을 의미합니다.
설명:
rtt는 "SDK > 클라우드 > SDK"의 총 소요 시간을 나타내므로 upRtt와 downRtt를 구분할 필요가 없습니다.
sendBytes
총 송신 바이트 수(시그널링 데이터 및 오디오/비디오 데이터 포함)의 단위는 바이트(Bytes)입니다.
systemCpu
현재 시스템의 CPU 사용률,단위 (%), Android 8.0 이상에서는 지원되지 않음.
upLoss
SDK에서 클라우드로까지의 업로드 패킷 손실률, 단위 (%).
해당 수치가 작을수록 좋으며, upLoss가 0%인 경우 업로드의 네트워크 품질이 매우 좋음을 의미하며, 클라우드에 업로드한 데이터 패킷이 기본적으로 손실되지 않습니다.
upLoss가 30%인 경우 SDK에서 클라우드로 전송되는 오디오 및 비디오 데이터 패킷의 30%가 전송 링크에서 손실됨을 의미합니다.
// 재생 지연 네트워크 지터 및 패킷 순서 변동으로 인한 음성 및 영상 끊김을 방지하기 위해 RTC Engine은 재생 측에서 재생 버퍼를 관리합니다. 이 버퍼는 수신된 네트워크 데이터 패킷을 정리하는 데 사용되며, 버퍼 크기는 현재 네트워크 품질에 따라 자동으로 조정됩니다. 이 버퍼 크기를 밀리초 단위 시간으로 환산하고,즉jitterBufferDelay)입니다.
사용자는 통화 중에 네트워크 변화를 인지할 뿐만 아니라 현재 SDK와 백엔드의 연결 상태를 파악해야 합니다. 이를 통해 사용자는 현재 네트워크가 조정되었는지, 정상적으로 통화할 수 있는지를 더 정확하게 판단할 수 있습니다.
콜백 인터페이스
인터페이스에 대한 설명
onConnectionLost
SDK와 클라우드 간의 연결이 끊어졌습니다.
onTryToReconnect
SDK가 클라우드에 재연결을 시도 중입니다.
onConnectionRecovery
SDK와 클라우드와의 연결이 복구되었습니다.
연결 재설정 로직
사용자가 연결이 끊긴 경우, SDK는 자동으로 재연결을 지원합니다(30분 동안 재연결에 성공하지 못하면 자동으로 방을 나가고 -3301 오류 코드를 반환함). 연결 과정에서의 구체적인 연결 상태 및 처리 로직은 아래와 같습니다. 아래 그림은 사용자 Userid1이 채널에 입장한 후 연결이 끊어지고 다시 방에 입장하는 과정에서 수신한 리스너 콜백 이벤트를 보여줍니다.
구체적인 설명:
T1:사용자 측에서 enterRoom 인터페이스를 호출하여 방 입장 요청을 시작합니다.
T2:사용자 Userid1이 onEnterRoom 콜백을 수신하고, Userid2가 Userid1의 존재를 인지하여 약 300ms 후에 Userid2가 onRemoteUserEnterRoom 콜백을 수신합니다.
T3:Userid1 클라이언트가 네트워크 문제로 연결이 끊어지면 SDK가 방에 다시 입장하려고 시도합니다.
T4:Userid1이 8초 연속으로 서버에 연결되지 않으면 Userid1은 onConnectionLost 연결 끊김 콜백을 받습니다.
T5:Userid1이 3초 간격으로 서버에 연결되지 않으면 Userid1은 onTryToReconnect 재시도 콜백을 받습니다.
T6:Userid1이 24초마다onTryToReconnect 재시도 콜백을 받습니다.
T7:Userid2는 Userid1의 연결 끊김 알림을 받고 90초 지난 후에 SDK에서 원격 사용자 Userid1의 연결 끊김을 판단되면 Userid2는 onRemoteUserLeaveRoom 콜백을 받습니다.
T8:Userid1이 연결이 끊긴 동안 언제든지 재연결에 성공되면 Userid1은 onConnectionRecovery 복구 콜백을 받습니다.