Γιατί η Retell δημιούργησε τη δική της πύλη SIP και WebRTC

Πριν η Retell δημιουργήσει τη δική της πύλη (gateway), ένας κορυφαίος πάροχος συνέδεε τις τηλεφωνικές κλήσεις και τις κλήσεις από browser με τους πράκτορες AI της Retell. Η πλατφόρμα του παρόχου παρουσίαζε επανειλημμένα περιστατικά, και ο πάροχος χρειαζόταν κατά μέσο όρο περίπου 50 έως 60 λεπτά για να επιλύσει το καθένα. Δεν είχαμε κανέναν τρόπο να επιλύσουμε ένα περιστατικό γρηγορότερα. Ορισμένες εισερχόμενες κλήσεις δεν έφταναν ποτέ στη Retell, οπότε τα συστήματά μας δεν είχαν καμία καταγραφή τους. Μαθαίναμε για τις χαμένες κλήσεις από τα αιτήματα υποστήριξης πελατών.

Θέλαμε να έχουμε τον έλεγχο της ποιότητας και της διαθεσιμότητας κάθε κλήσης, γι’ αυτό δημιουργήσαμε τη δική μας πύλη SIP και WebRTC. Από τον Οκτώβριο του 2026, η πύλη διαχειρίζεται το 100% των τηλεφωνικών κλήσεων και των κλήσεων από browser της Retell.

Η πύλη της Retell είναι το σύστημα που συνδέει τα τηλεφωνικά δίκτυα και τους web browsers με τους φωνητικούς πράκτορες AI της Retell. Υποστηρίζει το SIP (Session Initiation Protocol), το πρότυπο που χρησιμοποιούν τα τηλεφωνικά συστήματα για την έναρξη και τον τερματισμό κλήσεων, και το WebRTC (Web Real-Time Communication), το πρότυπο που χρησιμοποιούν οι browsers για ζωντανό ήχο.

Η πύλη εγκαθιστά κάθε κλήση, μεταφέρει τον ήχο και τον αναμειγνύει για όλους τους συμμετέχοντες, και διαχειρίζεται τις μεταβιβάσεις, τη ζωντανή ακρόαση (ένας επόπτης ακούει την κλήση την ώρα που εξελίσσεται), την ανάληψη κλήσης (take-over — ένας επόπτης ή ανθρώπινος εκπρόσωπος αναλαμβάνει στη θέση του πράκτορα AI εν μέσω κλήσης) και τους τερματισμούς κλήσεων.

Για να κάνουμε αυτές τις αλλαγές, αντικαταστήσαμε τον πάροχο σε τρία βήματα.

Βασικά αποτελέσματα:

• Η καθυστέρηση (latency) της υποδομής είναι περίπου 90% χαμηλότερη, από 50 ms σε 0.5 ms.
• Κάθε τηλεφωνική κλήση φτάνει πρώτα στη Retell, ακόμη και οι κλήσεις που αποτυγχάνουν.
• Οι λειτουργίες κλήσεων κυκλοφορούν με το δικό χρονοδιάγραμμα εκδόσεων της Retell.

Τι μεσολαβεί ανάμεσα σε έναν καλούντα και έναν πράκτορα AI

Τα demo φωνητικού AI συνήθως δείχνουν το τελευταίο βήμα ενός περίπλοκου συστήματος: το μοντέλο που ακούει και απαντά. Ένας τηλεφωνικός πράκτορας σε παραγωγή χρειάζεται πολύ περισσότερα. Μπροστά από το μοντέλο υπάρχουν συνήθως αρκετά επίπεδα. Αυτά καθορίζουν αν μια κλήση συνδέεται, πόσο γρήγορα κινείται ο ήχος και τι συμβαίνει όταν κάτι αποτύχει.

Μια κλήση προς έναν πράκτορα της Retell περνά από τα εξής τέσσερα επίπεδα:

