29 Jan
2009
29 Jan
'09
2:51 p.m.
Hola gente:
Creo que este tema ya lo habia preguntado en su momento, y no recuerdo quien
me respondio que postee el Message que tengo y el Message que quiero... La
situacion es esta:
PBX <---> Kamailio <---> VoIP provider
El proveedor de VoIP no acepta paquetes SIP con direcciones IP invalidas en
el Head, por supuesto tengo el Kamailio con una IP publica (dada por el
proveedor).
La idea es que en una llamada saliente, al pasar por Kamailio, se modifique
el Head para que el proveedor reconozca el Message correctamente.
Record-Route: <sip:200.xx.xx.53;lr=on>
Via: sip/2.0/UDP 200.xx.xx.53;branch=ssdsdwewf.casqwq44.0
Via: sip/2.0/UDP 192.168.10.150:5060;branch=kchmvamydgcnwewqaq
Max-Forwards: 69
Necesito que el Message sea:
Record-Route: <sip:200.xx.xx.53;lr=on>
Via: sip/2.0/UDP 200.xx.xx.53:5060;branch=xxxxxxxxxx
Max-Forwards: 69
Resumiendo, que el Header solo envie la direccion del Kamailio y no del
Telefono que tiene detras.
Apreciare cualquier respuesta, gracias!
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p21727191.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
29 Jan
29 Jan
3:15 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El día 29 de enero de 2009 14:51, sadzas <sadzas(a)gmail.com> escribió:
El proveedor de VoIP no acepta paquetes SIP con
direcciones IP invalidas en
el Head, por supuesto tengo el Kamailio con una IP publica (dada por el
proveedor).
En tu otro correo te preguntamos muchas veces a qué llamas IP
inválidas. Por favor, refiérete a ellas como IP privadas o lo que
realmente sean, porque a mí la única IP inválida que se me ocurre es
ésta:
hola.que.tal.tio
XD
La idea es que en una llamada saliente, al pasar por
Kamailio, se modifique
el Head para que el proveedor reconozca el Message correctamente.
Record-Route: <sip:200.xx.xx.53;lr=on>
Via: sip/2.0/UDP 200.xx.xx.53;branch=ssdsdwewf.casqwq44.0
Via: sip/2.0/UDP 192.168.10.150:5060;branch=kchmvamydgcnwewqaq
Max-Forwards: 69
Necesito que el Message sea:
Record-Route: <sip:200.xx.xx.53;lr=on>
Via: sip/2.0/UDP 200.xx.xx.53:5060;branch=xxxxxxxxxx
Max-Forwards: 69
Resumiendo, que el Header solo envie la direccion del Kamailio y no del
Telefono que tiene detras.
Lo que pides *revienta* el protocolo SIP en su totalidad, lo siento
pero Kamailio no puede, ni debe, hacer esa bestialidad. No hay ninguna
cabecera "inválida" en ese request, y al proveedor NO le debería
importar, EN ABSOLUTO, que haya un segundo "Via" con la IP que sea.
En serio, ¿quién te ha dicho que esa IP es inválida? Me imagino que
has hablado con tu proveedor, y algún tipo que no tiene ni idea ha
mirado el INVITE y "deducido" que hay una IP inválida. No y no.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:33 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
2009/1/29 sadzas <sadzas(a)gmail.com>om>:
Hola gente:
Creo que este tema ya lo habia preguntado en su momento, y no recuerdo quien
me respondio que postee el Message que tengo y el Message que quiero... La
situacion es esta:
PBX <---> Kamailio <---> VoIP provider
El proveedor de VoIP no acepta paquetes SIP con direcciones IP invalidas en
el Head, por supuesto tengo el Kamailio con una IP publica (dada por el
proveedor).
Inválida significa privada?
Cuál es el motivo que el proveedor te ha dado?
La idea es que en una llamada saliente, al pasar por Kamailio, se modifique
el Head para que el proveedor reconozca el Message correctamente.
Record-Route: <sip:200.xx.xx.53;lr=on>
Via: sip/2.0/UDP 200.xx.xx.53;branch=ssdsdwewf.casqwq44.0
Via: sip/2.0/UDP 192.168.10.150:5060;branch=kchmvamydgcnwewqaq
Max-Forwards: 69
Necesito que el Message sea:
Record-Route: <sip:200.xx.xx.53;lr=on>
Via: sip/2.0/UDP 200.xx.xx.53:5060;branch=xxxxxxxxxx
Max-Forwards: 69
Resumiendo, que el Header solo envie la direccion del Kamailio y no del
Telefono que tiene detras.
Usa un B2BUA. Un proxy SIP no hace ni debe hacer esto.
Apreciare cualquier respuesta, gracias!
Te recomendaría buscar alguna implementación de THIG, algunos
operadores/service providers lo usan para hacer algo similar.
Sin embargo, según la argumentación que recibas del proveedor,
considera buscarte otro...
Saludos,
--
Victor Pascual Ávila
3:43 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Iñaki Baz Castillo wrote:
En tu otro correo te preguntamos muchas veces a qué llamas IP
inválidas. Por favor, refiérete a ellas como IP privadas o lo que
realmente sean, porque a mí la única IP inválida que se me ocurre es
ésta:
hola.que.tal.tio
XD
Muchas veces se les dice invalida a las IPs privadas. Si ustedes lo conocen
solo como Privadas, OK de ahora en adelante me referire a estas IPs como
privadas y ya.
Iñaki Baz Castillo wrote:
Lo que pides *revienta* el protocolo SIP en su totalidad, lo siento
pero Kamailio no puede, ni debe, hacer esa bestialidad. No hay ninguna
cabecera "inválida" en ese request, y al proveedor NO le debería
importar, EN ABSOLUTO, que haya un segundo "Via" con la IP que sea.
En serio, ¿quién te ha dicho que esa IP es inválida? Me imagino que
has hablado con tu proveedor, y algún tipo que no tiene ni idea ha
mirado el INVITE y "deducido" que hay una IP inválida. No y no.
Saludos.
El proveedor no acepta IPs privadas, eso es un hecho. Estuve mucho tiempo
tratando de hacer esto funcionar y solo lo logre con un proxy en el medio
(Brekeke) que es lo que esta funcionando en este momento y de donde saque el
Message correcto. Tal vez no haya especificado, pero supongo que lo habran
sabido al momento de ver el Message: Lo que les mostre ahi es el INVITE del
Proxy hacia el destino final. Voy a intentar explicar todo con el maximo
detalle:
El esquema es:
PBX <---> Proxy <---> VoIP provider
INVITE (PBX - Proxy)
Via: sip/2.0/UDP 192.168.2.1:5060;branch=xxxxxxxxxx
Max-Forwards: 70
Allow:
INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTITY,REFER,REGISTER,UPDATE
Supported: timer,replaces,100rel
From: ...
To: ...
Contact: ...
etc.
INVITE (Proxy - VoIP Provider)
Via: sip/2.0/UDP 200.xx.xx.53:5060;branch=xxxxxxxxxx ---> Lo cambio por la
IP del Kamailio
Max-Forwards: 70
Allow:
INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTITY,REFER,REGISTER,UPDATE
Supported: timer,replaces,100rel
From: ...
To: ...
Contact: ...
etc.
Esto no solo es posible y valido, sino que esta actualmente funcionando con
el proxy Brekeke. Espero haberme explicado correctamente.
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p21728150.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
3:49 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El día 29 de enero de 2009 15:43, sadzas <sadzas(a)gmail.com> escribió:
El proveedor no acepta IPs privadas, eso es un hecho.
No acepta IP's privadas ¿dónde? ¿podrías detallar qué error SIP
devuelve el proveedor cuando le llega el INVITE de Kamailio?
Estuve mucho tiempo
tratando de hacer esto funcionar y solo lo logre con un proxy en el medio
(Brekeke) que es lo que esta funcionando en este momento y de donde saque el
Message correcto.
Eso de "correcto" vamos a dejarlo....
Tal vez no haya especificado, pero supongo que lo
habran
sabido al momento de ver el Message: Lo que les mostre ahi es el INVITE del
Proxy hacia el destino final. Voy a intentar explicar todo con el maximo
detalle:
El esquema es:
PBX <---> Proxy <---> VoIP provider
INVITE (PBX - Proxy)
Via: sip/2.0/UDP 192.168.2.1:5060;branch=xxxxxxxxxx
Max-Forwards: 70
Allow:
INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTITY,REFER,REGISTER,UPDATE
Supported: timer,replaces,100rel
From: ...
To: ...
Contact: ...
etc.
INVITE (Proxy - VoIP Provider)
Via: sip/2.0/UDP 200.xx.xx.53:5060;branch=xxxxxxxxxx ---> Lo cambio por la
IP del Kamailio
Max-Forwards: 70
Allow:
INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTITY,REFER,REGISTER,UPDATE
Supported: timer,replaces,100rel
From: ...
To: ...
Contact: ...
etc.
Esto no solo es posible y valido, sino que esta actualmente funcionando con
el proxy Brekeke.
Lo siento pero no. Estás partiendo de la base de que "correcto"
significa "lo que funcionaba con el proxy Brokoli" y no es así. Si
lees la sección 16 del RFC 3261 verás que un proxy NO puede eliminar
una cabecera "Via" NUNCA. Lo que un proxy debe hacer es *añadir* su
propio Via y *respetar* los que ya había (puede añadirles ciertos
parámetros como el "received" y "rport" si procede).
Pero mientras sigas sin decirnos qué problema real tienes (a parte de
que el proveedor no permite Ip's privadas) no podemos ayudar mucho
más.
E insisto, NO puedes pedir a Kamailio que quite un Via, Kamailio es un
proxy y los proxies NO deben quitar cabeceras "Via". Esto sí que es lo
correcto.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:51 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Tambien pude apreciar que en el Message Body, Kamailio reenvia la IP original
que le llego a el. Lo que necesito es que la reenvie con la IP propia.
Ejemplo:
Message Body
Session Description Protocol
Owner/creator ...xx... : 192.168.2.1
En realidad, la IP privada deberia cambiar por la IP del Kamailio.
No se si me hago entender.
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p21728377.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
3:55 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El día 29 de enero de 2009 15:51, sadzas <sadzas(a)gmail.com> escribió:
Tambien pude apreciar que en el Message Body, Kamailio reenvia la IP original
que le llego a el. Lo que necesito es que la reenvie con la IP propia.
Ejemplo:
Message Body
Session Description Protocol
Owner/creator ...xx... : 192.168.2.1
En realidad, la IP privada deberia cambiar por la IP del Kamailio.
Espera, ¿quieres que en el SDP la IP que figure sea la de Kamailio? ¿y
cómo se supone que un proxy SIP va a manejar el RTP que reciba si
pones su IP en el SDP?
O tal vez te refieras a la línea "o" del SDP. Dicha línea incluye la
IP del originador y DA IGUAL que sea privada, lo que importa es la IP
de media. Para eso tendrás que usar RtpProxy o configurar tu Asterisk
con externip y en el router redirigir los puertos RTP al Asterisk y
todo eso.
PD: Sigues sin detallar el verdadero problema. "El proveedor no
permite IP inválida" no me dice nada a mí.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:58 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El día 29 de enero de 2009 15:51, sadzas <sadzas(a)gmail.com> escribió:
Tambien pude apreciar que en el Message Body, Kamailio
reenvia la IP original
que le llego a el. Lo que necesito es que la reenvie con la IP propia.
Ah, según leo dices que "pudiste apreciar", o sea, que nadie te ha
dicho nada al respecto, ni siquiera el proveedor, sino que son tus
propias conclusiones. Por suerte las cosas suelen funcionar como las
especificaciones dictan y no como alguien, sin leerlas, aprecia que
deberían funcionar.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:01 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Iñaki Baz Castillo wrote:
Vamos Iñaqui... con correcto me refiero a correcto PARA el VoIP provider.
Con respecto al problema real: Es solo ese, en cuanto el Proveedor ve una IP
privada en el SIP, lo descarta, lo toma como un mensaje no valido. Voy a
intentar pedir una captura del proveedor y postear una mia.
En cuanto a la eliminacion de los VIA (..sección 16 del RFC 3261..)... OK,
es algo que un proxy NO debe hacer...
ahora bien... es posible hacerlo con Kamailio? tan simple como eso.
en el proxy "brocoli" como lo bautizaste yo lo hago con el comando
"net.sip.via.multiple=false" tan simple como eso... tal vez aca no sea tan
facil, pero tal vez, SOLO TAL VEZ hay una forma.
De todos modos, A NO ENOJARSE POR FAVOR! que aca no estoy poniendo en tela
de juicio el conocimiento de nadie mas que el mio! OK? E Iñaqui, si de
alguna forma te molestan mis mensajes, te frustran o whatever, no los
respondas y ya, pero creeme que estoy preguntando con toda la humildad del
mundo!
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p21728559.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
Estuve mucho tiempo
tratando de hacer esto funcionar y solo lo logre con un proxy en el medio
(Brekeke) que es lo que esta funcionando en este momento y de donde saque
el
Message correcto.
Eso de "correcto" vamos a dejarlo....
4:10 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
2009/1/29 sadzas <sadzas(a)gmail.com>om>:
en el proxy "brocoli" como lo bautizaste
Y anda que no suena mejor así XDD
yo lo hago con el comando
"net.sip.via.multiple=false" tan simple como eso... tal vez aca no sea tan
facil, pero tal vez, SOLO TAL VEZ hay una forma.
Curioso que un proxy implemente opciones que revietan el RFC 3261, curioso.
De todos modos, A NO ENOJARSE POR FAVOR! que aca no
estoy poniendo en tela
de juicio el conocimiento de nadie mas que el mio! OK? E Iñaqui, si de
alguna forma te molestan mis mensajes, te frustran o whatever, no los
respondas y ya, pero creeme que estoy preguntando con toda la humildad del
mundo!
Que no, que no me enojo ni nada de eso ! :)
Es simplemente que no me acabas de dar la información que te pedimos y
sólo insistes en dar algunas apreciaciones erróneas una y otra vez.
Por eso intento insistir por mi parte en que no debes dar esas
apreciaciones por válidas, así nos será a todos más fácil buscar el
problema real.
Véte a saber, igual lo único que ocurre es que el proveedor SIP tiene
un comportamiento incorrecto! pero si lo que argumentas es que debes
quitar un "Via" para que el INVITE sea correcto... pues no avanzamos
;)
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:24 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Iñaki Baz Castillo wrote:
Ah, según leo dices que "pudiste apreciar", o sea, que nadie te ha
dicho nada al respecto, ni siquiera el proveedor, sino que son tus
propias conclusiones. Por suerte las cosas suelen funcionar como las
especificaciones dictan y no como alguien, sin leerlas, aprecia que
deberían funcionar.
No, por supuesto que esto no es una idea mia, sino que es un hecho del
proveedor. Averiguando un tiempo despues de contratarlo me entero que muchas
personas tienen el mismo inconveniente que yo, al realizar un trunk desde
una PBX (con IP privada) al proveedor, no pueden establecer llamadas
salientes, solo entrantes. (Lo mismo que me pasaba a mi)
Por que digo esto del SDP?? Porque revisando todas las capturas que hice,
poniendo un Asterisk de por medio, y luego un Cisco (con Nat traversal), el
INVITE llegaba al proveedor con la IP privada de la PBX, que es justamente
lo que me indico el proveedor que elimine de mis mensajes.
Lo logre con el brocoli (que de hecho, si, suena mejor que el nombre real),
pero el inconveniente es que no tengo licencia y es pago. Por eso quise
intentar con Kamailio.
Es realmente una lastima que no se puedan eliminar los VIA, o ¿tal vez si se
puede?
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p21728987.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
4:39 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
2009/1/29 sadzas <sadzas(a)gmail.com>om>:
No, por supuesto que esto no es una idea mia, sino que
es un hecho del
proveedor. Averiguando un tiempo despues de contratarlo me entero que muchas
personas tienen el mismo inconveniente que yo, al realizar un trunk desde
una PBX (con IP privada) al proveedor, no pueden establecer llamadas
salientes, solo entrantes. (Lo mismo que me pasaba a mi)
Por que digo esto del SDP?? Porque revisando todas las capturas que hice,
poniendo un Asterisk de por medio, y luego un Cisco (con Nat traversal), el
INVITE llegaba al proveedor con la IP privada de la PBX, que es justamente
lo que me indico el proveedor que elimine de mis mensajes.
Si tu proveedor te ha dicho que no puede llegar ese segundo Via
entonces cambia de proveedor.
Lo logre con el brocoli (que de hecho, si, suena mejor
que el nombre real),
pero el inconveniente es que no tengo licencia y es pago. Por eso quise
intentar con Kamailio.
Es realmente una lastima que no se puedan eliminar los VIA, o ¿tal vez si se
puede?
Imposible, o tal vez se pueda hacer con la función de eliminar
cabeceras, pero los Via los administra Kamailio internamente, así que
igual no te funciona.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:47 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Iñaki Baz Castillo wrote:
Si tu proveedor te ha dicho que no puede llegar ese segundo Via
entonces cambia de proveedor.
Cambiar de proveedor a esta altura no es una posibilidad...
Iñaki Baz Castillo wrote:
Imposible, o tal vez se pueda hacer con la función de eliminar
cabeceras, pero los Via los administra Kamailio internamente, así que
igual no te funciona.
Una lastima, lei tarde tu post e hice una pregunta en el foro de open ser,
seguro se van a reir de mi como vos... XD
gracias Iñaqui!
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p21729475.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
5:35 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El Jueves, 29 de Enero de 2009 14:43, sadzas escribió:
INVITE (Proxy - VoIP Provider)
Via: sip/2.0/UDP 200.xx.xx.53:5060;branch=xxxxxxxxxx ---> Lo cambio por la
IP del Kamailio
Max-Forwards: 70
Allow:
INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTITY,REFER,REGISTER,UP
DATE Supported: timer,replaces,100rel
From: ...
To: ...
Contact: ...
etc.
Esto no solo es posible y valido, sino que esta actualmente funcionando con
el proxy Brekeke. Espero haberme explicado correctamente.
Lo que hace el brokoli ese no es de proxy, es de B2BUA, que no es lo mismo, ni
parecido.
--
Raúl Alexis Betancor Santana
Dimensión Virtual
5:40 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El Jueves, 29 de Enero de 2009 15:24, sadzas escribió:
No, por supuesto que esto no es una idea mia, sino que
es un hecho del
proveedor. Averiguando un tiempo despues de contratarlo me entero que
muchas personas tienen el mismo inconveniente que yo, al realizar un trunk
desde una PBX (con IP privada) al proveedor, no pueden establecer llamadas
salientes, solo entrantes. (Lo mismo que me pasaba a mi)
Si el proveedor solo soporta clientes que manden el Media y la Señalización
desde una IP pública, es una mierda de proveedor, eso para empezar.
Por que digo esto del SDP?? Porque revisando todas las
capturas que hice,
poniendo un Asterisk de por medio, y luego un Cisco (con Nat traversal), el
INVITE llegaba al proveedor con la IP privada de la PBX, que es justamente
lo que me indico el proveedor que elimine de mis mensajes.
Lo logre con el brocoli (que de hecho, si, suena mejor que el nombre real),
pero el inconveniente es que no tengo licencia y es pago. Por eso quise
intentar con Kamailio.
Es realmente una lastima que no se puedan eliminar los VIA, o ¿tal vez si
se puede?
Deberías de intentar hacer una capturas completas, de lo que mandas y recibes,
a nivel SIP y pegarlas.
Estoy seguro al 200% que llegaremos a la conclusión de que es un problema de
NAT ... (creo que ya te lo dije hace tiempo en el otro hilo).
Saludos
--
Raúl Alexis Betancor Santana
Dimensión Virtual
5:55 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Raúl Alexis Betancor Santana wrote:
Si el proveedor solo soporta clientes que manden el Media y la
Señalización
desde una IP pública, es una mierda de proveedor, eso para empezar.
Si, no te lo discuto...
Raúl Alexis Betancor Santana wrote:
Deberías de intentar hacer una capturas completas, de lo que mandas y
recibes,
a nivel SIP y pegarlas.
Estoy seguro al 200% que llegaremos a la conclusión de que es un problema
de
NAT ... (creo que ya te lo dije hace tiempo en el otro hilo).
Si, esto ya lo habiamos conversado. Y repito lo que dije en su momento. No
es tema de NAT, ya que el NAT no administra los mensajes SIP y el proveedor
discrimina el SIP. De hecho, lo probe con diferentes routers con diferentes
IOS. Cisco tiene IOS especialmente para esto, pero asi y todo no funciono.
Por lo que pude ver, el proveedor (IPLAN es el nombre) me rechaza todos los
paquetes SIP que le caen con una IP privada. ¿Como es esto?
El proveedor esta configurado para recibir trafico de una sola IP, que debe
ser publica. Por lo que pude hablar con el soporte del mismo, cuando recibe
la IP privada en el HEAD del SIP Message, lo rechaza, por ser trafico
invalido.
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p21730947.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
6:11 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El día 29 de enero de 2009 17:55, sadzas <sadzas(a)gmail.com> escribió:
Si, esto ya lo habiamos conversado. Y repito lo que
dije en su momento. No
es tema de NAT, ya que el NAT no administra los mensajes SIP y el proveedor
discrimina el SIP.
¿Puedes especificar a qué te refieres con esta frase?
De hecho, lo probe con diferentes routers con
diferentes
IOS. Cisco tiene IOS especialmente para esto, pero asi y todo no funciono.
Sí, routers con ALG, una auténtica maravilla que estropea el SIP
totalmente. Lo raro es que hasta funcione de vez en cuando.
Por lo que pude ver, el proveedor (IPLAN es el nombre)
me rechaza todos los
paquetes SIP que le caen con una IP privada. ¿Como es esto?
¿Con la IP privada *dónde*?
El proveedor esta configurado para recibir trafico de
una sola IP, que debe
ser publica. Por lo que pude hablar con el soporte del mismo, cuando recibe
la IP privada en el HEAD del SIP Message, lo rechaza, por ser trafico
invalido.
No te creas absolutamente nada de lo que te dice el servicio técnico
de ese proveedor. En cuanto ven una Ip privada en *cualquier sitio* se
les ilumina el cerebro y engañan diciendo que "esa es la causa" (sin
tener ni idea). He oído auténticas tonterías a muchos proveedores para
justificar que "la culpa la tiene el cliente".
De todas formas, hasta que no nos pegues unas capturas de un INVITE
que tu Kamailio envía al proveedor no podremos saber mucho más. Y esta
captura la puedes hacer tú, no dependes del proveedor (usa ngrep).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
6:17 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Iñaki Baz Castillo wrote:
No te creas absolutamente nada de lo que te dice el servicio técnico
de ese proveedor. En cuanto ven una Ip privada en *cualquier sitio* se
les ilumina el cerebro y engañan diciendo que "esa es la causa" (sin
tener ni idea). He oído auténticas tonterías a muchos proveedores para
justificar que "la culpa la tiene el cliente".
De todas formas, hasta que no nos pegues unas capturas de un INVITE
que tu Kamailio envía al proveedor no podremos saber mucho más. Y esta
captura la puedes hacer tú, no dependes del proveedor (usa ngrep).
Ok Iñaqui, voy a hacer eso mismo y vuelvo con la captura.
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p21731374.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
7:21 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El Jueves, 29 de Enero de 2009 16:55, sadzas escribió:
Si, esto ya lo habiamos conversado. Y repito lo que
dije en su momento. No
es tema de NAT, ya que el NAT no administra los mensajes SIP y el proveedor
discrimina el SIP. De hecho, lo probe con diferentes routers con diferentes
IOS. Cisco tiene IOS especialmente para esto, pero asi y todo no funciono.
Burffff .. necesito un traductor para esta frase. ...
Parafraseando una estrofa de una canción de Enigma ...
"Believe me .. it's a NAT problem, you will see the light..."
Por lo que pude ver, el proveedor (IPLAN es el nombre)
me rechaza todos los
paquetes SIP que le caen con una IP privada. ¿Como es esto?
Porque son unos chapuceros, aunque insisto en que es probable al 200% que
simplemente tengas mal configurado el asterisk y el router de turno.
El proveedor esta configurado para recibir trafico de
una sola IP, que debe
ser publica.
Eso es porque te facturan en función de la IP origen, normal, que la IP tiene
que ser pública, normal también, porque de redes privadas jamás les llegaría
el tráfico.
Pero que porque aparezca una IP privada en alguna parte del mensaje SIP,
rechacen el tráfico ... va a ser que no.
Por lo que pude hablar con el soporte del mismo,
cuando recibe
la IP privada en el HEAD del SIP Message, lo rechaza, por ser trafico
invalido.
Haznos un favor a todos y haz una bendita captura con el ngrep, que te lo
venimos pidiendo desde el primer día.
Captura de lo que envías y lo que te responden, por favor ... es muy simple.
--
Raúl Alexis Betancor Santana
Dimensión Virtual
2 Feb
2 Feb
7:04 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
1ro - Que paciencia la de todos ustedes con este tema
2do - De acuerdo en que los de soporte de los proveedores muchas veces ni
sabe como funcionan las cosas al interior de su red. Tengo una línea SIP que
no me deja registrar nada con ellos sino solo le softphone que ellos dan por
que tiene una negociación de credenciales especial que solo el proveedor le
envía ese softphone, y llamo al servicio técnico y ellos ni sabían que era
un invite o un username o password, entonces!!! No hay que confiarse de las
justificaciones que den en el soporte técnico. Lo de las credenciales lo se
por que mi asesor de tesis es el encargado de la telefonía IP de este
proveedor y me explico lo que hacían ellos realmente, sino todavía seguiría
tratando de registrar mi asterisk con ellos.
3ro - Según el RFC3323 sección 5.1 dice "Privacy services operating on
requests SHOULD remove all Via headers that have been added to the request
prior to its arrival at the privacy service (a practice referred to as "Via
stripping") and then SHOULD add a single Via header representing
themselves." Lo que quiere decir que los SIP Proxy Servers, si deberían
poder quitar encabezados Via y remplazarlos por otro que ellos mismo pongan.
Es por esto que propuse en la lista en ingles que seria bueno tener un
modulo o algoritmo para usar en Kamailio que facilite la implementación de
estos RFC (3323,3324,3325) pues no es tan sencillo hacer todo lo que en
ellos se especifica, creo yo. Conclusión, un SIP Proxy si debería poder
remover y cambiar los encabezados Via. Aunque estoy de acuerdo en que esa no
es la raíz del problema de nuestro amigo "sadzas". Hay que adjuntar la traza
SIP para poder saber la causa del problema, el proveedor no debería mirar
los otros Via que hayan en el mensaje SIP sino tan solo el ultimo, que es el
que tiene la IP publica "valida" para el.
David Céspedes
-----Mensaje original-----
De: users-es-bounces(a)lists.kamailio.org
[mailto:users-es-bounces@lists.kamailio.org] En nombre de Raúl Alexis
Betancor Santana
Enviado el: Jueves, 29 de Enero de 2009 01:22 p.m.
Para: Lista de usuarios de Kamailio
Asunto: Re: [Kamailio-Users-ES] Modificar Headers
El Jueves, 29 de Enero de 2009 16:55, sadzas escribió:
Si, esto ya lo habiamos conversado. Y repito lo que
dije en su momento. No
es tema de NAT, ya que el NAT no administra los mensajes SIP y el
proveedor
discrimina el SIP. De hecho, lo probe con diferentes
routers con
diferentes
IOS. Cisco tiene IOS especialmente para esto, pero asi
y todo no funciono.
Burffff .. necesito un traductor para esta frase. ...
Parafraseando una estrofa de una canción de Enigma ...
"Believe me .. it's a NAT problem, you will see the light..."
Por lo que pude ver, el proveedor (IPLAN es el nombre)
me rechaza todos
los
paquetes SIP que le caen con una IP privada. ¿Como es
esto?
Porque son unos chapuceros, aunque insisto en que es probable al 200% que
simplemente tengas mal configurado el asterisk y el router de turno.
El proveedor esta configurado para recibir trafico de
una sola IP, que
debe
ser publica.
Eso es porque te facturan en función de la IP origen, normal, que la IP
tiene
que ser pública, normal también, porque de redes privadas jamás les llegaría
el tráfico.
Pero que porque aparezca una IP privada en alguna parte del mensaje SIP,
rechacen el tráfico ... va a ser que no.
Por lo que pude hablar con el soporte del mismo,
cuando recibe
la IP privada en el HEAD del SIP Message, lo rechaza, por ser trafico
invalido.
Haznos un favor a todos y haz una bendita captura con el ngrep, que te lo
venimos pidiendo desde el primer día.
Captura de lo que envías y lo que te responden, por favor ... es muy simple.
--
Raúl Alexis Betancor Santana
Dimensión Virtual
_______________________________________________
Users-es mailing list
Users-es(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es
5 Feb
5 Feb
6:08 a.m.
New subject: [Kamailio-Users-ES] Modificar Headers
No dijeron nada de lo del RFC 3323 sección 5.1 donde dice que un Proxy si
puede remover los encabezados "Via:"!!!. Alguien lo ha hecho?, por que
cuando hable en la lista de ingles de crear un modulo para poder cumplir con
estos 3 RFC (3323, 3324, 3325) los que respondieron dijeron que los habían
implementado ellos mismos en el Kamailio.cfg sin necesidad de nada más.
-----Mensaje original-----
De: users-es-bounces(a)lists.kamailio.org
[mailto:users-es-bounces@lists.kamailio.org] En nombre de David A Céspedes
Enviado el: Lunes, 02 de Febrero de 2009 01:04 p.m.
Para: 'Lista de usuarios de Kamailio'
Asunto: Re: [Kamailio-Users-ES] Modificar Headers
1ro - Que paciencia la de todos ustedes con este tema
2do - De acuerdo en que los de soporte de los proveedores muchas veces ni
sabe como funcionan las cosas al interior de su red. Tengo una línea SIP que
no me deja registrar nada con ellos sino solo le softphone que ellos dan por
que tiene una negociación de credenciales especial que solo el proveedor le
envía ese softphone, y llamo al servicio técnico y ellos ni sabían que era
un invite o un username o password, entonces!!! No hay que confiarse de las
justificaciones que den en el soporte técnico. Lo de las credenciales lo se
por que mi asesor de tesis es el encargado de la telefonía IP de este
proveedor y me explico lo que hacían ellos realmente, sino todavía seguiría
tratando de registrar mi asterisk con ellos.
3ro - Según el RFC3323 sección 5.1 dice "Privacy services operating on
requests SHOULD remove all Via headers that have been added to the request
prior to its arrival at the privacy service (a practice referred to as "Via
stripping") and then SHOULD add a single Via header representing
themselves." Lo que quiere decir que los SIP Proxy Servers, si deberían
poder quitar encabezados Via y remplazarlos por otro que ellos mismo pongan.
Es por esto que propuse en la lista en ingles que seria bueno tener un
modulo o algoritmo para usar en Kamailio que facilite la implementación de
estos RFC (3323,3324,3325) pues no es tan sencillo hacer todo lo que en
ellos se especifica, creo yo. Conclusión, un SIP Proxy si debería poder
remover y cambiar los encabezados Via. Aunque estoy de acuerdo en que esa no
es la raíz del problema de nuestro amigo "sadzas". Hay que adjuntar la traza
SIP para poder saber la causa del problema, el proveedor no debería mirar
los otros Via que hayan en el mensaje SIP sino tan solo el ultimo, que es el
que tiene la IP publica "valida" para el.
David Céspedes
-----Mensaje original-----
De: users-es-bounces(a)lists.kamailio.org
[mailto:users-es-bounces@lists.kamailio.org] En nombre de Raúl Alexis
Betancor Santana
Enviado el: Jueves, 29 de Enero de 2009 01:22 p.m.
Para: Lista de usuarios de Kamailio
Asunto: Re: [Kamailio-Users-ES] Modificar Headers
El Jueves, 29 de Enero de 2009 16:55, sadzas escribió:
Si, esto ya lo habiamos conversado. Y repito lo que
dije en su momento. No
es tema de NAT, ya que el NAT no administra los mensajes SIP y el
proveedor
discrimina el SIP. De hecho, lo probe con diferentes
routers con
diferentes
IOS. Cisco tiene IOS especialmente para esto, pero asi
y todo no funciono.
Burffff .. necesito un traductor para esta frase. ...
Parafraseando una estrofa de una canción de Enigma ...
"Believe me .. it's a NAT problem, you will see the light..."
Por lo que pude ver, el proveedor (IPLAN es el nombre)
me rechaza todos
los
paquetes SIP que le caen con una IP privada. ¿Como es
esto?
Porque son unos chapuceros, aunque insisto en que es probable al 200% que
simplemente tengas mal configurado el asterisk y el router de turno.
El proveedor esta configurado para recibir trafico de
una sola IP, que
debe
ser publica.
Eso es porque te facturan en función de la IP origen, normal, que la IP
tiene
que ser pública, normal también, porque de redes privadas jamás les llegaría
el tráfico.
Pero que porque aparezca una IP privada en alguna parte del mensaje SIP,
rechacen el tráfico ... va a ser que no.
Por lo que pude hablar con el soporte del mismo,
cuando recibe
la IP privada en el HEAD del SIP Message, lo rechaza, por ser trafico
invalido.
Haznos un favor a todos y haz una bendita captura con el ngrep, que te lo
venimos pidiendo desde el primer día.
Captura de lo que envías y lo que te responden, por favor ... es muy simple.
--
Raúl Alexis Betancor Santana
Dimensión Virtual
_______________________________________________
Users-es mailing list
Users-es(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es
_______________________________________________
Users-es mailing list
Users-es(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es
9:38 a.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El día 5 de febrero de 2009 6:08, David A Céspedes
<ingdavidcespedes(a)cable.net.co> escribió:
No dijeron nada de lo del RFC 3323 sección 5.1 donde
dice que un Proxy si
puede remover los encabezados "Via:"!!!. Alguien lo ha hecho?, por que
cuando hable en la lista de ingles de crear un modulo para poder cumplir con
estos 3 RFC (3323, 3324, 3325) los que respondieron dijeron que los habían
implementado ellos mismos en el Kamailio.cfg sin necesidad de nada más.
David, el problema de base no es ese (aunque sadzas,
inexplicablemente, esté convencido de ello sin motivo). El hecho de
que el INVITE que llega a su proveedor tenga un segundo Via con IP
privada no es la causa de su problema. Lo que tiene es un problema de
NAT como una casa.
Dentro de 4 meses, cuando nos envíe alguna captura SIP, quedará todo aclarado.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:13 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Totalmente de acuerdo que el problema no es ese. Pero definitivamente un SIP
Proxy si debería poder cambiar los encabezados "Via:" ¿o no?
-----Mensaje original-----
De: users-es-bounces(a)lists.kamailio.org
[mailto:users-es-bounces@lists.kamailio.org] En nombre de Iñaki Baz Castillo
Enviado el: Jueves, 05 de Febrero de 2009 03:39 a.m.
Para: Lista de usuarios de Kamailio
Asunto: Re: [Kamailio-Users-ES] Modificar Headers
El día 5 de febrero de 2009 6:08, David A Céspedes
<ingdavidcespedes(a)cable.net.co> escribió:
No dijeron nada de lo del RFC 3323 sección 5.1 donde
dice que un Proxy si
puede remover los encabezados "Via:"!!!. Alguien lo ha hecho?, por que
cuando hable en la lista de ingles de crear un modulo para poder cumplir
con
estos 3 RFC (3323, 3324, 3325) los que respondieron
dijeron que los habían
implementado ellos mismos en el Kamailio.cfg sin necesidad de nada más.
David, el problema de base no es ese (aunque sadzas,
inexplicablemente, esté convencido de ello sin motivo). El hecho de
que el INVITE que llega a su proveedor tenga un segundo Via con IP
privada no es la causa de su problema. Lo que tiene es un problema de
NAT como una casa.
Dentro de 4 meses, cuando nos envíe alguna captura SIP, quedará todo
aclarado.
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Users-es mailing list
Users-es(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es
3:34 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El día 5 de febrero de 2009 15:13, David A Céspedes
<ingdavidcespedes(a)cable.net.co> escribió:
Totalmente de acuerdo que el problema no es ese. Pero
definitivamente un SIP
Proxy si debería poder cambiar los encabezados "Via:" ¿o no?
Pues no. Si lees todo el párrafo del RFC 3323 que antes mencionabas
verás que al principio dice:
-------------------------
5.1 Header Privacy
If a privacy level of 'header' is requested, then the originating
user has asked the privacy service to help to obscure headers that
might otherwise reveal information about the originator of the
request. However, the values that have been so obscured must be
recoverable when further messages in the dialog need to be routed to
the originating user agent. In order to provide these functions the
privacy service must frequently act as a transparent back-to-back
user agent *********(B2BUA)**********.
[...]
Privacy services operating on requests SHOULD remove all Via headers
that have been added to the request prior to its arrival at the
privacy service
-------------------------
Así que habla de un *B2BUA* y no de un proxy. El RFC 3261 dice bien
claro que un proxy NO puede quitar cabeceras Via. Además, es que no
tiene sentido quitar un Via ya que entonces ¿cómo sabrá el proxy a
dónde rutar las respuestas?
Definitivamente un proxy NO puede quitar cabeceras Via, va contra lo
más core del RFC 3261 :)
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:44 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Mmmmmm, pero según la sección 5
-------------------------
"This document defines a new SIP logical role called a "privacy
service". The privacy service role is instantiated by a network
intermediary, frequently by entities that can act as SIP proxy
servers. The function of a privacy service is to supply privacy
functions for SIP messages that cannot be provided by user agents
themselves."
-------------------------
Sera una contradicción en el RFC???? Pues dice que los servicios de
privacidad deben ser prestados por entidades que actúen como SIP Proxy
servers. Entonces como seria???
-Si el UA pide cualquier otro tipo de privacidad que no sea "Header" esta
debe ser implementada por el SIP Proxy
-Pero si la privacidad solicitada es de tipo "Header", entonces debe ser un
B2BUA quien se encargue de quitar los Via: que revelen información del
usuario que origina el mensaje y poner uno nuevo que relacionará la llamada
actual para manejar adecuadamente las respuesta que se originen,
relacionadas con este dialogo?.
-O debe ser un SIP proxy que en algunos casos actúe como B2BUA (como ya lo
hace Kamailio para algunas cosas)
-O un B2BUA que actúe a veces como SIP proxy.
La verdad me parece un poco complicado la implementación de estos RFC. No se
que piensen ustedes.
Saludos
David Céspedes
-----Mensaje original-----
De: users-es-bounces(a)lists.kamailio.org
[mailto:users-es-bounces@lists.kamailio.org] En nombre de Iñaki Baz Castillo
Enviado el: Jueves, 05 de Febrero de 2009 09:34 a.m.
Para: Lista de usuarios de Kamailio
Asunto: Re: [Kamailio-Users-ES] Modificar Headers
El día 5 de febrero de 2009 15:13, David A Céspedes
<ingdavidcespedes(a)cable.net.co> escribió:
Totalmente de acuerdo que el problema no es ese. Pero
definitivamente un
SIP
Proxy si debería poder cambiar los encabezados
"Via:" ¿o no?
Pues no. Si lees todo el párrafo del RFC 3323 que antes mencionabas
verás que al principio dice:
-------------------------
5.1 Header Privacy
If a privacy level of 'header' is requested, then the originating
user has asked the privacy service to help to obscure headers that
might otherwise reveal information about the originator of the
request. However, the values that have been so obscured must be
recoverable when further messages in the dialog need to be routed to
the originating user agent. In order to provide these functions the
privacy service must frequently act as a transparent back-to-back
user agent *********(B2BUA)**********.
[...]
Privacy services operating on requests SHOULD remove all Via headers
that have been added to the request prior to its arrival at the
privacy service
-------------------------
Así que habla de un *B2BUA* y no de un proxy. El RFC 3261 dice bien
claro que un proxy NO puede quitar cabeceras Via. Además, es que no
tiene sentido quitar un Via ya que entonces ¿cómo sabrá el proxy a
dónde rutar las respuestas?
Definitivamente un proxy NO puede quitar cabeceras Via, va contra lo
más core del RFC 3261 :)
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Users-es mailing list
Users-es(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users-es
4:55 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El día 5 de febrero de 2009 16:44, David A Céspedes
<ingdavidcespedes(a)cable.net.co> escribió:
-O debe ser un SIP proxy que en algunos casos actúe
como B2BUA (como ya lo
hace Kamailio para algunas cosas)
-O un B2BUA que actúe a veces como SIP proxy.
Ten en cuenta que los B2BUA no están definidos, no encontrarás ningún
estándar que hable de ellos. Sencillamente son un UAS donde acaba un
diálogo SIP y un UAC donde empieza otro, y punto. el grado de
transparencia que cada "vendor" le aplique es el que él quiera por los
motivos que él quiera, sin requerimientos basados en estándares.
Así que mas o menos es lo que tú dices: una "cosa" SIP que a veces
hace de proxy y otras de B2BUA bastante transparente, según la
necesidad. No intentes ceñir esto a ningún RFC ni especificación, pues
como te digo los B2BUA son "libres" de especificaciones.
PD: Kamailio no hace de B2BUA en ningún caso. Tiene ahora alguna
función avanzada para generar requests (hacer de UAC) pero como B2BUA
no actúa nunca, ¿a qué te refieres exactamente?
La verdad me parece un poco complicado la
implementación de estos RFC. No se
que piensen ustedes.
No es más qu eun RFC feliz como tantos otros, yo me lo tomaría como
una simple recomendación para que un proveedor pueda ofrecer esos
servicios de privacidad (también puede hacer lo que le dé la real
gana, igualmente).
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:47 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
PD: Kamailio no hace de B2BUA en ningún caso. Tiene ahora alguna
función avanzada para generar requests (hacer de UAC) pero como B2BUA
no actúa nunca, ¿a qué te refieres exactamente?
Leí un comentario tuyo que decía "How! This is becoming a B2BUA XD"
precisamente en lo de generar request, y estoy de acuerdo, con respecto a
todos los nuevos módulos y funciones que se están desarrollando en la
versión 1.5.
La verdad me parece un poco complicado la
implementación de estos RFC. No
se
que piensen ustedes.
No es más qu eun RFC feliz como tantos otros, yo me lo tomaría como
una simple recomendación para que un proveedor pueda ofrecer esos
servicios de privacidad (también puede hacer lo que le dé la real
gana, igualmente).
Lo digo por que como ya he comentado, mi tesis de grado la hice basado en la
recomendación técnica de SIPconnect, donde estos RFC son de obligatorio
cumplimiento, pero no los implemente en mi escenario de pruebas; primero por
falta de tiempo y segundo por que la verdad me pareció complicado cubrir
todas las diferentes posibilidades que ellos implican. Pienso que si un
usuario llega a pedir servicios de privacidad a su proxy o cualquier
intermediario que lo deba o pueda prestar, esto será un gran lio. Igual ya
entregue mi trabajo de grado, estoy esperando solo la sustentación. Pero
quede con la espinita de poder crear el algoritmo de implementación de estos
RFC que comprenda todos los posibles casos que se pueden presentar.
David Céspedes
5:57 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El día 5 de febrero de 2009 17:47, David A Céspedes
<ingdavidcespedes(a)cable.net.co> escribió:
PD: Kamailio no hace de B2BUA en ningún caso. Tiene
ahora alguna
función avanzada para generar requests (hacer de UAC) pero como B2BUA
no actúa nunca, ¿a qué te refieres exactamente?
Leí un comentario tuyo que decía "How! This is becoming a B2BUA XD"
precisamente en lo de generar request, y estoy de acuerdo, con respecto a
todos los nuevos módulos y funciones que se están desarrollando en la
versión 1.5.
Sí, cierto :)
Pero era un poco irónico. No era un B2BUa realmente, pero empieza a parecerlo XD
Lo digo por que como ya he comentado, mi tesis de
grado la hice basado en la
recomendación técnica de SIPconnect, donde estos RFC son de obligatorio
cumplimiento, pero no los implemente en mi escenario de pruebas; primero por
falta de tiempo y segundo por que la verdad me pareció complicado cubrir
todas las diferentes posibilidades que ellos implican. Pienso que si un
usuario llega a pedir servicios de privacidad a su proxy o cualquier
intermediario que lo deba o pueda prestar, esto será un gran lio. Igual ya
entregue mi trabajo de grado, estoy esperando solo la sustentación. Pero
quede con la espinita de poder crear el algoritmo de implementación de estos
RFC que comprenda todos los posibles casos que se pueden presentar.
Usaste WeSIP para implementar esos algoritmos, ¿verdad? (curiosidad).
Si es así, ¿qué tal la experiencia?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
7 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Lo digo por que como ya he comentado, mi tesis de
grado la hice basado en
la
recomendación técnica de SIPconnect, donde estos RFC
son de obligatorio
cumplimiento, pero no los implemente en mi escenario de pruebas; primero
por
falta de tiempo y segundo por que la verdad me pareció
complicado cubrir
todas las diferentes posibilidades que ellos implican. Pienso que si un
usuario llega a pedir servicios de privacidad a su proxy o cualquier
intermediario que lo deba o pueda prestar, esto será un gran lio. Igual ya
entregue mi trabajo de grado, estoy esperando solo la sustentación. Pero
quede con la espinita de poder crear el algoritmo de implementación de
estos
RFC que comprenda todos los posibles casos que se
pueden presentar.
Usaste WeSIP para implementar esos algoritmos, ¿verdad? (curiosidad).
Si es así, ¿qué tal la experiencia?
No, no los implemente como dije por falta de tiempo principalmente. Había
oído hablar algo de WeSIP pero no sabia que era, acabo de entrar a la pagina
y me pareció increíble. De solo pensar todo lo que se puede hacer me da
dolor de cabeza. Sumándole todas la nuevas características que trae la nueva
versión de Kamailio, que tomara bastante tiempo actualizarse y probarlas.
Lastima :-( no se java solo C++, por ahora quiero empezar aprendiendo PHP, y
ya mirare java después.
6 Feb
6 Feb
12:35 a.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Lastima :-( no se java solo C++, por ahora quiero
empezar aprendiendo PHP,
y ya mirare java después.
OT: Ruby mola XD
El trato de estos RFC pensaba hacerlo en el Kamailio.cfg directamente con el
leguaje normal (tipo C++) que se utiliza para configúralo, como muchos
dijeron que ya lo tenían implementado. Lo que no me queda claro es como
harían para remover los campos que revelaban alguna información que se
quería mantener privada, cambiar estos campos por unos nuevos anónimos, y
luego cuando se reciba una respuesta relacionar esta respuesta dentro del
mismo dialogo. El mejor y mas complicado ejemplo de esto, es el caso en el
que se remueven los encabezados Via. Había pensado algo como crear una nueva
tabla en MySQL antes de remover estos campos para guardar allí los datos que
se remueven, y los identificadores del dialogo y así poder relacionarlos
después con sus respuestas correspondientes. Pero hasta ahora solo tengo el
diagrama de flujo :-) no me he sentado a escribirlo como tal.
PD: Nunca había oído de Ruby, por lo que vi (en Wikipedia) es muy fácil,
leeré un poco mas a ver que tal.
9:17 a.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Buenas,
Iñaki Baz Castillo escribió:
El Jueves, 5 de Febrero de 2009, David A Céspedes
escribió:
yo alguna vez he pensado en conectar seas con Ruby mediante
eventmachine[1] pero mis conocimientos de C para entender como funciona
este módulo me echan para atras.
Saludos
1.- http://rubyeventmachine.com/
--
http://velouria.wordpress.com/
Lastima :-( no se java solo C++, por ahora quiero
empezar aprendiendo PHP,
y ya mirare java después.
OT: Ruby mola XD
18 Feb
18 Feb
7:47 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
David A Céspedes wrote:
Conclusión, un SIP Proxy si debería poder
remover y cambiar los encabezados Via.
Les pido que me corrijan si me equivoco... pero al parecer Kamailio SI deja
hacerlo.
lo estoy haciendo con:
remove_hf("Via: SIP/2.0/UDP 192.168.10.151:5060^.");
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p22085526.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
8 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El Miércoles, 18 de Febrero de 2009, sadzas escribió:
David A Céspedes wrote:
La puedes liar muy gorda haciendo eso. "Puede" que te funcione, pero vamos...
Además, ¿resuelve eso tu problema? ¿Hay alguna intención por tu parte de hacer
las capturas con ngrep que llevamos semanas pidiéndote?
--
Iñaki Baz Castillo
Conclusión, un SIP Proxy si debería poder
remover y cambiar los encabezados Via.
Les pido que me corrijan si me equivoco... pero al parecer Kamailio SI deja
hacerlo.
lo estoy haciendo con:
remove_hf("Via: SIP/2.0/UDP 192.168.10.151:5060^.");
8:21 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Iñaki Baz Castillo wrote:
La puedes liar muy gorda haciendo eso.
Si, de hecho asi fue, de todos modos lo deje en "espera" ya que no
puedo
sacar el server que esta funcionando en este momento para realizar las
capturas y ver que es lo que sale.
De todos modos, supongo que ustedes tenian razon con respecto al NAT, asi
que les hice caso y ahora tengo funcionando KAMALIO con RTPROXY. En cuanto
pueda reemplazo al "brocoli" actual por KAMAILIO y les cuento como fue...
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p22086217.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
8:27 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
(perdon por el off toppic)
Iñaqui, lei en una lista (fine del 2007) que estabas peleando con Asterisk +
Openser, y tenias el mismo problema que yo ahora, osea, que Asterisk no
puede registrar los telefonos, con lo cual no sabes si estan conectados o no
con "sip show peers".
¿Como lo resolviste?
Mi idea es que los telefonos puedas comunicarse entre si sin llegar a
Asterisk, pero si desean conferencias, voicemail, etc, la llamada se efectue
al asterisk.
Pudiste lograrlo eficientemente?
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p22086337.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
8:47 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
El Miércoles, 18 de Febrero de 2009, sadzas escribió:
Iñaqui, lei en una lista (fine del 2007) que estabas
peleando con Asterisk
+ Openser, y tenias el mismo problema que yo ahora, osea, que Asterisk no
puede registrar los telefonos, con lo cual no sabes si estan conectados o
no con "sip show peers".
No recuerdo ese problema. O sea, si registras los usuarios en OpenSer
evidentemente no los verás registrados en Asterisk.
¿Como lo resolviste?
Usando integración OpenSer + Asterisk, de tal forma que los usuarios se
registran en OpenSer y OpenSer ruta las llamadas a Asterisk (o no
necesariamente si son llamadas entre usuarios). Por otra parte, en Asterisk
debes crear un peer para cada usuario pero poniendo:
host = IP_OPENSER
qualify = no
La forma más chula es configurar Asterisk con Realtime dinámico para el
sip.conf (que mire en la tabla "sipbuddies" y que dicha tabla sea en realidad
una VIEW de la tabla "subscriber" de OpenSer).
Mi idea es que los telefonos puedas comunicarse entre
si sin llegar a
Asterisk, pero si desean conferencias, voicemail, etc, la llamada se
efectue al asterisk.
Perfectamente viable. Hay ejemplos de ello en voip-info y en el wiki de
Kamailio.
Pudiste lograrlo eficientemente?
Sí :)
--
Iñaki Baz Castillo
23 Feb
23 Feb
8:53 p.m.
New subject: [Kamailio-Users-ES] Modificar Headers
Iñaki Baz Castillo wrote:
No puedo lograrlo con telefonos que esten detras de NAT, sucede que al
enviar un INVITE, este se le envia a la IP privada del tel y por supuesto no
llega.
Los telefonos en LAN funcionan bien, y los telefonos haciendo NAT se
registran bien en la BD, mostrando la IP publica y la privada. (en contact
la privada, y en received la publica).
Haciendo una captura con NGREP veo esto, lo cual es logico que esta enviando
el INVITE a la IP privada, no puedo lograr que lo envie a la publica.
IP Asterisk: 200.xx.xx.87
IP Kamailio: 200.xx.xx.53
Tel que llama: 192.168.10.152
Tel que hace NAT: 192.168.2.10
U 192.168.10.152:5060 -> 200.xx.xx.53:5060
INVITE sip:6001@200.xx.xx.53 SIP/2.0.
Via: SIP/2.0/UDP 192.168.10.152:5060;branch=z9hG4bK-7d0886bc.
From: "6005" <sip:6005@200.xx.xx.53>;tag=1b7f20bc3b144e87o0.
To: "6001" <sip:6001@200.xx.xx.53>.
Call-ID: 12ee10a0-722d7ff3(a)192.168.10.152.
CSeq: 102 INVITE.
Max-Forwards: 70.
Proxy-Authorization: Digest
username="6005",realm="asterisk",nonce="4883c065",uri="sip:6001@200.xx.xx.53",algorithm=MD5,response="a9
a75f94f05a8e04d2ec7d5ae7ac8def".
Contact: "6005" <sip:6005@192.168.10.152:5060>.
U 200.xx.xx.53:5060 -> 192.168.10.152:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP
192.168.10.152:5060;branch=z9hG4bK-7d0886bc;rport=5060;received=192.168.10.152.
From: "6005" <sip:6005@200.xx.xx.53>;tag=1b7f20bc3b144e87o0.
To: "6001" <sip:6001@200.xx.xx.53>.
Call-ID: 12ee10a0-722d7ff3(a)192.168.10.152.
CSeq: 102 INVITE.
Server: Kamailio (1.4.3-notls (i386/linux)).
Content-Length: 0.
U 200.xx.xx.53:5060 -> 200.xx.xx.87:5060
INVITE sip:6001@200.xx.xx.87:5060 SIP/2.0.
Record-Route: <sip:200.xx.xx.53;lr=on;ftag=1b7f20bc3b144e87o0>.
Via: SIP/2.0/UDP 200.xx.xx.53;branch=z9hG4bKb157.98e72b53.0.
Via: SIP/2.0/UDP 192.168.10.152:5060;rport=5060;branch=z9hG4bK-7d0886bc.
From: "6005" <sip:6005@200.xx.xx.53>;tag=1b7f20bc3b144e87o0.
To: "6001" <sip:6001@200.xx.xx.53>.
Call-ID: 12ee10a0-722d7ff3(a)192.168.10.152.
CSeq: 102 INVITE.
Max-Forwards: 69.
Proxy-Authorization: Digest
username="6005",realm="asterisk",nonce="4883c065",uri="sip:6001@200.xx.xx.53",
U 200.xx.xx.87:5060 -> 200.xx.xx.53:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
200.xx.xx.53;branch=z9hG4bKb157.98e72b53.0;received=200.xx.xx.53.
Via: SIP/2.0/UDP 192.168.10.152:5060;rport=5060;branch=z9hG4bK-7d0886bc.
Record-Route: <sip:200.xx.xx.53;lr=on;ftag=1b7f20bc3b144e87o0>.
From: "6005" <sip:6005@200.xx.xx.53>;tag=1b7f20bc3b144e87o0.
To: "6001" <sip:6001@200.xx.xx.53>.
Call-ID: 12ee10a0-722d7ff3(a)192.168.10.152.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Contact: <sip:6001@200.xx.xx.87>.
Content-Length: 0.
U 200.xx.xx.87:5060 -> 200.xx.xx.53:5060
INVITE sip:6001@192.168.2.10:5060 SIP/2.0.
Via: SIP/2.0/UDP 200.xx.xx.87:5060;branch=z9hG4bK0105fa70;rport.
From: "6005" <sip:6005@200.xx.xx.87>;tag=as5bbe9873.
To: <sip:6001@192.168.2.10:5060>.
Contact: <sip:6005@200.xx.xx.87>.
Call-ID: 445adc075a5d751f30d1a306737b80b7(a)200.xx.xx.87.
CSeq: 102 INVITE.
U 200.xx.xx.53:5060 -> 200.xx.xx.87:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP
200.xx.xx.87:5060;branch=z9hG4bK0105fa70;rport=5060;received=200.xx.xx.87.
From: "6005" <sip:6005@200.xx.xx.87>;tag=as5bbe9873.
To: <sip:6001@192.168.2.10:5060>.
Call-ID: 445adc075a5d751f30d1a306737b80b7(a)200.xx.xx.87.
CSeq: 102 INVITE.
Server: Kamailio (1.4.3-notls (i386/linux)).
Content-Length: 0.
U 200.xx.xx.53:5060 -> 192.168.2.10:5060
INVITE sip:6001@192.168.2.10:5060 SIP/2.0.
Record-Route: <sip:200.xx.xx.53;lr=on;ftag=as5bbe9873>.
Via: SIP/2.0/UDP 200.xx.xx.53;branch=z9hG4bK1604.43fd3526.0.
Via: SIP/2.0/UDP 200.xx.xx.87:5060;branch=z9hG4bK0105fa70;rport=5060.
From: "6005" <sip:6005@200.xx.xx.87>;tag=as5bbe9873.
To: <sip:6001@192.168.2.10:5060>.
Contact: <sip:6005@200.xx.xx.87>.
U 200.xx.xx.87:5060 -> 200.xx.xx.53:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP
200.xx.xx.53;branch=z9hG4bKb157.98e72b53.0;received=200.xx.xx.53.
Via: SIP/2.0/UDP 192.168.10.152:5060;rport=5060;branch=z9hG4bK-7d0886bc.
Record-Route: <sip:200.xx.xx.53;lr=on;ftag=1b7f20bc3b144e87o0>.
From: "6005" <sip:6005@200.xx.xx.53>;tag=1b7f20bc3b144e87o0.
To: "6001" <sip:6001@200.xx.xx.53>;tag=as0a184172.
U 200.xx.xx.53:5060 -> 192.168.10.152:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.10.152:5060;rport=5060;branch=z9hG4bK-7d0886bc.
Record-Route: <sip:200.xx.xx.53;lr=on;ftag=1b7f20bc3b144e87o0>.
From: "6005" <sip:6005@200.xx.xx.53>;tag=1b7f20bc3b144e87o0.
To: "6001" <sip:6001@200.xx.xx.53>;tag=as0a184172.
Call-ID: 12ee10a0-722d7ff3(a)192.168.10.152.
U 200.xx.xx.53:5060 -> 192.168.2.10:5060
INVITE sip:6001@192.168.2.10:5060 SIP/2.0.
Record-Route: <sip:200.xx.xx.53;lr=on;ftag=as5bbe9873>.
Via: SIP/2.0/UDP 200.xx.xx.53;branch=z9hG4bK1604.43fd3526.0.
Via: SIP/2.0/UDP 200.xx.xx.87:5060;branch=z9hG4bK0105fa70;rport=5060.
From: "6005" <sip:6005@200.xx.xx.87>;tag=as5bbe9873.
To: <sip:6001@192.168.2.10:5060>.
Contact: <sip:6005@200.xx.xx.87>.
Call-ID: 445adc075a5d751f30d1a306737b80b7(a)200.xx.xx.87.
U 200.xx.xx.53:5060 -> 192.168.2.10:5060
INVITE sip:6001@192.168.2.10:5060 SIP/2.0.
Record-Route: <sip:200.xx.xx.53;lr=on;ftag=as5bbe9873>.
Via: SIP/2.0/UDP 200.xx.xx.53;branch=z9hG4bK1604.43fd3526.0.
Via: SIP/2.0/UDP 200.xx.xx.87:5060;branch=z9hG4bK0105fa70;rport=5060.
From: "6005" <sip:6005@200.xx.xx.87>;tag=as5bbe9873.
To: <sip:6001@192.168.2.10:5060>.
Contact: <sip:6005@200.xx.xx.87>.
Call-ID: 445adc075a5d751f30d1a306737b80b7(a)200.xx.xx.87.
U 200.xx.xx.53:5060 -> 192.168.2.10:5060
INVITE sip:6001@192.168.2.10:5060 SIP/2.0.
Record-Route: <sip:200.xx.xx.53;lr=on;ftag=as5bbe9873>.
Via: SIP/2.0/UDP 200.xx.xx.53;branch=z9hG4bK1604.43fd3526.0.
Via: SIP/2.0/UDP 200.xx.xx.87:5060;branch=z9hG4bK0105fa70;rport=5060.
From: "6005" <sip:6005@200.xx.xx.87>;tag=as5bbe9873.
To: <sip:6001@192.168.2.10:5060>.
Contact: <sip:6005@200.xx.xx.87>.
Call-ID: 445adc075a5d751f30d1a306737b80b7(a)200.xx.xx.87.
U 200.xx.xx.53:5060 -> 192.168.2.10:5060
INVITE sip:6001@192.168.2.10:5060 SIP/2.0.
Record-Route: <sip:200.xx.xx.53;lr=on;ftag=as5bbe9873>.
Via: SIP/2.0/UDP 200.xx.xx.53;branch=z9hG4bK1604.43fd3526.0.
Via: SIP/2.0/UDP 200.xx.xx.87:5060;branch=z9hG4bK0105fa70;rport=5060.
From: "6005" <sip:6005@200.xx.xx.87>;tag=as5bbe9873.
To: <sip:6001@192.168.2.10:5060>.
Contact: <sip:6005@200.xx.xx.87>.
Call-ID: 445adc075a5d751f30d1a306737b80b7(a)200.xx.xx.87.
La configuracion de mi CFG es:
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}
route(2);
if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the transaction fails
}
route(1);
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
t_relay();
exit;
} else {
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
#initial requests
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}
t_check_trans();
# record routing
if (!is_method("REGISTER|MESSAGE"))
record_route();
# account only INVITEs
if (is_method("INVITE")) {
if ($rU =~ "5[0-9]" && src_ip!=200.xx.xx.87){
route(3);
exit;
}
setflag(1); # do accounting
}
if (!uri==myself) {
append_hf("P-hint: outbound\r\n");
route(1);
}
# requests for my domain
if (is_method("PUBLISH"))
{
sl_send_reply("503", "Service Unavailable");
exit;
}
if (is_method("REGISTER"))
{
if (isflagset(5)) {
setbflag(6);
save("location");
};
if (!save("location"))
sl_reply_error();
append_hf("P-hint: usrloc applied\r\n");
exit;
}
if ($rU==NULL) {
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
if (!lookup("location")) {
switch ($retcode) {
case -1:
case -3:
t_newtran();
t_reply("404", "Not Found");
exit;
case -2:
sl_send_reply("405", "Method Not Allowed");
exit;
}
}
# when routing via usrloc, log the missed calls also
setflag(2);
route(1);
}
route[1] {
# for INVITEs enable some additional helper routes
if (is_method("INVITE")) {
t_on_branch("2");
t_on_reply("2");
t_on_failure("1");
}
if (!t_relay()) {
sl_reply_error();
};
exit;
}
route[2]{
force_rport();
if (nat_uac_test("19")) {
if (method=="REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
};
setflag(5);
};
}
route[3] {
log(1, "Reenvia a Asterisk \n");
rewritehostport("200.xx.xx.87:5060");
route(1);
}
branch_route[2] {
xlog("new branch at $ru\n");
}
onreply_route[2] {
xlog("incoming reply\n");
if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])")
{
force_rtp_proxy();
}
search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
if (isbflagset(6)) {
fix_nated_contact();
}
exit;
}
failure_route[1] {
if (t_was_cancelled()) {
exit;
}
}
--
View this message in context:
http://www.nabble.com/Modificar-Headers-tp21727191p22168773.html
Sent from the OpenSER Users - ES mailing list archive at Nabble.com.
Mi idea es que los telefonos puedas comunicarse
entre si sin llegar a
Asterisk, pero si desean conferencias, voicemail, etc, la llamada se
efectue al asterisk.
Perfectamente viable. Hay ejemplos de ello en voip-info y en el wiki de
Kamailio.
5540
days inactive
5565
days old
sr-users-es@lists.kamailio.org
37 comments
6 participants
participants (6)
-
Antonio Pardo -
David A Céspedes -
Iñaki Baz Castillo -
Raúl Alexis Betancor Santana -
sadzas -
Victor Pascual Ávila