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

Este artigo descreve como o roteamento direto implementa o protocolo SIP (Session Initiation Protocol) para garantir rotas de tráfego adequadas entre um controlador de borda de sessão (SBC) e o proxy SIP. Ele 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 por configurar a conexão entre o SBC e o serviço proxy SIP.

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

Observação

No roteamento direto dos Serviços de Comunicação do Azure, as SIP OPTIONS são habilitadas por padrão e não podem ser desabilitadas. A SBC deve iniciar a troca de OPTIONS primeiro, pois o Proxy SIP aguarda que a SBC inicie a troca.

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

Nome do parâmetro	Exemplo do valor
Solicitação-URI	OPTIONS sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Via Cabeçalho	Via: SIP/2.0/TLS sbc1.contoso.com:5061;alias;branch=z9hG4bKac2121518978
Cabeçalho Max-Forwards	Max-Forwards: 68
De cabeçalho	De cabeçalho de: sip:sbc1.contoso.com:5061
Para cabeçalho	Para: sip:sip.pstnhub.microsoft.com:5061
Cabeçalho CSeq	CSeq: 1 CONVITE
Cabeçalho do contato	Contato: sip:sbc1.contoso.com:5061; transport=tls

Observação

Os cabeçalhos SIP não contêm userinfo no URI SIP em uso. De acordo com 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 de usuário não deve estar vazio. Observe que o URI do 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 verifique se você não está usando cabeçalhos "Substitui" em solicitações SIP. O roteamento direto rejeitará solicitações SIP que tenham cabeçalhos Substitui 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 SIP Invite em uma chamada de entrada:

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

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

1. Verificar o certificado. Na conexão inicial, o serviço de roteamento direto usa o nome FQDN apresentado no cabeçalho do Contato e o corresponde ao Nome Comum ou ao Nome Alternativo da Entidade do certificado apresentado. O nome SBC deve corresponder a uma das seguintes opções:

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

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

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

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

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

   Verifique se o nome do FQDN do cabeçalho do Contato (sbc1.contoso.com) está registrado como um FQDN do SBC em qualquer recurso de Comunicação do Azure. Se encontrado, a chamada é enviada para esse recurso. Se não for encontrado, aplica-se a Etapa 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 do 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 do usuário é executada nesse 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 do Contato (FQDN: sbc1.contoso.com, depois de remover a parte do host: contoso.com), e verifique se esse nome está registrado como um FQDN do 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 nenhuma implantação Omnichannel para o recurso de Comunicação ou o número em 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 SIP da Microsoft, 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 da SBC; transport=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 do contato é necessário. Quando se trata de mensagens OPTIONS, as informações de usuário podem ser excluídas do URI do SIP e somente o FQDN pode ser enviado no seguinte formato:

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

Esse nome (FQDN) também deve estar no campo 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 em 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 a foo.a.com mas não bar.foo.a.com. f*.com combina foo.com mas não bar.com."

Se mais de um valor no cabeçalho Contact for apresentado em uma mensagem SIP pelo SBC, somente a parte FQDN do primeiro valor do cabeçalho Contact será usada. Como regra prática para roteamento direto, é importante que o FQDN seja usado para preencher o URI do SIP em vez do IP. Uma mensagem INVITE ou OPTIONS de entrada para SIP Proxy com cabeçalho Contact onde o nome do host é representado por IP e não FQDN, a conexão é recusada com 403 Proibido.

Solicitação-URI

Para todas as chamadas de entrada, o URI de solicitação é usado para identificar um chamado. Atualmente, o número de telefone deve conter um sinal de adição (+), conforme mostrado no exemplo a seguir.

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

Cabeçalho De

Para todas as chamadas recebidas, o cabeçalho De é 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 Contact ou Record-Route. 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. O Record-Route só é necessário 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 o Record-Route de nível superior contiver o nome do FQDN, o nome do FQDN será usado para fazer a conexão de saída na caixa de diálogo.

• Prioridade 2. Cabeçalho do 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 ambos Contact e Record-Route forem usados, o administrador do SBC deverá manter seus valores idênticos, o que causa sobrecarga administrativa.

Uso do nome do FQDN em Contato ou Rota de Registro

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

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

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

Cabeçalhos de contexto de chamada

No momento, 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 oferece suporte a 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 é 64 caracteres. O comprimento máximo do valor do cabeçalho UUI é 256 caracteres. O valor do cabeçalho da interface do usuário 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 oferecem suporte a até cinco cabeçalhos SIP personalizados. A chave de cabeçalho SIP personalizada deve começar com um prefixo X-MS-Custom- obrigatório. 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 da 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	Valor
Candidatos de mídia em 183 e 200 mensagens provenientes de	Processadores de mídia
Número de 183 mensagens que a SBC pode receber	Um por sessão
Ligação pode ser com resposta provisória (183)	Sim
Ligação 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 descanso HTTP da seguinte maneira:

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

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

  Observação

  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 a SBC envie e receba mídia de e para os candidatos do PSD fornecidos.

  Observação

  O roteamento direto não oferece suporte ao convite de oferta atrasada (convite sem SDP).

