Compartilhar via

Encaminhamento Direto - Protocolo SIP

  • Artigo
  • Aplica-se a:
    Microsoft Teams

Este artigo descreve como o Encaminhamento Direto implementa o Protocolo SIP (Session Initiation Protocol). Para encaminhar o tráfego entre um Controlador de Limite de Sessão (SBC) e o proxy SIP, alguns parâmetros SIP têm de ter valores específicos. Este artigo destina-se a administradores de voz responsáveis pela configuração da ligação entre o SBC no local e o serviço proxy SIP.

Processar o pedido recebido: localizar o inquilino e o utilizador

Antes de uma chamada de entrada ou saída poder ser processada, as mensagens OPTIONS são trocadas entre o Proxy SIP e o SBC. Estas mensagens OPÇÕES permitem que o Proxy SIP forneça as capacidades permitidas ao SBC. É importante que a negociação OPTIONS seja bem-sucedida (resposta 200OK), permitindo uma maior comunicação entre o SBC e o Proxy SIP para estabelecer chamadas. Os cabeçalhos SIP numa mensagem OPTIONS para o Proxy SIP são fornecidos como exemplo:

Nome do parâmetro Exemplo do valor
Request-URI OPÇÕES sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Através do Cabeçalho Via: SIP/2.0/TLS sbc1.adatum.biz:5058; alias; branch=z9hG4bKac2121518978
cabeçalho Max-Forwards Máximo de Reencaminhamentos:68
Do Cabeçalho De Cabeçalho De: sip:sbc1.adatum.biz:5058
Para Cabeçalho Para: sip:sip.pstnhub.microsoft.com:5061
Cabeçalho CSeq CSeq: 1 CONVIDAR
Cabeçalho do Contacto Contacto: sip:sbc1.adatum.biz:50588; transport=tls

Nota

  • Os cabeçalhos SIP não contêm userinfo no URI do SIP em utilização. De acordo com a RFC 3261, secção 19.1.1, a parte userinfo de um URI é opcional e PODE estar ausente quando o anfitrião de destino não tem uma noção de utilizadores ou quando o próprio anfitrião é o recurso que está a ser identificado. Se o sinal @ estiver presente num URI do SIP, o campo de utilizador NÃO DEVE estar vazio.
  • O URI do SIP com Encaminhamento Direto não é suportado.
  • Verifique a configuração do Controlador de Limites de Sessão e certifique-se de que não está a utilizar cabeçalhos "Substitui" em pedidos SIP. O Encaminhamento Direto rejeita pedidos SIP que tenham os cabeçalhos Substitui definidos.

Numa chamada recebida, o proxy SIP tem de localizar o inquilino para o qual a chamada está destinada e localizar o utilizador específico neste inquilino. O administrador inquilino pode configurar números não DID, por exemplo + 1001, em vários inquilinos. Por conseguinte, é importante encontrar o inquilino específico no qual deve efetuar a pesquisa de números porque os números não DID podem ser os mesmos em várias organizações do Microsoft 365 ou Office 365.

Esta secção descreve como o proxy SIP localiza o inquilino e o utilizador e efetua a autenticação do SBC na ligação de entrada.

Segue-se um exemplo da mensagem de Convite SIP numa chamada recebida:

Nome do parâmetro Exemplo do valor
Request-URI CONVIDAR sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
Através do Cabeçalho Via: SIP/2.0/TLS sbc1.adatum.biz:5058; alias; branch=z9hG4bKac2121518978
cabeçalho Max-Forwards Máximo de Reencaminhamentos:68
Do Cabeçalho Do Cabeçalho De: <sip:+17168712781@sbc1.adatum.biz; transport=udp; tag=1c747237679
Para Cabeçalho Para: sip:+183338006777@sbc1.adatum.biz
Cabeçalho CSeq CSeq: 1 CONVIDAR
Cabeçalho do Contacto Contacto: sip:+17168712781@sbc1.adatum.biz:5058; transport=tls

