Roteamento direto-protocolo SIPDirect Routing - SIP protocol

Este artigo descreve como o roteamento direto implementa o protocolo de iniciação de sessão (SIP).This article describes how Direct Routing implements the Session Initiation Protocol (SIP). Para direcionar corretamente o tráfego entre um controlador de borda de sessão (SBC) e o proxy SIP, alguns parâmetros de SIP devem ter valores específicos.To properly route traffic between a Session Border Controller (SBC) and the SIP proxy, some SIP parameters must have specific values. Este artigo destina-se a administradores de voz responsáveis por configurar a conexão entre o SBC local e o serviço de proxy SIP.This article is intended for voice administrators who are responsible for configuring the connection between the on-premises SBC and the SIP proxy service.

Processando a solicitação de entrada: encontrando o locatário e o usuárioProcessing the incoming request: finding the tenant and user

Em uma chamada de entrada, o proxy SIP precisa encontrar o locatário para o qual a chamada está destinada e localizar o usuário específico nesse locatário.On an incoming call, the SIP proxy needs to find the tenant to which the call is destined and find the specific user within this tenant. O administrador do locatário pode configurar números não-DID, por exemplo, + 1001, em vários locatários.The tenant administrator might configure non-DID numbers, for example +1001, in multiple tenants. Portanto, é importante localizar o locatário específico no qual realizar a pesquisa de número porque os números não-coversais podem ser iguais em várias organizações do Microsoft 365 ou do Office 365.Therefore, it is important to find the specific tenant on which to perform the number lookup because the non-DID numbers might be the same in multiple Microsoft 365 or Office 365 organizations.

Esta seção descreve como o proxy SIP localiza o locatário e o usuário e executa a autenticação do SBC na conexão de entrada.This section describes how the SIP proxy finds the tenant and the user, and performs authentication of the SBC on the incoming connection.

Veja a seguir um exemplo da mensagem de convite SIP em uma chamada recebida:The following is an example of the SIP Invite message on an incoming call:

Nome do parâmetroParameter name Exemplo do valorExample of the value
Solicitação-URIRequest-URI CONVIDAR sip:+18338006777@sip.pstnhub.microsoft.com SIP/2,0INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
Via cabeçalhoVia Header Via: SIP/2.0/TLS sbc1. adatum. biz: 5058; alias; Branch = z9hG4bKac2121518978Via: SIP/2.0/TLS sbc1.adatum.biz:5058;alias;branch=z9hG4bKac2121518978
Cabeçalho Max-ForwardsMax-Forwards header Máx-forwards: 68Max-Forwards:68
Do cabeçalhoFrom Header Do cabeçalho de: <SIP: 7168712781@sbc1. adatum. biz; Transport = UDP; tag = 1c747237679From Header From: sip:7168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679</span
Para cabeçalhoTo Header Para: sip:+183338006777@sbc1.adatum.bizTo: sip:+183338006777@sbc1.adatum.biz
Cabeçalho CSeqCSeq header CSeq: 1 conviteCSeq: 1 INVITE
Cabeçalho de contatoContact Header Contato: <SIP: 68712781@sbc1. adatum. biz: 5058; Transport = TLS>Contact: <sip: 68712781@sbc1.adatum.biz:5058;transport=tls>

