Delen via

Directe routering van Azure Communication Services: DETAILS VAN SIP-protocol

  • Artikel

In dit artikel wordt beschreven hoe directe routering het SIP (Session Initiation Protocol) implementeert om ervoor te zorgen dat de juiste verkeersroutes tussen een Session Border Controller (SBC) en de SIP-proxy worden uitgevoerd. Het markeert ook het belang van bepaalde SIP-parameters waarvoor specifieke waarden zijn vereist. Dit artikel is bedoeld voor spraakbeheerders die verantwoordelijk zijn voor het configureren van de verbinding tussen de SBC en de SIP-proxyservice.

De binnenkomende aanvraag verwerken: de Communication Services-resource zoeken

Notitie

SIP OPTIONS voor directe routering van Azure Communication Services zijn standaard ingeschakeld en kunnen niet worden uitgeschakeld. SBC moet eerst de OPTIONS-uitwisseling initiëren, omdat SIP Proxy wacht totdat SBC de uitwisseling start.

Voordat een binnenkomende of uitgaande oproep kan worden verwerkt, worden OPTIES-berichten uitgewisseld tussen SIP Proxy en de SBC. Met deze OPTIES-berichten kan SIP Proxy de toegestane mogelijkheden voor SBC bieden. Het is belangrijk dat OPTIES-onderhandeling succesvol is (200 OK-antwoord), waardoor verdere communicatie tussen SBC en SIP Proxy mogelijk is voor het tot stand brengen van aanroepen. De SIP-headers in een OPTIONS-berichten naar SIP-proxy worden als voorbeeld gegeven:

Parameternaam Voorbeeld van de waarde
Aanvraag-URI OPTIES sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Via koptekst Via: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978
Koptekst max-doorstuurservers Max-forwards:68
Van koptekst Uit koptekst van: sip:sbc1.contoso.com:5061
Naar koptekst Aan: sip:sip.pstnhub.microsoft.com:5061
CSeq-header CSeq: 1 UITNODIGING
Koptekst van contactpersoon Contactpersoon: sip:sbc1.contoso.com:5061; transport=tls

Notitie

De SIP-headers bevatten geen gebruikersinfo in de SIP-URI die wordt gebruikt. Volgens RFC 3261, sectie 19.1.1, is de gebruikersinfo onderdeel van een URI optioneel en kan afwezig zijn wanneer de doelhost geen notie van gebruikers heeft of wanneer de host zelf de resource is die wordt geïdentificeerd. Als het @-teken aanwezig is in een SIP-URI, mag het gebruikersveld niet leeg zijn. Let op: SIPS-URI mag niet worden gebruikt met directe routering, omdat deze niet wordt ondersteund. Controleer de configuratie van de sessierandcontroller en zorg ervoor dat u geen 'Replaces'-headers gebruikt in SIP-aanvragen. Met directe routering worden SIP-aanvragen geweigerd waarvoor headers zijn vervangen.

Bij een binnenkomende oproep moet de SIP-proxy de Azure Communication-resource vinden waarnaar de aanroep is bestemd. In deze sectie wordt beschreven hoe de SIP-proxy de resource vindt en verificatie van de SBC uitvoert op de binnenkomende verbinding.

Het voorbeeld van het SIP-uitnodigingsbericht voor een inkomende oproep:

Parameternaam Voorbeeld van de waarde
Aanvraag-URI INVITE sip:+54321@sip.pstnhub.microsoft.com SIP /2.0
Via koptekst Via: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978
Koptekst max-doorstuurservers Max-forwards:68
Van koptekst Uit koptekst van: <sip:+12345@sbc1.contoso.com; transport=udp; tag=1c68821811
Naar koptekst Aan: sip:+54321@sbc1.contoso.com
CSeq-header CSeq: 1 UITNODIGING
Koptekst van contactpersoon Contactpersoon: sip:+12345@sbc1.contoso.com:5061; transport=tls

