Roteamento direto dos Serviços de Comunicação do Azure: detalhes do protocolo SIP

Este artigo descreve como o roteamento direto implementa o SIP (Session Initiation Protocol) para garantir rotas de tráfego adequadas entre um SBC (Controlador de Borda de Sessão) e o proxy SIP. Também destaca a importância de certos parâmetros SIP que exigem valores específicos. Este artigo destina-se a administradores de voz responsáveis pela configuração da conexão entre o SBC e o serviço de proxy SIP.

Processando a solicitação de entrada: localizando o recurso Serviços de Comunicação

Nota

Nos Serviços de Comunicação do Azure, as OPÇÕES SIP de roteamento direto são habilitadas por padrão e não podem ser desabilitadas. O SBC deve iniciar a troca de OPÇÕES primeiro, pois o Proxy SIP aguarda que o SBC inicie a troca.

Antes que uma chamada de entrada ou saída possa ser processada, as mensagens OPTIONS são trocadas entre o Proxy SIP e o SBC. Essas mensagens OPTIONS permitem que o SIP Proxy forneça os recursos permitidos para o SBC. É importante que a negociação OPTIONS seja bem-sucedida (resposta 200 OK), permitindo uma maior comunicação entre SBC e SIP Proxy para estabelecer chamadas. Os cabeçalhos SIP em mensagens OPTIONS para SIP Proxy são fornecidos como um exemplo:

Nome do parâmetro	Exemplo do valor
Solicitação-URI	OPÇÕES sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Via cabeçalho	Via: sbc1.contoso.com:5061 SIP/2.0/TLS; pseudônimo; ramo=z9hG4bKac2121518978
Cabeçalho Max-Forwards	Max-Forwards:68
Do cabeçalho	Do cabeçalho de: sip:sbc1.contoso.com:5061
Para o cabeçalho	Fim: sip:sip.pstnhub.microsoft.com:5061
Cabeçalho CSeq	CSeq: 1 CONVIDAR
Cabeçalho de contato	Contato: sip:sbc1.contoso.com:5061; transporte = tls

Nota

Os cabeçalhos SIP não contêm userinfo no URI SIP em uso. De acordo com a RFC 3261, seção 19.1.1, a parte userinfo de um URI é opcional e pode estar ausente quando o host de destino não tem uma noção de usuários ou quando o próprio host é o recurso que está sendo identificado. Se o sinal @ estiver presente em um URI SIP, o campo usuário não deve estar vazio. Observe que o URI SIPS não deve ser usado com roteamento direto, pois não é suportado. Verifique a configuração do Controlador de Borda de Sessão e certifique-se de que você não está usando cabeçalhos "Substitui" em solicitações SIP. O roteamento direto rejeitará solicitações SIP que tenham cabeçalhos de substituição definidos.

Em uma chamada de entrada, o proxy SIP precisa localizar o recurso de Comunicação do Azure ao qual a chamada é destinada. Esta seção descreve como o proxy SIP localiza o recurso e executa a autenticação do SBC na conexão de entrada.

O exemplo da mensagem de convite SIP em uma chamada de entrada:

Nome do parâmetro	Exemplo do valor
Solicitação-URI	CONVIDAR gole:+54321@sip.pstnhub.microsoft.com SIP /2.0
Via cabeçalho	Via: sbc1.contoso.com:5061 SIP/2.0/TLS; pseudônimo; ramo=z9hG4bKac2121518978
Cabeçalho Max-Forwards	Max-Forwards:68
Do cabeçalho	Do cabeçalho de: <sip:+12345@sbc1.contoso.com; transporte=udp; etiqueta=1c68821811
Para o cabeçalho	Para: sip:+54321@sbc1.contoso.com
Cabeçalho CSeq	CSeq: 1 CONVIDAR
Cabeçalho de contato	Contato: sip:+12345@sbc1.contoso.com:5061; transporte = tls

Ao receber o convite, o proxy SIP executa as seguintes etapas:

1. Verifique o certificado. Na conexão inicial, o serviço de roteamento direto usa o nome FQDN apresentado no cabeçalho Contact e o faz corresponder ao nome Common Name ou Subject Alternative name do certificado apresentado. O nome SBC deve corresponder a uma das seguintes opções:

   • Opção 1. O nome FQDN completo apresentado no cabeçalho Contato deve corresponder ao Nome Comum/Nome Alternativo da Entidade do certificado apresentado.

   • Opção 2. A parte de domínio do nome FQDN apresentada no cabeçalho Contato (por exemplo, contoso.com do nome FQDN sbc1.contoso.com) deve corresponder ao valor curinga em Nome Comum/Nome Alternativo do Assunto (por exemplo, *.contoso.com).

