Sip.js: पुन: आमंत्रित करने के बाद एसीके पर गुम रूट हेडर।

को निर्मित 17 जन॰ 2018 · 7टिप्पणियाँ · स्रोत: onsip/SIP.js

हम अपनी SIP.js लाइब्रेरी को 0.7.5 से 0.9.1 तक अपडेट करने का प्रयास कर रहे हैं।

जब हम कॉल में वीडियो जोड़ने के लिए पुन: आमंत्रित करते हैं तो हमें समस्या होती है। समस्या यह है कि हमारा Kamailio सर्वर रीइनवाइट कॉल में रिकॉर्ड-रूट हेडर नहीं भेजता है। SIP RFC के अनुसार यह कामेलियो व्यवहार सामान्य है।

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

रूट सेट को रिकॉर्ड-रूट हेडर फ़ील्ड में यूआरआई की सूची में प्रतिक्रिया से सेट किया जाना चाहिए, रिवर्स ऑर्डर में लिया गया और सभी यूआरआई पैरामीटर को संरक्षित किया जाना चाहिए। यदि प्रतिक्रिया में कोई रिकॉर्ड-रूट हेडर फ़ील्ड मौजूद नहीं है, तो रूट सेट को खाली सेट पर सेट किया जाना चाहिए। यह रूट सेट, भले ही खाली हो, इस डायलॉग में भविष्य के अनुरोधों के लिए पहले से मौजूद रूट सेट को ओवरराइड करता है। प्रतिक्रिया के संपर्क शीर्षलेख क्षेत्र से दूरस्थ लक्ष्य को यूआरआई पर सेट किया जाना चाहिए

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

एक संवाद में अनुरोधों में रिकॉर्ड-रूट और संपर्क शीर्षलेख फ़ील्ड शामिल हो सकते हैं। हालांकि, इन अनुरोधों के कारण डायलॉग का रूट सेट संशोधित नहीं होता, हालांकि वे दूरस्थ लक्ष्य URI को संशोधित कर सकते हैं।

जैसा कि मैं सिप.जेएस संस्करण 0.7.5 में देख सकता हूं, रूट हेडर हमेशा अनुरोध (यह अनुरोध) से लिया गया था, लेकिन एसआईपी.जेएस संस्करण 0.9.1 में यह अंतिम प्रतिक्रिया (इस.प्रतिक्रिया) से लिया गया था जो हमारे मामले में ' t में रिकॉर्ड-रूट हैडर है।

यहाँ संस्करणों के बीच अंतर है:
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 कोड को थोड़ा बदल दिया। अगर प्रतिक्रिया में रिकॉर्ड-रूट हेडर हैं तो हम उन्हें एसीके में जोड़ देंगे, क्या हम इसे पहले से किए गए अनुरोध से लेने की कोशिश नहीं करेंगे। अगर हमारे पास कोई रूट नहीं होता तो हम इसे खाली छोड़ देते।

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

मैं सिर्फ यह जानना चाहता हूं कि आपने व्यवहार क्यों बदला। गलती मेरी है या तुम्हारी?

bug

स्रोत

DenisButCheR

सबसे उपयोगी टिप्पणी

हे डेनिस, मैंने इस पर गौर किया और इसके बारे में जेम्स से बात की।

यह एक बग है, लेकिन ऐसा प्रतीत होता है कि मूल व्यवहार भी सही नहीं था क्योंकि इसने मार्ग को एक संवाद के भीतर अद्यतन करने की अनुमति दी थी।

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 के रूप में होंगे

etamme 23 जन॰ 2018

👍2

सभी 7 टिप्पणियाँ

आप जिस अनुभाग की तलाश कर रहे हैं वह वास्तव में खंड 14 है:

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

कृपया उस अनुभाग के विरुद्ध अपने कोड की कार्यक्षमता की जांच करें, क्योंकि इस मामले में धारा 12 लागू नहीं होती है। सामान्यतया, पुन: आमंत्रित समर्थन 0.7.x में पर्याप्त रूप से स्थिर नहीं था, यहां तक कि समर्थित भी माना जा सकता है, लेकिन समर्थन को 0.8.x में निर्दिष्ट करने के लिए फ़्लेश किया गया था।

james-criscuolo 17 जन॰ 2018

मैंने धारा 14 को अच्छी तरह से जांच लिया है, और यह "रूटिंग सेट" के उपयोग/संशोधन के बारे में कुछ नहीं कहता है

लेकिन धारा 12 पर वापस आना - "रूट सेट" - प्रारंभिक आमंत्रण प्रसंस्करण के दौरान बनाया जाना है, और इन-डायलॉग संदेशों के प्रसंस्करण के दौरान संशोधन के बिना पुन: उपयोग किया जाता है।
RFC के उपयुक्त भागों का उल्लेख ऊपर दिया गया है।

अभी के लिए सवाल यह है कि क्यों "रूट सेट" को संवाद में संशोधित किया गया है (sip.js संस्करण 0.9.1 यह अंतिम प्रतिक्रिया this.response से लेता है) - क्योंकि यह गैर RFC अनुरूप है।

DenisButCheR 22 जन॰ 2018

हे डेनिस, मैंने इस पर गौर किया और इसके बारे में जेम्स से बात की।

etamme 23 जन॰ 2018

👍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 अंक, लेकिन मुझे लगता है कि समाधान इसी के समान होगा।

hafkensite 27 मार्च 2019

ऐसा लगता है कि मूल रिपोर्टर ने इस मुद्दे को बंद कर दिया। मैंने इसे फिर से खोल दिया है और हम सक्रिय रूप से इस कोड को देख रहे हैं।

egreenmachine 27 मार्च 2019

धन्यवाद @egreenmachine। यह होल्ड/अनहोल्ड (पुन: आमंत्रित) को भी प्रभावित करता है।

amessina 27 मार्च 2019

हमारे पास मामला यह था कि BYE पैकेट के पास फिर से आमंत्रित करने के बाद सही मार्ग नहीं थे।

hafkensite 27 मार्च 2019

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Sip.js: पुन: आमंत्रित करने के बाद एसीके पर गुम रूट हेडर।

सबसे उपयोगी टिप्पणी

सभी 7 टिप्पणियाँ

संबंधित मुद्दों