Bij ontvangst van de uitnodiging voert de SIP-proxy de volgende stappen uit:

  1. Controleer het certificaat. Bij de eerste verbinding neemt de directe routeringsservice de FQDN-naam die wordt weergegeven in de koptekst Contact en komt deze overeen met de algemene naam of alternatieve naam van het gepresenteerde certificaat. De SBC-naam moet overeenkomen met een van de volgende opties:

    • Optie 1. De volledige FQDN-naam die wordt weergegeven in de koptekst Contactpersoon, moet overeenkomen met de algemene naam/alternatieve naam van het gepresenteerde certificaat.

    • Optie 2. Het domeingedeelte van de FQDN-naam die wordt weergegeven in de koptekst Contactpersoon (bijvoorbeeld contoso.com van de FQDN-naam sbc1.contoso.com) moet overeenkomen met de jokertekenwaarde in Common Name/Subject Alternative Name (bijvoorbeeld *.contoso.com).

  2. Probeer een Microsoft 365-tenant te vinden met behulp van de volledige FQDN-naam die wordt weergegeven in de koptekst Contact.

    Controleer of de FQDN-naam van de koptekst contactpersoon (sbc1.contoso.com) is geregistreerd als DNS-naam in een Microsoft 365- of Office 365-organisatie. Als deze wordt gevonden, wordt de zoekactie van de gebruiker uitgevoerd in de tenant waarop de SBC-FQDN is geregistreerd als domeinnaam. Als dit niet wordt gevonden, is stap 3 van toepassing.

  3. Probeer een Azure Communication-resource te vinden met behulp van de volledige FQDN-naam die wordt weergegeven in de koptekst van de contactpersoon.

    Controleer of de naam van de FQDN van de header Contactpersonen (sbc1.contoso.com) is geregistreerd als een SBC-FQDN in een Azure Communication-resource. Als deze wordt gevonden, wordt de aanroep naar die resource verzonden. Indien niet gevonden, is stap 4 van toepassing.

  4. Stap 4 is alleen van toepassing als stap 2 en 3 is mislukt.

    Verwijder het hostgedeelte uit de FQDN, die wordt weergegeven in de header Contactpersoon (FQDN: sbc1.contoso.com, na het verwijderen van het hostgedeelte: contoso.com) en controleer of deze naam is geregistreerd als EEN DNS-naam in een Microsoft 365- of Office 365-organisatie. Als deze wordt gevonden, wordt de gebruikerszoekactie uitgevoerd in deze tenant. Als deze niet wordt gevonden, mislukt de aanroep.

  5. Stap 5 is alleen van toepassing als stap 2, 3 en 4 zijn mislukt.

    Verwijder het hostgedeelte uit de FQDN, die wordt weergegeven in de FQDN-header (FQDN: sbc1.contoso.com, na het verwijderen van het hostgedeelte: contoso.com) en controleer of deze naam is geregistreerd als een SBC-FQDN in een Azure Communication-resource. Als deze wordt gevonden, wordt de aanroep naar die resource verzonden. Als deze niet wordt gevonden, mislukt de aanroep.

  6. Als aan de resource een Dynamics Omnichannel-implementatie is gekoppeld, voert u het opzoeken van het telefoonnummer uit dat wordt weergegeven in de aanvraag-URI. Koppel het weergegeven telefoonnummer aan een Omnichannel-gebruiker (wachtrij) die u in de vorige stap hebt gevonden.

  7. Stap 7 is alleen van toepassing als stap 6 is mislukt.

    Als er geen Omnichannel-implementatie bestaat voor de communicatieresource of het nummer in de aanvraag-URI komt niet overeen met een geconfigureerd Omnichannel-nummer, stuurt u een oproep naar een Event Grid.

  8. Stap 8 is alleen van toepassing als stap 7 is mislukt.

    Als Event Grid niet is geconfigureerd of er geen regels zijn om de binnenkomende oproep te beheren, wordt de oproep verbroken.