1. Το PSTN (δημόσιο τηλεφωνικό δίκτυο μεταγωγής) είναι το παγκόσμιο τηλεφωνικό σύστημα. Οι κλήσεις από browser φτάνουν από έναν ιστότοπο ή μια web εφαρμογή.
2. Ο session border controller (SBC) είναι το ασφαλές σημείο εισόδου για τις τηλεφωνικές κλήσεις. Λαμβάνει κλήσεις από έξω και αποφασίζει πού θα δρομολογηθεί η καθεμία. Οι κλήσεις από browser παρακάμπτουν τον SBC και συνδέονται απευθείας με την πύλη.
3. Το επίπεδο πολυμέσων. Εγκαθιστά κάθε κλήση, μεταφέρει τον ήχο και προς τις δύο κατευθύνσεις, τον αναμειγνύει για όλους τους συμμετέχοντες και εκτελεί τους ελέγχους κλήσης, όπως μεταβιβάσεις και τερματισμούς. Οι τηλεφωνικές κλήσεις φτάνουν σε αυτό μέσω SIP. Οι κλήσεις από browser φτάνουν μέσω WebRTC. Στη Retell, η πύλη είναι το επίπεδο πολυμέσων.
4. Η υποδομή AI της Retell. Διεξάγει τη συνομιλία με τον καλούντα.

Πριν από την πύλη, ο πάροχος διαχειριζόταν τα επίπεδα 2 και 3. Η Retell εκτελούσε ένα λογισμικό ενδιάμεσα, τον αναμεταδότη ήχου (audio relay). Ο ήχος διέσχιζε το δημόσιο internet ανάμεσα στον πάροχο και στον αναμεταδότη, ένα άλμα περίπου 50 ms, και στη συνέχεια ο αναμεταδότης τον προωθούσε στην υποδομή AI της Retell.

Γιατί η πλατφόρμα του παρόχου δεν ήταν επαρκής

Η πλατφόρμα του παρόχου βρισκόταν στη διαδρομή κάθε κλήσης, οπότε τα περιστατικά της επηρέαζαν απευθείας τους πελάτες της Retell.

Ο πάροχος χρειαζόταν κατά μέσο όρο περίπου 50 έως 60 λεπτά για να ανακάμψει από ένα περιστατικό. Κατά τη διάρκεια ορισμένων περιστατικών, οι εισερχόμενες κλήσεις δεν έφταναν ποτέ από τον πάροχο στη Retell. Οι χαμένες κλήσεις δεν άφηναν ούτε καταγραφή κλήσης ούτε συμβάν στα συστήματά μας, πράγμα που σήμαινε ότι δεν είχαμε κανέναν τρόπο να εντοπίσουμε την αποτυχία μόνοι μας.

Η εξάρτηση από τον πάροχο προκαλούσε και άλλα προβλήματα:

• Οι απαιτήσεις των πελατών εξαρτώνταν από το τι υποστήριζε ο πάροχος, οπότε δεν μπορούσαμε να διαθέσουμε τίποτα που δεν υποστηριζόταν.
• Οι απαιτήσεις ασφάλειας και συμμόρφωσης ήταν δύσκολο να καλυφθούν μέσω της πλατφόρμας του παρόχου.
• Το άλμα μέσω του δημόσιου internet πρόσθετε καθυστέρηση σε κάθε κλήση.
• Ο λογαριασμός του παρόχου έφτανε τα εκατομμύρια δολάρια τον χρόνο.

Αξιολογήσαμε και άλλους παρόχους. Οι αξιολογήσεις επιβεβαίωσαν αυτό που ήδη πιστεύαμε: για να ελέγχουμε την ποιότητα του προϊόντος, έπρεπε να δημιουργήσουμε τη δική μας πύλη.

Πώς αντικαταστήσαμε τον πάροχο σε τρία βήματα

Κάθε βήμα μετέφερε ένα τμήμα της διαδρομής κλήσης στην υποδομή της Retell.

Τοποθέτηση των session border controllers της Retell μπροστά από τον πάροχο

Αναπτύξαμε τους δικούς μας SBCs και κατευθύναμε σε αυτούς όλη τη σηματοδοσία SIP. Οι πελάτες έστελναν τις τηλεφωνικές τους κλήσεις στη διεύθυνση της Retell αντί για εκείνη του παρόχου. Πρόσθεσαν επίσης τις διευθύνσεις IP της Retell στις λίστες επιτρεπόμενων διευθύνσεων (allowlists), δηλαδή τις λίστες διευθύνσεων από τις οποίες τα τηλεφωνικά τους συστήματα δέχονται κλήσεις. Αρχικά, οι SBCs προωθούσαν κάθε κλήση στον πάροχο.