2. Tente localizar um locatário do Microsoft 365 usando o nome FQDN completo apresentado no cabeçalho Contato.

   Verifique se o nome FQDN do cabeçalho Contato (sbc1.contoso.com) está registrado como um nome DNS em qualquer organização do Microsoft 365 ou Office 365. Se encontrado, a pesquisa do usuário é realizada no locatário que tem o FQDN SBC registrado como um nome de domínio. Se não for encontrado, aplica-se o Passo 3.

3. Tente localizar um recurso de Comunicação do Azure usando o nome FQDN completo apresentado no cabeçalho Contato.

   Verifique se o nome FQDN do cabeçalho Contact (sbc1.contoso.com) está registrado como um FQDN SBC em qualquer recurso de Comunicação do Azure. Se encontrado, a chamada é enviada para esse recurso. Se não for encontrado, aplica-se o Passo 4.

4. A Etapa 4 só se aplica se as Etapas 2 e 3 falharem.

   Remova a parte do host do FQDN, apresentada no cabeçalho Contato (FQDN: sbc1.contoso.com, depois de remover a parte do host: contoso.com) e verifique se esse nome está registrado como um nome DNS em qualquer organização do Microsoft 365 ou do Office 365. Se encontrado, a pesquisa de usuário é executada neste locatário. Se não for encontrado, a chamada falhará.

5. A etapa 5 só se aplica se as etapas 2, 3 e 4 falharem.

   Remova a parte do host do FQDN, apresentada no cabeçalho Contato (FQDN: sbc1.contoso.com, depois de remover a parte do host: contoso.com) e verifique se esse nome está registrado como um FQDN SBC em qualquer recurso de Comunicação do Azure. Se encontrado, a chamada é enviada para esse recurso. Se não for encontrado, a chamada falhará.

6. Se o recurso tiver uma implantação do Dynamics Omnichannel associada, execute a pesquisa do número de telefone apresentado no URI de solicitação. Corresponda o número de telefone apresentado a um usuário Omnichannel (fila) encontrado na etapa anterior.

7. A Etapa 7 só se aplica se a Etapa 6 falhar.

   Caso não exista uma implantação Omnichannel para o recurso de Comunicação ou o número no Request-URI não corresponda a nenhum número Omnichannel configurado, envie uma chamada para uma Grade de Eventos.

8. A Etapa 8 só se aplica se a Etapa 7 falhar.

   Se a Grade de Eventos não estiver configurada ou não houver regras para gerenciar a chamada de entrada, a chamada será descartada.

Requisitos detalhados para cabeçalho de contato e URI de solicitação

Cabeçalho do contato

Para todas as mensagens SIP de entrada (OPTIONS, INVITE) para o proxy Microsoft SIP, o cabeçalho Contact deve ter o FQDN SBC emparelhado no nome do host URI da seguinte maneira:

Sintaxe: Contato: <sip:phone ou sip address@FQDN do SBC; transporte = tls>

De acordo com RFC 3261, seção 11.1, um campo de cabeçalho de contato PODE estar presente em uma mensagem OPTIONS. No roteamento direto, o cabeçalho de contato é necessário. Quando se trata de mensagens OPTIONS, as informações do usuário podem ser excluídas do URI do SIP e apenas o FQDN pode ser enviado no seguinte formato:

Sintaxe: Contato: <sip:FQDN da SBC; transporte = tls>

Esse nome (FQDN) também deve estar no(s) campo(s) Nome comum ou Nome alternativo da entidade do certificado apresentado. A Microsoft oferece suporte ao uso de valores curinga do(s) nome(s) nos campos Nome Comum ou Nome Alternativo da Entidade do certificado. O suporte para curingas é descrito no RFC 2818, seção 3.1. Especificamente:

"Os nomes podem conter o caractere curinga *, que é considerado como correspondendo a qualquer componente de nome de domínio 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 mais de um valor no cabeçalho Contact apresentado em uma mensagem SIP pelo SBC, somente a parte FQDN do primeiro valor do cabeçalho Contact será usada. Como regra geral para roteamento direto, é importante que o FQDN seja usado para preencher o URI do SIP em vez do IP. Uma mensagem de entrada INVITE ou OPTIONS para SIP Proxy com cabeçalho de contato onde hostname é representado por IP e não FQDN, a conexão é recusada com 403 Forbidden.

Solicitação-URI

Para todas as chamadas de entrada, o Request-URI é usado para identificar um destinatário. Atualmente, o número de telefone deve conter um sinal de mais (+), conforme mostrado no exemplo a seguir.

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

Do cabeçalho

Para todas as chamadas recebidas, o cabeçalho Do é usado para corresponder ao número de telefone do chamador.

O número de telefone deve conter um +, conforme mostrado no exemplo a seguir.

From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811

Considerações sobre cabeçalhos de contato e rota de registro

O proxy SIP precisa 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 a SIP OPTIONS. Isso pode ser feito usando Contato ou Rota de Registro. De acordo com RFC 3261, seção 8.1.1.8, um cabeçalho de contato é necessário em qualquer solicitação que possa resultar em uma nova caixa de diálogo. A Rota de Registro só é necessária se um proxy quiser permanecer no caminho de solicitações futuras em uma caixa de diálogo.

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

• Prioridade 1. Rota de registro de nível superior. Se a Rota de Registro de nível superior contiver o nome FQDN, o nome FQDN será usado para fazer a conexão de entrada na caixa de diálogo de saída.

• Prioridade 2. Cabeçalho de contato. Se Record-Route não existir, o proxy SIP procurará o valor do cabeçalho Contact para fazer a conexão de saída. (Configuração recomendada.)

Se o Contato e a Rota de Registro forem usados, o administrador do SBC deverá manter seus valores idênticos, o que causa sobrecarga administrativa.

Uso do nome FQDN em Contato ou Rota de Registro

O uso de um endereço IP não é suportado em Rota de Registro ou Contato. A única opção suportada é um FQDN, que deve corresponder ao Nome Comum ou ao Nome Alternativo da Entidade do certificado SBC (há suporte para valores curinga no certificado).

• Se um endereço IP for apresentado em Rota de registro ou Contato, a verificação do certificado falhará e a chamada falhará.

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

Cabeçalhos de contexto de chamada

Atualmente, os cabeçalhos de contexto de chamada estão disponíveis apenas para o SDK de automação de chamadas. O SDK de automação de chamadas suporta cabeçalho de usuário para usuário e até cinco cabeçalhos SIP personalizados. Esses cabeçalhos são suportados nos métodos INVITE e REFER .

Cabeçalho de usuário para usuário

O cabeçalho SIP User-To-User (UUI) é um padrão do setor para passar informações contextuais durante um processo de configuração de chamada. O comprimento máximo de uma chave de cabeçalho UUI é de 64 caracteres. O comprimento máximo do valor do cabeçalho UUI é de 256 caracteres. O valor do cabeçalho UUI pode consistir em caracteres alfanuméricos e alguns símbolos selecionados, incluindo , , , , !, %, *_, , +. -~.;=

Cabeçalho personalizado

Os Serviços de Comunicação do Azure também suportam até cinco cabeçalhos SIP personalizados. A chave de cabeçalho SIP personalizada deve começar com um prefixo obrigatório X-MS-Custom- . O comprimento máximo de uma chave de cabeçalho SIP é de 64 caracteres, incluindo o prefixo X-MS-Custom- . A chave de cabeçalho SIP pode consistir em caracteres alfanuméricos e alguns símbolos selecionados, incluindo , , , , *, _+, , ~. -%!. O comprimento máximo do valor do cabeçalho SIP é de 256 caracteres. O valor do cabeçalho SIP pode consistir em caracteres alfanuméricos e alguns símbolos selecionados, incluindo , , , , !%, *, , _, +~, . -.;=

Para obter detalhes de implementação, consulte Como passar dados contextuais entre chamadas.

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

Aqui estão os detalhes de como o Proxy SIP processa chamadas de entrada.

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

Uma identidade dos Serviços de Comunicação do Azure pode ser usada em vários pontos de extremidade (aplicativos) ao mesmo tempo. Por exemplo, aplicativo Web, aplicativo para iPhone e aplicativo para Android. Cada ponto de extremidade pode sinalizar um repouso HTTP da seguinte maneira:

• Progresso da chamada – convertido pelo proxy SIP para a mensagem SIP 180. Ao receber a mensagem 180, o SBC deve gerar toque local.

• Resposta de mídia – convertida pelo proxy SIP para a mensagem 183 com candidatos de mídia no Session Description Protocol (SDP). Ao receber a mensagem 183, a SBC espera se conectar aos candidatos à mídia recebidos na mensagem do SDP.

  Nota

  Em alguns casos, a resposta de mídia pode não ser gerada, e o ponto final pode responder com a mensagem "Chamada aceita".

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

  Nota

  O roteamento direto não suporta convite de oferta atrasado (convite sem SDP).

Vários pontos finais tocando com resposta provisória

1. Ao receber o primeiro convite do SBC, o proxy SIP envia a mensagem "SIP SIP/2.0 100 Trying" e notifica todos os pontos de extremidade do usuário final sobre a chamada de entrada.

2. Após a notificação, cada ponto de extremidade começa a tocar e enviar mensagens de "Progresso da chamada" para o proxy SIP. Como a identidade dos Serviços de Comunicação do Azure é usada por vários pontos de extremidade, o proxy SIP pode receber várias mensagens de Progresso de Chamada.

3. Para cada mensagem de progresso da chamada recebida dos pontos de extremidade, o proxy SIP converte a mensagem de progresso da chamada para a mensagem SIP "SIP SIP/2.0 180 Ringing". O intervalo para enviar essas mensagens está correlacionado com o intervalo das mensagens recebidas do controlador de chamada. No diagrama a seguir, há duas 180 mensagens geradas pelo proxy SIP. Essas mensagens vêm dos dois pontos de extremidade SDK. Cada um dos pontos de extremidade tem um ID de tag exclusivo. Cada mensagem proveniente de um ponto final diferente é uma sessão separada (o parâmetro "tag" no campo "Para" é diferente). Mas um ponto de extremidade pode não gerar a mensagem 180 e enviar a mensagem 183 imediatamente, conforme mostrado no diagrama a seguir.

4. Depois que um ponto de extremidade gera uma mensagem de resposta de mídia com os endereços IP dos candidatos de mídia do ponto de extremidade, o proxy SIP converte a mensagem recebida em uma mensagem "SIP 183 Session Progress" com o SDP do ponto de extremidade substituído pelo SDP do processador de mídia. No diagrama a seguir, o ponto de extremidade da bifurcação 2 atendeu a chamada. A mensagem SIP 183 é gerada apenas uma vez. O 183 pode vir em um garfo existente ou começar um novo.

5. Uma mensagem de Aceitação de Chamada é enviada para o Proxy SIP com os candidatos finais do ponto de extremidade que aceitou a chamada. A mensagem de aceitação de chamada é convertida em mensagem SIP 200.

   

Vários pontos finais tocando sem resposta provisória

1. Ao receber o primeiro convite do SBC, o proxy SIP envia a mensagem "SIP SIP/2.0 100 Trying" e notifica todos os pontos de extremidade do usuário final sobre a chamada de entrada.

2. Após a notificação, cada ponto de extremidade começa a tocar e enviar a mensagem "Progresso da chamada" para o proxy SIP. Como a mesma identidade dos Serviços de Comunicação do Azure pode ser usada em vários aplicativos, o proxy SIP pode receber várias mensagens de Progresso de Chamada.

3. Para cada mensagem de progresso da chamada recebida dos pontos de extremidade, o proxy SIP converte a mensagem de progresso da chamada para a mensagem SIP "SIP SIP/2.0 180 Ringing". O intervalo para enviar as mensagens está correlacionado com o intervalo de recebimento das mensagens do controlador de chamada. Na imagem, há duas 180 mensagens geradas pelo proxy SIP, o que significa que a chamada é bifurcada para dois clientes diferentes e cada cliente envia o progresso da chamada. Cada mensagem é uma sessão separada (o parâmetro "tag" no campo "Para" é diferente)

4. Uma mensagem de Aceitação de Chamada é enviada para o Proxy SIP com os candidatos finais do ponto de extremidade que aceitou a chamada. A mensagem de aceitação de chamada é convertida em mensagem SIP 200.

   

Substitui a opção

O SBC deve apoiar CONVIDAR com Substituições.

Tamanho das considerações sobre SDP