Gedetailleerde vereisten voor contactpersoonheader en aanvraag-URI

Koptekst contactpersoon

Voor alle binnenkomende SIP-berichten (OPTIONS, INVITE) voor de Microsoft SIP-proxy moet de koptekst van de contactpersoon de gekoppelde SBC-FQDN in de hostnaam van de URI als volgt hebben:

Syntaxis: Contactpersoon: <sip:phone of sip address@FQDN van de SBC; transport=tls>

Volgens RFC 3261, sectie 11.1, kan een veld voor de koptekst van een contactpersoon aanwezig zijn in een OPTIONS-bericht. Bij directe routering is de koptekst van de contactpersoon vereist. Als het gaat om OPTIONS-berichten, kan de userinfo worden uitgesloten van de SIP-URI en kan alleen de FQDN worden verzonden in de volgende indeling:

Syntaxis: Contactpersoon: <sip:FQDN van de SBC; transport=tls>

Deze naam (FQDN) moet zich ook in de velden Algemene naam of Alternatieve naam voor onderwerp van het gepresenteerde certificaat hebben. Microsoft ondersteunt het gebruik van jokertekenwaarden van de naam(en) in de velden Algemene naam of Alternatieve naam voor onderwerp van het certificaat. De ondersteuning voor jokertekens wordt beschreven in RFC 2818, sectie 3.1. Specifiek:

"Namen kunnen het jokerteken *bevatten, dat wordt beschouwd als een onderdeel van één domeinnaam of onderdeelfragment. *.a.com komt bijvoorbeeld overeen met foo.a.com, maar niet bar.foo.a.com. f*.com komt overeen met foo.com, maar niet bar.com.".

Als er meer dan één waarde in de koptekst Contactpersoon wordt weergegeven in een SIP-bericht door de SBC, wordt alleen het FQDN-gedeelte van de eerste waarde van de koptekst Contact gebruikt. Als vuistregel voor directe routering is het belangrijk dat FQDN wordt gebruikt om SIP-URI in plaats van IP te vullen. Een binnenkomend UITNODIGINGs- of OPTIONS-bericht naar SIP-proxy met de header Contact, waarbij hostnaam wordt vertegenwoordigd door IP en niet door FQDN, wordt de verbinding geweigerd met 403 Verboden.

Aanvraag-URI

Voor alle binnenkomende oproepen wordt de aanvraag-URI gebruikt om een aanroep te identificeren. Op dit moment moet het telefoonnummer een plusteken (+) bevatten, zoals wordt weergegeven in het volgende voorbeeld.

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

Van koptekst

Voor alle binnenkomende oproepen wordt de van koptekst gebruikt om het telefoonnummer van de beller te vinden.

Het telefoonnummer moet een + bevatten, zoals wordt weergegeven in het volgende voorbeeld.

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

Overwegingen voor contact- en recordrouteheaders

De SIP-proxy moet de FQDN van de volgende hop berekenen voor nieuwe clienttransacties in dialoogvensters (bijvoorbeeld Bye of Opnieuw uitnodigen) en bij het beantwoorden van SIP OPTIONS. U kunt dit doen met behulp van contactpersoon of recordroute. Volgens RFC 3261, sectie 8.1.1.8, is een contactpersoonheader vereist in elke aanvraag die kan resulteren in een nieuw dialoogvenster. De recordroute is alleen vereist als een proxy op het pad van toekomstige aanvragen in een dialoogvenster wil blijven.

Voor het berekenen van de volgende hop gebruikt de SIP-proxy:

  • Prioriteit 1. Recordroute op het hoogste niveau. Als de recordroute op het hoogste niveau de FQDN-naam bevat, wordt de naam van de FQDN gebruikt om de uitgaande in-dialoogvensterverbinding te maken.

  • Prioriteit 2. Koptekst van contactpersoon. Als Record-Route niet bestaat, zoekt de SIP-proxy de waarde van de header Contact op om de uitgaande verbinding te maken. (Aanbevolen configuratie.)