Ao receber o convite, o proxy SIP efetua os seguintes passos:

  1. Verifique o certificado. Na ligação inicial, o serviço Encaminhamento Direto utiliza o nome do FQDN apresentado no cabeçalho Contacto e corresponde-o ao Nome Comum ou Nome Alternativo do Requerente do certificado apresentado. O nome SBC tem de corresponder a uma das seguintes opções:

    • Opção 1. O nome completo do FQDN apresentado no cabeçalho Contacto tem de corresponder ao Nome Comum/Nome Alternativo do Requerente do certificado apresentado.

    • Opção 2. A parte do domínio do nome do FQDN apresentada no cabeçalho Contacto (por exemplo, adatum.biz do nome FQDN sbc1.adatum.biz) tem de corresponder ao valor universal em Nome Comum/Nome Alternativo do Requerente (por exemplo, *.adatum.biz).

  2. Tente localizar um inquilino com o nome completo do FQDN apresentado no cabeçalho De contacto.

    Verifique se o nome do FQDN do Cabeçalho de contacto (sbc1.adatum.biz) está registado como um nome DNS em qualquer organização do Microsoft 365 ou Office 365. Se for encontrado, a pesquisa do utilizador é efetuada no inquilino que tem o FQDN SBC registado como um Nome de domínio. Se não for encontrado, o Passo 3 aplica-se.

  3. O passo 3 só se aplica se o Passo 2 falhar.

    Remova a parte do anfitrião do FQDN, apresentada no cabeçalho Contacto (FQDN: sbc12.adatum.biz, depois de remover a parte do anfitrião: adatum.biz) e marcar se este nome estiver registado como um nome DNS em qualquer organização do Microsoft 365 ou Office 365. Se for encontrado, a pesquisa do utilizador é efetuada neste inquilino. Se não for encontrada, a chamada falha.

  4. Com o número de telefone apresentado no Request-URI, execute a pesquisa de número inverso no inquilino encontrado no Passo 2 ou 3. Corresponda o número de telefone apresentado a um URI SIP de utilizador no inquilino encontrado no passo anterior.

  5. Aplicar definições de ramal. Localize os parâmetros definidos pelo administrador de inquilinos para este SBC.

    A Microsoft não suporta ter um proxy SIP de terceiros ou um Servidor de Agente de Utilizador entre o proxy SIP da Microsoft e o SBC emparelhado, o que pode modificar o URI do Pedido criado pelo SBC emparelhado.

    Os requisitos para as duas pesquisas (passos 2 e 3) necessários para o cenário em que um SBC está interligado a muitos inquilinos (cenário de transportadora) são abordados mais à frente neste artigo.

Requisitos detalhados para o Cabeçalho de contacto e Request-URI

Cabeçalho de contacto

Para todas as mensagens SIP recebidas (OPÇÕES, CONVIDAR) para o proxy do SIP da Microsoft, o Cabeçalho de contacto tem de ter o FQDN SBC emparelhado no nome de anfitrião do URI da seguinte forma:

Sintaxe: Contacto: <sip:phone ou sip address@FQDN do SBC; transport=tls>

De acordo com RFC 3261, secção 11.1, um campo cabeçalho de contacto pode estar presente numa mensagem OPÇÕES. No Encaminhamento Direto, é necessário o cabeçalho de contacto. Para mensagens INVITE no formato acima, para mensagens OPÇÕES, o userinfo pode ser removido do URI do SIP e apenas o FQDN enviado no formato seguinte:

Sintaxe: Contacto: <sip:FQDN do SBC; transport=tls>

Este nome (FQDN) também tem de estar nos campos Nome Comum ou Nome Alternativo do Requerente do certificado apresentado. A Microsoft suporta a utilização de valores universais dos nomes nos campos Nome Comum ou Nome Alternativo do Requerente do certificado.

O suporte para carateres universais está descrito em RFC 2818, secção 3.1. Especificamente:

"Os nomes podem conter o caráter universal *, que é considerado como correspondendo a qualquer componente de nome de domínio único ou fragmento de componente. Por exemplo, *.a.com corresponde foo.a.com, mas não bar.foo.a.com. f*.com corresponde foo.com, mas não bar.com".

Se o SBC enviar mais do que um valor no cabeçalho Contacto apresentado numa mensagem SIP, só é utilizada a parte FQDN do primeiro valor do cabeçalho Contacto.

Para o Encaminhamento Direto, é importante que o FQDN seja utilizado para preencher o URI do SIP em vez do IP. Uma mensagem DE CONVITE ou OPÇÕES recebida para o Proxy SIP com o Cabeçalho de contacto onde o nome do anfitrião é representado pelo IP e não pelo FQDN, a ligação é recusada com 403 Proibido.

