Ciao,
sposto la discussione sulle applicazioni VoIP in Ruby da questa parte se
no ci sparano.
Per Sickpig: ma usate per caso Adhearsion? Come controllate Asterisk?
Per inciso, se avete problemi con i segfault, magari riusciamo a darvi
una mano, lavoriamo abitualmente con Asterisk.
Per gli altri: qualcuno sviluppa, o ha sviluppato, applicazioni VoIP?
Con che stack e tecnologie?
Per i furbetti della JVM: lo so che su Java 7 -J-server non serve ma io
ce lo lascio lo stesso 
ā
Luca P.
[email protected]
Il 15/11/2013 10:46, Luca P. ha scritto:
Ciao,
sposto la discussione sulle applicazioni VoIP in Ruby da questa parte se no ci
sparano.
Per Sickpig: ma usate per caso Adhearsion? Come controllate Asterisk?
Per inciso, se avete problemi con i segfault, magari riusciamo a darvi una mano,
lavoriamo abitualmente con Asterisk.
Per gli altri: qualcuno sviluppa, o ha sviluppato, applicazioni VoIP?
Con che stack e tecnologie?
Io sono molto interessato a questa discussione perch stavo giustappunto
pensando allo sviluppo di uno strumento interno per la gestione del
numero per lāassistenza fondamentalmente. Premetto che sono MOLTO
ignorante su Adhearsion; lo conosco, avevo spulciato la doc qualche mese
fa ma non ho mai approfondito, e nemmeno scritto una riga di codice che
si appoggiasse ad esso.
Come si comporta con la lingua italiana? Parlo di text-to-speech
piuttosto che di speech-to-text. La scelta di JRuby per lāutilizzo di
Adhearsion dovuta al fatto che ci sono molti processi che sono CPU
intensive e bloccanti oppure per gestire molti eventi
contemporaneamente, per esempio tante chiamate contemporanee? Come si
comporta con la MRI e Rubinius?
JRuby mi affascina (concettualmente, come qualsiasi non-MRI) e questo
potrebbe darmi la spinta necessaria per provarlo.
Ciao
2013/11/15 Luca P. [email protected]
Ciao,
sposto la discussione sulle applicazioni VoIP in Ruby da questa parte se
no ci sparano.
ottima idea 
Per Sickpig: ma usate per caso Adhearsion? Come controllate Asterisk?
non usiamo adhersion.
ci siamo scritti una classe per parlare con asterisk via AMI (
https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=4817239).
Quando dobbiamo fare una chiamata il server rails si collega via AMI al
server asterisk, eseguiamo un Originate
che istanzia una chiamata al numero e poi fa il bridge sul peer sip
(browser) che ha generato la richiesta.
Per inciso, se avete problemi con i segfault, magari riusciamo a darvi una
mano, lavoriamo abitualmente con Asterisk.
magari! sarebbe bello.
praticamente il tutto si verifica sotto carico, la maggior parte delle
volte il seg fault al modulo rtp di asterisk.
purtroppo stiamo usando tutte parti di codice di asterisk relativamente
nuove, lāautentificazione e il signaling del sip
viene veicolato dai browser via websocket, asterisk nelle nuove versioni
ha
un suo server ws embedded, lato
client il signaling SIP gestito via JsSIP (jssip.net, progetto davvero
buono) mentre tutta la parte media sfrutta
le funzionalit WebRTC (attualmente usiamo solo chrome).
A questo aggiungi che facciamo girare una versione patchata di asterisk
per
il support del trascoding di opus
(GitHub - meetecho/asterisk-opus: Opus (transcoding) and VP8 (passthrough) support for Asterisk, needed for a better WebRTC integration, http://www.opus-codec.org/)
per
questioni di consumo di banda.
(usare ulaw/alaw sarebbe troppo dispendioso e gli unici due codec
abilitati
in chrome ad ora sono opus,ulaw).
Se hai qualche dritta sono tutto orecchie
Bene!
On Nov 15, 2013, at 12:24 PM, [email protected] wrote:
ottima idea
Per Sickpig: ma usate per caso Adhearsion? Come controllate Asterisk?
non usiamo adhersion.
Io vi consiglio di non ri-inventare la ruota 
nuove, lāautentificazione e il signaling del sip
(usare ulaw/alaw sarebbe troppo dispendioso e gli unici due codec abilitati
in chrome ad ora sono opus,ulaw).
My money is on this.
Secondo me vi conviene esplorare una soluzione con Kamailio come SBC con
oppure passare a FreeSWITCH che quei problemi non li ha.
Asterisk 12 sistema un sacco di problemi di questo tipo.
La 11 usa ancora la vecchia architettura e i plugin, soprattutto quelli
per media/RTP, sono un problema a livello di design.
Issue su Github e sentite cosa vi dicono, per cominciare!
Iniziare con Adhearsion davvero facile, ma a questo punto potremmo
anche organizzare un Hangout per chi fosse interessato.
Per quanto riguarda il TTS, Adhearsion quello che si chiama 3PCC, Third
Party Call Control, ovvero non tocca il media stream, ma gestisce solo
le logiche di chiamata
Tutto laudio se lo smazza lAsterisk o FreeSWITCH di turno.
Per il text-to-speech hai svariate opzioni, alcune sono free ma
scarsine, tipo FLite, altre leggermente migliori e costano poco, come
Cepstral, per poi arrivare alle soluzioni veramente costose.
Il vantaggio che Adhearsion supporta dal punto di vista dei comandi
moltissimi engine in maniera trasparente, tant che noi sviluppiamo con
FLite in locale, la qualit scarsa ma free e si installa in 10 minuti,
poi di solito senza modifiche si passa alla roba carrier-grade in
staging e produzione.
Adhearsion basato su Celluloid, quindi sullactor model, quindi 1 thread
per operazione/actor, quindi JRuby 
Poi per ragioni varie, non ultimo la semplicit, molti progetti meno
carichi girano su CRuby senza tanti problemi.
Consideriamo lo switch quando parliamo di sistemi che sono a 250+
chiamate attive contemporanee, con 20+ chiamate nuove al secondo, che se
fai le moltiplicazioni non sono noccioline 
ā
Luca P.
[email protected]
A questo aggiungi che facciamo girare una versione patchata di asterisk per
il support del trascoding di opus
(GitHub - meetecho/asterisk-opus: Opus (transcoding) and VP8 (passthrough) support for Asterisk, needed for a better WebRTC integration, http://www.opus-codec.org/) per
questioni di consumo di banda.
(usare ulaw/alaw sarebbe troppo dispendioso e gli unici due codec abilitati
in chrome ad ora sono opus,ulaw).
My money is on this.
pure io avevo puntato su questo, ma ho perso
la cosa crash anche con asterisk vanilla usando ulaw, purtroppo
Secondo me vi conviene esplorare una soluzione con Kamailio come SBC con
http://www.kamailio.org/w/2013/08/new-module-rtpproxy-ng-webrtc-to-bare-rtp/
oppure passare a FreeSWITCH che quei problemi non li ha.
Asterisk 12 sistema un sacco di problemi di questo tipo.
stiamo valutanto di passare a freeswitch proprio per questo motivo.
adesso che ce lo fai presente di sicuro valuteremo anche kamalio.
il problema che siamo abbastanza impantanati con un bel poā sdi
features di asterisk e per valutare se lāalternativa a tutto quello
che
ci serve time consuming.
La 11 usa ancora la vecchia architettura e i plugin, soprattutto quelli per
media/RTP, sono un problema a livello di design.
nella 12 tra lāaltro stata incorporata una parte della patch per
opus, purtroppo strippata del transcoding. da quello si capito
quelli della digium hanno una paura folle
di essere schiacciati come ābugsā per via di possbili brevetti usati
nellāimplementqazioe di opus
Issue su Github e sentite cosa vi dicono, per cominciare!
questa un idea, la pi banale ma sonostato cos tante volte
āsnobbatoā (usiamo asterisk dalla versione 1.2) che ormai non ci penso
nemmeno pi
Vedi, Adhearsion anche platform independent!
/shameless_plug
Luca P.
[email protected]
2013/11/15 Luca P. [email protected]:
sposto la discussione sulle applicazioni VoIP in Ruby da questa parte se
non usiamo adhersion.
Io vi consiglio di non ri-inventare la ruota
ci avevo dato un occhiata a suo tempo e allāepoca mi sembrava un poā
andare a caccia di farfalle con il cannone.
peroā adesso le nostre esigenze sono un poā aumentanteā¦ potrebbe
essere il caso di rivalutare
Non so quando lo avevi guardato, ma la versione 2 uscita ad Aprile
dellanno scorso ha cambiato quasi tutto.
In realt la semplicit di gestire le applicazioni in Ruby vs. taroccare
con extensions.conf ed AMI il punto di forza.
Inoltre un framework sviluppato per la telefonia da gente che fa
praticamente solo quello, quindi la task X labbiamo sicuramente gi
affrontata.
In questo momento abbiamo un piccolo difetto di diffusione e
documentazione, ma ci stiamo lavorando.
Io a questo punto lHangout introduttivo lo propongo a tutti coloro che
fossero interessati!
ā
Luca P.
[email protected]
2013/11/15 Luca P. [email protected]:
Non so quando lo avevi guardato, ma la versione 2 uscita ad Aprile dellanno
scorso ha cambiato quasi tutto.
anni fa (ai tempi asterisk 1.4 o gi di li)
In realt la semplicit di gestire le applicazioni in Ruby vs. taroccare con
extensions.conf ed AMI il punto di forza.
buono a sapersi.
Inoltre un framework sviluppato per la telefonia da gente che fa praticamente
solo quello, quindi la task X labbiamo sicuramente gi affrontata.
In questo momento abbiamo un piccolo difetto di diffusione e documentazione, ma
ci stiamo lavorando.
la documentazione una cosa fattore fondamentale per farsi che una
piattaforma/sw venga adottatto. purtroppo viene spesso lasciata
come āultimaā cosa. e da devel capisco benissimo qual il meccanismo
per cui succede questo.
Io a questo punto lHangout introduttivo lo propongo a tutti coloro che fossero
interessati!
quando vuoi io sono disponibile.
Il 15/11/2013 15:07, Luca P. ha scritto:
Io a questo punto lHangout introduttivo lo propongo a tutti coloro che fossero
interessati!
Decisamente interessato, ma non riesco prima di settimana prossima.
Ciao,
2013/11/15 [email protected] [email protected]:
2013/11/15 Luca P. [email protected]:
Io a questo punto lHangout introduttivo lo propongo a tutti coloro che fossero
interessati!
quando vuoi io sono disponibile.
anche io parteciperei allāhangout, solo per curiositaā sullāargomento
ciao ciao,
matteo.
P.S.: potrei proporvi di farlo un martedi per Hackatron? (hackatron.org)
Molto volentieri!
Come funziona?
Luca P.
[email protected]
Ciao,
2013/11/17 Luca P. [email protected]:
Molto volentieri!
Come funziona?
decidiamo un martediā che vada bene a chi eā interessato qui in lista
e poi pubblichiamo lāannuncio sulla community G+ di Hackatron. Per chi
eā nei dintorni di Venezia/Treviso ci saraā la possibilitaā di seguire
lāhangout fisicamente dallo stesso posto, altrimentiā¦ hangout
Lāhangout lo facciamo pubblico con streaming live (e registrazione) su
YouTube.
solitamente lāincontro settimanale lo si faā dalle 18.30 in poi, in
base agli orari che vanno bene a chi eā interessato possiamo fissare
come eā piuā comodo (propongo lāinizio tra le 18.30 e le 19.00).
ciao ciao,
matteo.
Benissimo per me!
Quanto durano le presentazioni di solito?
ā
Luca P.
[email protected]
Il giorno 19 novembre 2013 18:59, bugant [email protected] ha scritto:
Facciamo per Martediā prossimo? Va bene sulle 18.30?
Bravi, interessante.
Ci scappa anche link (e pubblicit per gli amici in Georgia ā¦ Mojo
Lingo
Ma va bene cos.
S.
Ciao,
2013/11/18 bugant [email protected]:
Ciao,
2013/11/17 Luca P. [email protected]:
Molto volentieri!
Come funziona?
decidiamo un martediā che vada bene a chi eā interessato qui in lista
e poi pubblichiamo lāannuncio sulla community G+ di Hackatron. Per chi
eā nei dintorni di Venezia/Treviso ci saraā la possibilitaā di seguire
lāhangout fisicamente dallo stesso posto, altrimentiā¦ hangout
Facciamo per Martediā prossimo? Va bene sulle 18.30?
ciao ciao,
matteo.
2013/11/19 Luca P. [email protected]:
Benissimo per me!
Quanto durano le presentazioni di solito?
di solito facciamo 15min.
peroā dimmi anche tu se sono abbastanza oppure no. poi cāeā la
sessione con le domande.
se credi, possiamo fare 20/30 min di talk.
se mi mandi anche un piccolo abstract lo metto nellāevento
grazie!
ciao ciao,
matteo.