Als zowel contact als recordroute worden gebruikt, moet de SBC-beheerder de waarden identiek houden, wat administratieve overhead veroorzaakt.

FQDN-naam gebruiken in contactpersoon of recordroute

Het gebruik van een IP-adres wordt niet ondersteund in RecordRoute of Contactpersoon. De enige ondersteunde optie is een FQDN, die moet overeenkomen met de algemene naam of alternatieve naam van het onderwerp van het SBC-certificaat (jokertekenwaarden in het certificaat worden ondersteund).

  • Als een IP-adres wordt weergegeven in recordroute of contactpersoon, mislukt de certificaatcontrole en mislukt de aanroep.

  • Als de FQDN niet overeenkomt met de waarde van de algemene of alternatieve naam voor onderwerp in het gepresenteerde certificaat, mislukt de aanroep.

Contextkoppen aanroepen

Oproepcontextheaders zijn momenteel alleen beschikbaar voor de Call Automation SDK. Call Automation SDK ondersteunt header user-to-user en maximaal vijf aangepaste SIP-headers. Deze headers worden ondersteund in de methoden INVITE en REFER.

User-To-User header

SIP User-To-User (UUI) is een industriestandaard voor het doorgeven van contextuele informatie tijdens het instellen van oproepen. De maximale lengte van een UUI-headersleutel is 64 tekens. De maximale lengte van de UUI-headerwaarde is 256 tekens. De waarde van de UUI-header kan bestaan uit alfanumerieke tekens en enkele geselecteerde symbolen, waaronder =, , ;., , !, %, *, , , _, , +, , . ~-

Aangepaste koptekst

Azure Communication Services ondersteunt ook maximaal vijf aangepaste SIP-headers. Aangepaste SIP-headersleutel moet beginnen met een verplicht X-MS-Custom- voorvoegsel. De maximale lengte van een SIP-headersleutel is 64 tekens, inclusief het X-MS-Custom- voorvoegsel. De SIP-headersleutel kan bestaan uit alfanumerieke tekens en enkele geselecteerde symbolen, waaronder ., , !%, *, , _, , +, , ~. - De maximale lengte van de SIP-headerwaarde is 256 tekens. De SIP-headerwaarde kan bestaan uit alfanumerieke tekens en enkele geselecteerde symbolen, waaronder =, , ;., , !, %, , *, _, +, , ~. -

Voor implementatiedetails raadpleegt u Contextuele gegevens doorgeven tussen aanroepen.

Binnenkomende oproep: SIP-dialoogvensterbeschrijving

Hier volgen de details van hoe SIP Proxy binnenkomende aanroepen verwerkt.

Parameternaam Weergegeven als
Mediakandidaten in 183 en 200 berichten afkomstig van Media-processors
Aantal 183 berichten dat SBC kan ontvangen Eén per sessie
Gesprek kan zijn met voorlopig antwoord (183) Ja
Oproep kan zonder voorlopig antwoord (183) Ja

Een Azure Communication Services-identiteit kan tegelijkertijd worden gebruikt in meerdere eindpunten (toepassingen). Bijvoorbeeld web-app, i Telefoon-app en Android-app. Elk eindpunt kan als volgt een HTTP-rest aangeven:

  • Voortgang van aanroepen: geconverteerd door de SIP-proxy naar het SIP-bericht 180. Bij het ontvangen van bericht 180 moet de SBC lokaal bellen genereren.

  • Mediaantwoord: geconverteerd door de SIP-proxy naar bericht 183 met mediakandidaten in Session Description Protocol (SDP). Bij het ontvangen van bericht 183 verwacht de SBC verbinding te maken met de mediakandidaten die in het SDP-bericht zijn ontvangen.

    Notitie

    In sommige gevallen wordt het mediaantwoord mogelijk niet gegenereerd en kan het eindpunt worden beantwoord met het bericht Oproep geaccepteerd.

  • Oproep geaccepteerd– geconverteerd door de SIP-proxy naar SIP-bericht 200 met SDP. Bij het ontvangen van bericht 200 wordt verwacht dat de SBC media verzendt en ontvangt van en naar de opgegeven SDP-kandidaten.

    Notitie

    Directe routering biedt geen ondersteuning voor uitnodiging voor vertraagde aanbiedingen (uitnodigen zonder SDP).