Η κατοχή των SBCs μάς έδωσε τον έλεγχο της δρομολόγησης. Κάθε τηλεφωνική κλήση έφτανε πλέον πρώτα στην υποδομή της Retell, όπου μπορούσαμε να τη δούμε ανεξάρτητα από το αν συνδεόταν.

Για ένα διάστημα, οι κλήσεις ακολουθούσαν μεγαλύτερη διαδρομή. Ανάμεσα στους SBCs της Retell και στην υποδομή AI της Retell, κάθε κλήση έβγαινε από το δίκτυό μας προς τον πάροχο και επέστρεφε. Στη διαδρομή διέσχιζε δύο φορές το δημόσιο internet. Οι κλήσεις από browser εξακολουθούσαν να πηγαίνουν απευθείας στον πάροχο.

Σταδιακή μεταφορά των τηλεφωνικών κλήσεων στην πύλη, από 1% έως 100%

Στη συνέχεια δημιουργήσαμε την πύλη και την αναπτύξαμε πίσω από τους SBCs, μέσα στο δίκτυο της Retell. Μόλις η πύλη τέθηκε σε λειτουργία, κάθε τηλεφωνική κλήση μπορούσε να ακολουθήσει μία από δύο διαδρομές: μέσω του παρόχου ή μέσω της πύλης.

Οι SBCs επέλεγαν τη διαδρομή για τις εισερχόμενες κλήσεις. Η υποδομή AI της Retell την επέλεγε για τις εξερχόμενες κλήσεις. Αυξήσαμε σταδιακά το μερίδιο των τηλεφωνικών κλήσεων μέσω της πύλης: 1%, 5%, 10%, 20%, 30%, 50% και τελικά 100%. Στη διαδρομή μέσω της πύλης, το άλμα ανάμεσα στους SBCs και στην πύλη διαρκεί περίπου 0.5 ms, επειδή και τα δύο βρίσκονται μέσα στο δίκτυο της Retell.

Μεταφορά των κλήσεων από browser στην πύλη με το WebRTC SDK της Retell

Οι κλήσεις από browser ήταν οι τελευταίες που είχαν απομείνει στον πάροχο. Δημιουργήσαμε το δικό μας WebRTC SDK (software development kit), τον κώδικα που χρησιμοποιεί ένας ιστότοπος ή μια web εφαρμογή για να πραγματοποιεί κλήσεις από browser, και δρομολογήσαμε τις κλήσεις από browser μέσω της πύλης.

Με τη μεταφορά των κλήσεων από browser, καταργήσαμε τον πάροχο και τον αναμεταδότη ήχου. Πλέον μια κλήση παραμένει στο δίκτυο της Retell από τη στιγμή που φτάνει έως ότου φτάσει στην υποδομή AI της Retell.

Γιατί η μετάβαση ήταν δύσκολη

Ο στόχος ήταν να αναλάβουμε τον έλεγχο χωρίς να αλλάξει καμία συμπεριφορά στην οποία βασίζονταν οι πελάτες. Το δύσκολο κομμάτι ήταν η αντικατάσταση του παρόχου κατά τη διάρκεια ζωντανών κλήσεων χωρίς καμία ενόχληση για τους πελάτες. Οι εισερχόμενες κλήσεις, οι εξερχόμενες κλήσεις, οι μεταβιβάσεις, οι κλήσεις από browser και οι έλεγχοι κλήσης έπρεπε όλα να συνεχίσουν να λειτουργούν όπως πριν, σε όλη τη διάρκεια της μετάβασης.

Αυτό σήμαινε τη διατήρηση τεσσάρων πραγμάτων:

• Συμπεριφορά πρωτοκόλλου (πώς η πύλη επικοινωνεί μέσω SIP με τα συστήματα στην άλλη άκρη μιας κλήσης): Οι πάροχοι τηλεπικοινωνιών και τα τηλεφωνικά συστήματα των πελατών έπρεπε να λαμβάνουν τη συμπεριφορά που περίμεναν.
• Χρονισμός ήχου (πότε φτάνει ο ήχος σε κάθε πλευρά της κλήσης): Ο ήχος έπρεπε να κινείται και προς τις δύο κατευθύνσεις χωρίς νέα κενά ή καθυστερήσεις.
• Δικαιώματα συμμετεχόντων (ποιος σε μια κλήση μπορεί να ακούει, να μιλά ή να ξεκινά ανάληψη κλήσης): Ένας επόπτης που χρησιμοποιεί ζωντανή ακρόαση έπρεπε να διατηρεί τα ίδια δικαιώματα.
• Σημασιολογία κύκλου ζωής κλήσης (πώς μια κλήση ξεκινά, αλλάζει και τερματίζεται): Κάθε κλήση έπρεπε να ξεκινά, να μεταβιβάζεται και να τερματίζεται με τον ίδιο τρόπο και να στέλνει τα ίδια συμβάντα στα συστήματα της Retell.

Η σταδιακή διάθεση μάς επέτρεψε να δοκιμάσουμε κάθε συμπεριφορά σε ένα μικρό μερίδιο πραγματικών τηλεφωνικών κλήσεων. Διευρύναμε το μερίδιο μόνο αφού η συμπεριφορά αποδεικνυόταν σταθερή.

Το βασικό δίδαγμα για εμάς είναι ότι μια τέτοια μετάβαση πύλης εξαρτάται από τον έλεγχο της δρομολόγησης, από ισχυρή παρατηρησιμότητα (observability) και από δοκιμές που καλύπτουν ολόκληρο τον κύκλο ζωής της κλήσης. Παρατηρησιμότητα σημαίνει να μπορείτε να βλέπετε τι κάνει κάθε κλήση την ώρα που εξελίσσεται.

Η διαδρομή κλήσης της Retell σήμερα: SBCs, πύλη και WebRTC SDK

Η νέα μας διαδρομή κλήσης αποτελείται από τρία μέρη.

Οι SBCs της Retell βρίσκονται στο όριο με τον έξω κόσμο. Λαμβάνουν σηματοδοσία SIP από τους παρόχους τηλεπικοινωνιών και τα τηλεφωνικά συστήματα των πελατών και στη συνέχεια δρομολογούν κάθε κλήση.

Η πύλη κάνει τη δουλειά που έκανε παλιότερα ο πάροχος. Εγκαθιστά κλήσεις, μεταφέρει και αναμειγνύει ήχο και εκτελεί τους ελέγχους κλήσης. Επικοινωνεί με την υποδομή AI της Retell μέσω HTTP και WebSocket, δύο τυπικών τρόπων με τους οποίους οι servers ανταλλάσσουν αιτήματα και μεταδίδουν δεδομένα σε ροή.

Το WebRTC SDK της Retell επιτρέπει σε ιστότοπους και web εφαρμογές να στέλνουν κλήσεις από browser απευθείας στην πύλη.

Οι έλεγχοι ασφάλειας και συμμόρφωσης αποτελούν μέρος του σχεδιασμού. Περιλαμβάνουν πιστοποιημένη πρόσβαση, δικαιώματα συμμετεχόντων, διαχείριση ευαίσθητου ήχου και απόκρυψη ευαίσθητων πληροφοριών.

Τι άλλαξε με την κατοχή της πύλης

Η κατοχή της διαδρομής κλήσης σημαίνει ότι είμαστε υπεύθυνοι για κάθε πτυχή της ποιότητας μιας κλήσης.

Δεν περιμένουμε πλέον έναν πάροχο για να δημιουργήσει λειτουργίες κλήσεων. Ένας πελάτης από τον χώρο της ασφάλισης χρειαζόταν προσαρμοσμένα SIP headers σε μηνύματα SIP BYE για μία από τις καμπάνιες του. Τα SIP headers είναι πεδία που μεταφέρουν επιπλέον πληροφορίες μαζί με μια κλήση. Ένα μήνυμα BYE είναι το σήμα που τερματίζει μια κλήση. Ο πάροχος δεν υποστήριζε τότε προσαρμοσμένα headers σε μηνύματα BYE, οπότε δημιουργήσαμε τη λειτουργία στην πύλη. Επειδή ελέγχουμε τον κώδικα και τη διαδικασία εκδόσεων, διαθέτουμε λειτουργίες με το δικό μας χρονοδιάγραμμα εκδόσεων.