Ao receber o convite, o proxy SIP executa as seguintes etapas:On receiving the invite, the SIP proxy performs the following steps:

  1. Verifique o certificado.Check the certificate. 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 do requerente do certificado apresentado.On the initial connection, the Direct Routing service takes the FQDN name presented in the Contact header and matches it to the Common Name or Subject Alternative name of the presented certificate. O nome SBC deve corresponder a uma das seguintes opções:The SBC name must match one of the following options:

    • Opção 1.Option 1. O nome FQDN completo apresentado no cabeçalho do contato deve corresponder ao nome comum/nome alternativo do assunto do certificado apresentado.The full FQDN name presented in the Contact header must match the Common Name/Subject Alternative name of the presented certificate.

    • Opção 2. Option 2. A parte do domínio do nome FQDN apresentada no cabeçalho do contato (por exemplo, adatum.biz do nome FQDN sbc1.adatum.biz) deve coincidir com o valor curinga em nome comum/nome alternativo do assunto (por exemplo, *. adatum.biz).The domain portion of the FQDN name presented in the Contact header (for example adatum.biz of the FQDN name sbc1.adatum.biz) must match the wildcard value in Common Name/Subject Alternative Name (for example *.adatum.biz).

  2. Tente localizar um locatário usando o nome FQDN completo apresentado no cabeçalho do contato.Try to find a tenant using the full FQDN name presented in the Contact header.

    Verifique se o nome FQDN do cabeçalho do contato (sbc1.adatum.biz) está registrado como um nome DNS em qualquer organização do Microsoft 365 ou do Office 365.Check if the FQDN name from the Contact header (sbc1.adatum.biz) is registered as a DNS name in any Microsoft 365 or Office 365 organization. Se encontrado, a pesquisa do usuário é realizada no locatário que tem o FQDN do SBC registrado como um nome de domínio.If found, the lookup of the user is performed in the tenant that has the SBC FQDN registered as a Domain name. Se não for encontrado, a etapa 3 será aplicada.If not found, Step 3 applies.

  3. A etapa 3 aplica-se apenas se a etapa 2 falhar.Step 3 only applies if Step 2 failed.

    Remova a porção do host do FQDN, apresentada no cabeçalho do contato (FQDN: sbc12.adatum.biz, após remover a porção do host: adatum.biz) e verifique se esse nome está registrado como um nome DNS em qualquer organização do Microsoft 365 ou do Office 365.Remove the host portion from the FQDN, presented in the Contact header (FQDN: sbc12.adatum.biz, after removing the host portion: adatum.biz), and check if this name is registered as a DNS name in any Microsoft 365 or Office 365 organization. Se encontrado, a pesquisa do usuário será realizada nesse locatário.If found, the user lookup is performed in this tenant. Se não for encontrado, a chamada falhará.If not found, the call fails.

  4. Usando o número de telefone apresentado na solicitação-URI, execute a pesquisa de número reverso dentro do locatário localizado na etapa 2 ou 3.Using the phone number presented in the Request-URI, perform the reverse number lookup within the tenant found in Step 2 or 3. Compare o número de telefone apresentado a um URI de SIP do usuário dentro do locatário encontrado na etapa anterior.Match the presented phone number to a user SIP URI within the tenant found on the previous step.

  5. Aplicar configurações de tronco.Apply trunk settings. Localize os parâmetros definidos pelo administrador de locatários para este SBC.Find the parameters set by the tenant admin for this SBC.

    A Microsoft não oferece suporte a um servidor de proxy SIP ou de agente de usuário de terceiros entre o proxy SIP da Microsoft e o SBC emparelhado, que pode modificar o URI de solicitação criado pelo SBC emparelhado.Microsoft does not support having a third-party SIP proxy or User Agent Server between the Microsoft SIP proxy and the paired SBC, which might modify the Request URI created by the paired SBC.

    Os requisitos para as duas pesquisas (etapas 2 e 3) necessárias para o cenário em que um SBC está interconectado a vários locatários (cenário de transportadora) são abordados mais adiante neste artigo.The requirements for the two lookups (steps 2 and 3) needed for the scenario where one SBC is interconnected to many tenants (carrier scenario) are covered later in this article.

Requisitos detalhados para cabeçalho e solicitação-URI de contatoDetailed requirements for Contact header and Request-URI

Cabeçalho de contatoContact header

Para todas as chamadas recebidas para o proxy SIP da Microsoft, o cabeçalho do contato deve ter o o FQDN do SBC emparelhado no nome do host do URI da seguinte maneira:For all incoming calls to the Microsoft SIP proxy, the Contact header must have the paired SBC FQDN in the URI hostname as follows:

Sintaxe: contato: <SIP: telefone ou SIP address@FQDN do SBC; Transport = TLS>Syntax: Contact: <sip:phone or sip address@FQDN of the SBC;transport=tls>

Esse nome também deve estar no (s) campo (s) nome (s) nome (s) do requerente ou nome alternativo do certificado.This name must also be in the Common Name or Subject Alternative name field(s) of the presented certificate. A Microsoft oferece suporte ao uso de valores curinga do (s) nome (s) nos campos nome comum ou nome alternativo do assunto do certificado.Microsoft supports using wildcard values of the name(s) in the Common Name or Subject Alternative Name fields of the certificate.

O suporte para caracteres curinga está descrito no RFC 2818, seção 3,1.The support for wildcards is described in RFC 2818, section 3.1. CriadasSpecifically:

"Os nomes podem conter o caractere curinga * que é considerado para corresponder a um único 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 corresponde a foo.com, mas não bar.com. ""Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com."

Se mais de um valor no cabeçalho do contato apresentado em uma mensagem SIP for enviado pelo SBC, somente a parte FQDN do primeiro valor do cabeçalho do contato será usada.If more than one value in the Contact header presented in a SIP message is sent by the SBC, only the FQDN portion of the first value of the Contact header is used.

Solicitação-URIRequest-URI

Para todas as chamadas recebidas, o URI de solicitação é usado para corresponder ao número de telefone a um usuário.For all incoming calls, the Request-URI is used to match the phone number to a user.

Atualmente, o número de telefone deve conter um sinal de adição (+), conforme mostrado no exemplo a seguir.Currently The phone number must contain a plus sign (+) as shown in the following example.

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

Considerações de cabeçalhos de rota de contato e registroContact and Record-Route headers considerations

O proxy SIP precisa calcular o próximo FQDN de salto para as novas transações de cliente em caixa de diálogo (por exemplo, até mais ou convidar) e ao responder às opções de SIP.The SIP proxy needs to calculate the next hop FQDN for new in-dialog client transactions (for example Bye or Re-Invite), and when replying to SIP Options. É usado o contato ou a rota de registro.Either Contact or Record-Route are used.