A interface de roteamento direto pode enviar uma mensagem SIP superior a 1.500 bytes. O tamanho do SDP causa principalmente esse comportamento. No entanto, se houver um tronco UDP atrás do SBC, ele poderá rejeitar a mensagem se ela for encaminhada do proxy SIP da Microsoft para o tronco sem modificações. A Microsoft recomenda remover alguns valores em SDP no SBC ao enviar a mensagem para os troncos UDP. Por exemplo, os candidatos ICE ou codecs não utilizados podem ser removidos.

Transferência de chamadas

O roteamento direto suporta dois métodos para transferência de chamadas:

• Opção 1. Processos de proxy SIP Refere-se do cliente localmente e atua como um Referee, conforme descrito na seção 7.1 da RFC 3892.

  Com essa opção, o proxy SIP encerra a transferência e adiciona um novo convite.

• Opção 2. O proxy SIP envia a Referência ao SBC e atua como um Cedente, conforme descrito na Seção 6 da RFC 5589.

  Com essa opção, o proxy SIP envia uma Refer para o SBC e espera que o SBC manipule a transferência completamente.

O proxy SIP seleciona o método com base nos recursos relatados pelo SBC. Se o SBC indicar que suporta o método "Refer", o proxy SIP usa a opção 2 para transferências de chamadas. O exemplo de um SBC enviando a mensagem de 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 Refer como um método suportado, o roteamento direto usará a Opção 1 (o proxy SIP atua como um Referee). O SBC também deve sinalizar que suporta o método Notifique: Exemplo de SBC indicando que o método Refer não é suportado:

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

Processos de proxy SIP Referem-se do cliente localmente e atuam como um árbitro

Se o SBC indicou que o método Refer não é suportado, o proxy SIP atua como um referee. A solicitação Refer que vem do cliente termina no proxy SIP. A solicitação de referência do cliente é mostrada como "Transferência de chamada para Dave" no diagrama a seguir. Para obter mais informações, consulte a seção 7.1 do RFC 3892.

O proxy SIP envia o Refer para o SBC e atua como um cedente

Proxy SIP como um cedente é o método preferido para transferências de chamadas.

A norma é explicada na Seção 6 do RFC 5589. As RFCs relacionadas são:

• Controle de chamada SIP (Session Initiation Protocol) - Transferência

• Cabeçalho SIP (Session Initiation Protocol) "Substitui"

• Mecanismo "Referenciado por" do Protocolo de Início de Sessão (SIP)

Esta opção pressupõe que o proxy SIP atua como um cedente e envia uma mensagem de referência para o SBC. O SBC atua como cessionário e lida com o Refer para gerar uma nova oferta de transferência. Existem dois casos possíveis:

• A chamada é transferida para um participante externo da RTPC.
• A chamada é transferida de um ponto de extremidade SDK para outro ponto de extremidade SDK no mesmo recurso por meio do SBC.

Se a chamada for transferida de um ponto de extremidade do SDK para outro ponto de extremidade do SDK por meio do SBC, espera-se que o SBC emita um novo Convite (inicie uma nova caixa de diálogo) para o destino de transferência usando as informações recebidas na mensagem Consultar. Para preencher os campos Para/Transferor para a transação da solicitação internamente, o proxy SIP precisa transmitir essas 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 host e:

• Um número de telefone E.164 na parte do nome de usuário 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 do recurso de comunicação, respectivamente.

O cabeçalho REFERRED-BY tem um URI SIP com MRI do transferidor codificado nele e ID do recurso do transferidor e outros parâmetros de contexto de transferência, conforme mostrado na tabela a seguir:

Parâmetro	valor	Description
X-M	Ressonância magnética	Ressonância magnética completa do alvo de transferência/transferência conforme preenchido por CC
X-T	ID de Inquilino do	ID do recurso x-t ID do recurso opcional conforme preenchido pela CC
X-Ti	ID de correlação do cedente	ID de correlação da chamada para o cedente
X-TT	Transferir URI de chamada de destino	URI de substituição de chamada codificado

Neste caso, o tamanho do cabeçalho de referência pode ser de até 400 símbolos. O SBC deve suportar o tratamento de mensagens Refer com tamanho até 400 símbolos.

Reencaminhamento de chamadas

Um SDK de Automação de Chamadas dos Serviços de Comunicação do Azure pode redirecionar chamadas de entrada para outro número ou ponto de extremidade do SDK/Teams, tocar em outro usuário ou usuários em paralelo (toque simultâneo) ou tocar em um grupo de usuários ou números. Coisas a considerar:

• Request-URI na solicitação INVITE do proxy SIP para o usuário C contém o parâmetro cause .

• O cabeçalho History-Info é preenchido.

• Quando o usuário A é outro usuário PSTN, o proxy SIP gera a resposta provisória "SIP SIP/2.0 181 Call is being forwarded" para o usuário A.

• Se o Usuário A e o Usuário C forem usuários PSTN, o proxy SIP preservará a resposta provisória "SIP SIP/2.0 181 Call is being forwarded".

• O cabeçalho History-Info deve ser usado para prevenção de loop.

Temporizador de sessão

O proxy SIP suporta (sempre oferece) o temporizador de sessão. O uso do temporizador de sessão pelo SBC não é obrigatório.

Uso 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 manipula o Request-URI como um número de telefone, fazendo a correspondência do número para um usuário. Se o parâmetro não estiver presente, o proxy SIP aplicará heurísticas para determinar o tipo de usuário Request-URI (número de telefone ou um endereço SIP).

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

Cabeçalho History-Info

Nota

Nos Serviços de Comunicação do Azure, o cabeçalho de roteamento direto History-Info é habilitado por padrão e não pode ser desabilitado.

O cabeçalho History-Info é usado para redirecionar solicitações SIP e "fornece(m) um mecanismo padrão para capturar as informações do histórico de solicitações para permitir uma ampla variedade de serviços para redes e usuários finais". Para obter mais informações, consulte RFC 4244 – Seção 1.1. Para roteamento direto, esse cabeçalho é usado em cenários simultâneos de toque e encaminhamento de chamadas.

History-Info está habilitado da seguinte forma:

• O proxy SIP insere um parâmetro que contém o número de telefone associado em entradas History-Info individuais que compõem o cabeçalho History-Info enviado para o controlador PSTN. Usando apenas entradas que têm o parâmetro de número de telefone, o controlador PSTN reconstrói um novo cabeçalho History-Info e o passa para o provedor de tronco SIP via proxy SIP.

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

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

• Uma entrada de histórico individual no cabeçalho History-Info reconstruído tem o parâmetro de número de telefone fornecido combinado com o FQDN de roteamento direto (sip.pstnhub.microsoft.com) definido como a parte do host do URI. Um parâmetro de 'user=phone' adicionado como parte do URI do SIP. Quaisquer outros parâmetros associados ao cabeçalho History-Info original, exceto os parâmetros de contexto do telefone, passados no cabeçalho History-Info reconstruído.

  Nota

  Entradas que são privadas (conforme determinado pelos mecanismos definidos na Seção 3.3 da RFC 4244) encaminhadas como estão porque o provedor de tronco SIP é um par confiável.

• O Inbound History-Info é preservado para prevenção de loops.

A seguir está 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 foi redirecionada várias vezes, as informações sobre cada redirecionamento são incluídas com o motivo apropriado em ordem cronológica, em uma lista separada por vírgula.

Exemplo de cabeçalho:

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

O URI SIP no cabeçalho History-Info é formatado de acordo com a Seção 25 da RFC 3261 (consulte a definição de addr-spec). No exemplo anterior, o texto original do cabeçalho Reason URI é SIP;cause=496;text="User Busy", que obtém seu ;, "e = os caracteres escaparam para seus valores %3Bhexadecimais ASCII , %22, e 3D, respectivamente.

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

Conexão SBC com roteamento direto e mecanismo de failover

Consulte a seção Mecanismo de failover para sinalização SIP em Requisitos de infraestrutura de roteamento direto.

Repetir-Depois

Se um datacenter de roteamento direto estiver ocupado, o serviço poderá enviar uma mensagem de repetição após com um intervalo de um segundo para o SBC. Quando o SBC recebe uma mensagem 503 com um cabeçalho Retry-After em resposta a um convite, o SBC deve encerrar essa conexão e tentar o próximo datacenter da Microsoft disponível.

Tratamento de novas tentativas (resposta 603)

Se um usuário final observar várias chamadas perdidas para uma chamada depois de recusar a chamada de entrada, isso significa que o mecanismo de repetição do provedor de tronco SBC ou PSTN está configurado incorretamente. O SBC deve ser reconfigurado para interromper os esforços de repetição na resposta 603.