A pesar de que ya lo he hecho para otros servicios, incluyendo el ATA, el conseguir hacer el "register" me costó mucho tiempo. Accediendo a la consola de asterisk tenía activado el debug:
# asterisk -r
sip set debug [on | trunkName ]
Según el instante lo puse tanto probando con on como con el nombre del trunk entrante (inbound trunk) .
Uno de los manuales principales que me ha guiado ha sido el de ADSLZone. No obstante, como ya decía, no acaba de funcionar del todo.
*** Register ***
Con respecto al register existen distintos formatos:
register => user[:secret[:authuser]]@host[:port][/extension]
register => fromuser@fromdomain:secret@host
register => fromuser@fromdomain:secret:authuser@host:port/extension
Lo siguiente es tener claro cuáles de los todos los valores que fuimos obteniendo se corresponden con esos valores. Porque, y aquí está donde me hice el lío (y la verdad, posiblemente me lo siga haciendo. Pero sabré por dónde van los tiros).
- DigestUserName: e34[teléfono]@evisemad.yoigo.com.
- fromuser@fromdomain: +34[teléfono]@ims.masmovil.com. Como podéis ver, esto es el DigestUserName.
- fromuser: +34[teléfono].
- fromdomain: ims.masmovil.com.
Este es el ejemplo genérico que ponen en el manual:
"DigestUserName":"AuthPassword":"DigestUserName"@[proxy]/[TEL]
Por lo que quedaría algo así:
+34[teléfono]@ims.masmovil.com:[p@$$W0rd]:e34[teléfono]@evimsemad.yoigo.com:5060/+34[teléfono]~3600
Si supierais la de combinaciones que hice pensando que el resultado que me devolvía era un error... Aunque catalogué cada formato no lo hice con los mensajes. Eran los mismos:
[2021-05-30 11:27:39] NOTICE[445]: chan_sip.c:15828 sip_reregister: -- Re-registration for +34[teléfono]@evimsemad.yoigo.com
[2021-05-30 11:27:39] NOTICE[30765]: app_queue.c:9096 reload_queue_rules: queuerules.conf has not changed since it was last loaded. Not taking any action.
[2021-05-30 11:27:39] NOTICE[445]: chan_sip.c:24840 handle_response_register: Outbound Registration: Expiry for evimsemad.yoigo.com is 2390 sec (Scheduling reregistration in 2375 s)
Estas líneas no significaban que el register estuviese mal. Y yo emperrado en que sí.
Lo dicho: tirad del formato que os pongo y os hará que el register funcione.
*** Outbound trunk ***
Esta configuración es la que está relacionada con las llamadas salientes. Aquí la muestra de un error que cometí:
- fromuser=e34[teléfono]@ims.masmovil.com
- fromuser=+34[teléfono]
[2021-05-30 11:41:35] WARNING[445][C-0000001c]: chan_sip.c:24304 handle_response_invite: Received response: "Forbidden" from '<sip:e34[teléfono]%40ims.masmovil.com@ims.masmovil.com>;tag=XXXXXXXXX'
Por lo que hice alguna prueba más cambiando ese parámetro en concreto. Así es como en mi caso tengo la siguiente configuración. ¿Qué se podría hacer mejor? Seguro que sí. Pero de momento cumple su función:
type=peer
timeout=3600
sendrpid=yes
secret=[password]
registertimeout=3600
qualify=no
port=5060
outboundproxyport=5060
outboundproxy=evimsemad.yoigo.com
nat=force_rport,comedia
insecure=port,invite
host=ims.masmovil.com
fromuser=+34[teléfono]
fromdomain=ims.masmovil.com
dtmfmode=rfc2833
disallow=all
directmedia=no
defaultuser=+34[teléfono]@ims.masmovil.com
context=from-pstn
authname=+34[teléfono]@ims.masmovil.com
auth=+34[teléfono]@ims.masmovil.com
allow=alaw,gsm
*** Inbound trunk ***
En este caso empecé con los parámetros que se muestran en el manual pero después revisando el debug conseguí no tener que configurar un nuevo trunk.
Hice una prueba muy aproximada de lo que tenían en el manual:
username=+34[teléfono]
type=peer
trustrpid=yes
timeout=3600
sendrpid=yes
secret=[password]
registertimeout=3600
qualify=no
port=5060
outboundproxyport=5060
outboundproxy=evimsemad.yoigo.com
nat=force_rport,comedia
keepalive=30
insecure=port,invite
host=ims.masmovil.com
;host=evimsemad.yoigo.com
fromuser=+34[teléfono]
fromdomain=evimsemad.yoigo.com
dtmfmode=rfc2833
disallow=all
directmedia=no
context=from-pstn
allow=alaw,gsm
Y me devolvio el siguiente error:
[2021-06-04 21:22:13] NOTICE[445][C-00000028]: chan_sip.c:26605 handle_request_invite: Failed to authenticate device <sip:[unMóvil]@[IPAsterisk]>;tag=XXXXXXXXXXXXXXXX
[2021-06-04 21:22:16] WARNING[3337][C-00000027]: app_dial.c:2507 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Subscriber absent)
La verdad no recuerdo si encontré otros mensajes diferentes. Pero acabé haciendo otros cambios:
username=+34[teléfono]
authname=+34[teléfono]@ims.masmovil.com
auth=+34[teléfono]@ims.masmovil.com
callerid=+34[teléfono]
type=peer
trustrpid=yes
timeout=3600
sendrpid=yes
secret=[password]
registertimeout=3600
qualify=no
port=5060
nat=force_rport,comedia
keepalive=30
insecure=port,invite
host=evimsemad.yoigo.com
fromuser=+34[teléfono]
fromdomain=evimsemad.yoigo.com
dtmfmode=rfc2833
disallow=all
directmedia=no
context=from-pstn
allow=alaw,gsm
Y ya estaría. Como decía con esta configuración ya no hace falta crear otro trunk adicional tal y como indican en el manual.
Como comentario adicional: he visto este mensaje con la corrección que ahora os contaré. Pero sólo con un teléfono de esos de spam, algo raro porque con mi móvil conseguí que no saliera.
Sólo hay una cosa curiosa que sucede cuando llegan unas llamadas y que tendré que buscar qué parámetro tengo que añadir o qué valor tengo que darle (si es que ya lo tengo en mi configuración). Cuando llegan las llamadas el origen llega con un formato como el siguiente:
[miMóvil];phone-context=+34
También es otra rara: he visto que el teléfono que os decía aparecía sin este formato.
*** Otros ***
Algunas de las correcciones o búsquedas que hice, además de activar el debug para ver en directo qué mostraba la consola de asterisk al entrar la llamada hice una comparáción desde Wireshark de un tcpdump desde la centralita a la hora de hacer el register con otro .pcap generado por el propio router.
También quisiera comentar que he tenido configurado uno de los teléfonos IP conectados al servicio de VoIP de la operadora y a mi asterisk a la vez. Evidentemente el sistema se liaba: empezaba con la centralita y a los dos segundos saltaba el teléfono y la centralita no acababa de mostrar que se había producido esa llamada.
hola!
ResponderEliminaresto te sigue funcionando? porque a mi simpre me da timeout cuando intenta conectar a ims.masmovil.com
Hola!!
EliminarSiento no haberte respondido antes.
La verdad es que como he estado trasteando un poco más tenía parada esta configuración y estaba con el teléfono conectado directamente al servicio. Y volver atrás no ha sido todo lo sencillo (o directo como espetaba).
Para lo que me estás preguntando: sí. Sigue registrándose sin problemas.
El tema del timeout me lo dio en algún momento. Y despistaba mucho. Pero después viendo el estado en el que se encontraba sí que aparecía registrado. Por lo que me pillas qué puede ser.
¿Has probado a hacer algún tcpdump a ver si eso te puede dar más pistas?
Hola, lo primero felicitarte por el trabajo que le llevas dando al maldito router jejejej. Creo que me he leído todas las entradas que hablas de él y no he visto nada de que hayas intentado dar la vuelta a la contraseña encriptada del pppoe, quizas se me haya pasado, si es así sorry. Has hecho algún intento de sacarla?
ResponderEliminarMuchas gracias gracias de nuevo, muy buen trabajo
Muchas gracias! Me alegra mucho de que te hayan gustado.
EliminarTienes razón. No he sacado nada sobre el PPPoE. Por lo que me ha parecido ver no tira de este protocolo. Pero como esa parte no la he estudiado en profundidad no sabría decirte. Sólo saqué una contraseña que era la del GPON. Aparte de eso, me temo que no usa nada más.
Siento no poder ayudarte más.
Un saludo!
Veo que lograste al final de toda la experiencia obtener usuario y contraseña del servicio SIP dentro de los archivos de configuracion una ves ingresado por SSH correcto?, tengo la misma necesidad para utilizar esa información para un FreePBX o algo parecido, pero yo apenas voy en la parte de hacer debug en la consola js de chrome,asi que me falta camino por recorrer, alguna recomendación?
ResponderEliminarHola:
EliminarSiento responderte casi un año después. He sido un poco desastre con el tema de los mensajes. La mayoría de los datos se podían intuir por las publicaciones que hay por internet. Pero otros son los que sí que obtuve al acceder por ssh.
El tema que me indicas es complejo. Si es el mismo router, leyéndote las últimas entregas te ayudarán a acceder. Incluso si no lo fuera, podrías intentar aplicar la misma técnica para leer el tráfico TR-069. Si no no se me ocurre.
Una vez más, siento muchísimo no haberte leído antes.
Un saludo!
Hola, estoy siguiendo tu blog y me gustaria saber el formato del passw para ponerlo en mi router fritzbox. Resulta que tengo los datos SIP capturados con Wireshark y no consigo que el teléfono conecte.
ResponderEliminarGracias
Hola!!
EliminarSiento mucho no haberte podido responder antes.
La verdad, no sabría decirte. El formato que obtengo accediendo al router está en texto plano. Por lo que sería lo que tendrías que poner en cualquier cliente/servidor que tenga que acceder a tu operadora. Si no es así, no sé que más decirte.
Siento no haberte podido ayudar y mucho más responderos tan tarde.
Un saludo!