De acordo com a RFC 3261, o cabeçalho do contato é necessário em qualquer solicitação que pode resultar em uma nova caixa de diálogo.According to RFC 3261, Contact header is required in any request that can result in a new dialog. A rota de registro será necessária apenas se um proxy quiser permanecer no caminho de solicitações futuras em uma caixa de diálogo.The Record-Route is only required if a proxy wants to stay on the path of future requests in a dialog. Se um SBC de proxy estiver em uso com a otimização de mídia local para roteamento direto, será necessário configurar uma rota de registro, pois o SBC do proxy precisa permanecer na rota.If a proxy SBC is in use with Local Media Optimization for Direct Routing, a record route will need to be configured as the proxy SBC needs to stay in the route.

A Microsoft recomenda usar somente o cabeçalho do contato se não for usado um SBC do proxy:Microsoft recommends using only Contact header if a proxy SBC is not used:

  • Por RFC 3261, a rota de registro é usada se um proxy quiser permanecer no caminho de solicitações futuras em uma caixa de diálogo, que não é essencial se nenhum SBC de proxy estiver configurado, pois todo o tráfego vai entre o proxy SIP da Microsoft e o SBC emparelhado.Per RFC 3261, Record-Route is used if a proxy wants to stay on the path of future requests in a dialog, which is not essential if no proxy SBC is configured as all traffic goes between the Microsoft SIP proxy and the paired SBC.

  • O proxy SIP da Microsoft usa apenas o cabeçalho do contato (não o caminho do registro) para determinar o próximo salto ao enviar opções de ping de saída.The Microsoft SIP proxy uses only Contact header (not Record-Route) to determine the next hop when sending outbound ping Options. Configurar apenas um parâmetro (contato) em vez de dois (contato e rota de registro) simplifica a administração se um SBC de proxy não estiver em uso.Configuring only one parameter (Contact) instead of two (Contact and Record-Route) simplifies the administration if a proxy SBC is not in use.

Para calcular o próximo salto, o proxy SIP usa:To calculate the next hop, the SIP proxy uses:

  • Prioridade 1.Priority 1. Rota de registro de nível superior.Top-level Record-Route. Se a rota de registro de nível superior contiver o nome FQDN ou IP, o nome FQDN ou o IP será usado para fazer a conexão de entrada na caixa de diálogo.If the top-level Record-Route contains the FQDN name or IP, the FQDN name or IP is used to make the outbound in-dialog connection.

  • Prioridade 2.Priority 2. Cabeçalho do contato.Contact header. Se a rota de registro não existir, o proxy SIP irá procurar o valor do cabeçalho do contato para fazer a conexão de saída.If Record-Route does not exist, the SIP proxy will look up the value of the Contact header to make the outbound connection. (Essa é a configuração recomendada.)(This is the recommended configuration.)

Se tanto o contato quanto a rota de registro forem usados, o administrador de SBC deve manter os valores idênticos, o que causa sobrecarga administrativa.If both Contact and Record-Route are used, the SBC administrator must keep their values identical, which causes administrative overhead.

Uso do nome FQDN em contato ou rota de registroUse of FQDN name in Contact or Record-Route

Não há suporte para o uso de um endereço IP em Record-Route ou Contact.Use of an IP address is not supported in either Record-Route or Contact. A única opção com suporte é um FQDN, que deve corresponder ao nome comum ou ao nome alternativo do requerente do certificado SBC (há suporte para valores curinga no certificado).The only supported option is an FQDN, which must match either the Common Name or Subject Alternative Name of the SBC certificate (wildcard values in the certificate are supported).

  • Se um endereço IP for apresentado em Record-Route ou Contact, a verificação do certificado falhará e a chamada falhará.If an IP address is presented in Record-route or Contact, the certificate check fails and the call fails.

  • Se o FQDN não coincidir com o valor do nome comum ou alternativo do sujeito no certificado apresentado, a chamada falhará.If the FQDN does not match the value of the Common or Subject Alternative Name in the presented certificate, the call fails.

Chamada recebida: Descrição da caixa de diálogo SIPInbound call: SIP dialog description

A tabela a seguir resume as diferenças de fluxo de chamada e as semelhanças entre os modos não bypass e bypass:The following table below summarizes the call flow differences and similarities between non-bypass and bypass modes:

Nome do parâmetroParameter name Modo não bypassNon-bypass mode Modo ignorarBypass mode
Candidatos a mídia em 183 e 200 mensagens vindas deMedia candidates in 183 and 200 messages coming from Processadores de mídiaMedia processors ClientesClients
Número de mensagens 183 que o SBC pode receberNumber of 183 messages SBC can receive Um por sessãoOne per session MuitosMultiple
A chamada pode ter uma resposta provisionada (183)Call can be with provisional answer (183) SimYes SimYes
A chamada pode ser sem resposta provisório (183)Call can be without provisional answer (183) SimYes SimYes

Fluxo de bypass de não mídiaNon-media bypass flow

