GPT-Live-1 יכולה כעת לחייג החוצה: מה ה-SIP GA באמת פותח, ומה היא עדיין לא תעשה

הדבר החדש השימושי ביותר שסוכן קולי של OpenAI יכול לעשות הוא ללחוץ על 1. מאז שעות מאוחרות ב-4 בנובמבר 2026, הפעלה של GPT-Live-1יכולה לבצע שיחה יוצאת למספר טלפון אמיתי דרך SIP trunk, להאזין לתפריט שעונה, ולשלוח צלילי מקלדת בחזרה בקו. החלק האחרון הזה — DTMF דו-כיווני — הוא ההבדל בין סוכן קולי שמדבר לבין סוכן קולי שמסוגל לעבור דרך עץ טלפוני אל המחלקה שאליה הוא באמת צריך להגיע.

המודל עצמו אינו חדש. GPT-Live-1 נמצא ב-ChatGPT Voice מאז 8 ביולי 2026 וב-API מאז 10 בספטמבר 2026 במחיר של 0.05 דולר לדקה. מה שהשתנה ב-4 בנובמבר הוא שכבת התעבורה. ג'סטין אוברטי מ-OpenAI הודיע ש-API הטלפוניה היוצאת "זה עתה קודם … ל-GA", "ומאפשר למפתחים לבצע שיחות טלפון מסוכן הקול החי שלהם" דרך "כל ספק SIP trunk (למשל, Telnyx או Twilio)"; גרג ברוקמן הרחיב על כך באותו לילה. ההודעה מוסיפה ששיחות יכולות להשתמש ב-HD Voice ויכולות לשלוח ולקבל אירועי לוח מקשים.

אז זהו סיפור של יכולת, לא סיפור של מודל, והחומר המעניין נמצא בתיעוד ולא בפוסט. המדריך של OpenAI לטלפוניה ול-SIP קובע כעת ששיחות יוצאות "זמינות לכל הארגונים דרך ה-Live API, לא דרך נקודת הקצה ליצירת שיחות של ה-Realtime API" — שני משפטים שבשקט פוסלים נתח גדול מהאינטגרציות שאנשים ינסו לעשות בהן שימוש חוזר.

מה שינה "GA", ומה הוא לא שינה

לפני הקידום, שיחות יוצאות היו קיימות אך לא היו זמינות באופן כללי — זו המשמעות של "promoted". המנגנון כבר נבנה, והדלת נפתחה. התיעוד של OpenAI כולל כעת את המשפט המתאים, שלפיו שיחות SIP יוצאות "זמינות לכל הארגונים דרך Live API", וזה הדבר הקרוב ביותר להצהרת GA בעמוד: המדריך עצמו אינו נושא תווית beta, preview או alpha בשום מקום.

מה שלא השתנה הוא מודל הקול. דוגמת ה-outbound בתיעוד של OpenAI עצמה עדיין מגדירה model: "gpt-live-1", ורשימת הבדיקה לשותפים עדיין אומרת לאינטגרטורים לחפש "גרסת חבילה שתומכת ב-gpt-live-1". אין מודל ייעודי ל-outbound, אין מחיר נפרד, ואין שכבת טלפוניה. אתם משלמים את אותו $0.05 לדקה עבור שכבת הקול ששילמתם בספטמבר; פשוט עכשיו מותר לכם להוציא אותו על שיחות שיוצאות מהשרת שלכם.

הסתייגות תפעולית אחת מסתתרת במדריך ולא בהכרזה: OpenAI אומרת לכם לוודא ש"תמיכת SIP של GPT-Live מופעלת עבור הפרויקט שלכם, ושקו ה-SIP של הספק שלכם מנותב לאותו פרויקט לפני השימוש בתהליך הזה". תווית GA והגדרת פרויקט מופעלת אינן אותו דבר, ופניית התמיכה הראשונה של השבוע תהיה של מישהו שיש לו האחד בלי השני.

התנאים המוקדמים שקובעים אם ה-trunk שלך עובד בכלל