Request-URI

Para todas as chamadas recebidas, o Request-URI é utilizado para corresponder o número de telefone a um utilizador.

Atualmente, o número de telefone tem de conter um sinal de adição (+), conforme mostrado no exemplo seguinte.

INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0

Do Cabeçalho

Para todas as chamadas recebidas, o Cabeçalho De é utilizado para corresponder o número de telefone do autor da chamada à lista de números de telefone bloqueados do destinatário e utilizado para efetuar a pesquisa inversa de números para localizar o nome do autor da chamada a partir de registos de inquilino e de utilizador existentes.

Para que estas pesquisas funcionem, o número de telefone tem de conter um +, conforme mostrado no exemplo seguinte.

From: <sip:+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679

Considerações sobre cabeçalhos de contactos e Record-Route

O proxy SIP tem de calcular o FQDN do próximo salto para novas transações de cliente na caixa de diálogo (por exemplo, Bye ou Re-Invite) e ao responder às Opções do SIP. São utilizados Contactos ou Record-Route.

De acordo com a RFC 3261, secção 8.1.1.8, o Cabeçalho de contacto é necessário em qualquer pedido que possa resultar numa nova caixa de diálogo. A Record-Route só é necessária se um proxy quiser permanecer no caminho dos pedidos futuros numa caixa de diálogo. Se um SBC de proxy estiver a ser utilizado com a Otimização de Multimédia Local para o Encaminhamento Direto, é necessário configurar uma rota de registos, uma vez que o SBC do proxy tem de permanecer na rota.

A Microsoft recomenda utilizar apenas o Cabeçalho de contacto se não for utilizado um SBC de proxy:

  • Por RFC 3261, secção 20.30, Record-Route é utilizado se um proxy quiser permanecer no caminho de pedidos futuros numa caixa de diálogo, o que não é essencial se nenhum SBC de proxy estiver configurado, uma vez que todo o tráfego vai entre o proxy SIP da Microsoft e o SBC emparelhado.

  • O proxy SIP da Microsoft utiliza apenas o Cabeçalho de contacto (não a Rota de Registo) para determinar o próximo salto ao enviar opções de ping de saída. Configurar apenas um parâmetro (Contacto) em vez de dois (Contacto e Rota de Registo) simplifica a administração se um SBC de proxy não estiver a ser utilizado.

Para calcular o próximo salto, o proxy SIP utiliza:

  • Prioridade 1. Rota de Registos de nível superior. Se o Record-Route de nível superior contiver o nome do FQDN, o nome do FQDN é utilizado para fazer a ligação de entrada na caixa de diálogo de saída.

  • Prioridade 2. Cabeçalho de contacto. Se Record-Route não existir, o proxy SIP procura o valor do cabeçalho De contacto para fazer a ligação de saída. O cabeçalho de contacto é a configuração recomendada.

Se forem utilizados contactos e Record-Route, o administrador do SBC tem de manter os respetivos valores idênticos, o que causa sobrecarga administrativa.

Utilização do nome do FQDN em Contacto ou Record-Route

A utilização de um endereço IP não é suportada em Record-Route nem em Contacto. A única opção suportada é um FQDN, que tem de corresponder ao Nome Comum ou Nome Alternativo do Requerente do certificado SBC (os valores de caráter universal no certificado são suportados).

  • Se um endereço IP for apresentado em Record-route ou Contact, o certificado marcar falha e a chamada falha.

  • Se o FQDN não corresponder ao valor do Nome Alternativo comum ou do Requerente no certificado apresentado, a chamada falhará.

Chamada de entrada: descrição da caixa de diálogo SIP

A tabela seguinte resume as diferenças e semelhanças do fluxo de chamadas entre os modos de não ignorar e ignorar:

Nome do parâmetro Modo de não ignorar Modo de ignorar
Candidatos à comunicação social em 183 e 200 mensagens provenientes de Processadores de multimédia Clientes
Número de 183 mensagens que o SBC pode receber Um por sessão Múltiplos
A chamada pode ser com resposta provisória (183) Sim Sim
A chamada pode ser sem resposta provisória (183) Sim Sim

Fluxo de desativação não multimédia