Meerdere eindpunten die worden gebeld met een voorlopig antwoord

  1. Bij ontvangst van de eerste uitnodiging van de SBC verzendt de SIP-proxy het bericht SIP/2.0 100 Uitproberen en ontvangt alle eindpunten van eindgebruikers over de binnenkomende oproep.

  2. Na de melding begint elk eindpunt met het overgaan en verzenden van berichten over de voortgang van oproepen naar de SIP-proxy. Omdat de Azure Communication Services-identiteit wordt gebruikt door meerdere eindpunten, ontvangt de SIP-proxy mogelijk meerdere berichten over de voortgang van gesprekken.

  3. Voor elk bericht over de voortgang van oproepen dat van de eindpunten is ontvangen, converteert de SIP-proxy het bericht Voortgang van oproep naar het SIP-bericht SIP/2.0 180. Het interval voor het verzenden van dergelijke berichten komt overeen met het interval van de ontvangende berichten van de oproepcontroller. In het volgende diagram zijn er twee 180 berichten gegenereerd door de SIP-proxy. Deze berichten zijn afkomstig van de twee SDK-eindpunten. De eindpunten hebben elk een unieke tag-id. Elk bericht dat afkomstig is van een ander eindpunt, is een afzonderlijke sessie (de parameter tag in het veld Aan is anders). Maar een eindpunt genereert mogelijk geen bericht 180 en verzendt direct bericht 183, zoals wordt weergegeven in het volgende diagram.

  4. Zodra een eindpunt een Media Answer-bericht genereert met de IP-adressen van de mediakandidaten van het eindpunt, converteert de SIP-proxy het bericht dat is ontvangen naar een sip 183-sessievoortgangsbericht door de SDP van het eindpunt vervangen door de SDP van de mediaprocessor. In het volgende diagram heeft het eindpunt van Fork 2 de oproep beantwoord. Het SIP-bericht van 183 wordt slechts één keer gegenereerd. De 183 kan op een bestaande fork komen of een nieuwe starten.

  5. Er wordt een oproepacceptatiebericht verzonden naar de SIP-proxy met de uiteindelijke kandidaten van het eindpunt dat de oproep heeft geaccepteerd. Het oproepacceptatiebericht wordt geconverteerd naar SIP-bericht 200.

    Diagram met meerdere eindpunten die overgaan met een voorlopig antwoord.

Meerdere eindpunten worden gebeld zonder voorlopig antwoord

  1. Bij ontvangst van de eerste uitnodiging van de SBC verzendt de SIP-proxy het bericht SIP/2.0 100 Uitproberen en ontvangt alle eindpunten van eindgebruikers over de binnenkomende oproep.

  2. Na de melding wordt elk eindpunt gebeld en wordt het bericht 'Voortgang aanroepen' verzonden naar de SIP-proxy. Omdat dezelfde Azure Communication Services-identiteit kan worden gebruikt in meerdere toepassingen, kan de SIP-proxy meerdere berichten over de voortgang van oproepen ontvangen.

  3. Voor elk bericht over de voortgang van oproepen dat van de eindpunten is ontvangen, converteert de SIP-proxy het bericht Voortgang van oproep naar het SIP-bericht SIP/2.0 180. Het interval voor het verzenden van de berichten komt overeen met het interval van het ontvangen van de berichten van de oproepcontroller. Op de afbeelding zijn er twee 180 berichten gegenereerd door de SIP-proxy, wat betekent dat de aanroep wordt gesplitst naar twee verschillende clients en elke client de voortgang van de oproep verzendt. Elk bericht is een afzonderlijke sessie (parameter 'tag' in het veld Aan is anders)

  4. Er wordt een oproepacceptatiebericht verzonden naar de SIP-proxy met de uiteindelijke kandidaten van het eindpunt dat de oproep heeft geaccepteerd. Het oproepacceptatiebericht wordt geconverteerd naar SIP-bericht 200.

    Diagram met meerdere eindpunten die zonder voorlopig antwoord overgaan.