OpenAI לא אימצה SIP במובן הכללי. היא אימצה פרוסה צרה ומודרנית שלו, וטראנק שנכשל באחד מהבאים לא יתחבר, לא משנה מה ההכרזה הבטיחה לגבי "כל ספק טראנק SIP".

• איתות — TLS נדרש, לא אופציונלי. SIP פשוט מעל UDP או TCP לא בא בחשבון.

• מדיה — נדרש SDES-SRTP, ויש להפעיל את SRTP אצל הספק, ולא רק שהוא נתמך על ידו.

• כתובת URL של הספק — מצפים ל-sips: נקודת קצה, עם ברירת מחדל לפורט 5061, ללא פרטי התחברות, ללא נתיב וללא פרמטרי URI מצורפים.

• יעד — מספר E.164 כגון +14155550123 ולא שום דבר אחר. כתובות SIP URI אינן נתמכות באופן מפורש, ולכן סכימת שלוחה פנימית אינה קיצור דרך.

• אימות — digest, עם שם משתמש וסיסמה של SIP, ובנוסף caller_number בפורמט E.164 שהופך למזהה המתקשר שהנמען שלך רואה.

• היגיינת רשת — שמות מארח מקומיים וכתובות IP פרטיות מפורשות נדחים, מה ששולל מערכת בדיקה שמכוונת אל עמדת מעבדה.

• פורמט שמע — השאר את audio.format לא מוגדר, מכיוון ש-SIP מנהל עליו משא ומתן. הגדרתו היא מסוג הפרמטרים שנראים מועילים אך שוברים את השיחה.

שימו לב למשמעות הדבר לגבי הטענה של "כל ספק". כל ספק שמדבר איתות TLS עם מדיה SDES-SRTP יעבוד; רבים מאוד מטראנקי SIP זולים עדיין משתמשים כברירת מחדל ב-UDP וב-RTP רגיל, והם אינם מכוסים במשפט הזה. החיווט הוא יצירת סשן ולא webhook: אתם שולחים POST אל /v1/live/sessions עם transport.type מוגדר ל-sip, והמדריך אומר במפורש ש"אין צורך ב-webhook לשיחה נכנסת או בבקשת accept לשיחה יוצאת."

מה שאתה מקבל בחזרה הוא session.id וסוג תעבורה, והתיעוד גלוי באופן יוצא דופן לגבי הפער בין זה לבין המציאות: "התגובה הזו לא אומרת שהשיחה נענתה." צלצול, מענה וכשל מגיעים מאוחר יותר בתור אירועי transport.ringing, transport.answered ו-transport.failed ב-WebSocket צדדי בכתובת /v1/live/sessions/{session_id}/attach. יש להתחבר מיד — רק שלוש השניות האחרונות של אירועים משוחזרות — ולהסיר כפילויות לפי event_id, כי המדריך מזהיר שמסירות כפולות הן עניין שגרתי.

המעטפה: שלוש דקות לצלצל, שעתיים לדבר

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

• מגבלת צלצול — שלוש דקות. שיחה שלא נענתה עד אז מסתיימת.

• מגבלת חיבור — שעתיים, שלאחריהן הסשן מסתיים ללא קשר למה שקורה.

• משטח בקרה — העברה באמצעות /v1/live/sessions/{id}/refer, ניתוק באמצעות /v1/live/sessions/{id}/hangup, DTMF נשלח عبر פס הצד באמצעות transport.dtmf.send.

• מצבי כשל — תצורת סשן שגויה נכשלת באופן גלוי בעת היצירה, הגדרת התעבורה עשויה להחזיר 502, פסק זמן באתחול מחזיר 504, וכל דבר מאוחר יותר מגיע באופן אסינכרוני כ-transport.failed.

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

כמה עולה שיחה, בכנות

דף התמחור של OpenAI מפרט שיחות קוליות ב-GPT-Live-1 בעלות של $0.05 לדקה, "בחיוב לפי שנייה, ללא עיגול כלפי מעלה לדקה שלמה." זהו כל המחיר שפורסם, והוא רק אחד משני החיובים ששיחה יוצאת מייצרת. חיוב סיום השיחה אצל המוביל הוא השני, והוא תלוי ביעד, בנפח ובאיזה ספק טראנק בחרתם. OpenAI שומרת לעצמה את עיבוד האודיו ואת לוגיקת הסשן; הספק הוא הבעלים של רגל ה-PSTN.

