RFC 3261 SIP: Session Initiation Protocol Junho 2002
o Caso contrário, se ela não for tag-geada pelo receptor, a resposta PRECISA ser enviada ao endereço indicado pelo valor de "sent-by", usando os procedimentos descritos na parte 5 de [4].
18.3 Enquadramento
No caso de transportes orientado a mensagem (como o UDP), se a mensagem possui um campo-cabeçalho Content-Length, o corpo da mensagem é assumido conter muitos bytes. Se houver bytes adicionais no pacote de transporte ultrapassando o término do corpo, eles PRECISAM ser descartados. Se o pacote de transporte terminar antes do término do corpo da mensagem, isso é considerado um erro. Se a mensagem for uma resposta, ela PRECISA ser descartada. Se a mensagem for uma requisição, o elemento DEVE gerar uma resposta 400 (Bad Request). Se a mensagem não tiver nenhum campo-cabeçalho Content-Length, o corpo da mensagem é assumido terminar ao final do pacote de transporte.
No caso de transportes orientados à fluxo, como o TCP, o campo-cabeçalho Content-Length indica o tamanho do corpo. O campo-cabeçalho Content-Length PRECISA ser usado com transportes orientados a fluxo.
18.4 Tratamento de Erro
Tratamento de erro é independente se a mensagem foi uma requisição ou se foi uma resposta.
Se o usuário de transporte pede para uma mensagem a ser enviada por um meio de transporte não confiável, e o resultado é um erro ICMP, o comportamento depende do tipo de erro ICMP. Host, rede, porta ou erros de protocolo inalcançável, ou erros de problema parâmetro DEVE fazer que a camada de transporte informar ao usuário de transporte de uma falha no envio. Erros ICMP source quench e TTL exceeded DEVEM ser ignorados.
Se o usuário de transporte pede para uma requisição ser enviada por meio de um transporte confiável, e o resultado é uma falha de conexão, a camada de transporte DEVE informar ao usuário de transporte de uma falha no envio.
19 Componentes Comuns de Mensagem
Há certos componentes de mensagens SIP que aparecem em vários lugares dentro de mensagens SIP (e às vezes, fora delas) que merecem discussão em separado.
Rosenberg, et. al. Standards Track [Página 147]
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.
Nenhum comentário:
Postar um comentário