Um utilizador do Teams pode ter vários pontos finais ao mesmo tempo. Por exemplo, o cliente teams para Windows, o cliente teams para iPhone e Telefonia do Teams (cliente Android do Teams). Cada ponto final pode sinalizar um descanso HTTP da seguinte forma:

  • Progresso da chamada – convertido pelo proxy SIP para a mensagem SIP 180. Ao receber a mensagem 180, o SBC tem de gerar toques locais.

  • Resposta multimédia – convertida pelo proxy SIP para a mensagem 183 com candidatos a multimédia no Protocolo SDP (Session Description Protocol). Ao receber a mensagem 183, o SBC espera ligar-se aos candidatos de multimédia recebidos na mensagem SDP.

    Nota

    Em alguns casos, a resposta Multimédia pode não ser gerada e o ponto final pode responder com a mensagem "Chamada Aceite".

  • Chamada aceite – convertida pelo proxy SIP para a mensagem SIP 200 com SDP. Ao receber a mensagem 200, espera-se que o SBC envie e receba multimédia de e para os candidatos SDP fornecidos.

    Nota

    O Encaminhamento Direto não suporta o Convite de Oferta Atrasado (Convidar sem SDP).

Vários pontos finais a tocar com resposta provisória

  1. Ao receber o primeiro Convite do SBC, o proxy SIP envia a mensagem "SIP SIP/2.0 100 A Tentar" e notifica todos os pontos finais do utilizador final sobre a chamada recebida.

  2. Após a notificação, cada ponto final começa a tocar e a enviar mensagens de "Progresso da chamada" para o proxy SIP. Uma vez que um utilizador do Teams pode ter vários pontos finais, o proxy SIP pode receber várias mensagens de Progresso da Chamada.

  3. Para cada mensagem de Progresso da Chamada recebida dos clientes, o proxy SIP converte a mensagem Progresso da Chamada na mensagem SIP "SIP SIP/2.0 180 Toque". O intervalo para enviar essas mensagens cumpre o intervalo das mensagens recebidas do Controlador de Chamadas. No diagrama seguinte, existem duas 180 mensagens geradas pelo proxy SIP. Estas mensagens provêm dos dois pontos finais do Teams do utilizador. Cada um dos clientes tem um ID de Etiqueta exclusivo. Cada mensagem proveniente de um ponto final diferente é uma sessão separada (o parâmetro "tag" no campo "Para" é diferente). No entanto, um ponto final pode não gerar a mensagem 180 e enviar a mensagem 183 de imediato, conforme mostrado no diagrama seguinte.

  4. Assim que um ponto final gera uma mensagem de Resposta multimédia com os endereços IP dos candidatos a multimédia do ponto final, o proxy SIP converte a mensagem recebida numa mensagem "Progresso da Sessão do SIP 183" com o SDP do cliente substituído pelo SDP do Processador de Multimédia. No diagrama seguinte, o ponto final do Fork 2 atendeu a chamada. Se o ramal não for ignorado, a mensagem SIP 183 é gerada apenas uma vez (Bot de Anel ou Ponto Final de Cliente). O 183 pode vir num fork existente ou iniciar um novo.

  5. É enviada uma mensagem de Aceitação de Chamada com os candidatos finais do ponto final que aceitaram a chamada. A mensagem Aceitação de Chamada é convertida na mensagem SIP 200.

Diagrama a mostrar vários pontos finais a tocar com resposta provisória.

Vários pontos finais a tocar sem resposta provisória

  1. Ao receber o primeiro Convite do SBC, o proxy SIP envia a mensagem "SIP SIP/2.0 100 A Tentar" e notifica todos os pontos finais do utilizador final sobre a chamada recebida.

  2. Após a notificação, cada ponto final começa a tocar e a enviar a mensagem "Progresso da chamada" para o proxy SIP. Uma vez que um utilizador do Teams pode ter vários pontos finais, o proxy SIP pode receber várias mensagens de Progresso da Chamada.

  3. Para cada mensagem de Progresso da Chamada recebida dos clientes, o proxy SIP converte a mensagem Progresso da Chamada na mensagem SIP "SIP SIP/2.0 180 A Tentar". O intervalo para enviar as mensagens cumpre o intervalo de receção das mensagens do Controlador de Chamadas. No diagrama seguinte, existem duas 180 mensagens geradas pelo proxy SIP, o que significa que o utilizador iniciou sessão em três clientes do Teams e cada cliente envia o progresso da chamada. Cada mensagem é uma sessão separada (o parâmetro "tag" no campo "Para" é diferente)

  4. É enviada uma mensagem de Aceitação de Chamada com os candidatos finais do ponto final que aceitaram a chamada. A mensagem Aceitação de Chamada é convertida na mensagem SIP 200.

