sr-users-es

sr-users-es@lists.kamailio.org

487 discussions

Start a nNew thread

[OpenSER-Users-ES] Problemas de Auithentication

by David Villasmil

Perdonad, El problema es cuando una llamada viene de GW1/GW2... que les da DECLINED Ideas? David

16 years, 11 months

[OpenSER-Users-ES] ¿Es adecuado alterar el "From" en llamadas con "peering" o dentro del mismo proveedor?

by Iñaki Baz Castillo

Hola, supongamos que un cliente_A de un proveedor SIP llama a un número PSTN ajeno al proveedor. Entonces el proveedor le añade alguna cabecera (RPID y/o PAI) y la manda al gateway PSTN, que acepta dicha cabecera y la muestra como callerid. Pero ahora supongamos que el cliente_A llama a un número PSTN que se corresponde con otro cliente_B del mismo proveedor. Es decir, la llamada no sale del proveedor. Ahora bien, si no tocamos nada raro, el INVITE llegará finalmente a un teléfono SIP que mostrará como callerid el "From" original, cuando era de esperar (por los usuarios) que el callerid fuese el número PSTN asociado al cliente_A. En este caso de nada vale la cabecera PAI o RPID puesto que los teléfonos SIP generalmente muestran el From. En este caso sólo se me ocurre alterar el From, bien a nivel de proxy o al pasar la llamada por algún B2BUA del sistema. ¿Es "legítimo" hacerlo en este caso? ¿qué otra alternativa nos queda sino? PD: Otro escenario similar sería el de una llamada entre proveedores SIP con acuerdos de peering. ¿Sería lógico requerir de una cabecera "RPID" o "PAI" en el acuerdo y modificar el From con dicha cabecera antes de entregar la llamada a nuestros usuarios? En fin, la PSTN siempre poniendo trabas... incluso cuando la esquivas XD Gracias por cualquier aclaración. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 11 months

[OpenSER-Users-ES] Seguridad en cabeceras y parámetros

by Iñaki Baz Castillo

Hola, si llega un INVITE con la cabecera: Call-Info:;answer-after=0 algunos UAS descolgarán automáticamente la llamada. Pues hombre, está bien pero representa a todas luces un posible problema de seguridad y privacidad (¿¿espionaje?? XD). Tal vez el proxy sólo debería permitirse este tipo de cabeceras en ciertas condiciones (llamada desde el B2BUA y cosas así). De hecho así lo prevee el RFC 3261 respecto de las cabeceras Call-Info y Alert-Info. El caso es que en Asterisk éste problema no existe puesto que del INVITE que le llega al que Asterisk genera no se parece ni el "From" (y no es coña). Pero sé que otros B2BUA actúan de manera más transparente replicando las cabeceras desconocidas. En este último caso me pregunto si existe algún listado de cabeceras o parámetros que deba vigilar a parte de los mencionados. Se me ocurren: - Call-Info - Alert-Info - RPID - PAI ¿Alguno más? Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 11 months

[OpenSER-Users-ES] ¿Se puede enviar DTMF durante el Early Media?

by Iñaki Baz Castillo

Hola, algo que fastidia a todo el mundo es el tema de que te cobren una llamada nada más salir el buzón de voz. Lo lógico y deseable (al margen de la actitud avariciosa de las grandes operadoras) es que al llamar a un número y salir el buzón de voz no se cobre la llamada y se ofrezca la posibilidad de dejar un mensaje pulsando algún dígito. El impedimento técnico que veo es que parece ser no se permite el envío de DTMF durante el EarlyMedia. Pero no encuentro documentación sobre ello. El caso es que durante el EarlyMedia el audio es bidireccional, o sea, el SDP del "183 Session Progress" dice: a=sendrecv (de hecho esto lo he verificado también a nivel de gateway PSTN: una llamada desde la PSTN a un gateway y éste la dirige a un SIP UAS que responde con 183, y el gateway envía y recibe audio desde el UAS). A todo esto una duda que tengo es precisamente esto de poder enviar y recibir audio durante un EarlyMedia, ¿se puede o no se puede? ¿se hace? Por otra parte, mi Twinkle no me permite enviar DTMF durante el EarlyMedia, pero vamos, que ni lo intenta por lo que no sé qué pasaría si sí me dejase. Y por las pruebas que he hecho llamando desde la PSTN (fijo y móvil) y respondiendo con un EarlyMedia, tampoco parece que se permita el envío de DTMF. En fin, que la única opción honesta que he encontrado es la de reproducir el mensaje del buzón en EarlyMedia, y sólo tras el mensaje responder la llamada para que el llamante deje su mensaje (y sólo en ese caso provocar que tenga que pagar su llamada). Con lo fácil que es... lo cab***as que son las compañías. Bueno, sin más, que no sé exactamente cuál es mi pregunta pero tal vez alguien me ayude a definirla XD Saludos. -- Iñaki Baz Castillo

16 years, 11 months

[OpenSER-Users-ES] Modificar el cuerpo de los responses (200 OK + SDP)

by Gustavo Sutil Vega