Um usuário do teams pode ter vários pontos de extremidade ao mesmo tempo.A Teams user might have multiple endpoints at the same time. Por exemplo, Teams para cliente Windows, Team para cliente iPhone e telefone do Teams (cliente Android do Teams).For example, Teams for Windows client, Teams for iPhone client, and Teams Phone (Teams Android client). Cada ponto de extremidade pode sinalizar um HTTP REST da seguinte maneira:Each endpoint might signal an HTTP rest as follows:

  • Andamento da chamada – convertido pelo proxy SIP para a mensagem SIP 180.Call progress – converted by the SIP proxy to the SIP message 180. Na recepção da mensagem 180, o SBC deve gerar um toque local.On receiving message 180, the SBC must generate local ringing.

  • Resposta de mídia – convertida pelo proxy SIP para a mensagem 183 com candidatos a mídia no protocolo de descrição de sessão (SDP).Media answer – converted by the SIP proxy to message 183 with media candidates in Session Description Protocol (SDP). Na recepção da mensagem 183, o SBC espera a conexão com os candidatos à mídia recebidos na mensagem SDP.On receiving message 183, the SBC expects to connect to the media candidates received in the SDP message. Observe que, em alguns casos, a resposta de mídia pode não ser gerada, e o ponto de extremidade pode atender com a mensagem "chamada aceita".Note that in some cases the Media answer might not be generated, and the end point might answer with “Call Accepted” message.

  • Chamada aceita – convertida pelo proxy SIP para a mensagem SIP 200 com SDP.Call accepted – converted by the SIP proxy to SIP message 200 with SDP. Na recepção da mensagem 200, o SBC é esperado para enviar e receber mídia para e dos candidatos SDP fornecidos.On receiving message 200, the SBC is expected to send and receive media to and from the provided SDP candidates.

Vários pontos de extremidade em toque com resposta provisórioMultiple endpoints ringing with provisional answer

  1. Ao receber o primeiro convite do SBC, o proxy SIP envia a mensagem "SIP SIP/2.0 100 tentando" e notifica todos os pontos de extremidade do usuário final sobre a chamada recebida.On receiving the first Invite from the SBC, the SIP proxy sends the message "SIP SIP/2.0 100 Trying" and notifies all end user endpoints about the incoming call.

  2. Durante a notificação, cada ponto de extremidade começará a tocar e enviar mensagens de "andamento da chamada" ao proxy SIP.Upon notification, each endpoint will start ringing and sending "Call progress” messages to the SIP proxy. Como um usuário do teams pode ter vários pontos de extremidade, o proxy SIP pode receber várias mensagens de progresso de chamada.Because a Teams user can have multiple end points, the SIP proxy might receive multiple Call Progress messages.

  3. Para cada mensagem de progresso de chamada recebida dos clientes, o proxy SIP converte a mensagem de progresso da chamada na mensagem SIP "SIP SIP/2.0 180 tentando".For every Call Progress message received from the clients, the SIP proxy converts the Call Progress message to the SIP message "SIP SIP/2.0 180 Trying". O intervalo para enviar tais mensagens é definido pelo intervalo das mensagens de recebimento do controlador de chamada.The interval for sending such messages is defined by the interval of the receiving messages from the Call Controller. No diagrama a seguir, há 2 180 mensagens geradas pelo proxy SIP.In the following diagram, there are two 180 messages generated by the SIP proxy. Essas mensagens são provenientes dos dois pontos de extremidade das equipes do usuário.These messages come from the two Teams endpoints of the user. Cada um dos clientes tem uma ID de marca exclusiva.The clients each have a unique Tag ID. Todas as mensagens recebidas de um ponto de extremidade diferente serão uma sessão separada (o parâmetro "tag" no campo "para" será diferente).Every message coming from a different endpoint will be a separate session (the parameter “tag” in the “To” field will be different). Mas um ponto de extremidade pode não gerar a mensagem 180 e enviar a mensagem 183 imediatamente, conforme mostrado no diagrama a seguir.But an endpoint might not generate message 180 and send message 183 right away as shown in the following diagram.

  4. Depois que um ponto de extremidade gerar uma mensagem de resposta de mídia com os endereços IP dos candidatos à mídia do ponto de extremidade, o proxy SIP converterá a mensagem recebida para uma mensagem "andamento da sessão SIP 183" com o SDP do cliente substituído pelo SDP do processador de mídia.Once an endpoint generates a Media Answer message with the IP addresses of endpoint’s media candidates, the SIP proxy converts the message received to a "SIP 183 Session Progress" message with the SDP from the client replaced by the SDP from the Media Processor. No diagrama a seguir, o ponto de extremidade da bifurcação 2 atendeu na chamada.In the following diagram, the endpoint from Fork 2 answered the call. Se o tronco não for bypass, a mensagem SIP do 183 será gerada apenas uma vez (um bot ou ponto final do cliente).If the trunk is non-bypassed, the 183 SIP message is generated only once (either Ring Bot or Client End Point). O 183 pode vir em uma bifurcação existente ou iniciar uma nova.The 183 might come on an existing fork or start a new one.

  5. Uma mensagem de aceitação de chamadas é enviada com os candidatos finais da empresa que aceitou a chamada.A Call Acceptance message is sent with the final candidates of the endpoint that accepted the call. A mensagem de aceitação da chamada é convertida para a mensagem SIP 200.The Call Acceptance message is converted to SIP message 200.

