A utilização de registros no DNS (Domain Name Service) para utilização de auto descoberta de serviços na rede é muito comum, além de proporcionar balanceamento de carga e servidores backup (failover).

Embora não seja obrigatório, o uso de registros no DNS para utilização do VoIP permite uma maior flexibilidade na configuração de apontamento para servidores e reduz futura manutenção dos terminais de voz sobre IP.

Como o protocolo SIP pode ser utilizado de diversas formas (UDP, TCP, TCP com criptografia, entre outros), apenas uma requisição de DNS sobre um host (padrão “A” no DNS) não informa muita coisa sobre qual protocolo, servidor e porta utilizar. Registros Network Authority Pointment (NAPTR) são comumente utilizados em conjunto com registros Services (SRV) para descoberta de quais tipos de serviços estão disponíveis, assim como quais endereços de servidores e portas devem ser utilizados.

Devido a utilização de domínio no protocolo SIP, clientes podem utilizar o DNS para descobrir o tipo de protocolo, servidor e porta a conectar. Tomamos por exemplo uma chamada para SIP:+5551992425885@voipdomain.io. Apenas com esta informação não sabemos qual tipo de conexão (se SIP, pode ser UDP, TCP, TCP com criptografia, etc, assim como pode utilizar H.323, IAX, IAX2, entre outros) devemos utilizar, assim como servidor e porta responsável por realizar a conexão ao destino desejado. Para descobrir estas questões, inicia-se requisitando os registros NAPTR do domínio voipdomain.io, onde obtemos:

voipdomain.io IN NAPTR 10 100 "S" "SIP+D2U" "" _sip._udp.voipdomain.io.
voipdomain.io IN NAPTR 20 100 "S" "SIP+D2T" "" _sip._tcp.voipdomain.io.
voipdomain.io IN NAPTR 30 100 "S" "E2U+email" "!^.*$!mailto:contact@voipdomain.io!i" _sip._tcp.voipdomain.io.

Para entendermos melhor os três registros acima, eles são compostos dos seguintes campos:

  • Domínio (a qual o registro pertence);
  • IN NAPTR tipo de regitro;
  • 10, 20 ou 30 é a preferência do registro, sendo que quanto menor o valor, maior a prioridade;
  • 100 é o peso, sendo que quanto menor o valor, maior a prioridade. O peso só é utilizado para ordenar a prioridade de registros com o mesmo valor de preferência (utilizado para failover);
  • “S” é a sinalização de tipo de serviço, onde temos quatro possíveis opções:
    • “S” para serviços, e define que registro do tipo SRV deve ser requisitado para o endereço informado;
    • “A”, “AAAA” ou “A6” para endereços comuns de IPv4 ou IPv6;
    • “U” para endereços absolutos de internet (URI), e indica que o endereço informado é a URI que o aplicativo deve acessar;
    • “P” para “não-terminais”, ou seja, uma regra que aponta para outros NAPTR, e que é específico para algumas aplicações que utilizam expressões regulares (falaremos mais sobre isto abaixo).
  • ”” e “!^.*$!mailto:contact@voipdomain.io!i” são as expressões regulares que devem ser utilizadas no endereço requisitado, ou seja, no serviço “E2U+email”, deve-se aplicar a expressão regular, que troca quaisquer valor informado pelo texto “mailto:contact@voipdomain.io”;
  • _SERVIÇO._PROTOCOLO.domínio é o apontamento final ou não-terminal para onde deve ser realizado mais operações (consulta SRV, outros NAPTR, etc).

Baseado nestas informações, a resposta do domínio aponta para três formas de entrar em contato com o domínio voipdomain.io, sendo a primeira preferência (10), com poso 100 de ordenação (números mais baixos tanto para preferência quanto peso possuem maior prioridade e prioridade só é utilizando quando existir mais de um registro com o mesmo valor de preferência), o serviço (S) “SIP+D2U”, que significa SIP sobre UDP, e apontando para _sip._udp.voipdomain.io para maiores informações. Para descobrirmos mais detalhes (endereço do servidor e porta) requisitamos o apontamento SRV deste endereço (veremos mais adiante detalhes de apontamentos SRV).

Next we have the “services” field, “SIP+D2U”, “SIP+D2T” and “E2U+email” in the example above. “SIP+D2U” is SIP over UDP, “SIP+D2T” is SIP over TCP and (you guessed it) “E2U+email” stands for email. This is the application specific service optios we have to reach example.com.

It might be hard to notice the next field, “”, because there is nothing there, but this is the “regular expression” field. The regular expression is used to mutate the original request (in this case “example.com”) into something new. We’re not using it here but you could use this to substitute the entire name or parts of the name used in the original query. (NOTE: These are NOT cumulative. You would never use a regular expression on the output of a NAPTR lookup, only on the original query.)

The last item we have is the “replacement”. In the first result from our example above, we have “_sip._udp.example.com”. Regular expressions and replacements are mutually exclusive. If you have one, you shouldn’t have the other. The replacement is used as the “result” of the NAPTR lookup instead of mutating the original request as the regular expression in the paragraph above.