Optie Vervangen

De SBC moet UITNODIGEN ondersteunen met Replaces.

Grootte van SDP-overwegingen

De directe routeringsinterface kan een SIP-bericht verzenden dat groter is dan 1500 bytes. De grootte van SDP veroorzaakt voornamelijk dergelijk gedrag. Als er echter een UDP-trunk achter de SBC staat, kan het bericht worden geweigerd als het wordt doorgestuurd van de Microsoft SIP-proxy naar de niet-gewijzigde trunk. Microsoft raadt aan om bepaalde waarden in SDP op de SBC te verwijderen wanneer het bericht naar de UDP-trunks wordt verzonden. De ICE-kandidaten of ongebruikte codecs kunnen bijvoorbeeld worden verwijderd.

Oproepoverdracht

Directe routering ondersteunt twee methoden voor oproepoverdracht:

  • Optie 1. SIP-proxyprocessen Verwijzen van de client lokaal en fungeren als referee zoals beschreven in sectie 7.1 van RFC 3892.

    Met deze optie beëindigt de SIP-proxy de overdracht en voegt een nieuwe uitnodiging toe.

  • Optie 2. SIP-proxy verzendt de verwijzing naar de SBC en fungeert als een transferor als beschrijving in sectie 6 van RFC 5589.

    Met deze optie verzendt de SIP-proxy een verwijzing naar de SBC en verwacht dat de SBC de overdracht volledig verwerkt.

De SIP-proxy selecteert de methode op basis van de mogelijkheden die door de SBC zijn gerapporteerd. Als de SBC aangeeft dat deze de methode Refer ondersteunt, gebruikt de SIP-proxy optie 2 voor oproepoverdrachten. Het voorbeeld van een SBC die het bericht verzendt dat de verwijzingsmethode wordt ondersteund:

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

Als de SBC niet aangeeft dat verwijzen als een ondersteunde methode, gebruikt directe routering optie 1 (SIP-proxy fungeert als een referee). De SBC moet ook signaleren dat de methode Notify wordt ondersteund: Voorbeeld van SBC dat aangeeft dat refer-methode niet wordt ondersteund:

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

SIP-proxyprocessen Verwijzen van de client lokaal en fungeert als een referee

Als de SBC aangeeft dat de refer-methode niet wordt ondersteund, fungeert de SIP-proxy als referee. De refer-aanvraag die afkomstig is van de client, wordt beëindigd op de SIP-proxy. De verwijzingsaanvraag van de client wordt weergegeven als 'Oproepoverdracht naar Dave' in het volgende diagram. Zie sectie 7.1 van RFC 3892 voor meer informatie.

Diagram van oproepoverdracht met SIP Proxy die fungeert als een scheidsrechter.

SIP-proxy verzendt de verwijzing naar de SBC en fungeert als een overdrachtsor

SIP Proxy als transferor is de voorkeursmethode voor oproepoverdrachten.

De standaard wordt uitgelegd in sectie 6 van RFC 5589. De gerelateerde RFC's zijn:

Bij deze optie wordt ervan uitgegaan dat de SIP-proxy fungeert als een overdrachtsoptie en een verwijzingsbericht naar de SBC verzendt. De SBC fungeert als een overdrachtsverantwoordelijke en verwerkt de verwijzing om een nieuwe aanbieding voor overdracht te genereren. Er zijn twee mogelijke gevallen:

  • De oproep wordt doorgeschakeld naar een externe PSTN-deelnemer.
  • De aanroep wordt overgebracht van het ene SDK-eindpunt naar een ander SDK-eindpunt in dezelfde resource via de SBC.