Hola a tod@s. Alguien sabe como modificar el cuerpo de los replys? Para enviar un response en modo stateless se que se emplea sl_send_reply, pero solo toma como argumentos el codigo de error y la causa. Sabe alguien si se puede añadir un body a la respuesta? Lo que necesito es devolver mensajes 200 OK que porteen un SDP elegido por mi en el body. Se puede hacer esto con algun modulo disponible o habria que toquetear el codigo del modulo SL? Muchas gracias a todos!

16 years, 11 months

[OpenSER-Users-ES] Forwards/Alias

by David Villasmil

Hola a todos, He estado leyendo un post antigüo del amigo Iñaki (que por cierto está en todas partes ;) ), y por lo que pude entender OpenSer no tiene alias/forward en el sentido siguiente: User-A llama a User-B, y User-B tiene un forward a un número cualquiera... sea local, de otro dominio o de la PSTN. Según enetendí, OS simplemente hace un append_branch y llama a los dos a la vez?? Lo "normal", al menos en mi caso, es que OS buscara el forward del cliente B y volver a pasarlo todo por las rutas, con lo cual si es local lo encuentra sin problemas y si es de PSTN lo rutea por el gateway respectivo... ¿Es esto correcto? Si no, ¿cómo funciona? Un saludo David

16 years, 11 months

[OpenSER-Users-ES] Exigir la existencia de CPL para todos los usuarios

by Iñaki Baz Castillo

Hola, se me plantea una duda: Ahora mismo cuando se llama a un usuario se mira si tiene CPL y si no lo tiene se prosigue con un "lookup(location)" y tal. Lo malo de esto es que me obliga a replicar código para ambos casos: Por ejemplo, en el CPL uso "proxy_recurse" por lo que si durante el CPL recibo un 302 automáticamente genero un branch al Contact en vez de reenviar el 302 al llamante. Pero si no hay CPl entonces tengo que andar trasteando con el onreply_route y la función "get_contacts" para emular ese mismo comportamiento en caso de recibir un 302. Entonces se me estaba ocurriendo que en el INVITE hacer un: does_uri_exist() y en ese caso buscar CPL del usuario llamado, y si no existe CPL responder con 404 (y no hacer un lookup). Así simplifico código y lógica, pero lo malo es que tal vez ejecutar un CPL siempre cuando resulta que puede que sólo tenga un triste: <cpl> <incoming> <lookup source="registration"> <success> <proxy /> </success> </lookup> </incoming> </cpl> Pues igual resulta que es un poco derroche de procesador, ¿no? Bueno, en cualquier caso creo que lo haré, salvo que alguien me comente que es una locura usar CPL para cada llamada a un usuario. ;) Saludos y gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 11 months

[OpenSER-Users-ES] [OT] Duda DNS SRV en los Linksys PAP2

by Iñaki Baz Castillo

Hola, para que un Linksys PAP2 firmware 3.1.22(LS) haga resolución SRV hay que activar dos parámetros: - Use DNS SRV: yes - DNS SRV Auto Prefix: yes Si pongo el segundo a "no" no realiza la consulta SRV (o lo hace mal). ¿Sabéis qué implica el segundo parámetro? Gracias. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 11 months

[OpenSER-Users-ES] [OT] Provedores SIP y método INFO para DTMF

by Iñaki Baz Castillo

Hola, supongamos que un gateway PSTN_SIP me envía el DTMF en el RTP (RFC2833), y que me dicen que no pueden configurarlo para que me envíe SIP INFO. Qué faena, ¿no? Todo lo que podría ser un IVR a través de un servidor de aplicaciones SIP se va al garete... hum... El tráfico llegará a un MediaProxy. Aún no lo he mirado, pero por casualidad sabéis si MediaProxy sería capaz de detectar DTMF RFC2833 y generar SIP INFO? buff, ya me respondo yo que no, pero ni de coña. ¿Cómo solucionar este problema entonces? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

16 years, 11 months

[OpenSER-Users-ES] ¿Algún RFC o draft sobre agenda de contactos en servidor?

by Iñaki Baz Castillo

Hola, tengo entendido que el Windows Messenger (el MSN, Live o como quiera que se llame) usa SUBSCRIBE de alguna forma peculiar para el tema de los contactos en el servidor, es decir, que al registrarse el usuario desde cualquier localización recupera su lista de contactos a cuyo estado luego podría subscribirse. O sea, algo en plan: - Usuario abre el programa SIP en algún ordenador. - Introduce su usuario y contraseña y se registra en el servidor. - Envía un SUBSCRIBE "raro" para solicitar su agenda de contactos que recibe en un NOTIFY (o varios si el tamaño es demasiado grande) con algún "Content-Type" específico. - Una vez recuperados sus contactos se subscribe a su estado siguiendo el proceso normal ya estandarizado para ello. Bueno, que obviamente lo de arriba me lo estoy inventando. ¿Sabéis si existe algún RFC o draft para abordar este tema en SIP? ¿implementaciones propias de algún fabricante tal vez? En Jabber/XMPP todo esto existe, ¿no incluye SIP SIMPLE nada similar? Saludos. -- Iñaki Baz Castillo <ibc(a)aliax.net>

16 years, 11 months

← Newer
1
...
35
36
37
38
39
40
41
...
49
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

sr-users-es