Diagrama mostrando vários pontos de extremidade tocando com resposta de provisório

Vários pontos de extremidade tocando sem resposta provisórioMultiple endpoints ringing without provisional answer

  1. Ao receber o primeiro convite do SBC, o proxy SIP envia a mensagem "SIP SIP/2.0 100 tentando" e notifica todos os pontos de extremidade do usuário final sobre a chamada recebida.On receiving the first Invite from the SBC, the SIP proxy sends the message "SIP SIP/2.0 100 Trying" and notifies all end user endpoints about the incoming call.

  2. Após a notificação, cada ponto de extremidade começará a tocar e enviar a mensagem "andamento da chamada" ao proxy SIP.Upon notification, each endpoint will start ringing and sending the message "Call progress” to the SIP proxy. Como um usuário do teams pode ter vários pontos de extremidade, o proxy SIP pode receber várias mensagens de progresso de chamada.Because a Teams user can have multiple end points, the SIP proxy might receive multiple Call Progress messages.

  3. Para cada mensagem de progresso de chamada recebida dos clientes, o proxy SIP converte a mensagem de progresso da chamada na mensagem SIP "SIP SIP/2.0 180 tentando".For every Call Progress message received from the clients, the SIP proxy converts the Call Progress message to the SIP message "SIP SIP/2.0 180 Trying". O intervalo para enviar as mensagens é definido pelo intervalo de recebimento das mensagens do controlador de chamada.The interval for sending the messages is defined by the interval of receiving the messages from the Call Controller. Na imagem abaixo, há 2 180 mensagens geradas pelo proxy SIP, o que significa que o usuário se registrou em três clientes do Teams e cada cliente envia o andamento da chamada.On the picture below there are two 180 messages generated by the SIP proxy, meaning that user logged into three Teams clients and each client send the call progress. Todas as mensagens serão uma sessão separada ("marca" de parâmetro no campo "para" é diferente)Every message will be a separate session (parameter “tag” in “To” field is different)

  4. Uma mensagem de aceitação de chamadas é enviada com os candidatos finais da empresa que aceitou a chamada.A Call Acceptance message is sent with the final candidates of the endpoint that accepted the call. A mensagem de aceitação da chamada é convertida para a mensagem SIP 200.The Call Acceptance message is converted to SIP message 200.

Diagrama mostrando vários pontos de extremidade tocando sem resposta de provisório

Fluxo de bypass de mídiaMedia bypass flow

As mesmas mensagens (100 tentando, 180, 183) são usadas no cenário de bypass de mídia.The same messages (100 Trying, 180, 183) are used in the media bypass scenario.

O esquema abaixo mostra um exemplo do fluxo de chamadas de ignorar chamadas.The schema below shows an example of the bypass call flow. Observe que os candidatos à mídia podem vir de diferentes pontos de extremidade.Note that the media candidates can come from different endpoints.

Diagrama mostrando vários pontos de extremidade tocando com resposta de provisório

Opção substituiReplaces option

O SBC deve dar suporte a INVITE com substituições.The SBC must support Invite with Replaces.

Tamanho das considerações do SDPSize of SDP considerations

A interface de roteamento direto pode enviar uma mensagem SIP excedendo 1.500 bytes.The Direct Routing interface might send a SIP message exceeding 1,500 bytes. O tamanho do SDP causa principalmente isso.The size of SDP primarily causes this. No entanto, se houver um tronco UDP por trás do SBC, ele pode rejeitar a mensagem se ele for encaminhado do proxy Microsoft SIP para o tronco não modificado.However, if there is a UDP trunk behind the SBC, it might reject the message if it is forwarded from the Microsoft SIP proxy to the trunk unmodified. A Microsoft recomenda a remoção de alguns valores no SDP no SBC ao enviar a mensagem para os troncos UDP.Microsoft recommends stripping some values in SDP on the SBC when sending the message to the UDP trunks. Por exemplo, os candidatos à ICE ou codecs não utilizados podem ser removidos.For example, the ICE candidates or unused codecs can be removed.

Transferência de chamadasCall transfer

O roteamento direto dá suporte a dois métodos para transferência de chamadas:Direct Routing supports two methods for call transfer:

  • Opção 1.Option 1. Os processos de proxy SIP se referem ao cliente localmente e atuam como um referee, conforme descrito na seção 7,1 da RFC 3892.SIP proxy processes Refer from the client locally and acts as a Referee as described in section 7.1 of RFC 3892.

    Com essa opção, o proxy SIP encerra a transferência e adiciona um novo convite.With this option, the SIP proxy terminates the transfer and adds a new Invite.

  • Opção 2. Option 2. O proxy SIP envia a referência ao SBC e age como um transferíment como se descrever na seção 6 da RFC 5589.SIP proxy sends the Refer to the SBC and acts as a Transferor as describing in Section 6 of 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.With this option, the SIP proxy sends a Refer to the SBC and expects the SBC to handle the Transfer fully.

