@אוריה-דניאלי-0 כתב:

גם אם משעמם לכם, זה לא סיבה להקפיץ דברים לא רלוונטים...

רציתי קצת דסלייק.
זה הכל.
תודה.
תן עוד.

הגדרתי ככה בהגדרה שיחול על כל המערכת:

verify_phone_operator_network=yes 

ומה שקורה הוא, שיש לי מספר טלפון שקניתי מסלקום - ועשיתי שכל מי שמתקשר אליו - יופנה לקו שלי.
אבל בגלל ההגדרה הזו זה לא מופנה. הוא אומר: השלוחה אליה ... אינה מופעלת עקב חוסר בהגדרות...
מה עושים?

@חרב-פיפיות
עיין כאן
https://f2.freeivr.co.il/topic/8122/הרשאות-כניסה-לשלוחה/12

העתקתי לך הפוסט כאן מיד

ב"ה,

ניתן להגדיר פילטר בכניסה לשלוחה לפי מקור רשת השיחה באם הוא תואם לזיהוי המתקשר - לטובת מניעת זיופי שיחות.

להלן פירוט ההגדרות:

הפעלת אימות מקור השיחה:

verify_phone_operator_network=yes

ברירת מחדל - רק אם בוצע אימות וודאי הלקוח ממשיך לשלוחה.
באם לא בוצע אימות, או שיש הפניית שיחות, או שאין בכלל מידע האם המקור מאומת או לא - יוצא מהשלוחה שלב אחד אחורה, או כפי המוגדר ב:

verify_phone_operator_network_mismatch_goto=/1/66

או ניתוק:

verify_phone_operator_network_mismatch_goto=hangup

היציאה מהשלוחה/ניתוק הינם ללא השמעת הודעה כל שהיא.

המידע האם יש אימות של הרשת ביחס לזיהוי המתקשר מגיע מספק התקשורת, ועלול לא להתקבל במקרים מסויימים.
ניתן להגדיר שכאשר אין מידע האם רשת המקור זהה לרשת זיהוי המתקשר, יכנס לשלוחה:

verify_phone_operator_network_no_have_info_goto=in_extention

או ילך לשלוחה ייעודית:

verify_phone_operator_network_no_have_info_goto=/1/777

או ינתק:

verify_phone_operator_network_no_have_info_goto=hangup

ברירת מחדל אם יש אינדיקציה על ביצוע הפניה שיחות - לא מתחשב בזה - וזה יתפרש כחוסר התאמה.
ניתן להגדיר שאם יש אינדיקציה על הפניה שיחות - ידלג ויכנס לשלוחה:

verify_phone_operator_network_skip_have_referred=yes

@חרב-פיפיות
אני רוצה שזה יהיה בכלל המערכת!

@פלפל-שחור
לפנות לימות על זה?

@דף-חדש
זה השאלה שלי ושל @פלפל-שחור גם לפי הבנתי.

@פלפל-שחור כתב:

ההגדרה הזו למניעת זיופי שיחות מעולם לא אומתה אצלי אם היא בכלל פעילה. אני לא יכול לעשות זיוף שיחה כדי לבדוק את ההגדרה הזו.

וסתם אני ממליץ: הגיע הזמן לפתוח קטגוריה של AI בפורום.
לא?

Spoiler

כשאנחנו כותבים באשכולות, הברירת מחדל היא שהכותב לא מקבל התראה ברגע שיש פוסטים חדשים.
מדוע זה כך?
לא עדיף כבכל הפורומים האחרים - כן להיות עוקבים אוטומאטים ברגע שניק כותב פוסט?
לא שמתי לב לזה עד שאני קולט שרשור שממשיך להתעדכן מבלי שאני מקבל התראה, וכשאני מסתכל בראש האשכול אני רואה 1 עוקבים - וזה כנראה פותח האשכול...

לכל מצביעי הדיסלייק. הבנו. אתם יודעים לדסלייק.
חוץ מזה, אתם גם יודעים לענות?

Spoiler

@1668 ???
יש לך תשובה עניינית?

תודה על כיוון החשיבה, אבל שללתי לחלוטין ערבוב Threads בשרת שלי. השרת רץ בארכיטקטורת Stateless מלאה בתוך Node.js (סביבת single-threaded עם Event Loop אסינכרוני), וכל בקשה נכנסת מקבלת Context מבודד לחלוטין בזיכרון (Scoped Instance). אין שום משתנה גלובלי משותף שיכול לגרום ל-Race Condition בצד השרת.
יתרה מכך, הלוגים מראים שה-UUID של השיחה (אני משתמש בפרמטר ApiCallId שנשלח מימות המשיח) מוצמד בצורה סטרקטורלית (Structured Logging) לכל תגובה שיוצאת מהשרת. הנתונים נשלחים חזרה עם ה-Token הנכון של השיחה הספציפית.
החשד שלי הוא שבגלל ששלוחת ה-API מחזירה פקודות דינמיות (כמו read או go_to_folder), ה-Parser של ימות המשיח בצד ה-Client (המרכזייה עצמה) לא מבצע הקצאת זיכרון דינמית נפרדת לכל ApiCallId ברמת ה-Scope של ה-IVR, אלא משתמש ב-Buffer משותף פר שלוחה.
אם שני מחייגים פונים לשרת באותו מילי-שנייה:

1. שרת ה-API מחזיר שני אובייקטים נפרדים ותקינים לחלוטין.
2. ימות המשיח מקבלת את שניהם, אבל ה-VXML Interpreter של המרכזייה דורס את המשתנה [Read_Variable] של מחייג א' עם הערך של מחייג ב', עוד לפני שהסשן של מחייג א' הספיק לבצע את ה-Evaluation של ה-go_to_folder.
   בגלל שאין לי גישה ל-Low-level Engine של ימות המשיח, אני שוקל לעקוף את המגבלה הזו:
   במקום להחזיר פקודות ישירות ב-Response של ה-API, אני אעביר את המערכת למוד אסינכרוני (Webhook-based). ה-API רק ירשום את השיחה ב-Redis DB שלי ויחזיר מיד לשלוחה פקודת המתנה (play_file), ובמקביל שירות רקע (Worker) יבצע פולטריגר ישיר באמצעות API חיצוני (כמו UpdateExtension) כדי להזריק את הערך ישירות לתוך קובץ ה-ext.ini הזמני של אותה שיחה באופן ממוקד.
   מישהו פה ניסה לעבוד בטופולוגיה כזו מול ה-API של ימות כדי לפתור בעיות Memory Leak או דריסת Buffers בזמני עומס?

אני נתקל בבאג די מוזר בשלוחה שמשלבת נתונים משרת חיצוני ומעבירה אותם הלאה לשלוחה אחרת, ואשמח לעזרת המומחים כאן.
תיאור המקרה:
הגדרתי שלוחה ראשית (נניח 1) כ-type=api. היא פונה לשרת שלי, מקבלת חזרה קובץ הגדרות זמני ומבצעת read למשתמש.
בקובץ ה-ext.ini של השלוחה מוגדר:

type=api
api_link=https://myserver.com
api_add_id_list_message=yes
api_timeout=5

השרת מחזיר בהצלחה את הפרמטרים ויוצר משתנה גלובלי (לדוגמה [Read_Variable]). מיד לאחר מכן, המערכת אמורה להעביר את המחייג לשלוחה 2 (שהיא שלוחת תפריט רגילה type=menu) לצורך ניתוב מבוסס משתנה באמצעות go_to_folder.
הבעיה:
בכ-15% מהשיחות (בעיקר בזמני עומס), נראה שיש Race Condition (תחרות ריצה) במערכת. המשתנה [Read_Variable] מגיע לשלוחה 2 כשהוא ריק או שהוא מכיל את הערך של המחייג הקודם בתור (כאילו ה-Session לא נסגר בזמן והתבצעה דריסת זיכרון).
במערכת הלוגים של השרת שלי (API Logs) אני רואה סטטוס 200 OK מלא, והנתונים נשלחים תוך פחות מ-200 מילישניות, כך שזה לא קשור ל-Timeout.
האם מישהו נתקל בתופעה הזו?
האם יש דרך לאלץ Flush או Clear למאגר המשתנים הדינמיים של ה-IVR לפני המעבר לשלוחה הבאה, או שחובה לעבוד כאן עם Bridge ייעודי כדי לשמור על ה-Token של השיחה הנוכחית?
תודה מראש לכל העוזרים!

גם לכם מרגיש שהקול קצת נשי?
אם עובדים דרך בינה בשנייה אחת מביאים קול קרייני מקצועי משהו טוב. לא?

@וזכיני-לגדל כתב:

(אולי מישהו ינדב כאן קישור או שניים).

https://f2.freeivr.co.il/topic/2553/שלוחת-תפריט/11

שיחה-ממתינה כתב:

אגב, עם כל כך הוצאות, יש גם הכנסות? או שזה גם סודי?
אשמח מאוד לדעת.

ומה עם זה?

התקשרתי - וזה נשמע קו ממש, אבל ממש מושקע.
רואים שחשבת על הכל.
תודה.
אגב, עם כל כך הוצאות, יש גם הכנסות? או שזה גם סודי?
אשמח מאוד לדעת.

@שואל-שאלה
כמה שירים יש בקו?

@שואל-שאלה
הקו שלך כ"כ סודי?
לא מפרסם את זה ולא מפרסם מי הקריין.
מעניין.
רוצים להצליח כמוך...

@שואל-שאלה כתב:

קודם כול אני בטוח שאתם יודעים שיותר אין פרסומות בקו שלנו "עולם המוזיקה"!

בכמה עלה להוריד?
9.90 או יותר?