Traza: » pstn » links » start » digium » serweb » jabber » sip_ua » sip_uas » sip_uac » dns_srv
¡Actualmente no estás identificado! Introduce abajo tus datos de identificación para abrir una sesión. Necesitas tener las cookies activadas para identificarte.
Has olvidado tu contraseña? Obten una nueva.: Enviar nueva contraseña
ARREGLAR
Un expediente del domain name server (DNS) SRV ayuda a conectar con un usuario del SIP de una manera similar que un MX Record ayuda a entrega del email. Cuando envías el email a “john@example.com”, el MX Record para example.com pudo decir a agente de transferencia del correo entregar el email a una máquina totalmente diversa, tal como “zaphod.foobar.com”. Semejantemente, cuando deseas hacer una llamada telefónica del SIP a john@example.com, el expediente de SRV pudo decir a tu computadora que deba conectar con “galaxy.starsystem.tw” para hacer tan.
¿Por qué utilizar los expedientes del DNS SRV para el SIP? El marcar por nombres del dominio deja a usuario del SIP tener un solo público “dirección del SIP” que se pueda volver a dirigir en la voluntad a su localización actual. Los expedientes de SRV mantienen estabilidad y también abren la posibilidad para utilizar tu propio dominio, sin importar el dominio del servicio del SIP que estás utilizando.
Los expedientes del recurso del DNS SRV indican cómo encontrar los servicios para los varios protocolos.
Del RFC:
Este documento describe un DNS RR que especifique la localización de los servidores para un protocolo y un dominio específicos.
Actualmente, una necesidad sabe la dirección exacta de un servidor para entrarlo en contacto con, o difunde una pregunta.
El SRV RR permite que los administradores utilicen varios servidores para un solo dominio, que muevan servicios desde el anfitrión al anfitrión con poca queja, y que señalen algunos anfitriones como servidores primarios para un servicio y otros como reservas.
Los clientes piden un servicio/un protocolo específicos para un dominio específico (el dominio de la palabra se utiliza aquí en el sentido terminante del RFC 1034), y consiguen detrás los nombres de cualquier servidor disponible.
Para un poder del SIP en un dominio, esto significa eso
Ejemplo
Para utilizar expedientes de SRV, necesitarás la información siguiente:
a. El tipo del servicio del IETF (puedes ver el listado más o menos completo de ésos aquí, RFC original #2782 aquí) en el _servicetype. _layer4 del formato. b. La prioridad de tus sistemas. c. La carga, o “carga” esos sistemas puede dirigir. (opcional) d. El número de acceso que tu servicio funcionará encendido. e. El hostname del sistema que tu servicio funcionará encendido.
Toda esta información consigue entrada en tu archivo de la zona en la orden antedicha, como tan:
a (TTL) SRV b (c) d E.
Por ejemplo, harías un servidor del sip, funcionando en host.tld como tan:
_udp SRV 0 del _sip. 5060 host.tld.
Pues describí arriba, el _udp del _sip. es el tipo del servicio del IETF para el protocolo del SIP que funciona en el UDP. SRV es el tipo de registro del DNS, 0 es la prioridad de esta entrada, no tenemos una entrada de la carga aquí, y 5060 es el número de acceso que el SIP funciona encendido. host.tld es nuestro hostname.
Podrías hacer una disposición similar para el iax, como tan:
_udp SRV 0 del _iax. 4569 host.tld.
Por supuesto necesitarás cerciorarse de que host.tld tenga un expediente relacionado de A o expediente de CNAME a ir con él, como tan:
host.tld A xxx.xxx.xxx.xxx
Hay un documento extenso con un ejemplo muy detallado en el webite de Cisco:
http://www.cisco.com/univercd/cc/td/doc/product/voice/sipproxy/admingd/ver2_1/ddns.htm
Aquí está el archivo de la zona de la muestra del RFC. Observar el SRV que están definiendo son *not* para el SIP, así que será diferente para ti:
Ejemplo ficticio
Este ejemplo utiliza el servicio ficticio “foobar”, funcionando en el puerto 9 como ayuda adentro expedientes de SRV que entienden. Si el servicio “foobar” se pone en ejecución siempre, no se piensa que utilizará necesariamente expedientes de SRV. Esto es (parte de) el archivo para example.com, un dominio aún-inusitado de la zona:
$ORIGIN example.com.
@ SOA server.example.com. root.example.com. (
1995032001 3600 3600 604800 86400)
NS server.example.com.
NS ns1.ip-provider.net.
NS ns2.ip-provider.net.
; foobar - utilizar la viejo-lento-caja o la nuevo-rápido-caja si es cualquiera
; disponible, hacer que tres cuartos de las conexiones va a
; nuevo-rápido-caja.
. _tcp _foobar SRV 0 1 9 old-slow-box.example.com.
SRV 0 3 9 new-fast-box.example.com.
; si ni la viejo-lento-caja o la nuevo-rápido-caja está para arriba, cambiar a
; usar el servidor de los sysdmin la caja y
SRV 1 0 9 sysadmins-box.example.com.
SRV 1 0 9 server.example.com.
servidor A 172.30.79.10
viejo-lento-caja A 172.30.79.11
sysadmins-caja A 172.30.79.12
nuevo-rápido-caja A 172.30.79.13
; No se apoya NINGUNOS otros servicios
*. _tcp SRV 0 0 0.
*. _udp SRV 0 0 0.
Al poner una llamada, el cliente
Aquí está otra zona, disposición para el SIP:
$ORIGIN sipdomain.com.
@ SOA ns1.sipdomain.com. root.sipdomain.com. (
1995032001 3600 3600 604800 86400)
NS ns1.sipdomain.com.
NS ns1.elsewhere.ca.
NS ns2.elsewhere.ca.
;
; Para la elasticidad del sip del servicio 3 peticiones a 3x-load para cada 1 dado
; a 1x-load
_udp SRV 0 del _sip. 1 5060 1x-load.sipdomain.com.
SRV 0 3 5060 3x-load.sipdomain.com.
;
; Si los 1ros servidores de la prioridad no contestan, failover a este grupo
; dando peticiones a los servidores igualmente
SRV 1 0 5060 failover1.sipdomain.com.
SRV 1 0 5060 failover2.sipdomain.com.
;
; Si ningunos de nuestros servidores están encima… de intento otro
; Abastecedor del SIP a otra parte:
SRV 2 0 5060 offsite-failover1.elsewhere.ca.
SRV 2 0 5060 offsite-failover2.elsewhere.ca.
;
; Necesitas un expediente de A para cada anfitrión que fijas un SRV para
ns1 A 10.0.0.1
1x-load A 10.0.0.3
3x-load A 10.0.0.4
failover1 A 10.0.0.5
failover2 A 10.0.0.6
;
; Los recs de A que sostienen los dos finales SRVs están en la zona
; para elsewhere.ca
;
; No se apoya NINGUNOS otros servicios
*. _tcp SRV 0 0 0.
*. _udp SRV 0 0 0.
Definición del expediente del DNS:
blanco del puerto del peso de la prioridad de la clase SRV del _Service. _Proto.Name TTL
ejemplo
_sip. _udp.domain.tld. EN SRV 20 0 5060 mysipproxy.domain.tld.
_stun. _udp.domain.tld. EN SRV 20 0 3478 mystunserver.domain.tld.
Prueba de las puestas en práctica de SRV en clientes del SIP: Puestas en práctica de SRV: Resultados de la prueba de las puestas en práctica de SRV
Servidores del DNS que apoyan expedientes de SRV
Ver también