Hola, mi intuición me dice que si un usuario de mi OpenSer hace una llamada outbound a una cuenta SIP externa, mi proxy podría corregir el NAT de la cabecera SIP pero del SDP se debería encargar el in-blound proxy del llamado, es decir, mi proxy no debería aplicar RtpProxy para esta llamada.
¿Esto se suele hacer así? ¿es la "norma" en el mundo real?
Gracias por cualquier aclaración.
Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
El 17/10/07, Iñaki Baz Castillo ibc@in.ilimit.es escribió:
Hola, mi intuición me dice que si un usuario de mi OpenSer hace una llamada outbound a una cuenta SIP externa, mi proxy podría corregir el NAT de la cabecera SIP pero del SDP se debería encargar el in-blound proxy del llamado, es decir, mi proxy no debería aplicar RtpProxy para esta llamada.
¿Esto se suele hacer así? ¿es la "norma" en el mundo real?
Gracias por cualquier aclaración.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Wednesday 17 October 2007 16:36:08 Saúl Ibarra escribió:
Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
Digamos que si tengo clientes en el OpenSer pagan dineros por una buena calidad de voz, para ello es necesario "controlar" el ancho de banda y los recursos (RtpProxy por ejemplo).
Entiendo que en llamadas entre usuarios, llamadas de ellos a la PSTN (a través de mi supuesto gateway) y llamadas entrantes (vía PSTN o SIP) debo garantizar la máxima calidad.
Pero si un usuario mío (que está tras NAT como casi todos) quiere llamar a un externo se supone que el IN-bound proxy del externo debería encargarse de arreglar el SDP y rutar el audio por su media proxy, ¿no lo veis así?
El 17/10/07, Iñaki Baz Castillo ibc@in.ilimit.es escribió:
El Wednesday 17 October 2007 16:36:08 Saúl Ibarra escribió:
Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
Digamos que si tengo clientes en el OpenSer pagan dineros por una buena calidad de voz, para ello es necesario "controlar" el ancho de banda y los recursos (RtpProxy por ejemplo).
Entiendo que en llamadas entre usuarios, llamadas de ellos a la PSTN (a través de mi supuesto gateway) y llamadas entrantes (vía PSTN o SIP) debo garantizar la máxima calidad.
Pero si un usuario mío (que está tras NAT como casi todos) quiere llamar a un externo se supone que el IN-bound proxy del externo debería encargarse de arreglar el SDP y rutar el audio por su media proxy, ¿no lo veis así?
Yo así lo veo... :)
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Wednesday 17 October 2007 17:11:04 Iñaki Baz Castillo escribió:
Pero si un usuario mío (que está tras NAT como casi todos) quiere llamar a un externo se supone que el IN-bound proxy del externo debería encargarse de arreglar el SDP y rutar el audio por su media proxy, ¿no lo veis así?
Esto lo digo sencillamente para ahorrar RtpRptoxy en ese tipo de llamadas outbound.
Hola,
Con retraso, pero ahí va...
Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea de tus usuarios sin esperar a que sea un tercero el que lo arregle.
Saludos JesusR.
El 17/10/07, Iñaki Baz Castillo ibc@in.ilimit.es escribió:
Hola, mi intuición me dice que si un usuario de mi OpenSer hace una llamada outbound a una cuenta SIP externa, mi proxy podría corregir el NAT de la cabecera SIP pero del SDP se debería encargar el in-blound proxy del llamado, es decir, mi proxy no debería aplicar RtpProxy para esta llamada.
¿Esto se suele hacer así? ¿es la "norma" en el mundo real?
Gracias por cualquier aclaración.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
-- Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Monday 22 October 2007 16:48:00 Jesus Rodriguez escribió:
Hola,
Con retraso, pero ahí va...
Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea de tus usuarios sin esperar a que sea un tercero el que lo arregle.
Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas Outbound.
Gracias.
Hola Iñaki,
El Monday 22 October 2007 16:48:00 Jesus Rodriguez escribió:
Hola,
Con retraso, pero ahí va...
Digo yo que tu deberías 'arreglar' todo lo que este en tu mano, y luego si tal pasarle la pelota al otro. Si tu usuario esta nateado lo arreglas, pero si el otro lo esta, eso es cuestión de su proxy, no?
Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea de tus usuarios sin esperar a que sea un tercero el que lo arregle.
Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas Outbound.
mmm... eso es precisamente lo que tendrías que activar, ¿no? :-) . Usar rtpproxy para las llamadas salientes de tus usuarios.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Monday 22 October 2007 17:07:38 Jesus Rodriguez escribió:
Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea de tus usuarios sin esperar a que sea un tercero el que lo arregle.
Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas Outbound.
mmm... eso es precisamente lo que tendrías que activar, ¿no? :-) . Usar rtpproxy para las llamadas salientes de tus usuarios.
Vaya, no es la primera vez que entiendo justo lo contrario de lo que me dicen XD
Vale, yo a lo que me refería es que si un usuario mío hace una llamada outbound a través de mi proxy, es de esperar que el llamado esté tras un proxy que le "arregle" el NAT, y que por ello no debería hacer falta siquiera que yo aplique RtpProxy, ¿no?
Es que si el llamado no tiene solucionado el problema de NAT, ¿cómo es que se "atreve" a recibir llamadas? si da por hecho que el llamante le va a solucionar la papeleta es que algo falla, ¿no?
Bueno, como ves son sólo delirios fruto de la inexperiencia. XD
El Monday 22 October 2007 15:21:32 Iñaki Baz Castillo escribió:
El Monday 22 October 2007 17:07:38 Jesus Rodriguez escribió:
Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea de tus usuarios sin esperar a que sea un tercero el que lo arregle.
Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas Outbound.
mmm... eso es precisamente lo que tendrías que activar, ¿no? :-) . Usar rtpproxy para las llamadas salientes de tus usuarios.
Vaya, no es la primera vez que entiendo justo lo contrario de lo que me dicen XD
Vale, yo a lo que me refería es que si un usuario mío hace una llamada outbound a través de mi proxy, es de esperar que el llamado esté tras un proxy que le "arregle" el NAT, y que por ello no debería hacer falta siquiera que yo aplique RtpProxy, ¿no?
Error, cuando se recibe una llamada se espera recibirla "BIEN", no tener que andar "arreglando" el problema de otro. Eso es lo que te han dicho los demás compañeros.
Es que si el llamado no tiene solucionado el problema de NAT, ¿cómo es que se "atreve" a recibir llamadas? si da por hecho que el llamante le va a solucionar la papeleta es que algo falla, ¿no?
Si lo tiene solucionado, eres tú quien no lo tiene. Ejemplo:
Usuario A (NAT) <-> Proxy A <-> Proxy B <-> Usuario B
Si usuario A llama a B y el Proxy A no arregla el desaguisado del nat de su usuario, no pretendas que lo arregle el Proxy B
El Monday 22 October 2007 18:12:52 Raúl Alexis Betancor Santana escribió:
Vale, yo a lo que me refería es que si un usuario mío hace una llamada outbound a través de mi proxy, es de esperar que el llamado esté tras un proxy que le "arregle" el NAT, y que por ello no debería hacer falta siquiera que yo aplique RtpProxy, ¿no?
Error, cuando se recibe una llamada se espera recibirla "BIEN", no tener que andar "arreglando" el problema de otro. Eso es lo que te han dicho los demás compañeros.
Sí sí, es que eso es lo que yo pienso. En mi configuración aplico RtpProxy para las llamadas ENTRANTES a mis dominios de OpenSer (lo cuál incluye llamadas entre usuarios de dichos dominios).
Es que si el llamado no tiene solucionado el problema de NAT, ¿cómo es que se "atreve" a recibir llamadas? si da por hecho que el llamante le va a solucionar la papeleta es que algo falla, ¿no?
Si lo tiene solucionado, eres tú quien no lo tiene. Ejemplo:
Usuario A (NAT) <-> Proxy A <-> Proxy B <-> Usuario B
Si usuario A llama a B y el Proxy A no arregla el desaguisado del nat de su usuario, no pretendas que lo arregle el Proxy B
Vale, tal vez tengo que diferenciar entre dos cosas:
- Por supuesto que mi proxy (el A) debe arreglar el NAT de sus usuarios (hablando de señalización SIP, reescritura de Contact...), tanto cuando llama el usuario A al B como en el caso contrario.
- Pero el tema del audio RTP no entiendo porqué mi proxy A debe arreglarlo en caso de que el usuario A llame a B (siendo B de otro proxy).
O sea, yo entiendo que a de ser el proxy **responsable** del usuario llamado el que debe arreglar el problema del NAT para el RTP (el de SIP lo deben arreglar ambos proxies para sus usuarios).
Es que, si en una llamada de usuario A a B (ambos tras NAT) el proxy A aplica RtpProxy, entonces resulta que el proxy B también lo debe aplicar (pues su usuario está tras NAT), con lo que se estarían usando 2 RtpProxy innecesariamente, y además tengo entendido (aunque no lo he probado) que según el caso puede haber bloqueo por ambos RtpProxys esperandose el uno al otro para detectar los puertos.
El Monday 22 October 2007 16:31:14 Iñaki Baz Castillo escribió:
- Pero el tema del audio RTP no entiendo porqué mi proxy A debe arreglarlo
en caso de que el usuario A llame a B (siendo B de otro proxy).
Porque sino el c del SDP llega jodido, el control del RTPProxy solo se aplica en los scripts de OpenSer cuando el usuario está VALIDADO, una llamada entrante a un usuario del dominio (si aceptas llamadas de cualquier sitio, lo cual es lo lógico) no pasa por el nat_test y tampoco debería. ¿porqué demonios tendría yo que gastar mis recursos de RTPProxy para arreglar la llamada de otro operador?
O sea, yo entiendo que a de ser el proxy **responsable** del usuario llamado el que debe arreglar el problema del NAT para el RTP (el de SIP lo deben arreglar ambos proxies para sus usuarios).
Pues lo tienes mal entendido, es el del llamante el responsable.
Es que, si en una llamada de usuario A a B (ambos tras NAT) el proxy A aplica RtpProxy, entonces resulta que el proxy B también lo debe aplicar (pues su usuario está tras NAT), con lo que se estarían usando 2 RtpProxy innecesariamente, y además tengo entendido (aunque no lo he probado) que según el caso puede haber bloqueo por ambos RtpProxys esperandose el uno al otro para detectar los puertos.
¿Innecesariamente? ... ¿ a ti que te importa la infraestructura del otro operador? y si gasta o no recursos de RTPProxy ¿?, limitate a preocuparte por tus usuarios.
Hola Iñaki,
El Monday 22 October 2007 17:07:38 Jesus Rodriguez escribió:
Yo estoy de acuerdo con Saúl. Tú deberías "arreglar" todo lo que sea de tus usuarios sin esperar a que sea un tercero el que lo arregle.
Ok, ya he quitado la posibilidad de usar RtpProxy en llamadas Outbound.
mmm... eso es precisamente lo que tendrías que activar, ¿no? :-) . Usar rtpproxy para las llamadas salientes de tus usuarios.
Vaya, no es la primera vez que entiendo justo lo contrario de lo que me dicen XD
Vale, yo a lo que me refería es que si un usuario mío hace una llamada outbound a través de mi proxy, es de esperar que el llamado esté tras un proxy que le "arregle" el NAT, y que por ello no debería hacer falta siquiera que yo aplique RtpProxy, ¿no?
Es que si el llamado no tiene solucionado el problema de NAT, ¿cómo es que se "atreve" a recibir llamadas? si da por hecho que el llamante le va a solucionar la papeleta es que algo falla, ¿no?
Piensa que si tú no solucionas los temas de NAT, el remoto no tiene porqué hacerlo. ¿Por qué voy a tener que arreglar yo una llamada que recibo y que en el c= del SDP tiene direcciones privadas en lugar de públicas?. Yo espero que el origen de una llamada sea "alcanzable" y eso implica que el direccionamiento sea público. Que esa IP sea del UA o de un rtpproxy ya no me importa, pero sé que puedo llegar al origen.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Lunes, 22 de Octubre de 2007, Jesus Rodriguez escribió:
Piensa que si tú no solucionas los temas de NAT, el remoto no tiene porqué hacerlo. ¿Por qué voy a tener que arreglar yo una llamada que recibo y que en el c= del SDP tiene direcciones privadas en lugar de públicas?. Yo espero que el origen de una llamada sea "alcanzable" y eso implica que el direccionamiento sea público. Que esa IP sea del UA o de un rtpproxy ya no me importa, pero sé que puedo llegar al origen.
De acuerdo, gracias a ambos, ya estoy convencido :)
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Raúl Alexis Betancor Santana -
Saúl Ibarra