Diagrama a mostrar vários pontos finais a tocar sem resposta provisória.

Fluxo de desa ignorar multimédia

As mesmas mensagens (100 A tentar, 180, 183) são utilizadas no cenário de ignorar multimédia.

O esquema seguinte mostra um exemplo do fluxo de chamada de ignorar.

Nota

Os candidatos aos meios de comunicação podem vir de diferentes pontos finais.

Diagrama a mostrar o fluxo de desa ignorar multimédia.

Opção Substitui

O SBC tem de suportar Convidar por Substituições.

Tamanho das considerações de SDP

A interface de Encaminhamento Direto pode enviar uma mensagem SIP superior a 1500 bytes. O conteúdo SDP causa principalmente o excesso de tamanho. No entanto, se existir um porta-malas UDP atrás do SBC, poderá rejeitar a mensagem se for reencaminhada do proxy SIP da Microsoft para o ramal não modificado. A Microsoft recomenda remover alguns valores no SDP no SBC ao enviar a mensagem para os ramais UDP. Por exemplo, os candidatos do ICE ou codecs não utilizados podem ser removidos.

Transferência de chamadas

O Encaminhamento Direto suporta dois métodos de transferência de chamadas:

  • Opção 1. Processos de proxy SIP Veja a partir do cliente localmente e atua como Árbitro, conforme descrito na secção 7.1 do RFC 3892.

    Com esta opção, o proxy SIP termina a transferência e adiciona um novo Convite.

  • Opção 2. O proxy SIP envia a referência para o SBC e atua como um Transferor como descrito na Secção 6 do RFC 5589.

    Com esta opção, o proxy SIP envia uma Referência para o SBC e espera que o SBC processe totalmente a Transferência.

O proxy SIP seleciona o método com base nas capacidades comunicadas pelo SBC. Se o SBC indicar que suporta o método "Referenciar", o proxy SIP utiliza a Opção 2 para transferências de chamadas.

Segue-se um exemplo de um SBC que envia a mensagem a indicar que o método Refer é suportado:

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Se o SBC não indicar que Referenciar como um método suportado, o Encaminhamento Direto utiliza a Opção 1 (o proxy SIP atua como árbitro). O SBC também tem de sinalizar que suporta o método Notify:

Exemplo de SBC a indicar que o método Refer não é suportado:

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

Processos de proxy do SIP Veja a partir do cliente localmente e atua como Árbitro

Se o SBC indicar que o método Refer não é suportado, o proxy SIP atua como árbitro.

O pedido Refer proveniente do cliente é terminado no proxy SIP. O pedido Refer do cliente é apresentado como "Call transfer to Dave" (Transferir chamadas para o Dave) no diagrama seguinte. Para obter mais informações, consulte a secção 7.1 do RFC 3892.

Diagrama a mostrar um pedido de referência proveniente do cliente, Bob, para Dave.

O proxy SIP envia a referência para o SBC e atua como um Transferor

Este é o método preferencial para transferências de chamadas e é obrigatório para dispositivos que procuram a certificação de ignorar multimédia. A Transferência de Chamadas sem que o SBC consiga processar o Refer não é suportada no modo de desaproveição de multimédia.

A norma é explicada na Secção 6 do RFC 5589. Os RFCs relacionados são:

Esta opção pressupõe que o proxy SIP atua como um Transferor e envia uma Mensagem de Referência para o SBC. O SBC atua como um Transferee e processa a opção Referenciar para gerar uma nova oferta para transferência. Existem dois casos possíveis:

  • A chamada é transferida para um participante rtPC externo.
  • A chamada é transferida de um utilizador do Teams para outro utilizador do Teams no mesmo inquilino através do SBC.

Se a chamada for transferida de um utilizador do Teams para outro através do SBC, espera-se que o SBC emita um novo convite (inicie uma nova caixa de diálogo) para o destino de transferência (o utilizador do Teams) com as informações recebidas na mensagem Referenciar.