O proxy SIP seleciona o método com base nas funcionalidades relatadas pelo SBC.The SIP proxy selects the method based on the capabilities reported by the SBC. Se o SBC indicar que ele dá suporte ao método "refer", o proxy SIP usará a opção 2 para transferências de chamadas.If the SBC indicates that it supports the method “Refer”, the SIP proxy will use Option 2 for call transfers.

Veja a seguir um exemplo de um SBC que envia a mensagem informando que o método refer tem suporte:The following is an example of an SBC sending the message that the Refer method is supported:

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

Se o SBC não indicar que se referem ao método com suporte, o roteamento direto usará a opção 1 (o proxy SIP age como um referee).If the SBC doesn’t indicate that Refer as a supported method, Direct Routing will use Option 1 (SIP proxy acts as a Referee) . O SBC também deve sinalizar que ele dá suporte ao método Notify:The SBC must also signal that it supports the Notify method:

Exemplo de SBC que indica que não há suporte para o método de referência:Example of SBC indicating that Refer method is not supported:

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

Os processos de proxy SIP se referem ao cliente localmente e atuam como um refereeSIP proxy processes Refer from the client locally and acts as a Referee

Se o SBC indicou que o método refer não é compatível, o proxy SIP atua como um referee.If the SBC indicated that the Refer method is not supported, the SIP proxy acts as a Referee.

