Sip.js: رأس المسار مفقود في ACK بعد إعادة الدعوة.

تم إنشاؤها على ١٧ يناير ٢٠١٨ · 7تعليقات · مصدر: onsip/SIP.js

نحن نحاول تحديث مكتبة SIP.js الخاصة بنا من 0.7.5 إلى 0.9.1.

لدينا مشكلة عندما نجعل Reinvite لإضافة فيديو في المكالمة. المشكلة هي أن خادم Kamailio الخاص بنا لا يرسل عنوان Record-Route في مكالمة reINVITE. وفقًا لـ SIP RFC ، فإن سلوك Kamailio هذا طبيعي.

https://tools.ietf.org/html/rfc3261#section -12.1.2

يجب تعيين مجموعة المسار على قائمة URIs في حقل عنوان مسار السجل من الاستجابة ، ويتم أخذها بترتيب عكسي مع الاحتفاظ بجميع معلمات URI. في حالة عدم وجود حقل عنوان مسار السجل في الاستجابة ، يجب تعيين تعيين المسار على المجموعة الفارغة. تلغي مجموعة المسار هذه ، حتى لو كانت فارغة ، أي مسار موجود مسبقًا تم تعيينه للطلبات المستقبلية في مربع الحوار هذا. يجب تعيين الهدف البعيد إلى URI من حقل رأس جهة الاتصال للاستجابة

https://tools.ietf.org/html/rfc3261#section -12.2

قد تحتوي الطلبات الموجودة في مربع حوار على حقلي مسار السجل ورأس جهة الاتصال. ومع ذلك ، لا تتسبب هذه الطلبات في تعديل تعيين مسار مربع الحوار ، على الرغم من أنها قد تقوم بتعديل URI الهدف البعيد.

كما يمكنني أن أرى في الإصدار 0.7.5 من sip.js ، تم أخذ رأس المسار دائمًا من الطلب (this.request) ولكن في الإصدار 0.9.1 من sip.js ، فإنه يأخذ من الرد الأخير (this.response) والذي لا يوجد في حالتنا ' ر لديها عنوان مسار التسجيل.

هنا هو الفرق بين الإصدارات:
0.7.5) https://www.dropbox.com/s/jo055zsn9286q17/Screenshot٪202018-01-17٪2013.40.41.png؟dl=0
0.9.1) https://www.dropbox.com/s/u41kh91h3kzvt27/Screenshot٪202018-01-17٪2013.42.13.png؟dl=0

لذلك ما فعلته هو تغيير رمز 0.9.1 الخاص بك قليلاً. إذا كانت الاستجابة تحتوي على رأس (رؤوس) مسار السجل ، فسنضيفها إلى ACK ، أليس كذلك سنحاول أخذها من الطلب الذي كان لدينا من قبل. إذا لم يكن لدينا طريق ، فسنتركه فارغًا.

https://www.dropbox.com/s/1rrhyfnxe9sa88a/Screenshot٪202018-01-17٪2013.50.11.png؟dl=0

أريد فقط أن أعرف لماذا غيرت السلوك. هل هناك خطأي أو خطأك؟

bug

مصدر

DenisButCheR

التعليق الأكثر فائدة

مرحبًا دينيس ، لقد نظرت في هذا وتحدثت مع جيمس حوله.

هذا خطأ ، ولكن يبدو أن السلوك الأصلي لم يكن صحيحًا أيضًا لأنه سمح بتحديث مجموعة المسار داخل مربع حوار.

يجب أن يكون سلوك UAS عند الاستجابة لطلب تكوين الحوار ، الموضح في https://tools.ietf.org/html/rfc3261#section -12.1.1 ، هو نسخ رؤوس مسار التسجيل وعكسها وحفظها في مربع حوار متغير النطاق كمجموعة الطريق.

عند الاستجابة للطلبات داخل مربع حوار ، يجب أن يكون سلوك UAS ، كما هو موضح في https://tools.ietf.org/html/rfc3261#section -12.2 ، لإعادة استخدام مجموعة المسار الحالية المحددة في مربع الحوار.

