Newsgroup: it.tlc.telefonia.voip
Titolo: registrar e proxy

Ciao,
mi chiedevo se questi due elementi dell'architettura SIP fossero 
*sempre* necessari, o se viceversa le componenti client e server degli 
User Agent potessero cavarsela da soli e fare a meno di questi intermediari.

RimSA ha scritto:

Non sono necessari sempre. Infatti in alcuni casi (per esempio dua UA 
nella stessa rete locale, almeno un UA conosce l'IP dell'UA dell'altro, 
...) è possibile il peer to peer tra UA SIP; negli altri casi è 
necessario usare un proxy.

 necessario usare un proxy.
Se non fossimo il rete locale, ammettendo che il chiamante conosca 
l'indirizzo ip del chiamato, sarebbero necessari oppure no? Nel caso non 
lo fossero, quale sarebbe la prima parte dell'URI del destinatario 
(quella prima della @)?
Grazie!

RimSA ha scritto:

1) nel mio UA imposto user id "A"
2) nel tuo UA imposti user id "B"
3) io chiamo 
B...@123.1.2.3
 (il tuo indirizzo IP pubblico, e il tuo UA in 
ascolto sulla porta 5060)
4) e tu vedi in arrivo una chiamata da 
A...@152.3.2.1
 (il mio indirizzo IP 
pubblico)
Ovviamente per poterci sentire bisogna attivare anche i canali RTP (per 
l'audio) ovvero i due UA devono essere in ascolto sulle porte comunicate 
all'altro.
In pratica non succede mai di avere un "computer" visibile su internet a 
meno di settaggi particolari nel router, da qui la necessità di 
utilizzare un proxy.

 un proxy.
Basta un banale forward delle porte ...
-- 
Davide Granzotto 

marco ha scritto:

Mi inserisco in questa discussione e affino il quesito. Io ho la
necessità di sviluppare/acquistare un centralino voip (tipo voispeed)
che gestisca più linee telefoniche. Inoltre tale centralino deve
gestire uno svariato numero di interni.
Ora...è necessario l'uso di un proxy per la gestione, e quindi la
registrazione, di tutti gli interni che devono essere gestiti e di
tutte le linee telefoniche?? o è il centralino stesso che fa da proxy?
ciao e grazie

 tutte le linee telefoniche?? o è il centralino stesso che fa da proxy?
Nel tuo caso il centralino fa tutto quelle che ti serve.
-- 
Davide Granzotto 

Davide Granzotto ha scritto:

Grazie...quindi se devo progettare qst software alla fine del lavoro
avrò costruito sia proxy sia centralino. fantastico.
Dato che ci siamo vi pongo un ulteriore domanda, sperando di essere
abbastanza pertinenente alla discussione.
Per lo sviluppo dell'applicazione mi è stato chiesto di lavorare in
ambiente .NET.  a questo proposito ho trovato un paio di librerie che
possono fare al mio caso (
www.indepentsoft.com
 e 
vaxvoip.com
). Avete
qualche indicazione da darmi a riguardo o qualche consiglio su
possibili librerie alternative?
Infine durante un incontro con un'azienda concorrente, questa ci ha
esposto la soluzione che hanno ideato per la gestione di proxy e
centralino. Si affidano allo stack radvision e costruiscono
l'applicazione utilizzando il software di sviluppo prodotto
dall'omonima azienda...che mi dite di questa possibile alternativa?
grazie

 Basta un banale forward delle porte ...
Al solito Davide ha colpito nel segno :)
Ma esiste un softphone/telefono ip che non richieda la registrazione ad 
un registrar (o un proxy) per funzionare? Un coso cioè a cui posso 
attribuire solo l'ID e lasciarlo "in ascolto", dopo aver rigirato le 
opportune porte a fatto i necessari forellini nel firewall?
In alternativa, dotandosi di un registrar che giri su un pc in rete 
locale e di un meccanismo di registrazione dinamica DNS, è possibile 
"autocostruirsi" degli indirizzi sip del tipo 
sip:mionome@mio_dominio_su_ip_dinamico:miaportasip ?
In quest'ultimo caso, quali porte devo aprire e rigirare?

 In quest'ultimo caso, quali porte devo aprire e rigirare?
Di norma le porte sono due, la porta di segnalazione SIP che è quasi sempre 
la 5060 e la porta RTP, che può fariare in funzione degli apparecchi, ma è 
impostabile nel setup.
Volendo puoi fare anche il forward di porte diverse per più interni. Ad 
esempio:
5060 ->
192.168.1.10:5060
5061 ->
192.168.1.11:5060
5062 ->
192.168.1.12:5060
... e così via per tutti gli interni. Ovviamente dovrai fare una cosa 
analoga per l'RTP, anche se in quel caso probabilmente conviene impostare le 
differenti porte direttamente sugli apparecchi.
Uhm ... però ora che ci penso il forward delle porte RTP potrebbe anche non 
servire ... magari fai una prova e vedi che succede.
-- 
Davide Granzotto