يوفّر هذا الدليل تعليمات حول كيفية حلّ أخطاء Google Meet Media API الشائعة.
تحديد مشاكل رموز الخطأ وحلّها
في ما يلي نصائح لتحديد وحلّ المشاكل المتعلّقة برموز الأخطاء التي تعرضها نقطة نهاية
connectActiveConference
:
رموز الخطأ | |
---|---|
NO_ACTIVE_CONFERENCE |
تأكَّد من أنّ عميل Meet Media API لا يحاول الاتصال إلا بعد أن يكون المستخدم الذي تمّت مصادقته متواجدًا في مؤتمر على مساحة الاجتماع. |
INVALID_OFFER |
اطّلِع على متطلبات العرض للتحقّق من عدم توفّر أي تفاصيل ناقصة، مثل فتح القنوات المطلوبة لعرض البيانات. يمكنك أيضًا مقارنة سلسلة عرض تطبيقك بسلسلة نموذج العرض والبحث عن أي اختلافات. |
INCOMPATIBLE_DEVICE |
جهاز واحد أو أكثر في المؤتمر غير متوافق مع عملاء Meet Media API. لن يتمكّن تطبيقك من الانضمام، لذلك يمكنك إبلاغ المستخدمين النهائيين بذلك. |
CONNECTIONS_EXHAUSTED |
يمكن لعميل واحد فقط من Meet Media API الاتصال بمكالمة فيديو في كل مرة. إذا تعطّل تطبيقك، قد يظهر لك هذا الخطأ إذا حاول إعادة الاتصال. في هذه الحالة، انتظِر لمدة 30 ثانية تقريبًا حتى تنتهي مهلة الاتصال السابق في Meet. ثم أعد المحاولة مرة أخرى. |
خطة موحّدة
إذا لم يتم فتح قنوات البيانات مطلقًا ولم يتم تلقّي صوت أو فيديو مطلقًا، تأكَّد من استخدام الخطة الموحّدة فقط عند ضبط اتصال الأجهزة المشابهة على الجهاز.
خطأ في ترتيب أوصاف الوسائط
عند إنشاء اتصال بين الأجهزة من خلال عرض بروتوكول وصف الجلسة (SDP)، قد يظهر لك الخطأ التالي:
Failed to execute 'setRemoteDescription' on 'RTCPeerConnection':
Failed to set remote answer sdp:
The order of m-lines in answer doesn't match order in offer. Rejecting answer.
يعني ذلك أنّ أسطر وصف الوسائط في ردّ SDP لا تتطابق مع وصف الوسائط في عرض SDP:
عرض SDP | إجابة SDP |
---|---|
✅ m=audio 9 UDP/TLS/RTP/SAVPF 111 |
✅ m=audio 9 UDP/TLS/RTP/SAVPF 111 |
❌ m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 |
❌ m=audio 9 UDP/TLS/RTP/SAVPF 111 |
✅ m=audio 9 UDP/TLS/RTP/SAVPF 111 |
✅ m=audio 9 UDP/TLS/RTP/SAVPF 111 |
❌ m=audio 9 UDP/TLS/RTP/SAVPF 111 |
❌ m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 |
لإصلاح هذا الخطأ، تأكَّد من ضبط أنواع الوسائط المتشابهة بشكل صحيح و تجميعها معًا عند ضبط عنصر اتصال نظير. لا تتوفّر أوصاف الوسائط المُدمجة.
يوضّح نموذج الرمز البرمجي التالي كيفية مطابقة أوصاف الوسائط بشكل صحيح:
C++
rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
// Signal the entire video at once.
for (uint32_t i = 0; i < configurations.receiving_video_stream_count; ++i) {
webrtc::RtpTransceiverInit video_init;
video_init.direction = webrtc::RtpTransceiverDirection::kRecvOnly;
video_init.stream_ids = {absl::StrCat("video_stream_", i)};
webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::RtpTransceiverInterface>>
video_result = peer_connection->AddTransceiver(
cricket::MediaType::MEDIA_TYPE_VIDEO, video_init);
// . . .
}
JavaScript
pc = new RTCPeerConnection();
// Signal the entire video at once.
pc.addTransceiver(video, {'direction':'recvonly'});
pc.addTransceiver(video, {'direction':'recvonly'});
pc.addTransceiver(video, {'direction':'recvonly'});
خطأ في سمة دور بروتوكول أمان طبقة النقل لمخطّطات البيانات (DTLS)
عند ضبط سمة دور DTLS، قد يظهر لك الخطأ التالي:
All DTLS roles must be one of [ACTIVE, ACTPASS].
يحدث هذا الخطأ عندما لا يتم ضبط سمة a=setup:< >
بشكل صحيح لجميع
أوصاف الوسائط في عرض وصف الجلسة (SDP).
لحلّ هذا الخطأ، تأكَّد من أنّ كل وصف وسائط في عرض وصف الجلسة (SDP) يتضمّن إحدى السمات المطلوبة التالية:
a=setup:actpass
a=setup:active
v=0
o=- 4743178474630771513 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101
. . .
a=setup:actpass
. . .
m=audio 39807 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=setup:actpass
. . .
تحديد المشاكل المتعلقة بالصوت وحلّها
يمكن أن تساعدك الأقسام التالية في حلّ مشاكل الصوت في تطبيقك.
التحقّق من السجلات
إذا كنت تستخدم برنامج "عميل الويب" في متصفّح Chrome:
- افتح علامة تبويب جديدة وأدخِل في شريط العناوين:
chrome://webrtc-internals
. - انتقِل إلى القسم الذي يحمل الرمز
Stats graph for inbound-rtp
. - راجِع كل رسم بياني صوتي لمعرفة ما إذا كان يتم استلام الحِزم.
إذا كنت تستخدم العميل المرجعي لـ C++، تحقَّق مما إذا كان قد تم استدعاء
OnAudioFrame
.
التحقّق من نطاقات OAuth
لا يتم نقل الصوت إلا إذا تم تقديم النطاق المناسب مع طلب الربط الأولي. لحلّ الخطأ، تأكَّد من تقديم نطاقات OAuth 2.0 الصحيحة. لمزيد من المعلومات، يُرجى الاطّلاع على نطاقات Meet Media API.
التأكّد من إعداد المؤتمر بشكلٍ صحيح
عندما يتصل العميل بخوادم Google Meet، لا يتم قبوله تلقائيًا في المؤتمر. تأكَّد من أنّك تلقّيت تحديثًا لمورد التحكّم في الجلسة عبر قناة بيانات التحكّم في الجلسة مع حالة
STATE_JOINED
.{"sessionStatus":{"connectionState":"STATE_JOINED"}}
تأكَّد من أنّه هناك مشاركون آخرون في المؤتمر لم يتم كتم صوتهم.
التحقّق من إشارة الصوت
لا يوفّر Meet محتوى صوتيًا إلا إذا أشرت إلى ذلك في SDP offer. يجب توفّر ثلاثة أوصاف لملفّات وسائط صوتية مخصّصة للاستقبال فقط في المحتوى المعروض.
m=audio 39807 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:0
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:1
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
. . .
a=mid:2
. . .
a=recvonly
. . .
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
. . .
إذا تلقّت خوادم Meet عرضًا صالحًا، ستردّ بإجابة SDP تتضمّن ثلاثة أوصاف لوسائط صوتية مخصّصة للإرسال فقط.
m=audio 19306 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:0
. . .
a=sendonly
a=msid:virtual-6666 virtual-6666
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:1
. . .
a=sendonly
a=msid:virtual-6667 virtual-6667
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .
m=audio 9 UDP/TLS/RTP/SAVPF 111
. . .
a=mid:2
. . .
a=sendonly
a=msid:virtual-6668 virtual-6668
. . .
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
. . .
التحقّق من عملية تنفيذ المراقب
احرص على إنشاء نُسخ من بيانات الصوت في حال نقلت معالجة البيانات إلى سلسلت رسائل مختلفة.
إنّ AudioFrame.pcm16
هو في الواقع إشارة إلى البيانات الأساسية، لذا فإنّ محاولة الوصول إليه بعد
OnAudioFrame
يؤدي إلى سلوك غير محدّد، مثل خطأ في التقسيم.
تحديد المشاكل المتعلّقة بالفيديوهات وحلّها
يمكن أن تساعدك الأقسام التالية في حلّ مشاكل الفيديو في تطبيقك.
التحقّق من السجلات
إذا كنت تستخدم برنامج "عميل الويب" في متصفّح Chrome:
- افتح علامة تبويب جديدة وأدخِل في شريط العناوين:
chrome://webrtc-internals
. - انتقِل إلى القسم الذي يحمل الرمز
Stats graph for inbound-rtp
. - راجِع كل رسم بياني للفيديو لمعرفة ما إذا كان يتم استلام الحِزم.
إذا كنت تستخدم العميل المرجعي لـ C++، تحقَّق مما إذا كان قد تم استدعاء
OnVideoFrame
.
التحقّق من نطاقات OAuth
لا يتم نقل الفيديو إلا إذا تم تقديم النطاق المناسب مع طلب الربط الأولي. لحلّ الخطأ، تأكَّد من تقديم نطاقات OAuth 2.0 الصحيحة. لمزيد من المعلومات، يُرجى الاطّلاع على نطاقات Meet Media API.
التأكّد من إعداد المؤتمر بشكلٍ صحيح
عندما يتصل العميل بخوادم Meet، لا يتم السماح له تلقائيًا بالانضمام إلى المؤتمر. تأكَّد من أنّك تلقّيت تحديثًا لمورد التحكّم في الجلسة عبر قناة بيانات التحكّم في الجلسة مع حالة
STATE_JOINED
.{"sessionStatus":{"connectionState":"STATE_JOINED"}}
تأكَّد من أنّه هناك مشاركون آخرون في المؤتمر لم يتم كتم صوت بث الفيديو الخاص بهم.
إثبات صحة إشارة الفيديو
لا يوفّر Meet الفيديو إلا إذا تم الإشارة إليه في SDP offer. يجب أن يتضمّن العرض ما يصل إلى ثلاثة أوصاف لملفّات وسائط الفيديو المخصّصة للاستقبال فقط.
v=0
o=- 4743178474630771513 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 35 36 37 38 102 103 104 105 106 107 108 109 127 125 39 40 41 42 43 44 45 46 47 48 112 113 114 115 116 117 118 49
. . .
a=setup:actpass
a=mid:1
. . .
a=recvonly
. . .
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
. . .
إذا تلقّى Meet عرضًا صالحًا، سيردّ عليه بإجابة SDP
تتضمّن n
وصفًا لوسائط الفيديو المخصّصة للإرسال فقط، حيث يشير n
إلى عدد أوصاف وسائط
الفيديو في عرض SDP.
v=0
o=- 0 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS virtual-video-7777/7777
a=ice-lite
. . .
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99
. . .
a=setup:passive
a=mid:1
. . .
a=msid:virtual-video-7777/7777 virtual-video-7777/7777
a=rtcp-mux
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
. . .
تحديد المشاكل وحلّها في حال عدم ظهور الفيديو
- تأكَّد من توفُّر
m=video …
في عرض SDP المُرسَل إلى خوادم Meet. - تأكَّد من أنّ
a=recvonly
هي سمة ضمن كل سطرm=video
. - تأكَّد من توفُّر عدد متساوٍ من أسطر
m=video
في إجابة SDP. - تأكَّد من أنّ
a=sendonly
أوa=sendrecv
هما سمتان ضمن كل سطرm=video
في إجابة SDP. - تأكَّد من أنّه تم إرسال
VideoAssignmentRequest
بنجاح إلى خوادم Meet واستلامها. يجب إبلاغ العميل بالنجاح أو الإخفاق من خلال قناة البيانات نفسها.
تحديد وحلّ المشاكل المتعلّقة بانخفاض عدد عمليات بث الفيديوهات عن المتوقع
- تأكَّد من أنّ عرض SDP يحتوي على العدد الصحيح من أسطر
m=video …
. - تأكَّد من أنّ جميع أوصاف
m=video
في إجابة وصف بروتوكول وصف الجلسة (SDP) تحتوي على سمةa=sendonly
أوa=sendrecv
. إنّ أيّ أسطر تم وضع علامةa=recvonly
عليها في الإجابة تقلّل من عدد مصادر البث المُرسَلة إلى العميل بمقدار هذا القدر.
التحقّق من عملية تنفيذ المراقب
احرص على إنشاء نُسخ من بيانات الفيديو إذا نقلت معالجة البيانات إلى سلسلت رسائل مختلفة.
إنّ VideoFrame.frame
هي في الواقع إشارة إلى البيانات الأساسية، لذا فإنّ محاولة الوصول إليها بعد
OnVideoFrame
سيؤدي إلى سلوك غير محدّد، مثل خطأ في التقسيم.