SIP - O modelo de oferta / resposta
O uso de SDP com SIP é fornecido na resposta de oferta SDP RFC 3264. O tipo de corpo de mensagem padrão no SIP é application/sdp.
A parte chamadora lista os recursos de mídia que deseja receber no SDP, geralmente em um INVITE ou em um ACK.
A parte chamada lista seus recursos de mídia na resposta 200 OK ao CONVITE.
Um uso SIP típico de SDP inclui os seguintes campos: versão, origem, assunto, hora, conexão e uma ou mais mídias e atributos.
Os campos de assunto e hora não são usados pelo SIP, mas são incluídos para compatibilidade.
No padrão SDP, o campo assunto é um campo obrigatório e deve conter pelo menos um caractere, sugerido como s = - se não houver assunto.
O campo de hora geralmente é definido como t = 00. SIP usa os campos de conexão, mídia e atributo para configurar sessões entre UAs.
O campo de origem tem uso limitado com SIP.
O id de sessão geralmente é mantido constante durante uma sessão SIP.
A versão é incrementada cada vez que o SDP é alterado. Se o SDP enviado não for alterado em relação ao enviado anteriormente, a versão será mantida a mesma.
Como o tipo de sessão de mídia e codec a ser usado fazem parte da negociação de conexão, o SIP pode usar o SDP para especificar vários tipos de mídia alternativos e aceitar ou recusar seletivamente esses tipos de mídia.
A especificação de oferta / resposta, RFC 3264, recomenda que um atributo contendo um = rtpmap: seja usado para cada campo de mídia. Um fluxo de mídia é recusado definindo o número da porta como zero para o campo de mídia correspondente na resposta SDP.
Exemplo
No exemplo a seguir, o chamador Tesla deseja configurar uma chamada de áudio e vídeo com dois codecs de áudio possíveis e um codec de vídeo no SDP transportado no CONVITE inicial -
v = 0
o = John 0844526 2890844526 IN IP4 172.22.1.102
s = -
c = IN IP4 172.22.1.102
t = 0 0
m = audio 6000 RTP/AVP 97 98
a = rtpmap:97 AMR/16000/1
a = rtpmap:98 AMR-WB/8000/1
m = video 49172 RTP/AVP 32
a = rtpmap:32 MPV/90000Os codecs são referenciados pelos números de perfil RTP / AVP 97, 98.
A parte chamada Marry atende a chamada, escolhe o segundo codec para o primeiro campo de mídia e recusa o segundo campo de mídia, querendo apenas a sessão AMR.
v = 0
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110
s = -
c = IN IP4 200.201.202.203
t = 0 0
m = audio 60000 RTP/AVP 8
a = rtpmap:97 AMR/16000
m = video 0 RTP/AVP 32Se esta chamada apenas de áudio não for aceitável, Tom enviará um ACK e, em seguida, um BYE para cancelar a chamada. Caso contrário, a sessão de áudio seria estabelecida e os pacotes RTP trocados.
Como este exemplo ilustra, a menos que o número e a ordem dos campos de mídia sejam mantidos, a parte chamadora não saberá com certeza quais sessões de mídia estão sendo aceitas e recusadas pela parte chamada.
As regras de oferta / resposta são resumidas nas seções a seguir.
Regras para gerar uma oferta
Uma oferta SDP deve incluir todos os campos SDP obrigatórios (isso inclui v =, o =, s =, c = e t =). Esses são campos obrigatórios no SDP.
Geralmente inclui um campo de mídia ( m = ), mas não é obrigatório. As linhas de mídia contêm todos os codecs listados em ordem de preferência. A única exceção a isso é se o terminal suportar um grande número de codecs, os mais prováveis de serem aceitos ou os mais preferidos devem ser listados. Diferentes tipos de mídia incluem áudio, vídeo, texto, MSRP, BFCP e assim por diante.
Regras para gerar uma resposta
Uma resposta SDP a uma oferta deve ser construída de acordo com as seguintes regras -
A resposta deve ter o mesmo número de m = linhas na mesma ordem da resposta.
Fluxos de mídia individuais podem ser recusados definindo o número da porta como 0.
Os fluxos são aceitos enviando um número de porta diferente de zero.
As cargas úteis listadas para cada tipo de mídia devem ser um subconjunto das cargas úteis listadas na oferta.
Para cargas dinâmicas, o mesmo número de carga dinâmica não precisa ser usado em cada direção. Normalmente, apenas uma única carga útil é selecionada.
Regras para modificar uma sessão
Qualquer uma das partes pode iniciar outra troca de oferta / resposta para modificar uma sessão. Quando uma sessão é modificada, as seguintes regras devem ser seguidas -
O número da versão da linha de origem ( o = ) deve ser igual ao último enviado, o que indica que este SDP é idêntico à troca anterior, ou pode ser incrementado em um, o que indica um novo SDP que deve ser analisado.
A oferta deve incluir todas as linhas de mídia existentes e devem ser enviadas no mesmo pedido.
Fluxos de mídia adicionais podem ser adicionados ao final da lista m = line.
Um fluxo de mídia existente pode ser excluído configurando o número da porta como 0. Esta linha de mídia deve permanecer no SDP e em todas as trocas de ofertas / respostas futuras para esta sessão.
Chamada em espera
Uma pessoa em uma chamada pode colocar a outra temporariamente em espera. Isso é feito enviando um CONVITE com um SDP idêntico ao do CONVITE original, mas coma = sendonly atributo presente.
A chamada é reativada enviando outro CONVITE com o a = sendrecvatributo presente. A ilustração a seguir mostra o fluxo de uma chamada em espera.
