RFC 3261 Português Página 150

RFC 3261 SIP: Session Initiation Protocol Junho 2002

O parâmetro transport determina o mecanismo de transporte a ser usado no envio de mensagens SIP, conforme especificado em [4]. O SIP pode usar qualquer protocolo de transporte de rede. Os nomes dos parâmetros são definidos para UDP (RFC 768 [14]), TCP (RFC 761 [15]), e SCTP (RFC 2960 [16]). Para um URI do SIPS, o parâmetro transport PRECISA indicar um transporte confiável.

O parâmetro maddr indica o endereço do servidor a ser contactado por esse usuário, substituindo qualquer endereço derivado do campo host. Quando um parâmetro maddr estiver presente, os componentes porta e transporte da URI se aplicam ao endereço indicado no valor do parâmetro maddr. [4] descreve a interpretação adequada do transporte, maddr e hostport a fim de obter o endereço destino, porta e transporte para envii de uma requisição.

O campo maddr foi usado como uma forma simples de roteamento fruxo por origem. Ele permite a um URI especificar um proxy que precisa ser atravessado em rota ao destino. Continuar a usar o parâmetro maddr dessa forma é fortemente desencorajado (os mecanismos que o permitem estão depreciados). Implementações devem usar o mecanismo Route descrito neste documento, estabelecendo um conjunto de rota pré-existentes, se necessário (ver Seção 8.1.1.1). Isto fornece um URI completo para descrever o nó a ser atravessado.

O parâmetro ttl determina o valor time-to-live do pacote multicast UDP e PRECISA só ser usado se maddr for um endereço multicast e protocolo de transporte for o UDP. Por exemplo, especificar uma chamada para alice@atlanta.com usando multicast para 239.255.255.1 com valor TTL 15, o URI seguinte seria usado:

sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15

O conjunto de strings válidas de assinante telefônico é um subconjunto de strings válidas de usuário. O parâmetro URI user existe para distinguir números de telefones de nomes de usuário que acontecer se parecer com números de telefone. Se a string de usuário contiver um número de telefone formatado como um assinante de telefone, o valor "phone" do parâmetro user DEVE estar presente. Mesmo sem esse parâmetro, destinatários de URI's do SIP e do SIPS PODEM interpretar a parte pré-@ como um número de telefone, se restrições locais no espaço de nome para nome de usuário permiti-lo.

O método da requisição SIP construído a partir do URI pode ser especificado com o parâmetro method.

Rosenberg, et. al. Standards Track [Página 150]

Página Anterior

Tabela de Conteúdo

Página Seguinte



Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:

User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.

Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de 
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:

MUST:
    PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO, 
    NECESSITAR, É MANDATÓRIO.

MUST NOT:
    NÃO PODE, É PROIBIDO, É VEDADO.

SHOULD:
    DEVE, É RECOMENDADO.

SHOULD NOT:
    NÃO DEVE, NÃO É RECOMENDADO.

MAY:
    PODE, É OPCIONAL.