• שיחה שנענתה באורך דקה — $0.050 מ-OpenAI, בתוספת תעריף הדקה של חברת התקשורת שלך.

• שיחה בת ארבע דקות — $0.200 מ-OpenAI, בתוספת ספק התקשורת.

• אלף שיחות של ארבע דקות — 4,000 דקות, כלומר 200 דולר מ-OpenAI, בתוספת ספק התקשורת.

• שעה של שיחה מחוברת — 3.00 דולר מ-OpenAI, בתוספת דמי ספק השירות.

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

שימוש במודל הבקאנד ובכלים מחויב בנפרד, לפי המודל שאליו האצלתם. אם תנתבו את המקטע הזה דרך OrcaRouter, מרווח של 0% ותמחור לפי עלות יחולו שם ולא על דקת הקול — כך שהורדת מחיר מצד ספק במודל החשיבה תופיע בחשבון שלכם באותו יום, ואילו הורדה ב-gpt-live-1 לא.

אינטגרציית ה-Realtime שלך לא תועבר

הטעות היקרה ביותר שאפשר לעשות השבוע היא להניח שסטאק טלפוניה עובד של Realtime API הוא סטאק עובד של GPT-Live. בעמוד השותפים של OpenAI נאמר זאת בבירור: "אינטגרציה עם Realtime אינה תואמת אוטומטית ל-GPT-Live." נקודת הקצה שונה, מודל הסשן שונה, האצלה היא מושג שאין ל-Realtime באותה צורה, ופורמטי האודיו וסמנטיקת ההפרעה שהמדריך מבקש לבדוק לכל שותף אינם מועברים.

רשימת השותפים גם מסבכת את הניסוח של ההכרזה. OpenAI מתעדת את LiveKit עבור סוכני קול; את Twilio Agent Connect עבור "שיחות טלפון נכנסות ויוצאות"; את Telnyx עבור "חוויות שיחות יוצאות"; את Bandwidth עבור "שיחות נכנסות" מעל SIP; ואת Daily/Pipecat עבור שירות Live באופן כללי. במילים אחרות, Bandwidth מתועדת כאינטגרציה נכנסת, ו-LiveKit ו-Pipecat מתועדים ללא כיוון שיחה כלל. "כל ספק SIP trunk" הוא הצהרה על תאימות פרוטוקול, לא הצהרה לגבי איזה מחמשת השותפים של OpenAI השיק תמיכה בשיחות יוצאות.

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

שאלת הגרסה שאיש לא שאל

קיימת אי-בהירות פעילה בשם. GPT-Live-1.1 נכנס אל ChatGPT Voice ב-15 באוקטובר 2026 עם קולות חדשים בשש שפות, ו-OpenAI עדיין לא פרסמה gpt-live-1.1 כמזהה מודל עבור קוראי API. כל דוגמה יוצאת במדריך הטלפוניה משתמשת ב-gpt-live-1. אם עמית אומר לך שהסוכן היוצא מריץ 1.1 כי זה מה ש-ChatGPT משתמש בו, הוא מתאר את מוצר הצרכן, לא את תצורת הסשן שלך.

באופן מעשי: צטט gpt-live-1 בתוכנית שלך, והתייחס לכל זמינות של API 1.1 כאירוע נפרד שיש לאמת במועד שלו.

היכן החשיבה מתרחשת, ולמה זהו המנוף שאתה שולט בו

GPT-Live חצוי באמצע. הסיכום של התיעוד עצמו הוא שהוא "מאציל את ההיגיון ואת השימוש בכלים ל-backend בזמן שהוא מנהל את השיחה המדוברת". שכבת הקול מטפלת בתזמון, בהפרעות ובפרוזודיה; מודל נפרד עושה את החשיבה וקורא לכלים. ה-backend הזה מוגדר לכל סשן תחת delegation, באחד משני מצבים.

