Tipos de rotas

O OpenSIPS possue diversos tipos de rota, cada rota é acionada por um certo evento e permite que você process um certo tipo de mensagem (request ou reply)

route

O Bloco de roteamento de requisições (Request routing block) contém algumas ações a serem tomadas em uma requisição SIP

• Ativado por (triggered by): recebendo uma requisição da rede
• Processamento (processing): a requisição que gera a ativação
• Tipo (type): inicialmente stateless, mas pode ser forçada para tornar-se stateful utilizando as funções do TM
• Ação padrão (default action): Se a requisição ainda não foi encaminhada ou respondida a rota irá simplesmente discartar a requisição no fim

O bloco de roteamento principal é identificado por 'route{...}' ou 'route[0]{....}' e é executado por cada requisição.

A ação implicita após a execução do bloco principal é finalizar a requisição, para enviar uma resposta ou encaminhar a requisição as ações devem ser chamadas dentro do bloco de roteamento

Exemplo de uso:

   route {
        if(is_method("OPTIONS")) {
           # send reply for each options request
           sl_send_reply("200", "ok");
           exit();
        }
        route(1);
   }
   route[1] {
        # forward according to uri
        forward();
   }

Veja que se a 'route(X)' é chamada de uma 'branch_route[Y]' então a 'rota[X]' irá processar cada perna (lado) separadamente invés de todas as partes juntas como ocorre na rota principal (main route)

branch_route

O bloco de roteamento branch contém algumas ações que são processadas para cada perna (branch) da requisição

• Ativado por (triggered by): preparação de uma nova perna (da requisição), os lados (cada perna) está devidamente formado mas ainda não enviado.
• Processando (processing): a requisição sip (com as particularidade de cada perna como RURI e branch flags)
• Tipo (type): stateful
• Ação padrão (default action): se a perna não foi derrubada (via drop) a perna será automaticamente enviada

Este bloco é executado apenas pelo módulo TM após este ser definido via t_on_branch('nome ou numero da rota');

Exemplo de uso:

   route {
       lookup("location");
       t_on_branch("1");
       if(!t_relay()) {
           sl_send_reply("500", "relaying failed");
       }
   }
   branch_route[1] {
       if(uri=~"10\.10\.10].10") {
           # discard branches that go to 10.10.10.10
           drop();
       }
   }

failure_route

Bloco para roteamento de transações com falha, este contém uma série de ações a serem tomadas para cada transação que recebe apenas repostas negativas (>=300) para todas as pernas

• Ativado por (triggered by): recebimento ou geração (nterno neste caso) de um reply negativo para completar a tranasação (todas as pernas são terminadas com replies negativos)
• Processando (processing): a requisição horiginal (que foi enviada)
• Tipo (type): stateful
• Ação default: Se nao for gerada uma nova perna ou nenhum reply é forçado por padrão o reply será enviado de volta para o UAC

A 'failure_route' é executada apenas pelo módulo TM após este ser armado através da função t_on_failure("nome ou numero da rota").

Veja que a 'failure_route' é processada na requisição que iniciou a transação, não no reply.

Exemplo de uso:

   route {
       lookup("location");
       t_on_failure("1");
       if(!t_relay()) {
           sl_send_reply("500", "relaying failed");
       }
   }
   failure_route[1] {
       if(is_method("INVITE")) {
            # call failed - relay to voice mail
            t_relay("udp:voicemail.server.com:5060");
       }
   }

onreply_route

Bloco de roteamento de resposta (reply), este contém algumas ações executadas para os replies.

• Ativado por (triggered by): receber um reply da rede
• Processando (processing): o reply recebido
• tipo (type): stateful (se pertencer a uma transação) ou stateless (se estiver no reply global)
• Ação padrão (default action): Se o reply não é descartado (apenas replies temporarios podem) então será injetado e processado pela engine de transação

Existem alguns tipos de rotas onreply:

• global: recebe qualquer reply recebido pelo OpenSIPS e não precisa de nenhuma definição especifica , apenas 'onreply_route{...}' ou 'onreply_route[0]{...}' é suficiente