السلوك الحالي للاعتماد على وجود رؤوس مسار السجل في الطلبات داخل مربع حوار لإعادة إنشاء مجموعة المسار غير صحيح.

سنصلح هذا في الإصدار التالي ، ولكن في الوقت الحالي يمكنك حل المشكلة عن طريق استدعاء record_route () لجميع الطلبات ، الأولية والمتسلسلة ، بحيث تكون رؤوس مسار التسجيل في الطلبات المتسلسلة مثل https: //tools.ietf. يقول org / html / rfc3261 # section -12.2 أنه اختياري.

etamme في ٢٣ يناير ٢٠١٨

👍2

ال 7 كومينتر

القسم الذي تبحث عنه هو في الواقع القسم 14:

https://tools.ietf.org/html/rfc3261#section -14

يرجى التحقق من وظائف الكود الخاص بك مقابل هذا القسم ، حيث لا ينطبق القسم 12 في هذه الحالة. بشكل عام ، لم يكن دعم إعادة الدعوة مستقرًا بدرجة كافية في 0.7.x حتى يتم اعتباره مدعومًا ، ولكن تم تجسيد الدعم للمواصفات في 0.8.x.

james-criscuolo في ١٧ يناير ٢٠١٨

لقد راجعت بدقة القسم 14 ، ولم يذكر شيئًا عن الاستخدام / تعديل "مجموعة التوجيه"

ولكن بالعودة إلى القسم 12 - "مجموعة المسار" - يجب تشكيلها أثناء معالجة INVITE الأولية ، وإعادة استخدامها بدون تعديل أثناء معالجة الرسائل داخل الحوار.
الاستشهاد بأجزاء مناسبة من RFC مذكور أعلاه.

في الوقت الحالي ، السؤال هو لماذا تم تعديل "مجموعة المسار" في مربع الحوار (الإصدار 0.9.1 sip.js يأخذ من الاستجابة الأخيرة this.response) - لأن هذا غير متوافق مع RFC.

DenisButCheR في ٢٢ يناير ٢٠١٨

مرحبًا دينيس ، لقد نظرت في هذا وتحدثت مع جيمس حوله.

هذا خطأ ، ولكن يبدو أن السلوك الأصلي لم يكن صحيحًا أيضًا لأنه سمح بتحديث مجموعة المسار داخل مربع حوار.

etamme في ٢٣ يناير ٢٠١٨

👍2

أواجه نفس المشكلة ، لماذا تم إغلاق هذه المشكلة بينما لم يتم إصلاح المشكلة بالفعل؟
تمكنت من الحصول على الرؤوس من خلال إيجاد مربع الحوار ونسخها من هناك.

diff --git a/src/SIPMessage.ts b/src/SIPMessage.ts
index a95e8ee..3226160 100644
--- a/src/SIPMessage.ts
+++ b/src/SIPMessage.ts
@@ -755,6 +755,9 @@ export class IncomingResponse extends IncomingMessage implements IncomingRespons
     if (!contact || !contact.uri) {
       throw new Error("Failed to parse contact header.");
     }
+
+    const dialog = this.ua.dialogs[this.callId + this.fromTag + this.toTag];
+
     const ruri = contact.uri;
     const request = new OutgoingRequest(
       C.ACK,
@@ -767,7 +770,7 @@ export class IncomingResponse extends IncomingMessage implements IncomingRespons
         fromTag: this.fromTag,
         toUri: this.to.uri,
         toTag: this.toTag,
-        routeSet: this.getHeaders("record-route").reverse()
+        routeSet: (dialog ? dialog.routeSet : this.getHeaders("record-route").reverse())
       },
       options ? options.extraHeaders : undefined,
       options ? options.body : undefined

0 نقطة للأسلوب الذي أعتقده ، لكنني أعتقد أن الحل سيكون مشابهًا لهذا.