A solicitação de referência que vem do cliente será terminada no proxy SIP.The Refer request that comes from the client will be terminated on the SIP proxy. (A solicitação de referência do cliente é mostrada como "transferência de chamada para Dave" no diagrama a seguir.(The Refer request from the client is shown as “Call transfer to Dave” in the following diagram. Para obter mais informações, consulte a seção 7,1 da RFC 3892.For more information, see section 7.1 of RFC 3892.

Diagrama mostrando vários pontos de extremidade tocando com resposta de provisório

Proxy SIP envie a referência ao SBC e age como um transferímentSIP proxy send the Refer to the SBC and acts as a Transferor

Esse é o método preferido para transferências de chamadas e é obrigatório para dispositivos que buscam certificação bypass de mídia.This is the preferred method for call transfers, and it is mandatory for devices seeking media bypass certification. A transferência de chamadas sem o SBC não pode fazer referência não é compatível com o modo de bypass de mídia.Call Transfer without the SBC being able to handle Refer is not supported in media bypass mode.

O padrão é explicado na seção 6 da RFC 5589.The standard is explained in Section 6 of RFC 5589. Os RFCs relacionados são:The related RFCs are:

Essa opção pressupõe que o proxy SIP atue como um transferíment e envia uma mensagem de referência ao SBC.This option assumes that the SIP proxy acts as a Transferor and sends a Refer message to the SBC. O SBC atua como um transferida e manipula a referência para gerar uma nova oferta para transferência.The SBC acts as a Transferee and handles the Refer to generate a new offer for transfer. Há dois casos possíveis:There are two possible cases:

  • A chamada é transferida para um participante PSTN externo.The call is transferred to an external PSTN participant.
  • A chamada é transferida de um usuário do teams para outro usuário do teams no mesmo locatário por meio do SBC.The call is transferred from one Teams user to another Teams user in the same tenant via the SBC.

Se a chamada for transferida de um usuário do teams para outro por meio do SBC, espera-se que o SBC emita um novo Invite (iniciar uma nova caixa de diálogo) para o destino da transferência (o usuário do Teams) usando as informações recebidas na mensagem de referência.If the call is transferred from one Teams user to another via the SBC, the SBC is expected to issue a new invite (start a new dialog) for the transfer target (the Teams user) using the information received in the Refer message.

Para preencher os campos para/transferíment para a transação da solicitação internamente, o proxy SIP precisa transmitir essas informações dentro dos cabeçalhos refere-se a/REFERENCIAdo.To populate the To/Transferor fields for the transaction of the request internally, the SIP proxy needs to convey this information inside the REFER-TO/REFERRED-BY headers.

O proxy SIP formará a opção fazer como um URI SIP formado por um FQDN do proxy SIP no nome do host e qualquer um dos seguintes:The SIP proxy will form the REFER-TO as a SIP URI comprised of a SIP proxy FQDN in the hostname and either one of the following:

  • Um número de telefone E. 164 na parte username do URI, caso o destino da transferência seja um número de telefone ouAn E.164 phone number in the username part of the URI in case the transfer target is a phone number, or

  • parâmetros x-m e x-t codificando a ID de locatário e MRI de destino da transferência completa, respectivamentex-m and x-t parameters encoding the full transfer target MRI and tenant ID respectively

O cabeçalho REFERENCIAdo é um URI de SIP com o transferível MRI codificado, bem como a ID do locatário do transportador e outros parâmetros de contexto de transferência, conforme mostrado na tabela a seguir:The REFERRED-BY header is a SIP URI with transferor MRI encoded in it as well as transferor tenant ID and other transfer context parameters as shown in the following table:

ParâmetroParameter ValorValue DescriçãoDescription
x-mx-m ENCONTRAMRI MRI completa do transportador/destino de transferência conforme preenchido pelo CCFull MRI of transferor/transfer target as populated by CC
x-tx-t ID do locatárioTenant ID ID de locatário opcional de ID de locatário x-t como preenchido pelo CCx-t Tenant ID Optional Tenant Id as populated by CC
x-tix-ti ID de correlação do transportadorTransferor Correlation Id ID de correlação da chamada para o transferidarCorrelation Id of the call to the transferor
x-TTx-tt URI da chamada de destino de transferênciaTransfer target call URI URI de substituição de chamadas codificadasEncoded call replacement URI

Nesse caso, o tamanho do cabeçalho de referência pode ter até 400 símbolos.The size of the Refer Header can be up to 400 symbols in this case. O SBC deve dar suporte a manipulação de mensagens com tamanho de até 400 símbolos.The SBC must support handling Refer messages with size up to 400 symbols.

Diagrama mostrando vários pontos de extremidade tocando com resposta de provisório

Temporizador de sessãoSession timer

O proxy SIP dá suporte (sempre oferece) o temporizador da sessão em chamadas sem bypass, mas não o oferece em chamadas ignoradas.The SIP proxy supports (always offers) the Session Timer on non-bypass calls but does not offer it on bypass calls. O uso do temporizador de sessão pelo SBC não é obrigatório.Use of the Session Timer by the SBC is not mandatory.

Uso do parâmetro Request-URI User = PhoneUse of Request-URI parameter user=phone

O proxy SIP analisa o URI da solicitação e, se o parâmetro User = Phone estiver presente, o serviço manipulará o URI da solicitação como um número de telefone, correspondendo ao número para um usuário.The SIP proxy analyses the Request-URI and if the parameter user=phone is present, the service will handle the Request-URI as a phone number, matching the number to a user. Se o parâmetro não estiver presente, o proxy SIP aplica heurística para determinar o tipo de usuário da solicitação-URI (número de telefone ou endereço SIP).If parameter is not present the SIP proxy applies heuristics to determine the Request-URI user type (phone number or a SIP address).

Microsof recomenda sempre aplicar o parâmetro User = Phone para simplificar o processo de configuração de chamadas.Microsof recommends always applying the user=phone parameter to simplify the call setup process.

Histórico-cabeçalho de informaçõesHistory-Info header

O cabeçalho histórico-informações é usado para redirecionar solicitações SIP e "fornecer (s) 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."The History-Info header is used for retargeting SIP requests and “provide(s) a standard mechanism for capturing the request history information to enable a wide variety of services for networks and end-users.” Para obter mais informações, consulte RFC 4244 – seção 1,1.For more information, see RFC 4244 – Section 1.1. Para o Microsoft Phone System, esse cabeçalho é usado nos cenários SimulRing e encaminhamento de chamadas.For Microsoft Phone System, this header is used in Simulring and Call Forwarding scenarios.

Se estiver enviando, o histórico-informações será habilitado da seguinte maneira:If sending, the History-Info is enabled as follows:

  • O proxy SIP inserirá um parâmetro contendo o número de telefone associado em entradas do histórico-informações individuais que compõem o cabeçalho do histórico-informações enviado ao controlador PSTN.The SIP proxy will insert a parameter containing the associated phone number in individual History-Info entries that comprise the History-Info header sent to the PSTN Controller. Usando somente entradas com o parâmetro número de telefone, o controlador PSTN recriará um novo cabeçalho de informações de histórico e passará para o provedor de tronco SIP via proxy SIP.Using only entries that have the phone number parameter, the PSTN Controller will rebuild a new History-Info header, and pass it on to the SIP trunk provider via SIP proxy.

  • History-info header será adicionado para casos de toque simultâneo e encaminhamento de chamadas.History-Info header will be added for simultaneous ring and call forwarding cases.

  • History-info header não será adicionado para casos de transferência de chamadas.History-Info header will not be added for call transfer cases.

  • Uma entrada de histórico individual no cabeçalho reconstruído histórico de informações terá o parâmetro de número de telefone fornecido combinado com o FQDN (sip.pstnhub.microsoft.com) definido como a parte do host do URI; um parâmetro de "User = Phone" será adicionado como parte do URI SIP.An individual history entry in the reconstructed History-Info header will have the phone number parameter provided combined with the Direct Routing FQDN (sip.pstnhub.microsoft.com) set as the host part of the URI; a parameter of ‘user=phone’ will be added as part of the SIP URI. Todos os outros parâmetros associados ao cabeçalho do histórico original-informações, exceto para parâmetros de contexto de telefone, serão passados no cabeçalho reconstruído histórico-informações.Any other parameters associated with the original History-Info header, except for phone context parameters, will be passed through in the re-constructed History-Info header. Observe que as entradas privadas (conforme determinado pelos mecanismos definidos na seção 3,3 da RFC 4244) serão encaminhadas como ocorre porque o provedor de tronco SIP é um par confiável.Note that entries that are private (as determined by the mechanisms defined in Section 3.3 of RFC 4244) will be forwarded as is because the SIP trunk provider is a trusted peer.

  • Histórico de entrada-as informações são ignoradas.Inbound History-Info is ignored.

Veja a seguir o formato do cabeçalho do histórico de informações enviado pelo proxy SIP:Following is the format of the History-info header sent by the SIP proxy:

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3B\cause%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.If the call was redirected several times, information about every redirect is included with the appropriate reason in chronological order.

Exemplo de cabeçalho:Header Example:

History-info: 
<sip:+14257123456@sip.pstnhub.microsoft.com;user=phone?Reason=SIP;cause=302;text=”Move Temporarily”>;index=1
<sip:+14257123457@sip.pstnhub.microsoft.com;user=phone?Reason=SIP;cause=496;text=”User Busy”>;index=1.1

O histórico-informações é protegido por um mecanismo TLS obrigatório.The History-Info is protected by a mandatory TLS mechanism.

Conexão SBC para mecanismo de roteamento direto e de failoverSBC connection to Direct Routing and failover mechanism

Consulte o mecanismo de failover de seção para sinalização SIP em planejar para roteamento direto.See the section Failover mechanism for SIP signaling in Plan for Direct Routing.

Repetir-apósRetry-After

Se um datacenter de roteamento direto estiver ocupado, o serviço poderá enviar uma mensagem Retry-After com um intervalo de um segundo para o SBC.If a Direct Routing datacenter is busy, the service can send a Retry-After message with a one-second interval to the SBC. Quando o SBC recebe uma mensagem 503 com um cabeçalho Retry-After em resposta a um convite, o SBC deve terminar essa conexão e experimentar o próximo Datacenter da Microsoft disponível.When the SBC receives a 503 message with a Retry-After header in response to an INVITE, the SBC must terminate that connection and try the next available Microsoft datacenter.

Reinicialização do ICE: ignorar chamada de mídia transferida para um ponto de extremidade que não é compatível com bypass de mídiaICE Restart: Media bypass call transferred to an endpoint that does not support media bypass

O SBC deve dar suporte a reinícios de ICE conforme descrito em RFC 5245, seção 9.1.1.1.The SBC must support ICE restarts as described in RFC 5245, section 9.1.1.1.

A reinicialização no roteamento direto é implementada de acordo com os seguintes parágrafos da RFC:The restart in Direct Routing is implemented according to the following paragraphs of the RFC:

Para reiniciar o ICE, um agente deve alterar o Ice-pwd e o Ice-ufrag para o fluxo de mídia em uma oferta. Observe que é permitido usar um atributo no nível da sessão em uma oferta, mas fornecer o mesmo Ice-pwd ou Ice-ufrag como um atributo em nível de mídia em uma oferta subsequente. Isso não é uma alteração na senha, apenas uma alteração em sua representação e não causa uma reinicialização do ICE.To restart ICE, an agent MUST change both the ice-pwd and the ice-ufrag for the media stream in an offer. Note that it is permissible to use a session-level attribute in one offer, but to provide the same ice-pwd or ice-ufrag as a media-level attribute in a subsequent offer. This is not a change in password, just a change in its representation, and does not cause an ICE restart.

Um agente define o restante dos campos no SDP para este fluxo de mídia como seria uma oferta inicial desse fluxo de mídia (consulte a seção 4,3). Consequentemente, o conjunto de candidatos pode incluir alguns, nenhum ou todos os candidatos anteriores desse fluxo e pode incluir um conjunto totalmente novo de candidatos coletados, conforme descrito na seção 4.1.1.An agent sets the rest of the fields in the SDP for this media stream as it would in an initial offer of this media stream (see Section 4.3). Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that stream and MAY include a totally new set of candidates gathered as described in Section 4.1.1.

Se a chamada foi inicialmente estabelecida com o bypass de mídia, e a chamada for transferida para um cliente Skype for Business, o roteamento direto precisará inserir um processador de mídia--isso ocorre porque o roteamento direto não pode ser usado com um cliente Skype for Business com o bypass de mídia.If the call was initially established with media bypass, and the call is transferred to a Skype for Business client, Direct Routing needs to insert a Media Processor--this is because Direct Routing cannot be used with a Skype for Business client with media bypass. O direcionamento direto inicia o processo de reinicialização ICE alterando o Ice-pwd e Ice-ufrag e oferecendo novos candidatos à mídia em um convite.Direct Routing starts the ICE restart process by changing the ice-pwd and ice-ufrag and offering new media candidates in a reinvite.