Recent Changes - Search:
SapienTel /

Auguri2006

Siamo alle soglie del Natale, tutti un pò di corsa, vediamo se riusciamo ad affacciarci ed entrare per un saluto, bastano pochi colpi di mouse, e possiamo farci gli auguri!!! La Teleriunione degli Auguri, cadrà quindi venerdì 22, alle ore 15,30, e l'importante... è di presentarsi con qualcosa di rosso !!

E dopo gli auguri, di cosa parleremo ??

Riunione precedente

  • Per ciò che riguarda SER, occorre documentare meglio l'utilizzo del modulo ENUM (vedi appresso)
  • Per SEMS, manca di illustrare meglio il suo interfacciamento con SER, mentre per la sintesi da testo, ho provato il sintetizzatore pur senza usare l'italiano, e non mi pare per nulla adatto ad un funzionamento in real-time. I test devono essere tuttora svolti in modo sistematico.

Serviva di rimpiazzare OpenSER?

No. A quanto pare, l'affermazione che per far funzionare SEMS, occorre usare SER come stack SIP, NON implica l'utilizzo di SER anche nel ruolo di Redirect Server per la segnalazione entrante. Pertanto, la configurazione precedente, che utilizzava OpenSER, poteva essere lasciata. Ormai è stata rimossa, andiamo avanti così

Autenticazione degli INVITE

Si è riscontrato che SER sfida il client che invia l'INVITE, ad autenticarsi. Questo è il comportamento di default previsto del suo file di configurazione, motivato dal desiderio di evitare chiamate entranti provenienti da fonti sconosciute: Di fatto questo comportamento però, impedisce agli account Sapientel di ricevere chiamate dall'esterno, rendendo quasi inutile il servizio. Attualmente, si è scelto di rimuovere del tutto la richiesta di autenticazione, mentre nel futuro imminente, si tenterà di gestire correttamente i seguenti tre casi:

  1. il destinatario dell'INVITE è un account Sapientel: non è richiesta nessuna autenticazione.
  2. il mittente dell'INVITE è un account Sapientel: è richiesta autenticazione. Si tratta del caso in cui l'account usi SER come Outbound Proxy, e l'autenticazione del mittente è il primo passo per inoltrare all'esterno l'INVITE in modo sicuro, ad es. via TLS
  3. mittente e destinatario NON SONO account Sapientel: in questo caso la richiesta è respinta con un messaggio del tipo we do not relay, impedendo l'uso di SER come Open Relay (in perfetta analogia a quanto accade come misura antispam nei server SMTP

Operare o meno come descritto per il primo caso, dovrebbe poter essere deciso dal destinatario dell'INVITE che potrebbe, invece, voler restringere le chiamate entranti, ai soli mittenti autenticati. Come si fa a fare questo? Forse utilizzando il modulo CPL ?? (il Call Processing Language è descritto nella RFC 3880, ma vedi anche qui)

ENUM e SER

Nella documentazione corrente si afferma che per usare ENUM di SER, occorre essere registrati presso e164.org, ma questo non è completamente corretto. ENUM di SER interviene per le chiamate uscenti, che passano di lì se l'utente Sapientel configura smile come OutBound Proxy, e la registrazione presso e164.org, è un problema che riguarda il destinatario. Occorre esplicitare questi fatti, e spostare i commenti riguardanti e164.org, nella pagina i tuoi poteri.

Firewall e NAT

Sicuramente occorre svolgere molti più test in modo sistematico, ma i fallimenti di Piero da Fastweb, e di Alef da dentro la facoltà, sembrano indicare qualche serio problema. In particolare, occorre verificare il comportamento del firewall di Ateneo, ossia se lascia passare l'UDP (e quindi l'RTP) o meno. Pe effettuare questa verifica, occorre disporre di un risponditore (un annuncio, ed un echo test) piazzato su di una macchina firewallata, ad es. utilizzando gli strumenti offerti da PJSIP. Nel caso in cui l'RTP risulti effettivamente bloccato, occorrerà trovare il modo di forzare l'uso del MediaProxy per le comunicazioni che coinvolgono uno UA interno all'ateneo, i cui flussi RTP saranno così instradati attraverso una macchina non firewallata.

MediaProxy

Oltre che per i motivi esposti al punto precedente, l'uso di un MediaProxy o Nathelper è utile per permettere l'utilizzo di UA NATttati, che non dispongono del supporto di STUN (ovvero, che non sanno a quale server STUN rivolgersi). La descrizione della configurazione di MediaProxy fornita nella attuale documentazione non è soddisfacente, in quanto si limita a riportare quanto indicato nella documentazione originale di SER. Occorre qui una operazione di sintesi tra quanto espresso lì e quando dichiarato nella documentazione dei moduli, provvedendo inoltre ad una analisi critica delle diverse soluzione disponibili (MediaProxy vs. RTPproxy)

Prenotazione delle risorse - vedi qui

Dovrebbe essere possible, per chi vuole servirsi del conference bridge (e poi, una volta realizzato il gateway SIP-H323, delle videoconferenze), prenotare la risorsa, per una data e orario fissati, e stabilire una password di accesso, in modo da garantirsi l'uso esclusivo della risorsa, e la protezione dall'acceso da parte di terze parti. Questo comportamento, potrebbe (forse) essere ottenuto mediante l'applicazione conf_auth di SEMS, ma resta il problema, di come chi organizza la conferenza, possa generare il PIN code da inserire.

GateWay SIP-H323

Yate è stato installato con successo da Gaetano, ma non ne è stato verificato il funzionamento. Chi può aiutare ?