Πλέον μπορούμε να καλύπτουμε μόνοι μας τις απαιτήσεις ασφάλειας ενός πελάτη (HIPAA, SOC 2 κ.λπ.). Η Retell μπορεί επίσης να αναπτύσσει την πύλη σε νέες περιοχές cloud όταν το χρειάζονται οι πελάτες.

Πότε η δημιουργία δικής σας πύλης είναι λάθος επιλογή

Μια πύλη είναι λάθος έργο για μια ομάδα που δεν διαθέτει την τεχνική δυναμικότητα για να λειτουργεί υποδομή επικοινωνιών πραγματικού χρόνου ή τις απαιτήσεις προϊόντος που θα τη δικαιολογούσαν.

Η δική μας δουλειά συνεχίστηκε και μετά την κυκλοφορία. Η λειτουργία μιας πύλης απαιτεί μια εξειδικευμένη ομάδα, καθώς και συνεχή επένδυση σε:

• Διαλειτουργικότητα τηλεφωνίας
• Δικτύωση
• Επεξεργασία πολυμέσων
• Ασφάλεια
• Παρακολούθηση
• Λειτουργίες βάρδιας ετοιμότητας (on-call)

Διαλειτουργικότητα τηλεφωνίας σημαίνει τη διατήρηση της συμβατότητας της πύλης με τους πολλούς παρόχους τηλεπικοινωνιών και τα τηλεφωνικά συστήματα με τα οποία συνδέεται.

Η κατοχή της πύλης σημαίνει επίσης ευθύνη για την αντιμετώπιση περιστατικών, τον σχεδιασμό χωρητικότητας, τη συντήρηση και την ασφαλή ανάπτυξη. Η Retell έκανε την επένδυση επειδή η ποιότητα των κλήσεων, η διαθεσιμότητα, η προσαρμογή και η ταχεία βελτίωση είναι κεντρικά στοιχεία του προϊόντος μας.

Συμβουλές για ομάδες που κάνουν το ίδιο

Αν η ομάδα σας αποφασίσει να δημιουργήσει τη δική της πύλη, να τι λειτούργησε για εμάς:

1. Αναλάβετε πρώτα τον έλεγχο του σημείου εισόδου SIP, ώστε να μπορείτε να διαχειρίζεστε τη δρομολόγηση και να βλέπετε κάθε τηλεφωνική κλήση πριν αντικαταστήσετε το επίπεδο πολυμέσων.
2. Μεταφέρετε τις τηλεφωνικές κλήσεις σταδιακά, δημιουργώντας την πύλη σας πίσω από τους SBCs σας.
3. Αντιμετωπίστε τις κλήσεις από browser ως πλήρη ενοποίηση που περιλαμβάνει το SDK, τον έλεγχο ταυτότητας, την εγκατάσταση σύνδεσης και τη μεταφορά ήχου.
4. Ενσωματώστε ελέγχους ασφάλειας και συμμόρφωσης από την αρχή, όπως κάναμε με την πύλη της Retell.
5. Μετράτε την καθυστέρηση, την ποιότητα ήχου και τη συμπεριφορά σε αποτυχίες σε όλη τη διάρκεια της μετάβασης, συμπεριλαμβανομένων των κλήσεων που αποτυγχάνουν πριν φτάσουν στην εφαρμογή σας.

Συνδέστε το τηλεφωνικό σας σύστημα με τη Retell

Αν οι απαιτήσεις τηλεφωνίας έχουν καθυστερήσει την υιοθέτηση φωνητικού AI στην επιχείρησή σας, ξεκινήστε με τον οδηγό προσαρμοσμένης τηλεφωνίας. Δείχνει πώς να συνδέσετε το τηλεφωνικό σας σύστημα με τη Retell μέσω SIP trunk (μιας απευθείας σύνδεσης SIP ανάμεσα σε δύο τηλεφωνικά συστήματα) και ποιες διευθύνσεις της Retell να προσθέσετε στη λίστα επιτρεπόμενων διευθύνσεων. Για περισσότερο τεχνικό περιεχόμενο, δείτε τα άρθρα μας για το Real-Time Reliability, τα Retell Workflows και το Retell Memory.

Και αν διαχειρίζεστε μεγάλους όγκους κλήσεων ή έχετε αυστηρές απαιτήσεις συμμόρφωσης, μιλήστε με την ομάδα μας.