RFC 3261 Português Página 80

RFC 3261 SIP: Session Initiation Protocol Junho 2002

o Se a oferta inicial estiver em um INVITE, o answer PRECISA estar em uma mensagem confiável não-falha do UAS de volta ao UAC qual está correlacionada com esse INVITE. Para essa especificação, isso é somente a resposta final 2xx a esse INVITE. Esse mesmo aceite exato PODE também ser colocado em quaisquer respostas provisórias enviadas antes do aceite. O UAC PRECISA tratar a primeira descrição de sessão que ele recebe como aceite, e PRECISA ignorar quaisquer descrições de sessão em respostas subseqüentes ao INVITE inicial.

o Se a oferta inicial está na primeira mensagem confiável de não-falha do UAS de volta ao UAC, o answer PRECISA está no reconhecimento para essa mensagem (nessa especificação, ACK a uma resposta 2xx).

o Após ter enviado ou recebido um aceite à primeira oferta, o UAC PODE gerar ofertas subsequentes em requisições baseadas nas regras especificadas para esse método, mas somente se ele tiver recebido os aceites para quaisquer ofertas anteriores, e não ter enviado quaisquer ofertas para o qual ele não tinha obtido um aceite.

o Uma vez o UAS tenha enviado ou recebido um aceite à oferta inicial, ele NÃO PODE gerar ofertas subseqüente em quaisquer respostas ao INVITE inicial. Isto significa que um UAS baseado unicamente nessa especificação nunca pode gerar ofertas subseqüentes até a conclusão da transação inicial.

Concretamente, as regras acima especificam dois intercâmbios para UA's compatíveis com essa especificação unicamente - a oferta está no INVITE e o aceite na resposta 2xx (e possivelmente em uma 1xx também, com o mesmo valor), ou o oferta está na 2xx e o aceite está no ACK. Todos agentes-usuários que suportam INVITE PRECISAM suportar esses dois intercâmbios.

O Session Description Protocol (SDP) (RFC 2327) [1] PRECISA ser suportado por todos agentes-usuários como um meio para descrever sessões, e seu uso para construir ofertas e aceites PRECISA seguir os procedimentos definidos em [13].

As restrições do modelo oferta-aceite como descrito apenas se aplica aos corpos cujo valor do campo-cabeçalho Content-Disposition é "session". Portanto, é possível que ambos INVITE e ACK contenham uma mensagem do corpo (por exemplo, o INVITE carrega uma foto (Content-Disposition: render) e o ACK uma descrição de sessão (Content-Disposition: session)).

Se o campo-cabeçalho Content-Disposition estiver ausente, corpos com application/sdp no Content-Type implica na disposição "session", enquanto outros tipos de conteúdo implica em "render".

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

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.