Para preencher os campos Para/Transferor para a transação do pedido internamente, o proxy SIP tem de transmitir estas informações dentro dos cabeçalhos REFER-TO/REFERRED-BY.

O proxy SIP forma o REFER-TO como um URI SIP composto por um FQDN de proxy SIP no nome do anfitrião e um dos seguintes:

  • Um número de telefone E.164 na parte do nome de utilizador do URI, caso o destino da transferência seja um número de telefone ou

  • Parâmetros x-m e x-t que codificam a ressonância magnética de destino de transferência completa e o ID de inquilino, respetivamente

O cabeçalho REFERRED-BY é um URI do SIP com a ressonância magnética do transferor codificada no mesmo e o ID do inquilino do transferor e outros parâmetros de contexto de transferência, conforme mostrado na tabela seguinte:

Parâmetro Valor Descrição
x-m RESSONÂNCIA MAGNÉTICA Ressonância Magnética Completa do transferor/destino de transferência conforme preenchido por CC
x-t ID do locatário ID de Inquilino x-t ID Opcional do Inquilino preenchido por CC
x-ti ID de Correlação do Transferor ID de Correlação da chamada para o transferidor
x-tt Transferir URI de chamada de destino URI de substituição de chamada codificada

Neste caso, o tamanho do Cabeçalho de Referência pode ter até 400 símbolos. O SBC tem de suportar o processamento de Mensagens de referência com um tamanho máximo de 400 símbolos.

Diagrama a mostrar o processo de referência a.

Reencaminhamento de chamadas

Um utilizador do Teams pode reencaminhar chamadas recebidas para outro número ou utilizador do Teams, ligar para outros utilizadores ou utilizadores em paralelo (cadência simultânea) ou tocar num grupo de utilizadores ou números. Considere o seguinte:

  • Request-URI no pedido INVITE do proxy SIP para o Utilizador C contém o parâmetro da causa .

  • Com base nas configurações de ramal (parâmetro ForwardCallHistory ), o cabeçalho History-Info é preenchido.

  • Quando o Utilizador A é outro utilizador RTPC, o proxy SIP gera a resposta provisória "SIP SIP/2.0 181 Chamada está a ser reencaminhada" ao Utilizador A.

  • Se o Utilizador A e o Utilizador C forem utilizadores RTPC, o proxy SIP preserva a resposta provisória "SIP SIP/2.0 181 Chamada está a ser reencaminhada".

  • O cabeçalho History-Info deve ser utilizado para a prevenção de ciclos.

Temporizador de sessão

O proxy SIP suporta (oferece sempre) o Temporizador de Sessão em chamadas sem ignorar, mas não o oferece em chamadas de bypass. A utilização do Temporizador de Sessão pelo SBC não é obrigatória.

Utilização do parâmetro Request-URI user=phone

O proxy SIP analisa o Request-URI e, se o parâmetro user=phone estiver presente, o serviço processa o Request-URI como um número de telefone, correspondendo o número a um utilizador. Se o parâmetro não estiver presente, o proxy SIP aplica heurística para determinar o tipo de utilizador Request-URI (número de telefone ou um endereço SIP).

A Microsoft recomenda que aplique sempre o parâmetro user=phone para simplificar o processo de configuração da chamada.

cabeçalho History-Info

O cabeçalho History-Info é utilizado para reativar pedidos SIP e "fornece(s) um mecanismo padrão para capturar as informações do histórico de pedidos para permitir uma grande variedade de serviços para redes e utilizadores finais". Para obter mais informações, consulte RFC 4244 – Secção 1.1. Para o Sistema Telefónico Microsoft, este cabeçalho é utilizado em cenários de Simulring e Reencaminhamento de Chamadas.