That’s all of our fields. So because we have the “S” designation in the “flag” field, our next step is to find the SRV record for the replacement “_sip._udp.example.com”.

host -t SRV _sip._udp.example.com

_sip._udp.example.com SRV 5 100 5060 sip-udp01.example.com. _sip._udp.example.com SRV 10 100 5060 sip-udp02.example.com.

We get two answers here so first we’ll try sip-udp01.example.com because it has the lower of the two priorities. (priority 5 before priority 10. 100 is the weight which is used to differentiate between records of the same priority.) Next we do an “A” record lookup to find the IP of the server to use to send our SIP INVITE.

host sip-udp01.example.com

sip-udp01.example.com has address 11.22.33.44

So in this example, our top preference would be to send a SIP INVITE via UDP to port 5060 on 11.22.33.44. Failing that, we would look up the IP for the other SRV response (sip-udp02.example.com) and hit that via UDP on port 5060 as well. Failing all of that, we would go back to the next response we got via the original NAPTR lookup and do an SRV lookup on _sip._tcp.example.com and presumably try a TCP connection to some other server and port combination. And lastly, failing all of that, the last response from the NAPTR lookup has us sending an email to info@example.com.

Of course this usually isn’t done on the command line, but by an application. It is handy, however, to see how you can mimic the requests a VoIP application is going to make for illustration and troubleshooting purposes.

Not all clients will be able to speak all protocols so you should try to supply some alternate methods of contact in your NAPTR response rather than just one protocol in practical implementations. This could become particularly interesting in a fully IP world when, for example, my “contact info” is anders@example.com. The NAPTR record would return several ways for me to be contacted perhaps via VoIP, an IM option and lastly an email option. Remember, VoIP calls aren’t restricted to numbers only, so as long as a client supports it, NAPTR allows for your email address to also be your VoIP “number”.

While most major DNS server packages out there today support NAPTR and SRV records natively, some do not. In the case of djbdns’s tinydns authoritative nameserver, there is a patch for NAPTR support but you can also describe NAPTR records in the generic record format. There is a djbdns NAPTR record builder that creates NAPTR records in the generic syntax for use with an unpatched djbdns tinydns server.

Note: Be aware that some applications (such as OpenSER / OpenSIPS) prepend the protocol information (_sip._tcp or _sip._udp) to names automatically before doing the SRV lookups. Check your nameserver log to see what clients are asking for.

SIP can be run, for example, over UDP, TCP or TCP with TLS (SSL) encryption however standard “A” DNS record lookups won’t tell you anything about which of these protocols to use. NAPTR records are commonly used with SIP in conjunction with SRV records to discover what types of service are available for a name, (such as SIP, email or web) what name to use for an SRV lookup and (using the SRV record) what port and “A” records to use to find the IP for the service. That might come off sounding somewhat complicated so lets take a look at the entire process through an example.

Lets consider a call to 2125551212@example.com. Given only this address though, we don’t know what IP address, port or protocol to send this call to. We don’t even know if example.com supports SIP or some other VoIP protocol like H.323 or IAX2. I’m implying that we’re interested in placing a call to this URL but if no VoIP service is supported, we could just as easily fall back to emailing this user instead. To find out, we start with a NAPTR record lookup for the domain we were given: A documentação original pode ser obtida no site da ITU-T, aqui.

O formato de um número no padrão E.164 é precedido pelo prefixo de chamada internacional (sinal de mais), pelo código do país (de 1 a 3 dígitos), pelo código de área (quando existente) e o número do assinante.

Um número no padrão E.164 pode ter no máximo 15 dígitos (sem o prefixo). Por ser um padrão que pode ser aplicado em todo mundo, o VoIP Domain escolheu esta padronização para basear todos os números públicos do sistema. Em todos relatórios e configurações, será utilizado este padrão, mesmo para ligações locais.

Abaixo, um exemplo de número no padrão E.164:

+55 51 992425885

Onde, + é o prefixo de chamada internacional, 55 é o código do Brasil, 51 é o código de área do estado do Rio Grande do Sul e 992425885 é o número do assinante.

Através de informações da base de dados da ITU-T fornecida por cada país, podemos ter mais informações sobre o número, tal como o código de área e que este número é um terminal móvel (telefone celular). Muitas informações podem ser obtidas nestas documentações, que podem ser acessadas aqui. O VoIP Domain já possui uma base de dados com as informações disponibilizadas pela ITU-T, podendo ter mais informações sobre um número.

O sistema utiliza estas informações para bilhetagem, visto que muitos países possuem tarifas diferentes baseadas no tipo de número discado, tais como telefone móvel, fixo, via satélite, entre outros.

Os termos utilizados pela ITU-T para o padrão E.164 são os seguintes:

  • CC - Country Code: Código do país (de 1 a 3 dígitos)
  • NDC - National Destination Code: Código de área
  • N(S)N - National (Significant) Number: Número completo excluindo o código do país
  • SN - Subscriber Number: Número do assinante