• por request/transação: manipula todos os replies que pertençam a uma certa transação e precisa ser definida durante o request (via 't_on_reply()' , no script deve ser criada como 'onreply_route[N] {...}.

• por perna (branch): manipula apenas os replies que pertençam a uma certa perna (branch) da transação, precisa ser definida 't_on_reply()' durante a requisição, mas em uma BRANCH ROUTE, para processar quando uma perna é processada , o nome deve ser 'onreply_route[N]{....}'

Alguns blocos 'onreply_route' podem ser executados pelo módulo TM para alguns replies especiais, para isso a 'onreply_route' deve ser definida para a requisição cuja resposta deve ser processada dentro desta, através do t_on_reply("nome ou numero da rota").

Exemplos de uso:

 route {
        seturi("sip:bob@opensips.org");  # first branch
        append_branch("sip:alice@opensips.org"); # second branch

        t_on_reply("global"); # the "global" reply route
                              # is set the whole transaction
        t_on_branch("1");

        t_relay();
 }

 branch_route[1] {
        if ($rU=="alice")
                t_on_reply("alice"); # the "alice" reply route
                                      # is set only for second branch
 }

 onreply_route {
        xlog("OpenSIPS received a reply from $si\n");
 }


 onreply_route[alice] {
        xlog("received reply on the branch from alice\n");
 }

 onreply_route[global] {
        if (t_check_status("1[0-9][0-9]")) {
                setflag(1);
                log("provisional reply received\n");
                if (t_check_status("183"))
                        drop;
        }
 }

error_route

A error route é executada automaticamente quando um erro de execução acontece no processamento de uma requisição, isso permite ao administrador decidir oque fazer em caso de erro, abaixo as ações.

• Acionado por (triggered by): Erro na rota
• Porcessando (processing): uma requisição que falhou
• Tipo (type): stateless (recomendado)
• Ação Default (default action): descarta a requisição

Na error_route as seguintes pseudo-variaveis estão disponiveis para acesso dos detalhes:

• $(err.class) - Classe de erro ( Atualmente '1' para tratamento de erro)
• $(err.level) - Nivel de severidade do erro
• $(err.info) - Texto descrevendo o erro
• $(err.rcode) - Reply recomendado para o erro
• $(err.rreason) - Frase com razão do erro recomendada para o reply

Exemplos de uso:

 error_route {
    xlog("--- error route class=$(err.class) level=$(err.level)
           info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n");
    xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n");
    sl_send_reply("$err.rcode", "$err.rreason");
    exit;
 }

local_route

A rota local é executada automaticamente quando uma nova requisição é gerada pelo módulo TM internamente. Esta é uma rota que tem a intenção de ser utilizada para inspeção de mensagens, accounting e para aplicação de últimas alterações em cabeçalhos, funções de sinalização e roteamento não são permitidas.

• Ativado por (triggered by): TM gerando uma nova requisição
• Processamento (processing): uma nova requisição
• Tipo: stateful
• Ação default: enviar o request pra fora

 local_route {
    if (is_method("INVITE") && $ru=~"@foreign.com") {
       append_hf("P-hint: foreign request\r\n");
       exit;
    }
    if (is_method("BYE") ) {
       acc_log_request("internally generated BYE");
    }
 }

startup_route

A startup_route é executada apenas quando o OpenSIPS é iniciado, antes do processamento de mensagens SIP começar, isso é útil se algumas ações de inicialização são necessárias, como carregar dados no cache para facilitar o uso para processamento no futura, veja que esta rota diferente das demais não é ativada pelo recebimento de uma mensagem, então a função pode ser utilizada aqui mas não fará o processamento de mensagem.

• Ativado por (triggered by): Inicialização do sistema, antes dos listeners serem iniciado
• Processando (processing): Funções de inicialização

Exemplo de uso:

 startup_route {
   avp_db_query("select gwlist where ruleid==1",$avp(i:100));
   cache_store("local", "rule1", "$avp(i:100)");
 }

timer_route

As timer_route são como o nome sugere, uma rota que é executada periódicamente num intervalo de tempo especificado (em segundos), assim como a startup_route ésta rota não processa mensagens, você pode ter mais de uma 'timer_route' definida.

• Ativada por (triggered by): ativado pelo time keeper
• Processand (processing): Funções que atualizam ações

Exemplo e uso:

 timer_route[gw_update, 300] {
   avp_db_query("select gwlist where ruleid==1",$avp(i:100));
   $shv(i:100) =$avp(i:100);
 }

event_route

A event_route é utilizada pela interface de eventos do OpenSIPS para executar uma função do script quando um evento é acionado, o nome da rota é o nome do evento que a mesma deve manipular.

• Ativado por (triggered by): Módulo event route quando um evento acontece
• Processando (processing): o evento ativado
• Tipo (type): stateless (recomendado)
• Ação Default: nenhum script é executado quando acontece um evento

Exemplo de uso:

 event_route[E_PIKE_BLOCKED] {
   xlog("The E_PIKE_BLOCKED event was raised\n");
 }

Voltar