Vários pontos de extremidade 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 Andamento 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 o envio dessas mensagens correlaciona-se com o intervalo do recebimento de mensagens do Controlador de Chamadas. No diagrama a seguir, há duas 180 mensagens geradas pelo proxy SIP. Essas mensagens vêm dos dois pontos de extremidade do SDK. Cada um dos pontos de extremidade tem um ID de tag exclusivo. Cada mensagem proveniente de um ponto de extremidade 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 "Progresso da sessão SIP 183" com o SDP do ponto de extremidade substituído pelo SDP do processador de mídia. No diagrama a seguir, o ponto de extremidade do Fork 2 atendeu à chamada. A mensagem SIP 183 é gerada apenas uma vez. O 183 pode vir em um fork existente ou iniciar um novo.

5. Uma mensagem de Aceitação de Chamada é enviada ao 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 de extremidade 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 Andamento da 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 correlaciona-se com o intervalo de recebimento das mensagens do controlador de chamadas. 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 ao 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.

   

Opção Substitui

A SBC deve apoiar o INVITE com Replaces.

Tamanho das considerações sobre o 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 oferece suporte a dois métodos para transferência de chamadas:

• Opção 1. Processos de proxy SIP Consulte o cliente localmente e atue como um Árbitro 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 o Refer para o SBC e atua como um Transferidor, conforme descrito na Seção 6 da RFC 5589.

  Com essa opção, o proxy SIP envia uma Referência ao SBC e espera que o SBC manipule a Transferência totalmente.

O proxy SIP seleciona o método com base nos recursos relatados pelo SBC. Se o SBC indicar que ele suporta o método "Refer", o proxy SIP usa a Opção 2 para transferências de chamada. 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 é 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 Notify : 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 a partir do cliente localmente e atua como um árbitro

Se o SBC indicou que o método Refer não é suportado, o proxy SIP atua como um árbitro. A solicitação Refer que vem do cliente termina no proxy SIP. A solicitação Refer 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 da RFC 3892.

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

O Proxy SIP como transferidor é o método preferido para transferências de chamadas.

O padrão é explicado na Seção 6 da RFC 5589. As RFCs relacionadas são:

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

• O SIP (Session Initiation Protocol) "substitui" o cabeçalho

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

Essa opção pressupõe que o proxy SIP atua como um transferidor e envia uma mensagem de referência para o SBC. A SBC atua como cessionária e lida com a Refer para gerar uma nova oferta de transferência. Há dois casos possíveis:

• A chamada é transferida para um participante PSTN externo.
• A chamada é transferida de um ponto de extremidade do SDK para outro ponto de extremidade do 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/Transferidor 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 de 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 RM de destino de transferência completa e a ID do recurso de comunicação, respectivamente.

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

Parâmetro	Valor	Descrição
x-m	MRI	MRI completa do transferidor/alvo de transferência conforme preenchido pelo CC
x-t	ID de locatário	ID do recurso x-t ID do recurso opcional conforme preenchido pela CC
x-ti	ID de correlação do transferidor	ID de correlação da chamada para o cedente
x-tt	URI de chamada de destino de transferência	URI de substituição de chamada codificado

O tamanho do cabeçalho de referência pode ser de até 400 símbolos nesse caso. O SBC deve suportar o tratamento de mensagens de referência com tamanho de 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 SDK/Teams, tocar para outros usuários ou usuários em paralelo (toque simultâneo) ou tocar em um grupo de usuários ou números. Itens a serem considerados:

• 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 a chamada está sendo encaminhada" 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 a chamada está sendo encaminhada".

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

Temporizador de sessão

O proxy SIP suporta (sempre oferece) o Timer de Sessão. O uso do Timer de Sessão pela 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, correspondendo o número a 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

Observação

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

O cabeçalho History-Info é usado para redirecionar solicitações SIP e "fornece um mecanismo padrão para capturar as informações do histórico de solicitações para habilitar 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 maneira:

• 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 ao controlador PSTN. Usando apenas entradas que têm o parâmetro de número de telefone, o controlador PSTN recria um novo cabeçalho History-Info e o transmite ao 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.

  Observação

  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 loop.

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 do URI Reason é SIP;cause=496;text="User Busy", que obtém seus caracteres ;, " e = escapados para seus valores hexadecimais ASCII %3B, %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.

Retry-After

Se um datacenter de roteamento direto estiver ocupado, o serviço poderá enviar uma mensagem Repetir Depois 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 Microsoft disponível.

Manipulando 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.