Se for enviado, o History-Info é ativado da seguinte forma:

  • O proxy SIP insere um parâmetro que contém o número de telefone associado em entradas de History-Info individuais que compõem o cabeçalho de History-Info enviado para o Controlador RTPC. Utilizando apenas entradas que tenham o parâmetro de número de telefone, o Controlador RTPC reconstrói um novo cabeçalho de History-Info e transmite-o ao fornecedor de ramal SIP através do proxy SIP.

  • History-Info cabeçalho é adicionado para casos simultâneos de toque e reencaminhamento de chamadas.

  • History-Info cabeçalho não será adicionado para casos de transferência de chamadas.

  • Uma entrada do histórico individual no cabeçalho de History-Info reconstruído terá o parâmetro de número de telefone fornecido combinado com o FQDN de Encaminhamento Direto (sip.pstnhub.microsoft.com) definido como a parte anfitriã do URI; é adicionado um parâmetro de "user=phone" como parte do URI do SIP. Quaisquer outros parâmetros associados ao cabeçalho de History-Info original, exceto os parâmetros de contexto do telemóvel, são transmitidos no cabeçalho de History-Info reconstruído.

    Nota

    As entradas privadas (conforme determinados pelos mecanismos definidos na Secção 3.3 de RFC 4244) são reencaminhadas tal como acontece porque o fornecedor de ramal SIP é um elemento fidedigno.

  • A History-Info de entrada é preservada quando o parâmetro ForwardCallHistory está ativado. Os History-Info preservados podem ser utilizados para a prevenção de ciclos.

Segue-se o formato do cabeçalho History-info enviado pelo proxy SIP:

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

Se a chamada tiver sido redirecionada várias vezes, as informações sobre cada redirecionamento são incluídas pela razão adequada por ordem cronológica, numa lista separada por vírgulas.

Exemplo de Cabeçalho:

History-Info:
  <sip:+14257123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+14257123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1

O URI do SIP no cabeçalho History-Info está formatado de acordo com a Secção 25 de RFC 3261 (veja a definição de addr-spec). No exemplo anterior, o texto original do cabeçalho Reason do URI é SIP;cause=496;text="User Busy", que obtém os respetivos ;carateres , "e = escapam para os respetivos valores hexadecimais %3BASCII , %22e 3D, respetivamente.

O History-Info está protegido por um mecanismo TLS obrigatório.

Ligação SBC ao Mecanismo de encaminhamento direto e ativação pós-falha

Veja a secção Mecanismo de ativação pós-falha para sinalização SIP em Planear o Encaminhamento Direto.

Retry-After

Se um datacenter de Encaminhamento Direto estiver ocupado, o serviço pode enviar uma mensagem de Retry-After com um intervalo de um segundo para o SBC. Quando o SBC recebe uma mensagem 503 com um cabeçalho de Retry-After em resposta a um CONVITE, o SBC tem de terminar essa ligação e experimentar o próximo datacenter da Microsoft disponível.

Processar repetições (resposta 603)

Se um utilizador final observar várias chamadas não atendidas para uma chamada após recusar a chamada recebida, significa que o mecanismo de repetição do fornecedor de ramal SBC ou RTPC está configurado incorretamente. O SBC tem de ser reconfigurado para parar os esforços de repetição na resposta 603.

Reinício do ICE: chamada de desativação de multimédia transferida para um ponto final que não suporta o bypass de multimédia

O SBC tem de suportar reinícios ice conforme descrito em RFC 5245, secção 9.1.1.1.

O reinício no Encaminhamento Direto é implementado de acordo com os seguintes parágrafos do RFC:

Para reiniciar o ICE, um agente TEM de alterar o ice-pwd e o ice-ufrag para o fluxo de multimédia numa oferta. É permitido utilizar um atributo ao nível da sessão numa oferta, mas fornecer o mesmo ice-pwd ou ice-ufrag como um atributo de nível de multimédia numa oferta subsequente. Esta não é uma alteração na palavra-passe, apenas uma alteração na respetiva representação e não causa um reinício do ICE.

Um agente define o resto dos campos no SDP para este fluxo de multimédia como faria numa oferta inicial deste fluxo de multimédia (consulte a Secção 4.3). Assim, o conjunto de candidatos MAY inclui alguns, nenhum ou todos os candidatos anteriores para esse fluxo, e MAY inclui um novo conjunto de candidatos reunidos conforme descrito na Secção 4.1.1.

Se a chamada tiver sido inicialmente estabelecida com o bypass de multimédia e a chamada for transferida para um cliente Skype for Business, cliente Web do Teams ou Teams no cliente VDI, o Direct Routing tem de inserir um Processador de Multimédia. O Encaminhamento Direto não pode ser utilizado com um Skype for Business, o Teams Web ou os clientes VDI do Teams com o bypass multimédia. O Encaminhamento Direto inicia o processo de reinício do ICE alterando o ice-pwd e ice-ufrag e oferecendo novos candidatos aos meios de comunicação num reinvite.