Als de aanroep wordt overgedragen van het ene SDK-eindpunt naar een ander SDK-eindpunt via de SBC, krijgt de SBC naar verwachting een nieuwe uitnodiging (start een nieuw dialoogvenster) voor het overdrachtsdoel met behulp van de informatie die is ontvangen in het refer-bericht. Als u de velden To/Transferor voor de transactie van de aanvraag intern wilt vullen, moet de SIP-proxy deze informatie overbrengen in de HEADERs REFER-TO/REFERRED-BY. De SIP-proxy vormt de REFER-TO als een SIP-URI die bestaat uit een SIP-proxy-FQDN in de hostnaam en beide:

  • Een E.164-telefoonnummer in het gebruikersnaamgedeelte van de URI voor het geval het overdrachtsdoel een telefoonnummer is, of

  • x-m- en x-t-parameters die respectievelijk de volledige overdrachtsdoel-MRI en communicatieresource-id coderen.

De HEADER REFERRED-BY heeft een SIP-URI met transferor MRI gecodeerd en de resource-id van de transferor en andere contextparameters voor overdracht, zoals wordt weergegeven in de volgende tabel:

Parameter Weergegeven als Beschrijving
x-m MRI Volledige MRI van transferor/overdrachtsdoel zoals ingevuld door CC
x-t Tenant-id x-t-resource-id Optionele resource-id zoals ingevuld door CC
x-ti Correlatie-id van transferor Correlatie-id van de aanroep naar de overboeker
x-tt Doeloproep-URI overdragen Versleutelde aanroepvervangings-URI

In dit geval kan de grootte van de verwijzingskop maximaal 400 symbolen zijn. De SBC moet ondersteuning bieden voor het verwerken van refer-berichten met een grootte van maximaal 400 symbolen.

Diagram van oproepoverdracht met SIP Proxy die fungeert als een overboeking.

Doorschakelen

Een Azure Communication Services Call Automation SDK kan binnenkomende oproepen omleiden naar een ander nummer of SDK/Teams-eindpunt, andere gebruikers of gebruikers parallel bellen (tegelijk bellen) of een groep gebruikers of nummers bellen. Aandachtspunten:

  • Request-URI in invite request from SIP proxy to User C contains the cause parameter.

  • De header Geschiedenis-info wordt ingevuld.

  • Wanneer gebruiker A een andere PSTN-gebruiker is, genereert SIP proxy de voorlopige reactie 'SIP/2.0 181-oproep wordt doorgestuurd' naar gebruiker A.

  • Als Gebruiker A en Gebruiker C PSTN-gebruikers zijn, blijft de SIP SIP/2.0 181-oproep voorlopig antwoord doorgestuurd.

  • De header Geschiedenis-info moet worden gebruikt voor luspreventie.

Sessietimer

De SIP-proxy ondersteunt (altijd) de sessietimer. Het gebruik van de sessietimer door de SBC is niet verplicht.

Gebruik van request-URI-parameter user=phone

De SIP-proxy analyseert de request-URI en als de parameter user=phone aanwezig is, verwerkt de service de Request-URI als een telefoonnummer, dat overeenkomt met het nummer van een gebruiker. Als de parameter niet aanwezig is, past de SIP-proxy heuristieken toe om het gebruikerstype Request-URI (telefoonnummer of een SIP-adres) te bepalen.

Microsoft raadt aan altijd de parameter user=phone toe te passen om het installatieproces voor gesprekken te vereenvoudigen.

Koptekst Geschiedenis-info

Notitie

In de header Geschiedenis-info voor directe routering van Azure Communication Services is standaard ingeschakeld en kan deze niet worden uitgeschakeld.

