ES2291970T3 - Procedimiento y dispositivo de emision de solicitudes hacia un servidor de nombres de dominio desde una maquina solicitante. - Google Patents
Procedimiento y dispositivo de emision de solicitudes hacia un servidor de nombres de dominio desde una maquina solicitante. Download PDFInfo
- Publication number
- ES2291970T3 ES2291970T3 ES04805642T ES04805642T ES2291970T3 ES 2291970 T3 ES2291970 T3 ES 2291970T3 ES 04805642 T ES04805642 T ES 04805642T ES 04805642 T ES04805642 T ES 04805642T ES 2291970 T3 ES2291970 T3 ES 2291970T3
- Authority
- ES
- Spain
- Prior art keywords
- request
- ntel
- block
- numbers
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/72—Finding out and indicating number of calling subscriber
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13091—CLI, identification of calling line
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13097—Numbering, addressing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13103—Memory
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Telephonic Communication Services (AREA)
- Computer And Data Communications (AREA)
Abstract
Procedimiento de emisión de al menos una solicitud (R) con destino a un servidor (1, 2, 3) de nombres de dominio desde una máquina solicitante (H), dicho servidor (1, 2, 3) de nombres de dominio siendo un servidor de nombres de dominio de numeración telefónica e164.arpa, cada nombre siendo determinado a partir del número (NTEL) de teléfono de destino al formato E.164, contenido en la dicha solicitud (R), de la forma siguiente: se elimina del número de teléfono E.164, que comprende el código del país, todos los caracteres no numéricos, se intercalan puntos entre los dígitos, se invierte el orden de los dígitos y se agrega la cadena " e164.arpa " al final de los dígitos, el procedimiento estando caracterizado porque un control preliminar de la validez del número (NTEL) de teléfono de destino de la solicitud (R) es realizado automáticamente y localmente a la máquina solicitante (H) con relación a una base (BD) de datos de números de teléfono, local a la máquina solicitante (H), paraenviar la solicitud (R) a partir de la máquina solicitante (H) con destino al servidor (1, 2, 3) de nombres de dominio solamente si su número (NTEL) de teléfono de destino pasa con éxito dicho control preliminar.
Description
Procedimiento y dispositivo de emisión de
solicitudes hacia un servidor de nombres de dominio desde una
máquina solicitante.
La invención concierne a un procedimiento de
emisión de al menos una solicitud con destino a un servidor de
nombres de dominio desde una máquina solicitante.
Los servidores de nombres de dominio (DNS en
inglés), más particularmente referidos por la invención, son los
servidores de nombres de dominio que reproducen la numeración
telefónica tal como e164.arpa.
En esos servidores, cada nombre es determinado a
partir del número de teléfono de destino al formato E.164,
contenido en la solicitud salida de la máquina solicitante. Cada
servidor de nombres de dominio comprende registros en la memoria,
asociados a los nombres y a las zonas que administra, y/o
referencias a otros servidores de nombres de dominio, para los
nombres y las zonas que no administra.
Según el protocolo ENUM, cuando un mensaje de
solicitud en lectura de un nombre llega a un servidor que administra
la zona que puede contener este nombre, éste retorna a la máquina
solicitante los registros, que están asociados a este nombre y que
están constituidos por identificadores de recurso (URI inglés) como
por ejemplo un número de fax, un número de teléfono móvil, una
dirección de correo.
Así, los servidores de nombres pueden estar
sometidos a muchas solicitudes en lectura o escritura, incluyendo
las solicitudes erróneas, para las cuales el nombre es inexistente
en los servidores de nombres de dominio.
En el caso de una solicitud para un nombre de
dominio desconocido, el servidor de nombres de dominio puede no
contestar a la máquina del solicitante en ciertos casos. La
inexistencia del nombre requerido puede ser entonces detectada
solamente por el rebase de un plazo de temporización después de la
emisión de la solicitud en la máquina solicitante, mientras que no
se recibió ninguna respuesta. Por otra parte, el tratamiento de
solicitudes erróneas sobrecarga y retrasa también aquella de las
solicitudes no erróneas en los servidores de nombres, que demandan
una respuesta.
La invención tiene como objetivo el obtener un
procedimiento y un dispositivo de emisión de solicitudes hacia un
servidor de nombres de dominio, atenuando las desventajas del estado
de la técnica y permitiendo disminuir el número de solicitudes
erróneas que deben tratar los servidores de nombres de dominio.
Para este propósito, un primer objeto de la
invención es un procedimiento de emisión de al menos una solicitud
con destino a un servidor de nombre de dominio desde una máquina
solicitante según la reivindicación 1.
Gracias a la invención, el recurso a los
servidores de nombres de dominio se vuelve más limitado y su ahorro
de tratamientos inútiles. Se reconoce una solicitud errónea y se
evita que alcancen los servidores de nombres desde la máquina
solicitante, y esto por el hecho de que el número de teléfono de
destino de la solicitud ha sido determinado como no válido, por
ejemplo determinando que es imposible que el mismo exista.
Según otras características de la invención,
- en la base de datos local se registra al menos
un código del país prescrito, y
el control preliminar comprende comprobar si el
código del país del número de teléfono de destino de la solicitud
se registra en la base de datos local;
- en la base local de datos de bloques de
números de teléfono se registra al menos un plan de numeración,
cada plan de numeración comprendiendo al menos un bloque de números
de teléfono,
el control preliminar comprende:
determinar, durante una etapa de determinación,
si el número de teléfono de destino de la solicitud pertenece a un
bloque del plan de numeración, el número de teléfono de destino de
la solicitud no pasa con éxito dicho control preliminar en caso
negativo en la etapa de la determinación;
- el plan de numeración se asocia un código de
país,
el plan de numeración correspondiendo al código
de país del número de teléfono de destino de la solicitud que es
aquel con relación al cual el control preliminar es realizado;
- una pluralidad de bloques separados de números
de teléfono, a los cuales se asocian respectivamente características
prescritas de números del bloque, es registrada en la base de datos
local,
dicha etapa de determinación comprende además
determinar, a cual bloque de números de teléfono de la base de
datos local el número de teléfono de destino de la solicitud
pertenece,
en el caso en que ha sido determinando que
número de teléfono de destino de la solicitud pertenece a un bloque
del plan de numeración,
leer en la base de datos local las
características asociadas al bloque de numeración determinado,
comprobar si el número de teléfono de destino de
la solicitud está conforme a dichas características leídas,
enviar de la máquina solicitante al servidor de
nombres de dominio la solicitud solamente si la verificación da un
resultado afirmativo;
- las características de números de bloque son
al menos uno entre:
una fecha de reservación de números de teléfono
del bloque,
un final del período de reservación de los
números de teléfono del bloque,
una fecha de asignación de los números de
teléfono del bloque,
un final del período de asignación de los
números de teléfono del bloque,
una fecha de inicio de la atribución del bloque
de números de teléfono,
una fecha final de atribución del bloque de
números de teléfono,
una longitud máxima de los números de teléfono
del bloque,
un longitud mínima de los números de teléfono
del bloque;
- si el número de teléfono de destino de la
solicitud no pasa con éxito dicho control preliminar, una señal de
error en el número de teléfono de destino de la solicitud es
reenviado a la máquina solicitante;
- la señal de error en el número de teléfono de
destino de la solicitud contiene una información sobre la o las
característica(s) de números de bloque, que no son respetados
por el número de teléfono de destino de la solicitud durante dicha
verificación.
Un segundo objeto de la invención es un
dispositivo de emisión de al menos una solicitud con destino a un
servidor de nombres de dominio desde una máquina solicitante según
la reivindicación 9.
Según una característica de la invención, los
medios de recepción, la base de datos de bloques de números de
teléfono, los medios de control automático y los medios de envío
están presentes en la máquina solicitante.
Según otra característica de la invención, los
medios de recepción, los medios de control automático y los medios
de envío están presentes en la máquina solicitante y la base de
datos de números de teléfono es interrogable por los medios de
control automático por medio de una red local. La invención
comprende también una máquina según la reivindicación 12, un
programa informático según la reivindicación 13 y un sistema según
la reivindicación 14.
La invención será mejor entendida con la lectura
de la descripción que seguirá, dada sólo a título de ejemplo no
limitativo con referencia a los dibujos anexados, en los cuales:
- la figura 1 representa esquemáticamente un
dispositivo de emisión de solicitudes según la invención con
destino a una arquitectura de servidores de nombres de dominio,
- la figura 2 representa esquemáticamente una
variante del dispositivo de emisión de solicitudes según la figura
1,
- la figura 3 representa un ejemplo del
organigrama del desarrollo del procedimiento de emisión de
solicitudes puesto en ejecución por el dispositivo según la
invención;
- la figura 4 representa un ejemplo del
contenido de la base de datos utilizada según la invención; y
- la figura 5 representa dos ejemplos de
organigramas de las etapas de verificación realizadas en el
procedimiento según la invención.
En el caso del campo de numeración telefónica de
la figura 1, los nombres en los servidores 3 de nombres de dominio
utilizan los números de teléfono de los usuarios según el protocolo
ENUM del grupo de trabajo sobre la puesta en correspondencia con
números de teléfono (Telephone Number Mapping Working Group)
definidos en el grupo de trabajo IETF (grupo de trabajo sobre la
red Internet, o Internet Engineering Task Force) según el documento
RFC2916, al cual se hace referencia aquí, RFC significando en inglés
"Request For Comments" y siendo publicaciones de referencia que
porta la red Internet. Según este documento, titulado "número
E.164 y servidores de nombres de dominio" (E.164 Number and DSN),
para traducir un número de teléfono E.164 en nombres de dominio, se
elimina el número de teléfono E.164 de un usuario, que comprende el
código del país (por ejemplo
+33-1-45295813 para un número de
teléfono de un usuario en Francia) todos los caracteres no
numéricos, se intercalan puntos entre los dígitos, se invierte el
orden de los dígitos y se agrega la cadena "e.164.arpa" al
final de los dígitos, para obtener el nombre de dominio, es decir
3.1.8.5.9.2.5.4.1.3.3.e164.arpa en el ejemplo precedente ilustrado
en las figuras 1, 2 y 3.
Al nombre es asociado en la memoria 4 asociada a
ese servidor 3 de nombres de dominio un conjunto de registros de
recurso NAPTR (para el registro del recurso del indicador de
autoridad de nombramiento o naming Authority Pointer Ressource
Record) según el documento del grupo de trabajo IETF RFC2915, hecho
nulo y sin efecto por el documento RFC3403, a los cuales se hace
referencia aquí. El registro NAPTR tiene, según la parte 4 del
documento IETF RFC3403, un código del tipo de DNS igual a 35 para el
campo TYPE del formato de registro de recurso según el párrafo
3.2.1 del documento IETF RFC1035. El registro NAPTR tiene así el
formato siguiente:
ORDEN, PREFERENCIA, BANDERAS (FLAGS), SERVICIOS,
REGEXP, REEMPLAZO.
El campo REGEXP contiene las informaciones I
propiamente dichas, tales como las informaciones I para alcanzar al
usuario, como por ejemplo sip:dupont@ft.com, mailto:dupont@ft.com,
http://www.exemple.fr, que son en este ejemplo otras informaciones
para alcanzar al Sr. Dupont que tiene el teléfono número
+33-1-45295813 (formato
internacional para el número 01 45 29 58 13 en Francia).
Así, en este ejemplo, los registros asociados a
este nombre de dominio serán:
\textdollarORIGIN 3.1.8.5
.9.2.5.4.1.3.3.e164.arpa
- IN NAPTR 10 10 "u" "E2U+sip" "!^.*\textdollar!sip:dupont@ft.com!"
- IN NAPTR 10 20 "u" "E2U+mailto" "!^.*\textdollar!mailto:dupont@ft.com!"
- EN NAPTR 10 20 "u" "E2U+http" "¡^.*\textdollar!http://www.exemple.fr!"
Por otra parte, el principio de delegación de la
arquitectura ENUM en el contexto de la gestión de la numeración
E164 define varios niveles de responsabilidad en estructura
arborescente en el sentido que un primer servidor 1 (llamado Tier0)
de nombres de dominio administra una raíz mundial de direcciones en
"e.164.arpa", los segundos servidores 2, 2a (llamados Tier1)
de nombres de dominio a los cuales el primer servidor 1 remite
administra cada uno un código de país (por ejemplo 6.4.e164.arpa
para Suecia, 3.3.e164.arpa para Francia metropolitana), y los
terceros servidores 3, 3a, 3b (llamados Tier2) de nombres de dominio
constituyen entonces los servidores 3 de nombres de dominio
precitados, que administran cada uno su zona asociada a nombres de
dominio. En la figura 1, las remisiones son simbolizadas por trazos
interrumpidos. Cada servidor 2, 2a de nombres de dominio remite a
uno o varios servidores 3, 3a, 3b de nombre de dominio, a los cuales
no remiten los otros servidores 2, 2a. El servidor 1 es conocido
como el padre de los servidores 2, 2a, ellos mismos los padres de
los servidores 3, 3a a los cuales estos remiten. Cada servidor 3,
3a, 3b administra la zona asociada a los números E164.
En el ejemplo precedente, el servidor 2a de
nombres de dominio 3.3.e164.arpa remite a varios servidores 3a, 3b
de nombre de dominio. El servidor 3a de nombres de dominio
administra por ejemplo un cierto número de direcciones en
3.3.e164.arpa, comprendiendo por ejemplo la dirección
3.1.8.5.9.2.5.4.1.3.3.e164.arpa y está asociado a la memoria 4 de
la figura 2. Por ejemplo, el servidor 3a administra la zona que se
termina por 9.2.5.4.1.3.3.e164.arpa, el servidor 3b administra una
zona que se termina por 8.2.5.4.1.3.3.e164.arpa.
Una máquina H que desea obtener informaciones I
presentes en un registro ENR de la arquitectura A envía a una
plataforma de servicios, que tiene el signo de referencia PS en las
figuras 1 y 2, una solicitud R que contiene un número NTEL de
teléfono E.164, permitiendo determinar el nombre ADR de este
registro ENR, y esto por traducción del número de teléfono NTEL
como fue explicado arriba. Esta máquina H solicitante es por ejemplo
un ordenador personal de un usuario. La plataforma PS de servicios
tiene por ejemplo una arquitectura cliente-servidor
y comprende un acceso 10 de recepción de las solicitudes R desde el
exterior y emitidas por las máquinas H y un módulo 11 de resolución
(resolver) para el tratamiento de las solicitudes recibidas en el
acceso 10. En función de la arquitectura, la solicitud validada por
el sistema puede ser emitida por un servidor DNS local en la red
del cliente solicitante. Las solicitudes que vienen de la plataforma
de servicios son así emitidas a nivel de esta red local. El módulo
11 de resolución es cliente de un servidor local (DNS local) de
nombres de dominio 12 conectados con el módulo 11 y está apto para
enviar al servidor local de nombres de dominio 12 conectado con el
módulo 11, señales de interrogación que corresponden a la solicitud
R recibida en el acceso 10. El servidor local 12 de nombres de
dominio está apto para emitir, en función de las señales de
interrogación, mensajes de solicitudes MR de informaciones I hacia
los servidores externos 1, 2, 3 de nombres de dominio de la manera
siguiente.
Los mensajes de solicitudes MR comprenden el
nombre ADR del campo a interrogar en la arquitectura para obtener
el registro ENR deseado.
La solicitud R enviada por la máquina H a la
plataforma PS especifica el número de teléfono E.164 deseado NTEL,
que la plataforma PS (por ejemplo por el módulo 11 de resolución)
traduce en nombre ADR a interrogar (por ejemplo ADR =
3.1.8.5.9.2.5.4.1.3.3.e164.arpa para NTEL =
+33-1-45295813), para formar el
mensaje MR corres-
pondiente.
pondiente.
El mensaje de solicitud MR que comprende el
nombre ADR es enviado inicialmente a la etapa E1 del servidor 1, el
cual remite a continuación durante la etapa E2 un primer mensaje de
respuesta al servidor local 12, indicándole una referencia al
servidor 2 correspondiente, seleccionado por esta dirección ADR, es
decir en el ejemplo precedente el servidor 2a. El servidor local 12
entonces envía durante la etapa E3 el mensaje de solicitud MR que
comprende el nombre ADR al servidor 2 seleccionado e indica en el
primer mensaje de respuesta, es decir en el ejemplo precedente el
servidor 2a, el servidor 2a entonces envía, durante la etapa E4, un
segundo mensaje de respuesta al servidor local 12, indicándole una
referencia al servidor 3 correspondiente, seleccionado por este
nombre ADR, es decir en el ejemplo precedente el servidor 3a. El
servidor local 12 entonces envía a continuación durante la etapa E5
el mensaje de solicitud MR que comprende el nombre ADR al servidor
3a de nombres de dominio seleccionado e indicado en el segundo
mensaje de respuesta.
Cada servidor 3, 3a, 3b comprende por lo menos
una entrada 5 de admisión de mensajes de solicitudes MR. Los
mensajes de solicitudes MR pueden ser por ejemplo solicitudes en
lectura de informaciones I con el nombre ADR o solicitudes en
escritura de informaciones I con el nombre ADR.
Cuando un mensaje MR de solicitud en lectura con
el nombre ADR llega a la entrada de admisión 5 y cuando el nombre
ADR es encontrado en el servidor 3, 3a, 3b, el o los registros NAPTR
de informaciones I son buscados con este nombre ADR. Luego, cuando
los registros NAPTR asociados a este nombre ADR son encontrados en
el servidor 3, 3a, 3b, esos registros NAPTR son leídos en la
memoria 4 asociada, por ejemplo los registros NAPTR indicados
arriba para el nombre 3.1.8.5.9.2.5.4.1.3.3.e164.arpa. El servidor
3, 3a, 3b comprende una primera salida 6 de suministro de un tercer
mensaje de respuesta a la solicitud MR en lectura presente en su
entrada 5. Este tercer mensaje de respuesta contiene los registros
NAPTR leídos en la memoria 4 asociados con el nombre ADR
especificado en el mensaje MR de solicitud en lectura, como aquellos
indicados en el ejemplo mencionado arriba, teniendo las
informaciones
I = sip:dupont@ft.com, mailto:dupont@ft.com, http://www.exemple.fr para el nombre 3.1.8.5.9.2.5.4.1.3.3.e164.arpa. El tercer mensaje de respuesta es enviado a la etapa E6 de salida 6 del servidor 3a al servidor local 12 y de allí a la máquina H solicitante por medio del acceso 13 de éste.
I = sip:dupont@ft.com, mailto:dupont@ft.com, http://www.exemple.fr para el nombre 3.1.8.5.9.2.5.4.1.3.3.e164.arpa. El tercer mensaje de respuesta es enviado a la etapa E6 de salida 6 del servidor 3a al servidor local 12 y de allí a la máquina H solicitante por medio del acceso 13 de éste.
Cuando un mensaje MR de solicitud en lectura con
el nombre ADR llega a la entrada de admisión 5, cuando el nombre
ADR es encontrado en el servidor 3, 3a, 3b, cuando los registros
NAPTR de informaciones I son buscados con este nombre ADR pero que
no se encuentra ningún registro NAPTR con este nombre ADR (porque no
hay registro NAPTR presente en este nombre ADR), el servidor 3
envía en su salida 6 al servidor local 12, y, de allí a la máquina
solicitante H, un mensaje de respuesta que indica la ausencia de
registros NAPTR con el nombre ADR.
Cuando un mensaje MR de solicitud en lectura a
un nombre ADR erróneo llega a la entrada de admisión 5, ese nombre
ADR no podrá ser encontrado en el servidor 3, puesto que el nombre
es inexistente en los servidores de nombres de dominio. Por
diversas razones (no disponibilidad de servidores o sobrecarga,
configuraciones de las tablas de enrutamiento), la duración de
resolución del nombre ADR puede ser larga, duración durante la cual
no se transmite ninguna respuesta. Así, el servidor local 12 no
recibirá jamás respuesta al último mensaje MR de solicitud que el
mismo se había remitido.
Según la invención, está previsto, localmente en
la máquina solicitante H, un dispositivo D de emisión de
solicitudes R destinadas a los servidores externos 1, 2, 3 de
nombres de dominio, los servidores 3 siendo los servidores en los
cuales los registros NAPTR están presentes.
Lo que ha sido descrito anteriormente
concerniente a los mensajes MR de solicitudes en lectura vale por
supuesto para los mensajes MR de solicitudes en escritura, en los
servidores 1, 2, 3, de un registro NAPTR especificado en la
solicitud R con el nombre ADR especificado en la solicitud R.
Este dispositivo D de emisión comprende medios
DR de recepción de solicitudes R desde la máquina solicitante H y
una base BD de datos de números de teléfono. Medios DC de control
son previstos en el dispositivo D de emisión para controlar
automáticamente si el número de teléfono NTEL de destino de la
solicitud R es válido con relación a los datos resultantes de la
base BD de datos de números de teléfono.
Medios DE son previstos para enviar la solicitud
R de la máquina solicitante H con destino al servidor 1, 2, 3 de
nombres de dominio solamente si el número NTEL del teléfono de
destino de esta solicitud R pasa con éxito el control preliminar de
los medios DC. Los medios DC de control por ejemplo forman parte de
una librería de validación que puede también comprender otras
funciones.
El dispositivo D de emisión por ejemplo está
instalado enteramente en la máquina solicitante H, como se
representa en la figura 1, en cuyo caso los medios DR de recepción
son por ejemplo un interfaz de recepción de las solicitudes salidas
de un interfaz DP, permitiendo que el usuario produzca una o más
solicitudes R en la máquina solicitante H componiendo en la misma
el número de teléfono NTEL de destino de esa o esas solicitudes
R.
En la variante representada en la figura 2, los
medios DR de recepción, los medios DC de control automático y los
medios DE de envío están presentes en la máquina solicitante H como
previamente, y la base BD de datos de números de teléfono es
interrogable por los medios DC de control automático por medio de
una red local RL. En esta variante, la base BD está por ejemplo
presente al nivel del módulo 11 de resolución.
Si, durante el control, el número NTEL del
teléfono de destino de la solicitud R es declarado no válido por
comparación con los datos de la base BD, la solicitud R no es
transmitida por los medios DE de la máquina solicitante H al módulo
11 de resolución. El control de la validez elimina así los mensajes
MR de solicitud, donde se sabe a priori que los mismos no
pueden tener registro NAPTR asociado en los servidores externos 1,
2, 3 de nombres de dominio, puesto que el número NTEL de teléfono de
destino correspondiente no es válido. Por lo tanto, ningún mensaje
de solicitud MR con el nombre de ADR traducido de este número NTEL
de teléfono será generado por el servidor local 12, ni enviado por
el mismo a los servidores externos 1, 2, 3 de nombre de dominio,
que serán así eliminados de los mensajes MR de nombre ADR erróneo y
de tratamientos inútiles de estos mensajes.
Los números NTEL de teléfono tienen el formato
siguiente:
CC \
C_{1}C_{2}C_{3}... \
C_{P}
donde CC es el código del país en
la numeración internacional, (según lo asignado por la Unión
Internacional de Telecomunicaciones), con uno, dos o tres dígitos,
(33 para Francia metropolitana, 362 para la Isla de la Reunión, 44
para el Reino Unido, 1 para los Estados Unidos, ...) y
C_{1}C_{2}C_{3}... C_{P} es el número de teléfono NTEL en el
plan de numeración nacional. El código del país puede ser geográfico
o no geográfico. En el ejemplo precedente, CC = 33 y el
C_{1}C_{2}C_{3}... C_{P} =
145295813.
Por ejemplo, actualmente en Francia, p = 9 y
C_{1}C_{2}C_{3}... C_{P} = Zabpqmcdu, con Z=1, 2, 3, 4, 5, 6
u 8, el 0 siendo agregado para numerar desde Francia
metropolitana.
El código del país CC está presente
explícitamente en el número NTEL que ha sido numerado por el
usuario, o, en su defecto, es configurado implícitamente para ser
el del país donde se encuentra la máquina solicitante H o es
insertado por la aplicación.
En la base BD local de datos de números de
teléfono se registra, en un modo de la realización, uno o varios
planes de numeración nacionales, cada uno asociado al código del
país correspondiente. Los medios DC de control realizan el control
del número NTEL con relación al código CC del país (código del país
o country code en inglés) rechazan la solicitud R en caso negativo
(emisión por ejemplo del mensaje (4), (7) u (8) descrito más
abajo), o, si resulta de este control que el código CC del número
NTEL es uno de los códigos existentes en la base BD, realizan el
control del número NTEL con relación al plan de la numeración que
corresponde al código CC del país del número NTEL de teléfono de
destino de la solicitud R presente en los medios DR. Claro está,
solamente el control del código CC del número NTEL podría ser
realizado según la invención, para eliminar las solicitudes basadas
en códigos que no corresponden a ningún país del código registrado
en la base, (emisión por ejemplo del mensaje (4), (7) u (8)
descrito más abajo).
Cada plan de numeración comprende uno o varios
bloques BN de números de teléfono, que pueden ser delimitados en el
ejemplo francés precedente por un cierto número de primeros dígitos
de los números de teléfono, tales como por la raíz nacional Zabpq
de los números de teléfono, un número que pertenece al bloque BN
cuando los primeros dígitos del número, sin el código CC, son
iguales a aquellos del bloque BN. Sin embargo, cualquier otra regla
lógica de pertenencia de un número a un bloque puede ser prevista,
un número puede pertenecer solamente a un bloque y los bloques del
mismo plan de numeración están separados. Así, un bloque designa de
una manera general un recurso del plan de numeración y contiene uno
o varios números de teléfono, que no se siguen necesariamente. Así,
el número 145295813 pertenece al bloque BN = 14529 pero no al bloque
10050.
Estos bloques son asignados a uno u otro de los
operadores de la telefonía.
En un modo de realización, las características
CAR prescritas de números de bloque son asociadas a cada bloque BN
y son registradas en la base BD de datos local.
En la figura 3, el procedimiento de emisión
según la invención se desarrolla por ejemplo de la manera
siguiente.
Una solicitud R que contiene el número NTEL de
teléfono de destino es recibida en la etapa E10 en los medios DR de
recepción y es transmitida a los medios DC de control.
Se determina a continuación en la etapa E11 por
los medios DC de control, si el número de teléfono NTEL de destino
de la solicitud R pertenece a uno de los bloques BN del plan de
numeración nacional correspondiente a éste en la base BD. Si fue
determinado que el número de teléfono NTEL de destino de la
solicitud R no pertenece a ninguna bloque BN, entonces este número
de teléfono NTEL no pasa el control preliminar con éxito, lo que
los medios DC de control señalan a los medios DE, en la etapa E12
representada en trazos interrumpidos en la figura 3, por un mensaje
NOK de denegación, que hace que los medios DE no transmitan la
solicitud R que contiene este número NTEL de teléfono de destino
hacia los servidores externos 1, 2, 3 de nombres de dominio. Por lo
tanto, los medios DE no transmiten las solicitudes R que contienen
un número NTEL de teléfono de destino que no pertenece a ningún
bloque BN. Por ejemplo actualmente, ningún bloque BN comienza con 7
en Francia (ningún número de teléfono en Francia comienza con 07) y
ningún número francés NTEL comenzando con 07 pasará con éxito el
control ejercido por los medios DC.
Si fue determinado en la etapa E11 que el número
NTEL de teléfono de destino de la solicitud R pertenecía a uno de
los bloques BN de la base BD, se determina en la etapa E13 siguiente
en los medios DC de control a cual bloque BN de la base BD
pertenece el número NTEL de teléfono de destino de la solicitud
R.
Luego, durante la etapa E14 de lectura, se
interroga automáticamente por los medios DC la base BD local sobre
las características CAR asociadas al bloque BN de números
determinados, la cual reenvía a los medios DC a la etapa E15
siguiente las características CAR asociadas a este bloque BN de
números determinado.
Los medios DC verifican seguidamente en la etapa
E16 si el número de teléfono NTEL de destino de la solicitud R está
conforme a dichas características CAR de la base BD. En caso
afirmativo, los medios DC de control envían a la etapa E17
siguiente un mensaje OK de aceptación de la solicitud R a los medios
DE, este mensaje OK de aceptación desencadenando la emisión de la
solicitud R de los medios DE hacia los servidores externos de
nombres de dominio 1, 2, 3 a la etapa E18 siguiente. En caso
negativo, los medios DC de control envían a la etapa E17 siguiente
el mensaje NOK de denegación de la solicitud R a los medios DE, este
mensaje NOK de denegación impide la emisión de la solicitud R de
los medios DE hacia los servidores externos de nombres de dominio 1,
2, 3. Los medios DE envían por lo tanto de la máquina solicitante H
al servidor externo 1, 2, 3 de nombres de dominio la solicitud R
solamente si los medios DC han establecido que el número de teléfono
NTEL de destino de la solicitud R estaba conforme a dichas
características CAR recibidas de la base BD y asociadas en la base
BD al bloque BN de pertenencia del número NTEL.
Las verificaciones son puestas en ejecución por
medios automáticos.
Como es representado en la figura 4, las
características CAR de números de bloque son por ejemplo:
- -
- un final Eres de período de reservación de los números de teléfono del bloque BN,
- -
- una fecha Baff de asignación de los números de teléfono del bloque BN (por ejemplo para una compañía),
- -
- un final Eaff de período de asignación de los números de teléfono de bloque BN,
- -
- una longitud Lmax máxima de los números de teléfono del bloque BN,
- -
- una longitud de Lmin mínima de los números de teléfono del bloque BN,
- -
- una fecha Batt de inicio de la atribución de un bloque BN de números de teléfono,
- -
- una fecha Eatt de final de la atribución de un bloque BN de números de teléfono,
- -
- un identificador Op del operador,
- -
- una zona geográfica Geo,
- -
- otras informaciones Inf.
La reservación de un recurso (bloque) en un plan
de numeración es una decisión tomada por una autoridad que
administra este plan, por ejemplo una autoridad nacional, como en
Francia la Autoridad de Regulación de las Telecomunicaciones (ART),
o internacional, como la Unión Internacional de Telecomunicaciones
(UIT), para conceder a una entidad (operador de telecomunicación,
suministrador de servicios, individuo privado), durante una duración
limitada (hasta Eres), una opción en el uso de venir a este recurso
de numeración. Este recurso no puede entonces ser ni reservado, ni
atribuido a otra parte.
La atribución de un recurso en un plan de
numeración es una decisión tomada por la autoridad que administra
este plan para conceder a una entidad el derecho de utilizar el
recurso, de Batt a Eatt.
La asignación de un recurso en un plan de
numeración consiste en su disposición por la entidad tributaria de
este recurso a un usuario final, eventualmente en el marco del
suministro de un servicio comercial.
El número NTEL es conforme a Eres, si la fecha
actual de la solicitud R es anterior a Eres. El número NTEL es
conforme a Baff, si la fecha actual de la solicitud R es posterior a
Baff. El número NTEL es conforme a Eaff, si la fecha actual de la
solicitud R es anterior a Eaff. El número NTEL es conforme a Lmax si
la longitud de NTEL es inferior o igual a Lmax. El número NTEL es
conforme a Lmin si la longitud de NTEL es superior o igual a Lmin.
El número NTEL es conforme a Batt, si la fecha actual de la
solicitud R es posterior a Batt. El número NTEL es conforme a Eatt,
si la fecha actual de la solicitud R es anterior a Eatt. La fecha de
Baff de asignación permite saber si el número NTEL está en
circulación o lo estará próximamente.
Por lo tanto, una solicitud R recibida en los
medios DR el 10 de diciembre de 2003 y conteniendo un número NTEL
determinado por los medios DC de control como perteneciendo al
bloque BN = 14528 no pasará con éxito este control, puesto que esta
fecha es posterior a Eres = 01/01/2002, así como es indicado en la
figura 4, y la solicitud R correspondiente no será transmitida por
los medios DE de la máquina H a los servidores externos 1, 2, 3 de
nombre de dominio. Por ejemplo, el mensaje (14) descrito más abajo
será transmitido.
Por el contrario, una solicitud R recibida en
los medios DR el 10 de diciembre de 2003 y conteniendo un número
NTEL determinado por los medios DC de control como perteneciendo al
bloque BN = 14529, como NTEL = 33 145295813, pasará sin éxito este
control porque respeta las condiciones correspondientes tales como
son indicadas en la figura 4, y la solicitud R correspondiente será
transmitida por los medios DE de la máquina H a los servidores
externos 1, 2, 3 de nombres de dominio.
El o los planes de numeración de la base BD de
datos están aptos para ser actualizados por cualquier medio
apropiado, en lo que concierne a los bloques BN y a cada una de las
características CAR.
En un modo de puesta en práctica, una señal de
error en el número de teléfono NTEL de destino de la solicitud R es
reenviado desde los medios DC de control a la interfaz usuaria DP de
la máquina solicitante H, el si este número de teléfono NTEL de
destino de la solicitud no pasa con éxito este control preliminar,
por ejemplo con una información sobre la o las
característica(s) CAR de números de bloque, que no son
respetados por el número de teléfono NTEL de destino de la
solicitud R.
Estos mensajes de error pueden ser por ejemplo
los siguientes:
- (1)
- la longitud del número debe estar comprendida entre "Lmin" y "Lmax",
- (2)
- el bloque "BN" no es asignado sino es reservado hasta "Eres",
- (2bis)
- código reservado pero no asignado,
- (3)
- el bloque no es reservado, ni atribuido,
- (3bis)
- sin bloque de pertenencia,
- (4)
- el código CC no es atribuido,
- (5)
- número no ENUM para un código CC para el cual un bloque específico ENUM fue definido,
- (6)
- formato E.164 incorrecto (no numérico): entero de longitud máxima 15 necesaria,
- (7)
- el código CC es atribuido solamente temporalmente o a fines de prueba,
- (8)
- el código CC no es referenciado en la librería de referencia de numeración internacional,
- (9)
- error del número en la fecha Batt de inicio de la atribución,
- (10)
- error del número en la fecha Eatt de fin de la atribución,
- (11)
- error del número en la fecha de Baff de inicio de la asignación,
- (12)
- bloque no asignado por el operador.
Por otra parte, las características CAR pueden
comprender un campo Nat del plan de numeración, pudiendo estar en
Res (reservado), o en Test (atribuido con fines de prueba), o en NA
(no afectable), o en AT, el mismo valor del campo Nat que es válido
para un mismo plan de numeración, por lo tanto para todos los
bloques BN de este plan de numeración. En lo que sigue, los bloques
BN forman, con sus características CAR asociadas, códigos y campos
asociados, líneas en la base BD, así como es representado en la
figura 4.
Verificaciones pueden ser realizadas por ejemplo
según un primer ejemplo representado en trazos continuos en la
figura 5 y descrito más abajo.
Verificaciones pueden ser inicialmente
realizadas con relación a los datos telefónicos internacionales de
la base BD según las etapas, V1, V2, V3, V4, V5, V6 descritas más
abajo, y después con relación a los datos telefónicos nacionales de
la base BD según las etapas, V7, V8, V9, V10, V11, V12 descritas más
abajo, y seguidamente con relación a los datos del operador según
las etapas, V13, V14 y siguientes.
Por ejemplo, se realiza inicialmente la
verificación V1 del número NTEL para saber si tiene un formato
numérico y no comienza con cero, para emitir en caso negativo el
mensaje (5) y en caso afirmativo pasar a la verificación V2
teniendo en cuenta (etapa T1) la base BD completa, también llamada
tabla T en lo que concierne a las líneas de la base BD en las
cuales las verificaciones son realizadas.
En el curso de la verificación V2, se verifica
si existe por lo menos una línea de la base BD, comenzando con el
código CC de NTEL, para en caso negativo emitir el mensaje (8) y en
caso afirmativo pasar a la verificación V3 teniendo en cuenta
(etapa T2) solamente las líneas de la tabla T que comienzan con el
código CC del número NTEL (por ejemplo eliminando en la tabla T
todas las líneas que no comienzan por CC), para que la tabla T
contenga nada más que las líneas del mismo plan de numeración.
En el curso de la verificación V3, se verifica
si el campo Nat de un bloque BN de la tabla T, como por ejemplo la
primera línea de la tabla T, está en Res y si se determina que sí,
se prueba en el curso de la verificación V4 si el campo Eres de
esta línea es indicado, para en caso afirmativo, transmitir el
mensaje (2bis), y, en caso negativo, transmitir el mensaje (4).
En caso negativo a la verificación V3, se
verifica en el curso de la verificación V5 si el campo Nat del
bloque BN del número NTEL está en Test y si se determina que sí, se
transmite el mensaje (7) y si se determina que no se pasa a la
verificación V6.
En el curso de la verificación V6, se verifica
si el campo Nat del bloque BN del número NTEL está en NA y si se
determinado que si, se transmite el mensaje (7) y si ha sido
determinado que no se pasa a la verificación V7.
En el curso de la verificación V7, se verifica
si el campo Nat del bloque BN del número NTEL está en NA y si se
determina que si, se transmite el mensaje (7) y si se determina que
no se pasa a la verificación V7.
En el primer ejemplo, la base BD comprende por
ejemplo intervalos de números (definidos por ejemplo por uno o
varios bloques BN) definidos como comprendiendo números ENUM y otros
intervalos de números (definidos por ejemplo por uno o varios
bloques BN) definidos como no comprendiendo números ENUM, así como
es representado en la figura 4 por el campo "ENUM?" colocado
en BD respectivamente con sí o con no para estos intervalos.
En el curso de la verificación V7, se verifica
si existe en la tabla T una o varias líneas que tienen un campo
ENUM? con sí. En caso afirmativo, se tiene en cuenta en el curso de
la etapa T3 en la tabla T solamente de las líneas donde el campo
ENUM? está con sí, es decir líneas de bloques de números ENUM (por
ejemplo eliminando de la tabla T todas las líneas que tienen un
campo ENUM? con no). Entonces, se elimina de la tabla T en el curso
de la etapa T4 las líneas donde los bloques no corresponden a los
primeros dígitos de NTEL, para seleccionar en la tabla T el bloque
BN de pertenencia de NTEL según la etapa E11 descrita arriba. En
caso afirmativo a la verificación V7 y después de las etapas T3 y
T4, se verifica en el curso de la verificación V8 si la tabla T
está vacía, es decir no pertenece a un bloque BN ENUM, y, en caso
afirmativo, se transmite el mensaje (5). El mensaje (5) traduce el
hecho de que el número NTEL corresponde en la base BD a un intervalo
de números (definidos por ejemplo por unos o varios bloques BN)
definidos como no comprendiendo números ENUM. En caso negativo a la
verificación V8, se pasa a la verificación V10.
En caso negativo a la verificación V7, se pasa a
la etapa T4 de selección del bloque BN de pertenencia del número
NTEL en la tabla T. Luego se realiza la verificación V9 para
determinarse si la tabla T está vacía, es decir si existe tal
bloque BN en la base BD, y, en caso afirmativo se transmite el
mensaje (3bis), mientras que en caso negativo, se pasa a la
verificación V10.
Para la verificación V10, se realizan las etapas
E13, E14 y E15.
La verificación V10 se basa en la conformidad
del número NTEL con Lmin y Lmax, para transmitir el mensaje (1) en
caso negativo y pasar a la verificación V11 en caso afirmativo.
La verificación V11 se basa en la conformidad
del número NTEL con Batt, para transmitir el mensaje (9) en caso
negativo y pasar a la verificación V12 en caso afirmativo. Se
transmite el mensaje (9) cuando, la fecha Batt de inicio de la
atribución no es indicada o es posterior a la fecha actual de la
verificación V11.
La verificación V12 se basa en la conformidad
del número NTEL con Eatt, para transmitir el mensaje (10) en caso
negativo y pasar a la verificación V13 en caso afirmativo. El
mensaje (10) es transmitido a la verificación V12 cuando la fecha
Eatt del final de la atribución es indicada y es anterior a la fecha
actual.
La verificación V13 se basa en la conformidad
del número NTEL con Baff, para transmitir el mensaje (11) en caso
negativo y pasar a la verificación V14 en caso afirmativo. Si la
fecha de Baff de inicio de la asignación es indicada y posterior a
la fecha actual, el mensaje (11) es transmitido a la verificación
V13.
La verificación V14 se basa en el punto de saber
si la fecha Baff de inicio de la asignación está indicada con 0,
para transmitir el mensaje (12) en caso negativo.
Por supuesto, otras verificaciones se pueden
realizar con relación a los datos del operador, tales como aquellos
a continuación.
Un mensaje (13) de sección dedicada no asignada
se transmite cuando, para un bloque BN de fecha Eres de reservación
indicada, la fecha Eres es anterior a la fecha actual.
Si la fecha de Eaff de final de la asignación es
indicada y anterior a la fecha actual, un mensaje (14) de error del
número en la fecha Eaff de final de la asignación es
transmitida.
El mensaje (2) traduce el hecho de que fue
comprobado que el bloque BN del número NTEL no tiene fechas Baff y
Eaff sino una fecha Eres, como para el bloque BN = 630 en la figura
4.
El mensaje (3) traduce el hecho de que fue
comprobado que el bloque BN del número NTEL no tiene una fecha
Eres, ni de fechas atribución Batt y Eatt, como para el bloque 620
en la figura 4.
En un segundo ejemplo, las verificaciones y las
etapas V7, T3 y V8 no son realizadas, se pasa, en caso negativo a
la verificación V6, directamente a la etapa T4 seguida por la
verificación V9 y las verificaciones se detienen en V12, así como
es representado en trazos interrumpidos en la figura 5.
Cuando en los primer y segundo ejemplos, todos
las verificaciones dieron un resultado positivo en el número NTEL y
ningún mensaje de error fue transmitido, el mensaje OK de aceptación
es transmitido a la etapa E17.
Las etapas del procedimiento descrito
previamente son realizadas por un dispositivo informático, en el
caso que el dispositivo de emisión de solicitudes con destino al
servidor DNS situado en la máquina solicitante, bajo la orden de
instrucciones de programa. Por lo tanto, la invención también se
relaciona con un programa informático destinado a ser almacenado o
transmitido por un soporte de datos que comprende instrucciones de
programa para hacer ejecutar el procedimiento por un dispositivo
informático. El soporte de datos puede ser un soporte material de
almacenaje, por ejemplo un CD-ROM, un disquete
magnético o un disco duro, o un soporte transmisible tal como una
señal eléctrica, óptica o de radio.
Claims (14)
1. Procedimiento de emisión de al menos una
solicitud (R) con destino a un servidor (1, 2, 3) de nombres de
dominio desde una máquina solicitante (H),
dicho servidor (1, 2, 3) de nombres de dominio
siendo un servidor de nombres de dominio de numeración telefónica
e164.arpa, cada nombre siendo determinado a partir del número (NTEL)
de teléfono de destino al formato E.164, contenido en la dicha
solicitud (R), de la forma siguiente: se elimina del número de
teléfono E.164, que comprende el código del país, todos los
caracteres no numéricos, se intercalan puntos entre los dígitos, se
invierte el orden de los dígitos y se agrega la cadena
"e164.arpa" al final de los dígitos, el procedimiento estando
caracterizado porque
un control preliminar de la validez del número
(NTEL) de teléfono de destino de la solicitud (R) es realizado
automáticamente y localmente a la máquina solicitante (H) con
relación a una base (BD) de datos de números de teléfono, local a
la máquina solicitante (H), para enviar la solicitud (R) a partir de
la máquina solicitante (H) con destino al servidor (1, 2, 3) de
nombres de dominio solamente si su número (NTEL) de teléfono de
destino pasa con éxito dicho control preliminar.
2. Procedimiento de transmisión de solicitudes
según la reivindicación 1, caracterizado porque en la base
(BD) de datos local está registrado al menos un código (CC) de país
prescrito, y
el control preliminar comprende verificar si el
código (CC) de país del número (NTEL) de teléfono de destino de la
solicitud (R) es uno registrado en la base (BD) de datos local.
3. Procedimiento de transmisión de solicitudes
según la reivindicación 1 o 2, caracterizado porque en la
base (BD) local de datos de números de teléfono está registrado al
menos un plan de numeración, cada plan de numeración comprendiendo
al menos un bloque (BN) de números de teléfono,
el control preliminar comprende:
determinar, en el curso de una etapa (E11) de
determinación, si el número (NTEL) de teléfono de destino de la
solicitud (R) pertenece a un bloque (BN) del plan de numeración, el
número (NTEL) de teléfono de destino de la solicitud (R) no pasando
con éxito (E12) dicho control preliminar en caso negativo a la etapa
(E11) de determinación.
4. Procedimiento de transmisión de solicitudes
según la reivindicación 3, caracterizado porque el plan de
numeración está asociado a un código (CC) de país,
el plan de numeración que corresponde al código
de país del número (NTEL) de teléfono de destino de la solicitud
(R) siendo aquel con relación al cual el control preliminar es
realizado.
5. Procedimiento de transmisión de solicitudes
según la reivindicación 3 o 4, caracterizado porque una
pluralidad de bloques (BN) separados de números de teléfono, a los
cuales están asociadas respectivamente características (CAR)
prescritas de números del bloque, es registrada en la base (BD) de
datos local,
dicha etapa de determinación comprende por otra
parte determinar (E13), a cual bloque (BN) de números de teléfono
de la base (BD) de datos local el número (NTEL) de teléfono de
destino de la solicitud (R) pertenece,
en el caso que fue determinado que el número
(NTEL) de teléfono de destino de la solicitud (R) pertenece a un
bloque (BN) del plan de numeración,
leer (E14, E15) en la base (BD) de datos local
las características (CAR) asociadas al bloque (BN) de numeración
determinado,
verificar (E16) si el número (NTEL) de teléfono
de destino de la solicitud (R) está conforme a dichas
características (CAR) leídas,
enviar (E18) de la máquina solicitante (H) al
servidor (1, 2, 3) de nombres de dominio la solicitud (R) solamente
si la verificación da un resultado afirmativo.
6. Procedimiento de transmisión de solicitudes
según la reivindicación 5, caracterizado porque
las características (CAR) de números de bloque
son al menos una entre:
- -
- una fecha (Bres) de reservación de los números de teléfono del bloque,
- -
- un final (Eres) de período de reservación de los números de teléfono del bloque,
- -
- una fecha (Baff) de asignación de los números de teléfono del bloque,
- -
- un final (Eaff) de período de asignación de los números de teléfono del bloque,
- -
- una fecha (Batt) de inicio de atribución del bloque (BN) de números de teléfono,
- -
- una fecha (Eatt) de final de atribución del bloque (BN) de números de teléfono,
- -
- una longitud (Lmax) máxima de los números de teléfono del bloque,
- -
- una longitud (Lmin) mínima de los números de teléfono del bloque.
7. Procedimiento de transmisión de solicitudes
según una de las reivindicaciones precedentes, caracterizado
porque si el número (NTEL) de teléfono de destino de la solicitud
(R) no pasa con éxito dicho control preliminar, una señal de error
en el número (NTEL) del teléfono de destino de la solicitud (R) es
enviado a la máquina solicitante (H).
8. Procedimiento de transmisión de solicitudes
según la reivindicación 7 y una de las reivindicaciones 5 y 6,
caracterizado porque la señal del error en el número de
teléfono de destino de la solicitud (R) contiene una información
sobre la o las característica(s) (CAR) de números de bloque,
que no son respetados por el número (NTEL) de teléfono de destino
de la solicitud (R) durante dicha verificación (E16).
9. Dispositivo de emisión de al menos una
solicitud (R) con destino a un servidor (1, 2, 3) de nombres de
dominio desde una máquina solicitante (H),
dicho servidor (1, 2, 3) de nombres de dominio
siendo un servidor de nombres de dominio de numeración telefónica
e164.arpa, cada nombre siendo determinado a partir del número (NTEL)
de teléfono de destino al formato E.164, contenido en dicha
solicitud (R), de la forma siguiente: se elimina del número de
teléfono E.164 que comprende el código del país, todos los
caracteres no numéricos, se intercalan puntos entre los dígitos, se
invierte el orden de los dígitos y se agrega la cadena
"e164.arpa" al final de los dígitos,
caracterizado porque el dispositivo es
local a la máquina solicitante (H) y comprende:
medios (DR) de recepción de la solicitud (R)
desde la máquina solicitante (H),
una base (BD) de datos de números de
teléfono,
medios (DC) de control automático de la validez
del número (NTEL) de teléfono de destino de la solicitud (R),
presente en los medios (DR) de recepción con relación a los datos
resultantes de la base (BD) de datos de números de teléfono, y
medios para enviar la solicitud (R) de la
máquina solicitante (H) con destino al servidor (1, 2, 3) de nombres
de dominio solamente si los medios (DC) de control determinaron que
su número (NTEL) de teléfono de destino pasa con éxito dicho
control de validez.
10. Dispositivo de emisión según la
reivindicación 9, caracterizado porque los medios (DR) de
recepción, la base (BD) de datos de números de teléfono, los medios
(DC) de control automático y los medios (DE) de envío están
presentes en la máquina solicitante (H).
11. Dispositivo de emisión según la
reivindicación 10, caracterizado porque los medios (DR) de
recepción, los medios (DC) de control automático y los medios (DE)
de envío está presente en la máquina solicitante (H) y la base (BD)
de datos de números de teléfono es interrogable por los medios (DC)
de control automático por medio de una red local (RL).
12. Máquina solicitante que comprende un
dispositivo de emisión de al menos una solicitud según cualquiera
de las reivindicaciones 9 a 11.
13. Programa informático, destinado para ser
almacenado en un soporte de datos y comprendiendo instrucciones de
programa para hacer ejecutar el procedimiento de emisión de al menos
una solicitud según cualquiera de las reivindicaciones 1 a 8.
14. Sistema que comprende al menos un servidor
(1, 2, 3) de nombres de dominio de numeración telefónica e164.arpa
y una pluralidad de máquinas solicitantes (H) según la
reivindicación 12, aptas para enviar al menos una solicitud con
destino a dicho servidor (1, 2, 3).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0315015 | 2003-12-19 | ||
| FR0315015 | 2003-12-19 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2291970T3 true ES2291970T3 (es) | 2008-03-01 |
Family
ID=34778515
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04805642T Active ES2291970T3 (es) | 2003-12-19 | 2004-12-03 | Procedimiento y dispositivo de emision de solicitudes hacia un servidor de nombres de dominio desde una maquina solicitante. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7961852B2 (es) |
| EP (1) | EP1695523B1 (es) |
| AT (1) | ATE370606T1 (es) |
| DE (1) | DE602004008335T2 (es) |
| ES (1) | ES2291970T3 (es) |
| WO (1) | WO2005069581A1 (es) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102004023634B4 (de) * | 2004-05-10 | 2007-09-27 | Siemens Ag | Verfahren zur Vollständigkeits- und Konsistenzprüfung einer Informationsbibliothek |
| US8358768B2 (en) * | 2006-08-25 | 2013-01-22 | Tekelec, Inc. | Methods, systems, and computer program products for providing a country code identifier in an international ENUM system |
| US8239422B2 (en) * | 2007-10-18 | 2012-08-07 | At&T Intellectual Property I, Lp | Methods and apparatus to provision network resource records |
| US8170190B2 (en) * | 2007-12-20 | 2012-05-01 | Verizon Patent And Licensing Inc. | Method and system for managing telephone number allocation |
| US8079820B2 (en) | 2008-12-18 | 2011-12-20 | General Electric Company | Blade module, a modular rotor blade and a method for assembling a modular rotor blade |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5590181A (en) * | 1993-10-15 | 1996-12-31 | Link Usa Corporation | Call-processing system and method |
| US5937053A (en) * | 1996-01-11 | 1999-08-10 | Telcordia Technologies, Inc. | System and method for processing international telephone numbers |
| GB9603590D0 (en) | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing a target entity over a communciations network |
| US6169911B1 (en) * | 1997-09-26 | 2001-01-02 | Sun Microsystems, Inc. | Graphical user interface for a portable telephone |
| WO2001013259A1 (en) * | 1999-08-13 | 2001-02-22 | Iradius. Com, Inc. | Personal web platform service and system |
| AU2001284644A1 (en) * | 2000-08-16 | 2002-02-25 | Verisign, Inc. | A numeric/voice name internet access architecture and methodology |
| US6917612B2 (en) * | 2000-09-01 | 2005-07-12 | Telefonaktiebolaged L M Ericsson | System and method for address resolution in internet protocol (IP)-based networks |
| US20020076027A1 (en) * | 2000-12-20 | 2002-06-20 | Nortel Networks Limited | Fallback to message compose on synchronous call attempt |
| US6947738B2 (en) * | 2001-01-18 | 2005-09-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Multimedia messaging service routing system and method |
| US7027582B2 (en) * | 2001-07-06 | 2006-04-11 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for resolving an entity identifier into an internet address using a domain name system (DNS) server and an entity identifier portability database |
| US6839421B2 (en) * | 2001-10-29 | 2005-01-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus to carry out resolution of entity identifier in circuit-switched networks by using a domain name system |
| US6865266B1 (en) * | 2002-01-16 | 2005-03-08 | Verizon Services Corp. | Methods and apparatus for transferring from a PSTN to a VOIP telephone network |
| US6968050B1 (en) * | 2002-03-27 | 2005-11-22 | Verizon Services Corp. | Methods and apparatus for authenticating and authorizing ENUM registrants |
| US7320026B2 (en) * | 2002-06-27 | 2008-01-15 | At&T Bls Intellectual Property, Inc. | Intersystem messaging using ENUM standard |
-
2004
- 2004-12-03 EP EP04805642A patent/EP1695523B1/fr not_active Not-in-force
- 2004-12-03 ES ES04805642T patent/ES2291970T3/es active Active
- 2004-12-03 DE DE602004008335T patent/DE602004008335T2/de active Active
- 2004-12-03 WO PCT/FR2004/003123 patent/WO2005069581A1/fr active IP Right Grant
- 2004-12-03 US US10/583,589 patent/US7961852B2/en not_active Expired - Fee Related
- 2004-12-03 AT AT04805642T patent/ATE370606T1/de not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| ATE370606T1 (de) | 2007-09-15 |
| DE602004008335D1 (de) | 2007-09-27 |
| US20070121794A1 (en) | 2007-05-31 |
| EP1695523A1 (fr) | 2006-08-30 |
| EP1695523B1 (fr) | 2007-08-15 |
| WO2005069581A1 (fr) | 2005-07-28 |
| DE602004008335T2 (de) | 2008-05-08 |
| US7961852B2 (en) | 2011-06-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2271340T3 (es) | Metodo y aparato para determinar un identificador de entidades. | |
| US7124102B2 (en) | Method and apparatus for determining a unique communication identifier | |
| ES2930109T3 (es) | Método, aparato y producto de programa informático, para descubrir servicios en una red de telecomunicación proporcionados por una función de red, NF, en una red de telecomunicación basada en una arquitectura Basada en Servicios, SBA | |
| US7373426B2 (en) | Network system using name server with pseudo host name and pseudo IP address generation function | |
| ES2292676T3 (es) | Metodo y sistema para facilitar el acceso a una cuenta de correo electronico a traves de una red de comunicacon movil. | |
| FI108388B (fi) | Sõhk÷postiliikenne matkaviestinjõrjestelmõssõ | |
| KR100369939B1 (ko) | 전화번호를 이용한 아이피브이6 인터넷 주소 자동생성방법 및 획득방법 | |
| ES2353215T3 (es) | Establecimiento de la conexion inicial en un sistema de comunicacion inalambrica. | |
| ATE225112T1 (de) | Vielfachsystem-teilnehmeridentifizierungsmodul | |
| ES2436513T3 (es) | Equilibrio de carga en una red de comunicación | |
| US20040192252A1 (en) | Emergency packet data network communication system and call features | |
| US8605736B2 (en) | Method, system and apparatus for heterogeneous addressing mapping | |
| ES2291970T3 (es) | Procedimiento y dispositivo de emision de solicitudes hacia un servidor de nombres de dominio desde una maquina solicitante. | |
| US11540347B2 (en) | Interworking between mobile railway networks and GSM networks | |
| ES2393943T3 (es) | Aparato y método para generar y transmitir un identificador de encaminamiento anónimo para mantener la privacidad de la identidad de un agente de usuario de sip | |
| CA2474573A1 (en) | Dialing using indirect addressing methods | |
| WO2003009546A1 (es) | Sistema de nombramientos de dominios (dns) para acceso a bases de datos | |
| ES2437290T3 (es) | Procedimiento para determinar un dominio para identidades de un grupo cerrado de abonados para un acceso abierto a la red | |
| ES2522572T3 (es) | Procedimiento, unidad de comunicación y sistema para identificar un servicio | |
| ES2649551T3 (es) | Procedimiento para retransmitir mensajes de emergencia de un aparato terminal en una red de comunicaciones | |
| US20150148009A1 (en) | Secure deployment of terminals in a wireless network | |
| PT1547423E (pt) | Método para proporcionar a um cliente de rede móvel características de funcionamento específicas do serviço de diferentes operadoras de rede radiotelefónica móvel. | |
| ES2217953B1 (es) | Sistema y metodo de direccionamiento de redes utilizando numeros de telefono. | |
| ES2320362T3 (es) | Procedimiento de direccionamiento de una red ip que se conecta a otra red ip. | |
| WO2001086470A1 (en) | Allocation of internet addresses using global network naming |