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!
El día 29 de enero de 2009 14:51, sadzas sadzas@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 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.
El día 29 de enero de 2009 15:43, sadzas sadzas@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 wrote:
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....
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!
2009/1/29 sadzas sadzas@gmail.com:
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.
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.
El día 29 de enero de 2009 15:51, sadzas sadzas@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í.
El día 29 de enero de 2009 15:51, sadzas sadzas@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 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?
2009/1/29 sadzas sadzas@gmail.com:
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 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!
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 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.
El día 29 de enero de 2009 17:55, sadzas sadzas@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 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.
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.
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@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.
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@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@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.
El día 5 de febrero de 2009 6:08, David A Céspedes ingdavidcespedes@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.
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@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@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.
El día 5 de febrero de 2009 15:13, David A Céspedes ingdavidcespedes@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.
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@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@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.
El día 5 de febrero de 2009 16:44, David A Céspedes ingdavidcespedes@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.
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
El día 5 de febrero de 2009 17:47, David A Céspedes ingdavidcespedes@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?
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.
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.
Buenas,
Iñaki Baz Castillo escribió:
El Jueves, 5 de Febrero de 2009, David A Céspedes escribió:
Lastima :-( no se java solo C++, por ahora quiero empezar aprendiendo PHP, y ya mirare java después.
OT: Ruby mola XD
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
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^.");
El Miércoles, 18 de Febrero de 2009, sadzas escribió:
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^.");
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 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...
(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?
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 wrote:
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.
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@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@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@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@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@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@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@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@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@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@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@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; }
}
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.
2009/1/29 sadzas sadzas@gmail.com:
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,
sr-users-es@lists.kamailio.org
-
Antonio Pardo -
David A Céspedes -
Iñaki Baz Castillo -
Raúl Alexis Betancor Santana -
sadzas -
Victor Pascual Ávila