- Supongamos un Asterisk con IP 80.80.80.80 y dominio "dominio_asterisk.org".
- Supongamos que dos extensiones de nuestro Asterisk son:
- "Yo" <200>
- "MiCompi" <213>
- Permitimos entrantes SIP sin autenticar (al igual que se permite entrantes
PSTN) ¡¡¡hay que evolucionar señores, muerte a la PSTN!!! XDD
- Nos llama un usuario "sip:213@dominio_externo.com". Es decir, a Asterisk le
llega un INVITE con:
From: "Pepito Externo" <sip:213@dominio_externo.com>
- Se procede en el dialplan y Asterisk llama a un usuario suyo (a mí):
Dial(SIP/200)
- La llamada llega a mi tfno 200, pero increiblemente los datos que ha puesto
Asterisk en el INVITE son:
From: "Pepito Externo" <sip:213@dominio_asterisk.org> <--- AHHHH !!!!
Es decir, en caso de que tengamos a nuestro compañero 213 metido en una
libreta de direcciones o algo así, nuestro tfno nos indicará que nos está
llamando el compañero 213 (ya que es el mismo username@dominio). No hay forma
de distinguir que nos llama un 213 EXTERNO (ya que Asterisk ha profanado el
dominio del llamante).
Es más, supongamos que no respondemos la llamada, y más tarde vemos las
llamadas perdidas ("coño, me ha llamado MiCompi"). Entonces pincho en dicha
llamada perdida y mi teléfono llama a MiCompi. Qué guay Asterisk.
En fin, ¿soy el único que se mete en estos follones SIP con Asterisk? ¿nadie
permite entrantes SIP y tiene estos problemas?
En mi opinión el "From" debería respetarse en la llamada que Asterisk hace al
usuario interno.
Agradezco cualquier sugerencia. Saludos.
--
Iñaki Baz Castillo
i...@in.ilimit.es
> En mi opinión el "From" debería respetarse en la llamada que Asterisk hace
> al usuario interno.
>
>
> Agradezco cualquier sugerencia. Saludos.
La única megañapa que se me ocurre es "corregir" la cabecera From en el propio
dialplan antes del Dial y poner la que tenía originalmente,
Sé que puedo añadir dicha cabecera con:
exten => _2XX,n,SIPAddHeader(${SIPCHANINFO(from)})
Pero lo malo es que quedan dos cabeceras "From" y eso es muy sucio (depende
del dispositivo SIP se podría interpretar le primera o la última, mal mal).
Puestos a seguir con esta chapucilla, ¿alguna forma de modificar el "From" que
Asterisk pone en el Dial para que deje el original?
Hombre, ten en cuenta que asterisk no es un proxy propiamente dicho, y
aquí estamos hablando de dos canales/llamadas "independientes", el que
entra a asterisk, y el que genera asterisk. Otra cosa es que asterisk
haga un bridge entre ellos para que se comuniquen. Del mismo modo, si
la llamada entrante viniese de un gateway H323, o de un primario Zap,
qué debería poner en el From según tu opinión?
[...]
> En fin, ¿soy el único que se mete en estos follones SIP con Asterisk? ¿nadie
> permite entrantes SIP y tiene estos problemas?
Creo que la mayoría no nos complicamos tanto la vida ;). Yo solo
permito entrantes desde mis proveedores de DID. Confío en que el
callerid que me envían está bien. En cualquier caso, se podría tocar
el calleridname para reflejar de donde viene la llamada.
> En mi opinión el "From" debería respetarse en la llamada que Asterisk hace al
> usuario interno.
Si el canal origen es SIP, podría estaría de acuerdo, pero y en los otros casos?
***
Y contestando a tu otro email, en principio no hay forma de modificar
el From desde el dialplan (utiliza siempre el fromdomain del peer o o
el dominio definido en sip.conf), aunque no sería complicado leer una
variable y asignarlo. El tema se cuece en la función initreqprep() en
channels/chan_sip.c.
Julián J. M.
Bueno, lo estoy posteando aquí XD
> ¿ No es un
> problema local del entorno exacto con el que estas trabajando ?
No no, es un problema que ocurre sin más, no depende del entorno: si asterisk
recibe un INVITE de un usuario externo y acaba haciendo un Dial a un usuario
en el nuevo INVITE el From se ha modificado.
Como bien dices abajo, en el caso de canales SIP sí que se podría mantener
(sin ningún problema) el From original.
Es decir, si la llamada viene de RDSI entonces Asterisk decide poner
como "From" el número RDSI llamante, ok, me parece bien.
Ahora, si la llamada es un SIP externo Asterisk debería poner un "From"
completo (¿¿por qué solo conserva el username pudiendo conservar **sin
problema alguno** también el dominio??).
> En cualquier caso, se podría tocar
> el calleridname para reflejar de donde viene la llamada.
Pero el calleridname sólo te permite cambiar el nombre y el username, en
ningún caso el dominio. Es más, he probado la burrada de:
Set(CALLERID(all) = 5000000@otro_dominio_inventado)
y entonces el "From" que genera Asterisk es de risa:
From: <sip:5000000@otro_dominio_inventado@IP_asterisk> <-- JAJA
> > En mi opinión el "From" debería respetarse en la llamada que Asterisk
> > hace al usuario interno.
>
> Si el canal origen es SIP, podría estaría de acuerdo, pero y en los otros
> casos?
En los otro no :)
> Y contestando a tu otro email, en principio no hay forma de modificar
> el From desde el dialplan (utiliza siempre el fromdomain del peer o o
> el dominio definido en sip.conf), aunque no sería complicado leer una
> variable y asignarlo. El tema se cuece en la función initreqprep() en
> channels/chan_sip.c.
Buff, cada vez que pretendo hacer algo mínimamente SIP con Asterisk se hace
necesario cambiar código XDDDD
Gracias por el dato. No obstante ya he reportado el bug en Digium.
Gracias ;)
Gracias, pero esa variable es para otro tema, es para que Asterisk
autodescubra cuales son sus dominios locales (vía DNS, /etc/hosts) y admita
registros de usuarios contra ese dominio.
[...]
> En fin, ¿soy el único que se mete en estos follones SIP con Asterisk?
> ¿nadie permite entrantes SIP y tiene estos problemas?
Si hijo, si .. eres el único que se complica tanto la vida, los
más "adelantados" lo más que hacen con el Asteriks para Inbound "abierto" es
configurar dundi y e.164.org, poco más .. o permitir entradas "abiertas",
pero te la juegas como le encuentren un fallo de seguridad (que seguro que
los tiene) al asterisk.
¿Tu conoces a alguna empresa que permita que se conecten a su PBX
directamente ? yo no .. to quisque pasa por el operador.
> En mi opinión el "From" debería respetarse en la llamada que Asterisk hace
> al usuario interno.
No tiene porqué, ya que NO RUTA la llamada, sino que genera UNA NUEVA hacia
adentro.
> Agradezco cualquier sugerencia. Saludos.
Repite conmigo este mantra ... "No volveré a intentar hacer cosas de operador
con un truño de PBX...", que Asterisk es una PBX un cuasi intento de B2BUA,
hace cosas muy bien .. pero no te salgas de lo "básico" que se pierde ...
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
> > En mi opinión el "From" debería respetarse en la llamada que Asterisk
> > hace al usuario interno.
>
> No tiene porqué, ya que NO RUTA la llamada, sino que genera UNA NUEVA hacia
> adentro.
No estoy de acuerdo. Aunque Asterisk genere una nueva llamada (que lo hace
puesto que es un B2BUA) sí que retransmite el username del callerid llamante
(el 215 de sip:215@dominio_que_sea en caso de llamente SIP).
Así que obviamente Asterisk trata de pasar info del llamante al llamado.
Pero en el caso de SIP_2_SIP lo hace mal, puesto que en SIP 215@dominio_A es
distinto de 215@dominio_B. No hay absolutamente ningún problema en que
respete el "From" original (no hablo del from_tag, claro) en llamadas
SIP_2_SIP-
De hecho, he reportado un bug y Olle me ha comentado eso mismo, que se debe a
una limitación en cuanto a que Asterisk corta a partir del @ "por lo sano".
> > Agradezco cualquier sugerencia. Saludos.
>
> Repite conmigo este mantra ... "No volveré a intentar hacer cosas de
> operador con un truño de PBX...", que Asterisk es una PBX un cuasi intento
> de B2BUA, hace cosas muy bien .. pero no te salgas de lo "básico" que se
> pierde ...
Cada vez que trato de hacer cualquier cosa mínimamente SIP que se separe un
poco de hacer y recibir llamados de tfnos SIP locales me viene a la mente tu
mismo pensamiento. :(
Ohhh, no soy un bicho raro (no tanto) !!!!
Eso sí, aún no somos ni "cuatro gatos" con este tema. XD
> Yo posteé (creo que antes de verano) en la lista de Asterisk, y en la
> de bugs, y
> no encontré respuesta. Pero ahora veo que no la tiene.
Lo reporté el otro día y al menos ya conozco que Ollew tiene intenciones de
hacerlo en un futuro, pero que requiere cambios no sólo SIP. Creo que te
interesará el reporte:
http://bugs.digium.com/view.php?id=11322
(igual le puedes meter un poco de feedback) ;)
> A mi parecer es un problema grave...porque cuando quieres devolver
> la llamada a quien te ha llamado...no puedes!. Mi ñapa para que me
> puedan contactar es poner la info de mi número en el contact...
Pero el "Contact" sólo se usa para request durante el mismo diálogo así que no
te servirá para devolver la llamada.
Yo lo he "conseguido" haciendo la super guarrada de añadir otro From (ya que
no se puede eliminar/modificar el que pone Asterisk):
exten => _2XX,1,SIPAddHeader(${SIPCHANINFO(from)}
exten => _2XX,n,Dial(SIP/${EXTEN})
Es una cerdada, ¡¡2 cabeceras From en un INVITE!! Es super anti-estándares.
Supongo que cada tfno decidirá si se queda con la primera o la segunda (si se
queda con la segunda te sale bien la jugada, pero es algo muy.... puaj).
por ejemplo llamando a Twinkle funciona (pura casualidad supongo).
En fin, a ver qué tal.
>- Permitimos entrantes SIP sin autenticar (al igual que se permite entrantes
>PSTN) ¡¡¡hay que evolucionar señores, muerte a la PSTN!!! XDD
Totalmente de acuerdo: si puedes recibir llamadas SIP por qué no hacerlo?
> - La llamada llega a mi tfno 200, pero increiblemente los datos que ha puesto
> Asterisk en el INVITE son:
> From: "Pepito Externo" <sip:213@dominio_asterisk.org> <--- AHHHH !!!!
Esto tal vez sea necesario para que Asterisk haga de intermediario
cuando los dos interlocutores no pueden comunicarse directamente entre
ellos (un NAT por ejemplo) y no puede hacer reinvite.
El problema aquí es si se puede confiar en el identificador que envía
el otro o hay que sobreescribirlo siempre. En las redes públicas es el
proveedor el que debe asegurarnos que no permite a sus clientes
falsificar el ID (aunque a veces esto no ocurre y mandan ids falsos).
> En fin, ¿soy el único que se mete en estos follones SIP con Asterisk? ¿nadie
> permite entrantes SIP y tiene estos problemas?
>
> En mi opinión el "From" debería respetarse en la llamada que Asterisk hace al
> usuario interno.
No soy experto en esto pero sospecho que cada uno pone en el @xx su
propia dirección, o sea la dirección a donde deberá hacerse la
conexión de datos. Tal vez sea problema del protocolo SIP y no de
Asterisk...
Yo diría que hagas la prueba pero me parece que no funciona así la cosa...
No, si claro que no funciona, es un asesinato al RFC3261 en toda regla. ;)
> > - La llamada llega a mi tfno 200, pero increiblemente los datos que ha
> > puesto Asterisk en el INVITE son:
> > From: "Pepito Externo" <sip:213@dominio_asterisk.org> <--- AHHHH
> > !!!!
>
> Esto tal vez sea necesario para que Asterisk haga de intermediario
> cuando los dos interlocutores no pueden comunicarse directamente entre
> ellos (un NAT por ejemplo) y no puede hacer reinvite.
No, en absoluto. El "From" header no tiene ninguna relevancia ni uso una vez
establecido el diálogo (los dos diálogos: A <-> Asterisk <-> B).
El único uso que tiene es para que el llamado (B) pueda
rechazar/desviar/loquesea una llamada y para mostrar el callerid al usuario
(y en SIP el callerid es "Nombre <sip:usuario@dominio>"), aunque Asterisk se
empeñe en decir que el callerid es sólo "Nombre <usuario>".
Una vez establecido el canal (diálogo) entre Asterisk y B, si B quiere enviar
algo a A (poner en espera, REFER, BYE...) lo hace a través de Asterisk, ya
que en el "Contact" header del INVITE que recibió B desde Asterisk pone:
Contact: A@IP_Asterisk
Y en este caso sí que es completamente correcto que aparezca la IP de Asterisk
ya que el diálogo es entre Asterisk y B. Es decir, el From ya no interviene
para nada una vez establecida una llamada.
> El problema aquí es si se puede confiar en el identificador que envía
> el otro o hay que sobreescribirlo siempre.
Ahora mismo en Asterisk da igual el dominio del llamante.
Sea "dominio_raro", "dominio_chungo" o lo que sea al usuario local de
Asterisk que recibe la llamada le va a aparecer siempre:
From: A@IP_Asterisk
> Tal vez sea problema del protocolo SIP y no de Asterisk...
Eso sí que no ;)
Y Asterisk invita a ello totalmente.
Ahh, perdona, te había entendido mal.
Bien, si alguien se hace pasar por un usuario de tu dominio entonces se tendrá
que autenticar. Es como en el correo electrónico:
- Cualquier puede enviar (sin autenticarse) correos a "gmail.com".
- Pero si un usuario quiere enviar un correo a "gmail.com" desde el
usuario "pe...@gmail.com" tendrá que autenticarse en el servidor de correo de
Gmail.
Pero es que insisto en que en Asterisk hacer ese spoofing es mucho más
sencillo ya que Asterisk no muestra el dominio.
O sea, si tienes un Asterisk que permite entrantes SIP anónimas (hay que
evolucionar decíamos, ¿no?), entonces si nos llama 203@dominio_externo.com y
Asterisk hace un "Dial(SIP/150)" a un usuario local 150, le enviará en el
From:
From: 203@IP_Asterisk
Exactamente lo mismo que si el usuario local 203 llama:
From: 203@IP_Asterisk
Es decir, el llamado local 150 verá lo mismo en su teléfono o softphone!!!!
Eso es Spoofing fácil fácil.
Y todavía peor: si 150 no respondió la llamada y consulta luego su lista de
llamadas perdidas en el tfno, verá que le ha llamado:
203@IP_Asterisk
y al devolverle la llamada resulta que llamará al usuario local 203 !!!
- ¿Si?
- Hola, que he visto que me has llamado pero estaba en el lavabo fumando.
- ¿Yoooo? yo no te he llamado, ¿qué fumas?
- ¡¡Oye, no empecemos que tengo aquí tu número registrado!!
- Eso no me lo dices a la cara.
Pedirle que se autentique, por supuesto.
esto tiene k tener algo escondido... a no ser k pongamos un openser delante no?
On 11/22/07, Iñaki Baz Castillo <i...@in.ilimit.es> wrote:
>
pero como le vas a pedir eso a un tio de la calle!!!!
Pero bueno, si se está haciendo pasar por alguien de nuestro dominio claro que
le pedimos que se autentique, ¿¿no??
Si efectivamente "es de la calle" y se está inventando el dominio entonces no
podrá autenticarse. De eso se trata, ¿no?
Por desgracia Asterisk no está concebido para tales efectos. En mi opinión
Asterisk está hecho para:
- Entorno SIP local.
- Entrantes/salientes vía PSTN.
- Tal vez salientes a PSTN vía proveedor SIP/IAX.
- Usuarios "roadwarriors" SIP/IAX configurados como tales (tema NAT y tal).
- En ningún caso comunicación alguna con proxies SIP ni otros entornos SIP (a
parte de trunks).
Cualquier otra cosa que intentes con Asterisk y SIP te defraudará.
Mucho "Asterisk y VoIP" pero en realidad Asterisk está hecho para sustituir a
las PBX locales y comunicarse con el mundo a través de la PSTN, para qué nos
vamos a engañar.
> esto tiene k tener algo escondido...
No hay nada escondido, llámale "limitación".
> a no ser k pongamos un openser delante no?
No del todo. Imagina este escenario:
- OpenSer alojando el dominio SIP "midominio.org" y usuarios registrados en él
(Asterisk sólo como PBX SIP).
- 210@dominio_externo llama a in...@midominio.org.
- La llamada llega obviamente a OpenSer quien ruta la llamada a Asterisk
(el "From" sigue intacto, por supuesto).
- Asterisk ejecuta el dialplan y decide llamar a un usuario del dominio:
Dial(SIP/1...@midominio.org)
- La llamada vuelve a OpenSer quien en esta ocasión la ruta al usuario
1...@midominio.org.
- Pero resulta que Asterisk ya ha metido la zarpa y ha cambiado el dominio del
From y ha puesto:
From: 210@IP_Asterisk
- Así que el usuario local 1...@midominio.org sólo sabrá que le llama alguien
con username 210, pero ni idea del dominio.
Triste.
No no, pero **sólo** puedes pedir autenticación si el From es de tu dominio.
Es decir, si te montas un proxy SIP y albergas usuarios con
dominio "midominio.org" sólo tiene sentido que pidas autenticación si quien
llama es un usuario de dicho dominio.
Y además, no es que puedas, es que debes hacerlo.
> Ahora bien, el
> hecho de que cualquiera me pueda mandar un invite con usuario y el dominio
> que le plazca debe ser controlado de alguno forma, tal y como hacen las
> compañias PSTN actuales.
Eso ya es otra historia, y muy difícil de controlar, sí.
Es exactamente lo mismo que con el correo electrónico, cualquiera puede mandar
un correo con el From modificado y liartela gorda (¿SPAM?).
> Se supone que alguien que llama desde la red de España (movil o fija) hacia
> otro usuario de la red de España, queda autenticado automaticamente por la
> confianza que hay entre carriers españoles
La PSTN nos protege.... XDDD
> (...que no de voicetrading, claro, jeje)
XDD
> si yo te llamo a iña...@in.ilimit.es, desde mi softphone, me vas a pedir
> contraseña???
Sí, y como no te la sabes no podrás llamar. ;)
Saludos.
> > Ahora bien, el
> > hecho de que cualquiera me pueda mandar un invite con usuario y el
> > dominio que le plazca debe ser controlado de alguno forma, tal y como
> > hacen las compañias PSTN actuales.
Un pista de cómo se puede cuajar ese control que mencionas en un futuro mundo
SIP:
RFC 3325 - Private Extensions to SIP for Asserted Identity within Trusted
Networks
http://www.faqs.org/rfcs/rfc3325.html
Bueno, pero lo interesante de la prueba sería averiguar si es
NECESARIO que después de la @ venga la dirección de tu servidor y qué
pasaría si viniera lo mismo que vino en la llamada original. Eso puede
ayudar a entender por qué las cosas se hacen como se están haciendo
Te puedo asegurar (RFC en mano) es que el From no debería cambiar, y sobre
todo que el From no afecta en absoluto a la aceptación o no de una llamada
(excepto que el tfno tenga configurado desvios/rechazos si llama
alguien@dominio en concreto).
Es decir, si Asterisk hiciese lo que tiene que hacer (respetar el dominio del
llamante en vez de cambiarlo por su propia IP) no habría **ningún** problema.
Garantizado.
> - Cualquier puede enviar (sin autenticarse) correos a "gmail.com".
> - Pero si un usuario quiere enviar un correo a "gmail.com" desde el
> usuario "pe...@gmail.com" tendrá que autenticarse en el servidor de correo de
> Gmail.
Hummm... no necesariamente... Supuestamente el smtp recibe lo que
venga y como venga y lo pone en la casilla de correo del destinatario.
Ultimamente con el problema del spam se estan agregando más
restricciones pero no necesariamente esa.
De todas formas normalmente no se autentica el remitente así que
cualquiera puede falsificar direcciones de orígen.
> Pero es que insisto en que en Asterisk hacer ese spoofing es mucho más
> sencillo ya que Asterisk no muestra el dominio.
Algo así como hace Outlook ¿no?, bueno, outlook lo hace peor porque no
solo no muestra el dominio sino que no muestra nada de la dirección,
sólo el nombre.
> O sea, si tienes un Asterisk que permite entrantes SIP anónimas (hay que
> evolucionar decíamos, ¿no?), entonces si nos llama 203@dominio_externo.com y
> Asterisk hace un "Dial(SIP/150)" a un usuario local 150, le enviará en el
>
> Es decir, el llamado local 150 verá lo mismo en su teléfono o softphone!!!!
> Eso es Spoofing fácil fácil.
Si. Supuestamente deberías confiar en que el administrador del otro
lado hará bien su trabajo. Pero ocurre exactamente como con el mail:
uno nunca puede estar seguro de que un mensaje es de quien dice ser a
no ser que se use firma digital. Lo único que se acerca en el email a
solucionar eso son las domain-keys, pero requieren que cada servidor
de mail tenga una domain-key válida convirtiéndose en un problema
parecido al de los certificados del https.
> Y todavía peor: si 150 no respondió la llamada y consulta luego su lista de
> llamadas perdidas en el tfno, verá que le ha llamado:
> 203@IP_Asterisk
> y al devolverle la llamada resulta que llamará al usuario local 203 !!!
Probablemente la única solución a este problema sería considerar no
confiable a ninguna llamada proveniente de internet y parcharles el ID
con algo que indique que la llamada fue externa.
>
> - ¿Si?
> - Hola, que he visto que me has llamado pero estaba en el lavabo fumando.
> - ¿Yoooo? yo no te he llamado, ¿qué fumas?
> - ¡¡Oye, no empecemos que tengo aquí tu número registrado!!
> - Eso no me lo dices a la cara.
Si, exactamente lo mismo que pasa con el mail:
-me has mandado un virus
-¿yo? No puede ser, yo uso Linux
-pero a mi me salia que venia de tu cuenta
-<incluya aquí su explicación tan detallada como desee del
funcionamiento del smtp>
Bueno, yo creo que bastaría con verificarlo y si funciona todo parchar
un Asterisk para que funcine así. Si no da ningún problema el
siguiente paso sería proponer el cambio en la lista de desarrollo de
Asterisk. Si es una mejora no deberían tener ninguna objeción. Yo por
las dudas primero preguntaría en asterisk-dev a ver si saben por qué
se está haciendo así.
Ale que no ..!, yo tengo un cliente que tiene 3 centrales Asterisk
configuradas, cada central maneja su propio dialplan y se pueden llamar
directamente de extensión a extensión de una central a la otra y pueden
devolverse las llamadas SIN NINGUN problema.
> - Entorno SIP local.
> - Entrantes/salientes vía PSTN.
Falso, puede ser entrante/saliente solo por SIP o IAX, no necesitas la PSTN
para nada.
> - Tal vez salientes a PSTN vía proveedor SIP/IAX.
Obvio.
> - Usuarios "roadwarriors" SIP/IAX configurados como tales (tema NAT y tal).
> - En ningún caso comunicación alguna con proxies SIP ni otros entornos SIP
> (a parte de trunks).
¿De donde sacas esa conclusión?
> Cualquier otra cosa que intentes con Asterisk y SIP te defraudará.
> Mucho "Asterisk y VoIP" pero en realidad Asterisk está hecho para sustituir
> a las PBX locales y comunicarse con el mundo a través de la PSTN, para qué
> nos vamos a engañar.
Falso, Asterisk no solo sustituye a las PBX locales, asterisk es capaz de
comunicarse con otros "entornos sip" sin necesidad de pasar por la PSTN ni
por ningún otro proxy sip, puedes activar el soporte de resolución por
dominios y SRV y funcionará.
> No hay nada escondido, llámale "limitación".
Las tiene y muchas, lo primero es entender las capacidades de lo que se tiene
entre las manos.
> - OpenSer alojando el dominio SIP "midominio.org" y usuarios registrados en
> él (Asterisk sólo como PBX SIP).
> - 210@dominio_externo llama a in...@midominio.org.
> - La llamada llega obviamente a OpenSer quien ruta la llamada a Asterisk
> (el "From" sigue intacto, por supuesto).
Por supuesto no, por estandar, OpenSer es un proxy no un B2BUA
> - Asterisk ejecuta el dialplan y decide llamar a un usuario del dominio:
> Dial(SIP/1...@midominio.org)
> - La llamada vuelve a OpenSer quien en esta ocasión la ruta al usuario
> 1...@midominio.org.
> - Pero resulta que Asterisk ya ha metido la zarpa y ha cambiado el dominio
> del From y ha puesto:
> From: 210@IP_Asterisk
Claro, porque es un B2BUA, creo que tienes esa parte confundida, Asterisk NO
ES un proxy SIP, es un B2BUA y limitadito, cuando has hecho el Dial a
1...@midominio.org, Asterisk ha creado un nuevo dialogo sip completo
TOTALMENTE separado del diálogo entrante.
> - Así que el usuario local 1...@midominio.org sólo sabrá que le llama
> alguien con username 210, pero ni idea del dominio.
Yo sigo sin ver el problema, Asterisk se comporta como debe, QUIERE quedarse
en medio de la conversación SIP y COMO NO ES UN PROXY SIP, la única forma es
cargarla con la generación de una nueva llamada.
Saludos
> Bueno, yo creo que bastaría con verificarlo y si funciona todo parchar
> un Asterisk para que funcine así. Si no da ningún problema el
> siguiente paso sería proponer el cambio en la lista de desarrollo de
> Asterisk. Si es una mejora no deberían tener ninguna objeción. Yo por
> las dudas primero preguntaría en asterisk-dev a ver si saben por qué
> se está haciendo así.
Entonces te interesará este reporte:
http://bugs.digium.com/view.php?id=11322
Verás porqué estoy tan seguro de lo que digo ;)
Me das la razón: Hablas de intercomunicar islas SIP a través de trunks
SIP/IAX.
Por cierto, espero que en cada central Asterisk de esas 3 que dices tengas un
rango de extensiones diferente, porque si no a ver cómo sabe un tfno si el
200 que le llama es de su central o de las otras.
> > - Entorno SIP local.
> > - Entrantes/salientes vía PSTN.
>
> Falso, puede ser entrante/saliente solo por SIP o IAX, no necesitas la PSTN
> para nada.
Que ya sé que se puede, pero sólo tiene sentido permitir entrantes SIP/IAX
desde trunks, no desde cualquier usuario SIP del mundo (me remito al ejemplo
que he puesto antes sobre el From).
> > - Usuarios "roadwarriors" SIP/IAX configurados como tales (tema NAT y
> > tal). - En ningún caso comunicación alguna con proxies SIP ni otros
> > entornos SIP (a parte de trunks).
>
> ¿De donde sacas esa conclusión?
Hablo de diferentes dominios SIP. Asterisk hace aguas (me remito de nuevo a mi
ejemplo).
> > Cualquier otra cosa que intentes con Asterisk y SIP te defraudará.
> > Mucho "Asterisk y VoIP" pero en realidad Asterisk está hecho para
> > sustituir a las PBX locales y comunicarse con el mundo a través de la
> > PSTN, para qué nos vamos a engañar.
>
> Falso, Asterisk no solo sustituye a las PBX locales, asterisk es capaz de
> comunicarse con otros "entornos sip" sin necesidad de pasar por la PSTN ni
> por ningún otro proxy sip, puedes activar el soporte de resolución por
> dominios y SRV y funcionará.
Yo hago incapié en el problema de dominio en llamadas entrantes y tú me
explicas cómo hace las salientes SIP. Creo que no tiene mucho que ver.
Por cierto, ya que mencionas Asterisk y SRV tal vez tengas que echar un
vistazo al comentario que viene en sip.conf:
srvlookup=yes ; Enable DNS SRV lookups on outbound calls
; Note: Asterisk only uses the first host
; in SRV records
Ahí ahí, implementaciones SIP perfectas, vamos...
Todo el buen rollito del failover basado en DNS SRV se va a la porra si quien
llama es Asterisk.
> > No hay nada escondido, llámale "limitación".
>
> Las tiene y muchas, lo primero es entender las capacidades de lo que se
> tiene entre las manos.
Debe ser que no las entiendo XD
> > - OpenSer alojando el dominio SIP "midominio.org" y usuarios registrados
> > en él (Asterisk sólo como PBX SIP).
> > - 210@dominio_externo llama a in...@midominio.org.
> > - La llamada llega obviamente a OpenSer quien ruta la llamada a Asterisk
> > (el "From" sigue intacto, por supuesto).
>
> Por supuesto no, por estandar, OpenSer es un proxy no un B2BUA
Venía implícito en lo de "ruta la llamada" ;)
> > - Asterisk ejecuta el dialplan y decide llamar a un usuario del dominio:
> > Dial(SIP/1...@midominio.org)
> > - La llamada vuelve a OpenSer quien en esta ocasión la ruta al usuario
> > 1...@midominio.org.
> > - Pero resulta que Asterisk ya ha metido la zarpa y ha cambiado el
> > dominio del From y ha puesto:
> > From: 210@IP_Asterisk
>
> Claro, porque es un B2BUA, creo que tienes esa parte confundida, Asterisk
> NO ES un proxy SIP, es un B2BUA y limitadito, cuando has hecho el Dial a
> 1...@midominio.org, Asterisk ha creado un nuevo dialogo sip completo
> TOTALMENTE separado del diálogo entrante.
Y sin embargo **SI** que le muestra al llamado el username del llamante, ¿por
qué SOLO el username si resulta que en SIP un usuario se identifica por
username y dominio?
Si fuese como tú dices no tendría sentido tampoco mostrar el username del
llamante.
Por cierto, no creo estar tan equivocado cuando el propio Ollew me da la razón
(¿o acaso ese señor también está equivocado?):
http://bugs.digium.com/view.php?id=11322
"So this is not really a bug, but a flaw in the current asterisk design where
we can't handle the at sign (@) in a "number" so the domain is separated and
can't be set in the caller ID on outbound calls."
> > - Así que el usuario local 1...@midominio.org sólo sabrá que le llama
> > alguien con username 210, pero ni idea del dominio.
>
> Yo sigo sin ver el problema, Asterisk se comporta como debe, QUIERE
> quedarse en medio de la conversación SIP y COMO NO ES UN PROXY SIP, la
> única forma es cargarla con la generación de una nueva llamada.
Insisto, al crear un nuevo canal (que sí, que eso es lo que hace Asterisk =
B2BUA) no hay ninguna razón que implique esconder el From domain, ninguna. Y
si no, que se modifique también el From username, ¿no?
Ese From con dominio profanado no tiene *****ninguna****** razón de ser ni
utilidad alguna (bueno, sí, permitir spoofing a saco).
> Saludos
Saludos.
Dos apuntes para futuras refernecias:
> > Claro, porque es un B2BUA, creo que tienes esa parte confundida, Asterisk
> > NO ES un proxy SIP, es un B2BUA
Tengo muy claro lo que es un proxy SIP y lo que es un B2BUA (aunque trates de
insinuar que no lo sé en cada correo XD).
> Por cierto, no creo estar tan equivocado cuando el propio Ollew me da la
> razón (¿o acaso ese señor también está equivocado?):
...esto, quería decir Olle.
Bueno, lo que responden es que no es un bug... En definitiva dicen lo
mismo que yo: cuando no hay nadie entre medio que se asegure (más o
menos) de que los datos que llegan no son falsos (como puede ser una
compañía de teléfonos), lo que contenta el identificador no es para
nada confiable. No se debería usar en absoluto.
En definitva, cuando alguien te llama por SIP no hay manera de saber
quién es: hemos vuelto a los viejos tiempos en que no había caller-id.
Mientras no se mejore el protocolo para realizar algún tipo de
autenticación, yo opino que el identificador debería reescribirse con
algún aviso de que es una llamada externa, y el dominio realmente no
sirve de nada.
Pero si quieres hacer una llamada _desde_ tu dominio, tendrás que
autenticarte...
El 22/11/07, paco gil <pag...@gmail.com> escribió:
> lo que te quiero hacer ver es que si apostamos por sip, pues pretendemos dar
> nuestro pep...@midominio.com como telefono de contacto. Si alguien me llama
> y le pido que se autentique... qué pitorreo no?? Ahora bien, el hecho de
> que cualquiera me pueda mandar un invite con usuario y el dominio que le
> plazca debe ser controlado de alguno forma, tal y como hacen las compañias
> PSTN actuales.
>
> Se supone que alguien que llama desde la red de España (movil o fija) hacia
> otro usuario de la red de España, queda autenticado automaticamente por la
> confianza que hay entre carriers españoles (...que no de voicetrading,
> claro, jeje)
>
> si yo te llamo a iña...@in.ilimit.es, desde mi softphone, me vas a pedir
> contraseña???
>
> cosas así no las entienden aquellos a los que pretendemos convencer de las
> bondades de asterisk y la voip.
>
> saludos,
>
>
> On 11/22/07, Iñaki Baz Castillo <i...@in.ilimit.es> wrote:
> >
> > El Thursday 22 November 2007 15:13:02 pag...@gmail.com escribió:
> > > On 11/22/07, Iñaki Baz Castillo <i...@in.ilimit.es> wrote:
> > > > El Thursday 22 November 2007 14:57:40 pag...@gmail.com escribió:
> > > > > lo que yo digo es que si asterisk no actuase tal y como lo hace...
> > > > > como evitas que te manden cosas con tu propio dominio? k harias si
> te
> > > > > manda el 2...@tudiminio.com??
> > > >
> > > > Pedirle que se autentique, por supuesto.
> > >
> > > pero como le vas a pedir eso a un tio de la calle!!!!
> >
> > Pero bueno, si se está haciendo pasar por alguien de nuestro dominio claro
> que
> > le pedimos que se autentique, ¿¿no??
> > Si efectivamente "es de la calle" y se está inventando el dominio entonces
> no
> > podrá autenticarse. De eso se trata, ¿no?
> >
> >
> >
> > --
> > Iñaki Baz Castillo
> > i...@in.ilimit.es
> >
> >
>
>
> >
>
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
¿He nombrado yo trunking por algún sitio?, he dicho que se comunican, no que
tenga definidos trunking entre ellos.
> Por cierto, espero que en cada central Asterisk de esas 3 que dices tengas
> un rango de extensiones diferente, porque si no a ver cómo sabe un tfno si
> el 200 que le llama es de su central o de las otras.
Pues no, de hecho se solapan en muchos rangos, cuando un usuario de la central
A quiere llamar a uno de la B tiene 2 opciones:
a) A marca N*usuarioenB , donde N es un código de acceso para la entrada a
cada central, este método se emplea desde los teléfonos IP, donde solo se
tienen teclas numéricas.
b) A marca usuar...@centralB.dominio.tld desde un softphone o desde el
click2call del escritorio y luego habla con su terminal IP normal.
> Que ya sé que se puede, pero sólo tiene sentido permitir entrantes SIP/IAX
> desde trunks, no desde cualquier usuario SIP del mundo (me remito al
> ejemplo que he puesto antes sobre el From).
por ¿?, tu puedes aceptar llamadas libremente, otra cosa es como controlas la
seguridad de eso.
> Hablo de diferentes dominios SIP. Asterisk hace aguas (me remito de nuevo a
> mi ejemplo).
Ya, el "feature" de zamparse la parte del dominio remoto. Pero hay formas
de "esquivar" esa feature, aunque enrevesadas.
> > Falso, Asterisk no solo sustituye a las PBX locales, asterisk es capaz de
> > comunicarse con otros "entornos sip" sin necesidad de pasar por la PSTN
> > ni por ningún otro proxy sip, puedes activar el soporte de resolución por
> > dominios y SRV y funcionará.
>
> Yo hago incapié en el problema de dominio en llamadas entrantes y tú me
> explicas cómo hace las salientes SIP. Creo que no tiene mucho que ver.
Yo no me refería solo a salientes, sino también a entrantes.
> Por cierto, ya que mencionas Asterisk y SRV tal vez tengas que echar un
> vistazo al comentario que viene en sip.conf:
>
> srvlookup=yes ; Enable DNS SRV lookups on outbound calls
> ; Note: Asterisk only uses the first host
> ; in SRV records
>
> Ahí ahí, implementaciones SIP perfectas, vamos...
> Todo el buen rollito del failover basado en DNS SRV se va a la porra si
> quien llama es Asterisk.
Si otra maravillosa "feature" de la "gloriosa implementación" de SIP que tiene
Asterisk, menos mal que se está trabajando para mejorarla.
> Y sin embargo **SI** que le muestra al llamado el username del llamante,
> ¿por qué SOLO el username si resulta que en SIP un usuario se identifica
> por username y dominio?
Porque como dice Olle, es una "feature" .. XD
> Si fuese como tú dices no tendría sentido tampoco mostrar el username del
> llamante.
Si tiene sentido, porque aunque Asterisk no implementa correctamente esa parte
de la gestión de la llamada SIP, eso es "superable" a base de complicar un
poco (bastante) el dialplan.
> Por cierto, no creo estar tan equivocado cuando el propio Ollew me da la
> razón (¿o acaso ese señor también está equivocado?):
>
> http://bugs.digium.com/view.php?id=11322
>
> "So this is not really a bug, but a flaw in the current asterisk design
> where we can't handle the at sign (@) in a "number" so the domain is
> separated and can't be set in the caller ID on outbound calls."
Olle lo que ha hecho es admitir que la implementación original es una chapuza
y que solo "estaba pensada" para usar números como username, de ahí que en
una "emulación" de una PBX tradicional, les importase tres pitos y un caracol
los dominios y los username alfanuméricos.
> > > - Así que el usuario local 1...@midominio.org sólo sabrá que le llama
> > > alguien con username 210, pero ni idea del dominio.
> >
> > Yo sigo sin ver el problema, Asterisk se comporta como debe, QUIERE
> > quedarse en medio de la conversación SIP y COMO NO ES UN PROXY SIP, la
> > única forma es cargarla con la generación de una nueva llamada.
>
> Insisto, al crear un nuevo canal (que sí, que eso es lo que hace Asterisk =
> B2BUA) no hay ninguna razón que implique esconder el From domain, ninguna.
> Y si no, que se modifique también el From username, ¿no?
>
> Ese From con dominio profanado no tiene *****ninguna****** razón de ser ni
> utilidad alguna (bueno, sí, permitir spoofing a saco).
Pero puedes "corregir" ese comportamiento anómalo complicando un poco el
dialplan, de forma que en la parte del callerID que SI puedes modificar desde
el dialplan añadas "información" para poder devolver la llamada si el usuario
marca directamente esa dirección desde la lista de llamadas recibidas por
ejemplo.
Método 1 para corregir el comportamiento "featuriano" de Asterisk:
- Llamada entrando desde dominio externo
- Modificas el callerid, poniendolo de la siguiente manera:
cidname: "Externa: usu...@dominio.tld" ó el CID buscado en una BD o
cualquier otra cosa.
cidnumber: "usuario-dominio*tld@Asterisk_IP", solo puedes tocar la parte
antes de la @, así que juega con ello.
Luego cuando el usuario tuyo quiera contestar usando lo que tiene en la lista
de llamadas recibidas, solo has de realizar la tarea inversa, para obtener
del cidnumber la "ruta" a la que llamar.
Esto no evita el spoofing, pero te permite devolver las llamadas a esos
dominios externos.
Si podrán, ver mi respuesta al mail de Iñaki en este mismo hilo.
Por ahora malamente y haciendo ñapas gordas XD
> > Hablo de diferentes dominios SIP. Asterisk hace aguas (me remito de nuevo
> > a mi ejemplo).
>
> Ya, el "feature" de zamparse la parte del dominio remoto. Pero hay formas
> de "esquivar" esa feature, aunque enrevesadas.
¿Entonces quedamos en que sería chulo que se dignase a respetar el From,
no? ;)
> > Y sin embargo **SI** que le muestra al llamado el username del llamante,
> > ¿por qué SOLO el username si resulta que en SIP un usuario se identifica
> > por username y dominio?
>
> Porque como dice Olle, es una "feature" .. XD
>
> > Si fuese como tú dices no tendría sentido tampoco mostrar el username del
> > llamante.
>
> Si tiene sentido, porque aunque Asterisk no implementa correctamente esa
> parte de la gestión de la llamada SIP, eso es "superable" a base de
> complicar un poco (bastante) el dialplan.
Esto.... no, ese es como responder: "sí tiene sentido porque debido a la
limitación que tiene funciona así", venga, no te pases XDDD
> Olle lo que ha hecho es admitir que la implementación original es una
> chapuza y que solo "estaba pensada" para usar números como username, de ahí
> que en una "emulación" de una PBX tradicional, les importase tres pitos y
> un caracol los dominios y los username alfanuméricos.
Vamos acercando posturas ;)
> > Ese From con dominio profanado no tiene *****ninguna****** razón de ser
> > ni utilidad alguna (bueno, sí, permitir spoofing a saco).
>
> Pero puedes "corregir" ese comportamiento anómalo complicando un poco el
> dialplan, de forma que en la parte del callerID que SI puedes modificar
> desde el dialplan añadas "información" para poder devolver la llamada si el
> usuario marca directamente esa dirección desde la lista de llamadas
> recibidas por ejemplo.
>
> Método 1 para corregir el comportamiento "featuriano" de Asterisk:
>
> - Llamada entrando desde dominio externo
> - Modificas el callerid, poniendolo de la siguiente manera:
> cidname: "Externa: usu...@dominio.tld" ó el CID buscado en una BD o
> cualquier otra cosa.
> cidnumber: "usuario-dominio*tld@Asterisk_IP", solo puedes tocar la parte
> antes de la @, así que juega con ello.
>
> Luego cuando el usuario tuyo quiera contestar usando lo que tiene en la
> lista de llamadas recibidas, solo has de realizar la tarea inversa, para
> obtener del cidnumber la "ruta" a la que llamar.
>
> Esto no evita el spoofing, pero te permite devolver las llamadas a esos
> dominios externos.
Vale, que sí, que poder hacer se puede (aunque sabes también como yo que la
solución que das a pesar de ser la única es una aberración).
Mira que sería sencillo esto:
- Configurar los tnfos con outbound proxy su mismo Asterisk.
- Asterisk respeta el "From" entero al recibir una llamada desde dominio
externo.
- El tfno local ve la llamada perdida y la devuelve (llega a Asterisk por
estar como outbound proxy).
- Si Asterisk implementase numeraciones de la forma "username@dominio" (como
Olle pretende) ruta la llamada y a correr.
Pero claro, como Asterisk no respeta el dominio del "From" pues todo eso es
imposible.
Jeje, sería chulo que cumpliese el estandar en tantas cosas ... buff
> Vale, que sí, que poder hacer se puede (aunque sabes también como yo que la
> solución que das a pesar de ser la única es una aberración).
Ya, pero tocar el código de chan_sip me da mareos ..., así que es más simple
la ñapa en el dialplan, que además el usuario ni se entera.
> Mira que sería sencillo esto:
... "Imagine Asterisk does the right job with SIP .... " ... XDD
Bueno, ya está Olle para eso:
http://svn.digium.com/view/asterisk/trunk/include/asterisk/channel.h?view=log
XD
No, si lo de los mareos lo digo porque el código es pésimo, habría que empezar
desde 0 para hacer algo bien hecho.
Acabo de darle una mirada al freepbx. En el apartado de rutas
entrantes tiene para ponerle un prefijo al caller-id cuando la llamada
viene de esa ruta. Eso soluciona el peligro de que te engañen.
Pero dado que el dominio se puede falsificar fácilmente, no tiene
sentido filtrar por dominios. El único filtro válido sería por
direcciones IP pero estamos hablando de que queremos que cualquier
persona nos llame. Si no podemos confiar en el caller-id, simplemente
lo borramos o lo modificamos y listo.
No necesariamente: si en la pantalla del teléfono te sale que la
llamada viene de EXT-120 o en la pantalla te dice que viene desde
SIP-EXTERNO, no hay más problemas. De todas formas el identificador no
es para nada confiable así que no vale la pena mantenerlo.
> ¿Entonces quedamos en que sería chulo que se dignase a respetar el From,
> no? ;)
En mi opinión preferiría que lo hicieran pero de todas maneras no
serviría para nada porque igual no es confiable en absoluto. Cuando la
llamada es externa simplemente es una llamada anónima "hasta que se
pruebe lo contrario". Que sea el receptor el que pregunto "si, ¿con
quien hablo?" y se encargue de juzgar él si le dicen la verdad o no.
> - Configurar los tnfos con outbound proxy su mismo Asterisk.
>
> - Asterisk respeta el "From" entero al recibir una llamada desde dominio
> externo.
>
> - El tfno local ve la llamada perdida y la devuelve (llega a Asterisk por
> estar como outbound proxy).
Esto llevaría a la presunción de que los identificadores externos son
reales y la gente podría malacostumbrarse a confiar en ellos. Después
los llamarían con una dirección falsificada y... bueno, ya te
imaginarás.
Los identificadores de llamadas provenientes de canales no confiables
(como un sip externo) deberían modificarse o eliminarse.
Insisto en que permitir identificación por usuario y dominio no tiene que
conllevar necesariamente permitir entrantes públicas vía SIP. Se pueden
tener, por el motivo que sea, varios dominios SIP dentro de una empresa o lo
que sea (delegaciones, empresas asociadas, colectivos...) y todo regido por
el mismo sistema (luego seguro y confiable).
Saludos.
Eso es cierto. De todas maneras dentro de una empresa se suele rutear
las llamadas basándose en el número y no en el dominio. Lo más
práctico es asignar rangos diferenets a las distintas áreas o
sucursales o lo que sea, como por ejemplo 2xxx par auna y 3xxx para
otra, o usar prefijos que usan para seleccionar el destino al llamar y
se agregan automáticamente al número en llamadas entrantes. De esa
forma se hace transparente al usuario y no depende de textos que no se
pueden escribir en teléfonos normales.
El 26/11/07, Alejandro Vargas <alejan...@gmail.com> escribió: