Tipos de rotas

De opensipsbrasil - wiki
Revisão de 22h36min de 6 de outubro de 2013 por Mike (discussão | contribs) (Criou página com '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==...')
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)
Ir para navegação Ir para pesquisar

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

The local route is executed automatically when a new SIP request is generated by TM, internally (no UAC side). This is a route intended to be used for message inspection, accounting and for applying last changes on the message headers. Routing and signaling functions are not allowed.

Triggered by : TM generating a brand new request

Processing : the new request

Type : stateful

Default action : send the request out


[@ 

 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

The startup_route is executed only once when OpenSIPS is started and before the processing of SIP messages begins. This is useful if some initiation actions are needed, like loading some data in the cache, to ease up the future processing. Notice that this route, compared to the others is not triggered at the receipt of a message, so the functions that can be called here must not do processing on the message.

Triggered : At startup, before the listener processes are started.

Processing : Initializing functions.


[@ 

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

@]

!!!!timer_route

The timer_route is as the name suggests, a route executed periodically at a configured interval of time specified next to the name(in seconds). The same as the startup_route, this route does not process a message. You can defined more timer routes.


Triggered by : The time keeper.

Processing : Functions that do refresh actions.


[@ 

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

@]

!!!! event_route The event_route is used by the OpenSIPS Event Interface to execute script code when an event is triggered. The name of the route is the event that has to be handled by that route.

Triggered by : the [| event_route ] module when an event raised by the OpenSIPS Event Interface

Processing : the event triggered

Type : stateless (recommended)

Default action : no script code is executed when the event is raised.

[@ 

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

@]

#comment1(:nl:)>>messagehead<< !!!!!~Stomaz — [-22 November 2012, 19:13-] >>messageitem<< Very good!! Is very util for me! Im starting in OpenSipS. Tanks!! >><<

Disponível em “http://opensips.com.br/wiki/index.php?title=Tipos_de_rotas&oldid=1448”