• האצלת Responses — delegation.type: "responses" עם backend נדרש מודל, בתוספת הוראות, כלים, בחירת כלים, מגבלות טוקנים ושכבת שירות. המדריך של OpenAI ממליץ להתחיל עם gpt-6-luna, או gpt-6-sol לעבודה קשה יותר, ומציין ש"אפשר לבחור את מודל Responses באופן בלתי תלוי במודל הקולי."

• האצלה ללקוח — delegation.type: "client", שבו האפליקציה שלך מריצה את ה-backend בעצמה. הניסוח של OpenAI הוא שזה מתיר "כל מודל, סוכן או שירות שהאפליקציה שלך מפעילה."

כאן נמצאים בפועל העלות והאיכות של סוכן יוצא, וזו הבחירה הארכיטקטונית היחידה בעמוד שהיא באמת שלך. מודל הקול קבוע, וכפי שמסתבר, אינו נמצא בקטלוג של OrcaRouter — GPT-Live-1 הוא חזית טלפוניה שאתה קונה מ-OpenAI, ושום חוכמת ניתוב לא משנה את זה. ה-backend הוא עניין אחר. במסגרת האצלה ללקוח, זוהי קריאת מודל רגילה שהקוד שלך מבצע, כלומר API אחד ל-200+ מודלים, מפתח יחיד מול הספקים שאתה מעריך, מעבר אוטומטי לגיבוי אם ספק נחלש באמצע קמפיין, ובחירת מודל לפי סוג קריאה: מודל זול כדי לנווט בתפריט IVR, ומודל חזק יותר כשבן אדם עונה.

תחת האצלת Responses, OpenAI מריצה את החלק הזה ומחייבת עליו לפי התעריפים שלה. שתי הגישות לגיטימיות; הן רק מציבות את ההחלטה במקומות שונים. אם אתם רוצים שה-backend יהיה החלטת ניתוב, האצלה בצד הלקוח היא המצב שנותן לכם את זה.

מה שהושמט מההודעה

בפוסט של GA, ההכרזה דלה בדברים שמכריעים פריסות. היא אינה אומרת דבר על זמינות אזורית, השהיה, מגבלות מקביליות או SLA. היא אינה אומרת דבר על חובות הקלטה, גילוי או הסכמה — ושיחות יוצאות הן המקום היחיד במוצר הזה שבו החובות האלה אינן תיאורטיות. בארצות הברית, ביצוע שיחות אוטומטיות לצרכנים ללא הסכמה הוא בעיית TCPA לפני שהוא בעיית הנדסה; באיחוד האירופי, הקלטת שיחה בלי ליידע את האדם בצד השני היא בעיה בפני עצמה. ה-API נותן לך caller_number ונקודת קצה לניתוק שיחה. הציות הוא באחריותך.

"HD Voice" גם שווה להתייחס אליו כאל טענה ולא כאל מפרט. התיעוד של OpenAI אומר רק ש-SIP מנהל משא ומתן על פורמט השמע ואינו מפרט קודקים, לכן השמע רחב-הפס בפוסט הוא הצהרת ספק שלא כומתה בשום מקום פומבי. בדוק אותה מול ספק השירות שלך לפני שאתה מכניס את זה למצגת.

מה לעשות עם זה, השבוע

אם כבר יש לך סוכן קולי GPT-Live על WebRTC, נתיב היציאה הוא תחבורה שנייה ולא כתיבה מחדש: סשן חדש שנוצר עם transport.type: "sip", trunk שמדבר TLS ו-SDES-SRTP, ו-WebSocket צדדי כדי לעקוב אחר צלצול, מענה ו-DTMF. הקצה יום ל-trunk, לא לסוכן.

אם אתה עובד ב-Realtime, אל תתזמן את ההעברה מתוך הנחה שזהו שינוי תצורה. קרא קודם את מקטעי האצילה והסשן, החלט אם ה-backend שלך צריך להיות של OpenAI או שלך, ורק אז בחר שותף — כי ייתכן שהשותף שבו אתה כבר משתמש לתעבורה נכנסת אינו זה שיש לו נתיב יוצא מתועד.

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