De header History-Info wordt gebruikt voor het opnieuw instellen van SIP-aanvragen en 'bieden(en) een standaardmechanisme voor het vastleggen van de informatie over de aanvraaggeschiedenis om een groot aantal services voor netwerken en eindgebruikers mogelijk te maken. Zie RFC 4244 – Sectie 1.1 voor meer informatie. Voor directe routering wordt deze header gebruikt in scenario's voor gelijktijdig bellen en doorschakelen.

Geschiedenisgegevens zijn als volgt ingeschakeld:

  • De SIP-proxy voegt een parameter in die het bijbehorende telefoonnummer bevat in afzonderlijke vermeldingen geschiedenis-info die de header History-Info bevatten die naar de PSTN-controller wordt verzonden. Als u alleen vermeldingen gebruikt die de parameter telefoonnummer hebben, wordt met de PSTN-controller een nieuwe header History-Info opnieuw opgebouwd en doorgegeven aan de SIP-trunkprovider via de SIP-proxy.

  • History-Info header wordt toegevoegd voor gelijktijdig bellen en doorschakelen van gesprekken.

  • De header Geschiedenis-info wordt niet toegevoegd voor oproepoverdrachtscases.

  • Een afzonderlijke geschiedenisvermelding in de gereconstrueerde header History-Info heeft de parameter voor telefoonnummers in combinatie met de FQDN voor directe routering (sip.pstnhub.microsoft.com) ingesteld als het hostgedeelte van de URI. Een parameter van user=phone toegevoegd als onderdeel van de SIP-URI. Alle andere parameters die zijn gekoppeld aan de oorspronkelijke header History-Info, met uitzondering van de parameters van de telefooncontext, die zijn doorgegeven in de gereconstrueerde header History-Info.

    Notitie

    Vermeldingen die privé zijn (zoals bepaald door de mechanismen die zijn gedefinieerd in sectie 3.3 van RFC 4244) die als zodanig zijn doorgestuurd omdat de SIP trunk-provider een vertrouwde peer is.

  • Inkomende geschiedenisgegevens blijven behouden voor luspreventie.

Hieronder volgt de indeling van de header History-info die door de SIP-proxy wordt verzonden:

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

Als de aanroep meerdere keren is omgeleid, wordt informatie over elke omleiding opgenomen in de juiste reden in chronologische volgorde, in een door komma's gescheiden lijst.

Koptekstvoorbeeld:

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

De SIP-URI in de header History-Info is opgemaakt volgens sectie 25 van RFC 3261 (zie de definitie van addr-spec). In het vorige voorbeeld is SIP;cause=496;text="User Busy"de oorspronkelijke tekst van de URI-headerReason, waarmee ;de bijbehorende tekens "zijn opgehaald, en = tekens zijn ontsnapt aan respectievelijk de ASCII-hexwaarden%3B, %22en 3D, respectievelijk.

De geschiedenisgegevens worden beveiligd door een verplicht TLS-mechanisme.

SBC-verbinding met directe routering en failovermechanisme

Zie de sectie Failover-mechanisme voor SIP-signalering in vereisten voor directe routeringsinfrastructuur.

Opnieuw proberen na

Als een datacenter voor directe routering bezet is, kan de service een bericht opnieuw proberen verzenden met een interval van één seconde naar de SBC. Wanneer de SBC een 503-bericht ontvangt met een header Opnieuw proberen na in reactie op een UITNODIGING, moet de SBC die verbinding beëindigen en het volgende beschikbare Microsoft-datacenter proberen.

Nieuwe pogingen verwerken (603-antwoord)

Als een eindgebruiker meerdere gemiste aanroepen voor één oproep ziet nadat de binnenkomende oproep is afgenomen, betekent dit dat het mechanisme voor opnieuw proberen van de SBC- of PSTN-trunkprovider onjuist is geconfigureerd. De SBC moet opnieuw worden geconfigureerd om de pogingen voor het 603-antwoord te stoppen.