PhonoSDK Ένα …τηλέφωνο στο web

Κάτι που συζητείται πολύ τις τελευταίες μέρες στο χώρο της σύγκλισης τηλεφωνίας και web (μετά την ανακοίνωσή του στην πρόσφατη jQuery Conference είναι το Phono, που δίνει τη δυνατότητα ενσωμάτωσης ενός softphone σε οποιοδήποτε browser (που έχει εγκατεστημένο το flash plugin για την ώρα).

Παρόλο που δεν είναι κάτι πρωτότυπο σαν ιδέα (βλ. πχ Zingaya, Flash Gateway for Asterisk, OpenZoep. TringMe, Ribbit κ.α.) στηρίζεται σε ανοιχτη αρχιτεκτονική (υιοθετώντας το XMPP για signaling και αφήνοντας ανοιχτό (για το μέλλον μιας και για την ώρα αξιοποιεί το Flash/RTMP) το θέμα της μεταφοράς ήχου, όπως εμφανίζεται στο ακόλουθο σχήμα:

Αν λυθούν κάποια θεματάκια με την αξιοποίηση Flash και jQuery από browsers σε φορητές συσκευές θα μπορούσε να αποτελέσει μια καλή πρόταση για πολυκαναλικότητα αλλά και πολυτροπότητα (multimodality) μέσω του browser (τουλάχιστον για το μεταβατικό στάδιο μέχρι να υιοθετηθεί η HTML5 και να οριστικοποιηθεί η σχετική λειτουργικότητα).

Προσωπικά μου θύμισε λίγο την αρχιτεκτονική που ακολουθείται στο project του red5phone, όπου στο ρόλο του Gateway υπάρχει ο red5 flash server.

Δεδομένης όμως της ανακοίνωσης του Moho που ήδη διατίθεται ως κομμάτι του Voxeo Prism, μπορούμε να κάνουμε την ασφαλή υπόθεση ότι αξιοποιούνται τα Moho/Prism στο ρόλο του Gateway για την επικοινωνία με το Tropo και τις υπόλοιπες υποδομές της Voxeo.

Σύμφωνα με την ανακοίνωση της εταιρείας, ο πηγαίος κώδικας του συγκεκριμένου gateway (που για την ώρα «κλειδώνει» τη χρήση του phono στις υποδομές της Voxeo) θα διατεθεί σύντομα οπότε αναμένουμε ώστε από τη μια να επιβεβαιώσουμε τις ..υποψίες μας και από την άλλη να δούμε κατά πόσο μπορεί να αξιοποιηθεί μια τέτοια προσέγγιση ώστε να μπορεί κανείς να έχει πρόσβαση και απευθείας σε υπηρεσίες αναγνώρισης/σύνθεσης ομιλίας (βλ. MRCP) στο δρόμο που πρότεινε ο Nicholay Shmyrev με αξιοποίηση του ενδιάμεσου.

Πολυκαναλικότητα: Η νέα Απαίτηση

Ένας από τους πιο δημοφιλείς όρους που συναντά κανείς πλέον στο χώρο των εφαρμογών/υπηρεσιών προστιθέμενης αξίας είναι αυτός του «Unified Self-Service”, που ουσιαστικά απαντά στην ανάγκη για «οργανωμένη» διάθεση της υπηρεσίας μέσα από πολλά κανάλια ανά πάσα στιγμή. Η τάση λοιπόν είναι για:

  • μια εφαρμογή
  • πολλά κανάλια αλληλεπίδρασης με τον τελικό χρήστη
  • ιδανικά το ίδιο περιβάλλον ανάπτυξης για όλα τα κανάλια
  • συγκεντρωτικές καταγραφές (logs)
  • συγκεντρωτικά στατιστικά στοιχεία για τη χρήση της εφαρμογής (business intelligence/analytics)
  • ανάπτυξη από την ίδια ομάδα προγραμματιστών
  • Τα παραπάνω δεν σημαίνουν απαραίτητα ότι η εμπειρία χρήσης της εφαρμογής είναι ίδια για όλα τα κανάλια αλλά προσαρμόζεται ώστε να εκμεταλλεύεται τις δυνατότητες και να καλύπτει τις αδυναμίες του κάθε καναλιού.

    Όσο για τα κανάλια; Πλέον είναι πολλά, όπως φαίνεται στο παρακάτω σχήμα:

    Και να σκεφτεί κανείς ότι το παραπάνω σχήμα είναι …ενδεικτικό μιας και μπορεί κανείς να προσθέσει τα μη ευρέως αυτοματοποιημένα κανάλια (π.χ. email, fax) αλλά και τις …εξειδικεύσεις του κάθε καναλιού, όπως mobile web, tv web (πχ βλ GoogleTV), browser softphone κλπ

    Η ανάκαμψη των φωνητικών εφαρμογών

    Μέχρι τα μέσα -τουλάχιστον, για τα δεδομένα της Ελλάδας- της περασμένης δεκαετίας τα κλειστά (συνήθως APIs για τη δημιουργία φωνητικών και τηλεφωνικών γενικότερα αλληλεπιδραστικών εφαρμογών αρνούνταν πεισματικά να παραδώσουν τη σκυτάλη στο ανοιχτά πρότυπα VXML (πλέον στην έκδοση 3.0), CCXML, GRXML κλπ.

    Και παρόλο που αρκετοί ήθελαν να δημιουργήσουν τέτοιες εφαρμογές ως μια από τις βασικές εκδοχές του ubiquitous computing (μιας και το mobile web ήταν ακόμη στα σπάργανα), χάθηκε η ευκαιρία ο χώρος να ακολουθήσει τους ρυθμούς εξέλιξης των εφαρμογών web. Βέβαια, με δεδομένες τις δυνατότητες των σημερινών συσκευών δεν μιλάμε για αντικατάσταση των εφαρμογών ιστού αλλά για συμπλήρωσή τους για εκείνες τις περιπτώσεις που ακόμη και η περιοριστική παροχή πληροφοριών με γραμμικό τρόπο είναι πιο κατάλληλη (ή η μόνη διαθέσιμη μέσω της κλήσης ενός τηλεφωνικού αριθμού κι από την πιο απλή τηλεφωνική συσκευή).

    Οι λόγοι της υστέρησης, πέρα από τον παραπάνω, είναι πολλοί:

  • κλειστή φύση των εφαρμογών τηλεφωνίας αλλά και της επικοινωνίας με μηχανές αναγνώρισης ομιλίας/σύνθεσης φωνής που ελέγχονταν από λίγες μεγάλες εταιρείες
  • διαρκώς νέα APIs και εργαλεία (γραφικά ή μη) που πρέπει να υιοθετηθούν από τους προγραμματιστές
  • μεγάλο κόστος εγκατάστασης τηλεπικοινωνιακών υποδομών διασύνδεσης και ακριβό υλικό τηλεφωνίας
  • μη εξοικείωση με τις τεχνολογίες τηλεφωνίας από το ευρύ κοινό προγραμματιστών
  • Οι τεχνολογίες web απαλλαγμένες από τα παραπάνω προβλήματα έγιναν το κύριο μέσο για τη διάδοση/διάχυση των πληροφοριών. Τα πράγματα άρχισαν να αλλάζουν με την είσοδο της προσέγγισης του ανοιχτού λογισμικού/λογισμικού ανοιχτού κώδικα στο χώρο της τηλεφωνίας (βλ. Asterisk) και του VoIP. Με τα εργαλεία αυτά υπήρχε πλέον η δυνατότητα να εγκαταστήσει και να φτιάξει εφαρμογές τηλεφωνίας οποιοσδήποτε με σχετικά μειωμένου κόστους εξοπλισμό και με υπηρεσίες που δίνονταν από τους τηλεπικοινωνιακούς παρόχους σε οικιακούς χρήστες.

    Το πρόβλημα όμως της ευρείας αποδοχής των εφαρμογών τηλεφωνίας παρέμενε μέχρι που μια νέα προσέγγιση υπόσχεται πλέον να δώσει λύση μέσω της σύγκλισης με τις τεχνολογίες ιστού και τη λογική της φιλοξενίας και την παροχή ως υπηρεσία (SaaS ή στη συγκεκριμένη περίπτωση VaaS: Voice as a Service): οι τηλεφωνικές υπηρεσίες βασισμένες στο σύννεφο (cloud telephony/voice).

    Θα λέγαμε ότι μέσα στο 2010, υπήρξε μια έκρηξη εμφάνισης πολλών εταιρειών και λύσεων προς την κατεύθυνση αυτή με τα ακόλουθα βασικά κοινά χαρακτηριστικά:

  • Παρέχεται ένα web based API μέσω του οποίου οι χρήστες/εφαρμογές μπορούν να καλέσουν βασικές υπηρεσίες τηλεφωνίας όπως η απάντηση κλήσεων, η αναπαραγωγή ήχου, η συλλογή επιλογών μέσω DTMF τόνων, η εγγραφή ήχου κλπ
  • Τα αποτελέσματα αποστέλλονται, στη συνέχεια, στα πλαίσια μιας αίτησης προς το διακομιστή της εφαρμογής για την περαιτέρω επεξεργασία και για να αποφασιστεί από την εφαρμογή πώς θα εξελιχθεί η αλληλεπίδραση
  • Η παραμετροποίηση/εγκατάσταση του απαιτούμενου υλικού, η εξασφάλιση τηλεφωνικού αριθμού/δρομολόγησης κλπ γίνεται από τον πάροχο χωρίς να πρέπει να ανησυχεί τον χρήστη
  • Έχει υιοθετηθεί πολιτική πληρωμής ανάλογα με τη χρήση με αποτέλεσμα το αρχικό κόστος εγκατάστασης να είναι πλέον μηδενικό
  • Κάποιες (με πρωτοπόρο τo tropo.com της Voxeo) προσπαθούν να εντάξουν από την αρχή και τις δυνατότητες αναγνώρισης και σύνθεσης ομιλίας
  • Τα χαρακτηριστικά αυτά έχουν αρχίσει να δίνουν μια νέα ώθηση στις τηλεφωνικές εφαρμογές και στον ολοένα και πιο πρωτοποριακό συμπληρωματικό συνδυασμό (και όχι βέβαια να λειτουργούν ανταγωνιστικά) με εφαρμογές web αλλά και εφαρμογές που αξιοποιούν άλλα κανάλια επικοινωνίας (πολύκαναλικές εφαρμογές) ώστε να μιλάμε πλέον για ανάκαμψή τους.

    Ανάμεσα στις πιο δημοφιλείς τέτοιες υπηρεσίες είναι:

  • Tropo (μέσω του Tropo WebAPI και ευρεία χρήση JSON)
  • Twilio (μέσω της υποστήριξης της TwiML)
  • Cloudvox|IfByPhone (με υιοθέτηση του FastAGI από τον κόσμο του Asterisk ως API
  • Teleku (UPDATE 2010-08-14 η οποία εξαγοράστηκε από τη Voxeo)
  • Invox
  • QuickFuse (με online γραφικό εργαλείο workflow)
  • VoiceSage
  • Παρόλο που με την προσέγγιση αυτή πράγματι διευρύνεται η βάση των προγραμματιστών που μπορούν να τις αξιοποιήσουν λόγω της απλούστευσης αλλά και η δυνατότητα για mashups, το βασικό θέμα είναι ότι το προγραμματιστικό μοντέλο επιστρέφει εκεί που βρισκόταν όχι πριν από τη VXML (και τον ενσωματωμένο form interpretation αλγόριθμο) αλλά ακόμη κι πριν από τους πίνακες καταστάσεων (state-tables ή state-machines).

    Αυτό που αναμένεται πλέον είναι, μαζί κι από την εμπειρία χρήσης της VXML σε δυναμικές εφαρμογές, τουλάχιστον όταν έρθει η ανάγκη για πιο πολύπλοκες εφαρμογές από αυτές ενός απλού κατευθυνόμενου διαλόγου ή μιας απλής business διαδικασίας, να αναδυθούν/προταθούν νέα μοντέλα και μηχανισμοί που θα δίνουν τη δυνατότητα στον προγραμματιστή ανεξάρτητα από την πλατφόρμα που θα επιλέξει να επιτύχει πιο εύκολα την επιθυμητή αίσθηση αλληλεπίδρασης (Voice User Interface).

    UPDATE: Μια πολύ ενδιαφέρουσα διάκριση σε γενιές συστημάτων IVR κάνει Nickolay Schmyrev, βασικός συντελεστής της ανάπτυξης του Sphinx στο άρθρο του εδώ.
    Ουσιαστικά αναφέρεται στις παραπάνω υπηρεσίες τηλεφωνίας ως τη δεύτερη γενιά μετά την πρώτη γενιά των εφαρμογών βασισμένων σε VXML και αφήνει υποσχέσεις για εφαρμογές τρίτης γενιάς βασισμένων στην υποβοήθηση της σημασιολογική ανάλυση του διαλόγου μέσα και από αξιοποίηση dialogue manager, όπως ο Ravenclaw, o DMCPP κ.α.

    Ανάγκη για «εμπλουτισμό» του data tag στο πρότυπο VoiceXML

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

    Προσωπικά, πρόσφατα (για τις ανάγκες της «φωνητικής» εκδοχής της εφαρμογής e-Αποδείξεις) παρατήρησα ότι η -σωστή βάσει της έκδοσης 2.1 του προτύπου- συμπεριφορά της πλατφόρμας της Voxeo (αναφέρομαι στον voicebrowser πίσω από το evolution και όχι στο prophecy) κατά την αίτηση ενός data element ήταν η διακοπή λειτουργίας με ανακήρυξη σφάλματος. Κι αυτό γιατι η εφαρμογή επέστρεφε μόνο JSON απαντήσεις.
    Η μόνη λύση ήταν να υποστηριχθεί η επιστροφή απαντήσεων σε xml φορμά μέσω μιας προαιρετικής παραμέτρου (&format=xml) κατά την κλήση. Βέβαια, ιδανικά, όλες οι REST-based εφαρμογές, παρόλο που η τάση είναι σαφώς υπέρ του JSON, θα έπρεπε να υποστηρίζουν, τόσο από πλευράς υλοποίησης όσο και από πλευράς τεκμηρίωσης, και τους δύο τρόπους και να αφήνουν την επιλογή χρήσης στον εκάστοτε προγραμματιστή-χρήστη των αντίστοιχων web API.

    UPDATE 2010-09-04: Η παραπάνω επισήμανση είναι μέρος μιας (τη 5ης) από τις ..πολλές που πλέον έχουν αρχίσει να συγκεντρώνουν οι ενδιαφερόμενοι, όπως ο Dominique Boucher στο blog της Nu Echo. Ο αριθμός των drafts της έκδοσης 3.0 του προτύπου έχει φτάσει πλέον στο 31 και κάτι πάει να γίνει με την «υποστήριξη» JSON…

    Εμπειρία το JBoss Experience 2009

    Μάλλον έχω μια ..έφεση στα online events (μιας και η διαμονή μέχρι πολύ πρόσφατα στα Χανιά και οι συνθήκες δουλειάς άφησαν ένα …μικρο-απωθημένο ως προς τη …ζωντανή παρακολούθηση συνεδρίων, συναντήσεων κλπ). Δυστυχώς δεν μπορώ να συγκρίνω -μιας και δεν έχω τη σχετική μεγάλη εμπειρία- με την αντίστοιχη δια ζώσης εμπειρία αλλά γενικά μπορώ να πω ότι είμαι ευχαριστημένος μιας και τελικά η απόσταση δεν αποτελεί εμπόδιο για τη συναναστροφή. Τείνω να πιστεύω, μάλιστα, ότι ισχύει το αντίθετο ειδικά όταν μπορείς να εντοπίσεις σχετικά εύκολα και γρήγορα το υπόβαθρο και τους ρόλους (π.χ. στην υποδοχή, στις παρουσιάσεις κλπ) του συνομιλητή και δεν αρκείσαι στο ταμπελάκι που μπορεί να φοράει ή τις ..διασυνδέσεις/συστάσεις των άλλων μελών της παρέας (αν αυτή υπάρχει μπορεί να λειτουργήσει και περιοριστικά).

    Η διαφορά στην ώρα βοήθησε ιδιαίτερα στην παρακολούθηση (έστω και με κάποια διαλείμματα – άλλο καλό κι αυτό) του χτεσινού event JBoss Experience 2009 από την JBoss. Ελάχιστα τα τεχνικά προβλήματα, κυρίως ως προς τη λειτουργία και τη λειτουργικότητα του chat client κατά τη διαχείριση ιστορικού και sessions ενώ στα θετικά ότι μπορεί κανείς να έχει πρόσβαση στο σχετικό υλικό ακόμα και ..ασύγχρονα (replays και pdf, mp3 από τις παρουσιάσεις).

    jboss_virtexper1

    Τα θέματα ήταν αρκετά ενδιαφέροντα (αν και κάπως ασαφώς κατηγοριοποιημένα κατά την άποψή μου) σε σημείο να είσαι σε μεγάλο δίλημμα για το τί θα παρακολουθήσεις. Η έμφαση δόθηκε στη ναυαρχίδα της JBoss, τον application server και τις ..συνοδευτικές τεχνολογίες (middleware, SOA) αλλά και στις προτάσεις για virtualization και cloud computing. Από την άλλη, ελάχιστα ακούστηκαν για τα πλάνα της JBoss στο χώρο των τηλεπικοινωνιακών «υποδομών» και τη σύγκλιση (βλ. telco 2.0, SDP ή/και Mobicents) ή τουλάχιστον εγώ δεν παραβρέθηκα σε σχετικές παρουσιάσεις.

    Για τελευταίο αφήνω την -πολύ μικρή σε σχέση με το αναμενόμενο- συμμετοχή Ελλήνων στο συγκεκριμένο event. Ανάμεσά τους ο ..πανταχού παρών Δημήτρης Ανδρεάδης από τη μεριά της JBoss αλλά και ο Χρήστος ο Βασιλάκης από το R&D της Forthnet…

    jboss_virtexper2

    Η …σκυτάλη τώρα (ως προς τον κόσμο της Java τουλάχιστον) στο ερχόμενο JHUG Tech Day

    Παρουσία, Διαθεσιμότητα και Επικοινωνία Πραγματικού Χρόνου

    Τελικά οι συναντήσεις του OpenCofee έχουν πολλά θετικά…Πέρα από την ενημέρωση για νέες προσπάθειες μέσα από τις παρουσιάσεις και τις νέες γνωριμίες με άτομα και τάσεις είναι και ένα καλό κίνητρο για ραντεβού και συνάντηση στις δύσκολες συνθήκες «συνεύρεσης» (μην παρεξηγηθώ,ε;) της Αθήνας…

    Η τελευταία εκδήλωση ήταν μια καλή αφορμή να τα πούμε από κοντά με το Γιάννη (της K2Dynamics), φίλο και παλιό συμφοιτητή, και να ανταλλάξουμε απόψεις για τη …μάχη χαρακωμάτων (όχι δεν αναφέρομαι στα …μπάχαλα των ημερών) στο χώρο των υποδομών και των εφαρμογών με απαιτήσεις επικοινωνίας πραγματικού χρόνου (RAI – Realtime Application Infrastructure) ανάμεσα στα –σημειωτέον ανοικτά– πρότυπα SIP (και οι επεκτάσεις τύπου SIMPLE) και XMPP.
    O Γιάννης έχει ασχοληθεί πάρα πολύ με το θέμα ενώ στο XMPP στηρίζεται και η υπηρεσία ζωντανής υποστήριξης PresenceSpace που εδώ και λίγο καιρό έχουν λανσάρει. Ελπίζω να δοθεί η ευκαιρία να την παρουσιάσει σύντομα σε επόμενη συνάντηση του OpenCoffee μπας και ξεφύγει η θεματολογία των παρουσιάσεων από τον αμιγώς web 2.0 και social oriented χαρακτήρα που έχουν αυτή τη στιγμή.

    Βέβαια, η κουβέντα είναι μεγάλη μιας και είναι σε εξέλιξη ακόμη η προσπάθεια ενδυνάμωσης αυτών καθ’αυτών των πρωτοκόλλων (π.χ. θέματα ασφάλειας) αλλά και εύρεσης τρόπων για διαλειτουργικότητα (interoperability). Μάλιστα το συγκεκριμένο θέμα ήταν από τα βασικά στην τελευταία συνάντηση του IETF. Περισσότερα από τα …παρασκήνια εδώ και εδώ όπου ο Dan York (από τον κόσμο του SIP) συζητά με τον Peter St. Andre από τους πρωτεργάτες της XMPP (πρώην Jabber και νυν μέρος της Cisco) κοινότητας.

    Mobicents: Η απόλυτη – ανοιχτή – πλατφόρμα σύγκλισης στο πεδίο της Java;

    Από τότε που έμαθα για την ύπαρξή του (και είναι αρκετός ο καιρός), η έννοια της «σύγκλισης» είναι για μένα συνυφασμένη με το project Mobicents.

    Υλοποιώντας μια αρχιτεκτονική που επιτρέπει την εξυπηρέτηση μεγάλου όγκου συμβάντων με πολύ μικρή καθυστέρηση χωρίς να έχει προβλήματα στο να προσαρμοστεί στις ανάγκες διαφορετικού φόρτου (scaling) μπορεί να υιοθετηθεί πέρα από το χώρο των τηλεπικοινωνιών (βλέπε SDP, IMS) σε χώρους όπως τον αυτούς των οικονομικών συναλλαγών, των online παιχνιδιών, των δικτύων αισθητήρων αλλά και του κατανεμημένου ελέγχου. Σχετικά αθόρυβα έχουν ολοκληρωθεί μια σειρά από στοιχεία διασύνδεσης με άλλες πλατφόρμες ανάμεσα στις οποίες ξεχωρίζουν η επικοινωνία μέσω SIP, η πλατφόρμα Asterisk, οι υποδομές XMPP (βλ. Jabber), πλατφόρμες Parlay/X κ.α. Εδώ και λίγο καιρό η Redhat μέσω της JBoss «αγκάλιασε» και επίσημα την ανάπτυξή του με αποτέλεσμα να συνεχίζει πλέον ως JBoss Communications Platform.

    jboss_telco

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

    UPDATE: Στο συγκεκριμένο χώρο – και στο χορό – έχουν ήδη μπει (εκτός των άλλων βέβαια):

  • η Oracle που μετά την εξαγορά της HotSip έχει λανσάρει προϊόντα όπως ο Oracle Communication and Mobility Server και η πλατφόρμα SDP
  • η HP με την πλατφόρμα OCMP
  • ενώ περισσότερα για την σύγκλιση των εφαρμογών υπάρχει ένα πολύ ενδιαφέρον white-paper εδώ.