Direktdirigering av Azure Communication Services: SIP-protokollinformation
Den här artikeln beskriver hur direktdirigering implementerar SIP (Session Initiation Protocol) för att säkerställa rätt trafikvägar mellan en sessionsgränskontrollant (SBC) och SIP-proxyn. Det belyser också vikten av vissa SIP-parametrar som kräver specifika värden. Den här artikeln är avsedd för röstadministratörer som ansvarar för att konfigurera anslutningen mellan SBC och SIP-proxytjänsten.
Bearbeta den inkommande begäran: hitta Communication Services-resursen
Kommentar
I Azure Communication Services är SIP-alternativ för direktdirigering aktiverade som standard och kan inte inaktiveras. SBC måste initiera OPTIONS-utbytet först, eftersom SIP Proxy väntar på att SBC ska starta utbytet.
Innan ett inkommande eller utgående samtal kan bearbetas utbyts OPTIONS-meddelanden mellan SIP Proxy och SBC. Med dessa ALTERNATIV-meddelanden kan SIP Proxy tillhandahålla de tillåtna funktionerna för SBC. Det är viktigt att OPTIONS-förhandlingen lyckas (200 OK-svar), vilket möjliggör ytterligare kommunikation mellan SBC och SIP Proxy för att upprätta anrop. SIP-huvudena i ett ALTERNATIV-meddelanden till SIP Proxy tillhandahålls som ett exempel:
| Parameternamn | Exempel på värdet |
|---|---|
| Request-URI | ALTERNATIV sip:sip.pstnhub.microsoft.com:5061 SIP /2.0 |
| Via sidhuvud | Via: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978 |
| Max-Forwards-huvud | Max-Forwards:68 |
| Från sidhuvud | Från sidhuvud från: sip:sbc1.contoso.com:5061 |
| Till rubrik | Till: sip:sip.pstnhub.microsoft.com:5061 |
| CSeq-huvud | CSeq: 1 BJUD IN |
| Kontaktrubrik | Kontakt: sip:sbc1.contoso.com:5061; transport=tls |
Kommentar
SIP-huvudena innehåller inte userinfo i SIP-URI:n som används. Enligt RFC 3261, avsnitt 19.1.1, är userinfo-delen av en URI valfri och kan vara frånvarande när målvärden inte har någon uppfattning om användare eller när själva värden är den resurs som identifieras. Om @-tecknet finns i en SIP-URI får användarfältet inte vara tomt. Observera att SIPS-URI:n inte ska användas med direkt routning eftersom den inte stöds. Kontrollera konfigurationen av sessionsgränskontrollanten och se till att du inte använder "Ersätter" huvuden i SIP-begäranden. Direktdirigering avvisar SIP-begäranden som har ersatta rubriker definierade.
Vid ett inkommande anrop måste SIP-proxyn hitta den Azure Communication-resurs som anropet är avsett för. Det här avsnittet beskriver hur SIP-proxyn hittar resursen och utför autentisering av SBC på den inkommande anslutningen.
Exemplet på SIP-inbjudan i ett inkommande samtal:
| Parameternamn | Exempel på värdet |
|---|---|
| Request-URI | BJUD IN SIP:+54321@sip.pstnhub.microsoft.com SIP /2.0 |
| Via sidhuvud | Via: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978 |
| Max-Forwards-huvud | Max-Forwards:68 |
| Från sidhuvud | Från sidhuvud från: <sip:+12345@sbc1.contoso.com; transport=udp; tag=1c68821811 |
| Till rubrik | Till: sip:+54321@sbc1.contoso.com |
| CSeq-huvud | CSeq: 1 BJUD IN |
| Kontaktrubrik | Kontakt: sip:+12345@sbc1.contoso.com:5061; transport=tls |
När du tar emot inbjudan utför SIP-proxyn följande steg:
Kontrollera certifikatet. Vid den första anslutningen tar direktdirigeringstjänsten det FQDN-namn som visas i kontakthuvudet och matchar det med det gemensamma namnet eller alternativt ämnesnamn för det presenterade certifikatet. SBC-namnet måste matcha något av följande alternativ:
Alternativ 1. Det fullständiga FQDN-namnet som visas i kontakthuvudet måste matcha det alternativa namnet för det presenterade certifikatet.
Alternativ 2. Domändelen av det FQDN-namn som visas i kontakthuvudet (till exempel contoso.com av FQDN-namnet sbc1.contoso.com) måste matcha jokertecknets värde i Alternativt namn/Ämne (till exempel *.contoso.com).
Försök att hitta en Microsoft 365-klientorganisation med det fullständiga FQDN-namnet som visas i rubriken Kontakt.
Kontrollera om FQDN-namnet från kontakthuvudet (sbc1.contoso.com) har registrerats som ett DNS-namn i någon Microsoft 365- eller Office 365-organisation. Om det hittas utförs sökningen av användaren i klientorganisationen som har SBC FQDN registrerat som ett domännamn. Om det inte hittas gäller steg 3.
Försök hitta en Azure Communication-resurs med det fullständiga FQDN-namnet som visas i kontakthuvudet.
Kontrollera om FQDN-namnet från kontakthuvudet (sbc1.contoso.com) har registrerats som ett SBC FQDN i någon Azure Communication-resurs. Om det hittas skickas anropet till resursen. Om det inte hittas gäller steg 4.
Steg 4 gäller endast om steg 2 och 3 misslyckades.
Ta bort värddelen från det fullständiga domännamnet, som visas i kontakthuvudet (FQDN: sbc1.contoso.com, efter att ha tagit bort värddelen: contoso.com) och kontrollera om det här namnet är registrerat som ett DNS-namn i någon Microsoft 365- eller Office 365-organisation. Om det hittas utförs användarsökningen i den här klientorganisationen. Om det inte hittas misslyckas anropet.
Steg 5 gäller endast om steg 2, 3 och 4 misslyckades.
Ta bort värddelen från det fullständiga domännamnet, som visas i kontakthuvudet (FQDN: sbc1.contoso.com, efter att ha tagit bort värddelen: contoso.com) och kontrollera om det här namnet är registrerat som ett SBC FQDN i någon Azure Communication-resurs. Om det hittas skickas anropet till resursen. Om det inte hittas misslyckas anropet.
Om resursen har en associerad Dynamics Omnichannel-distribution utför du sökningen av det telefonnummer som visas i Request-URI. Matcha det presenterade telefonnumret med en Omnichannel-användare (kö) som hittades i föregående steg.
Steg 7 gäller endast om steg 6 misslyckades.
Om det inte finns någon Omnichannel-distribution för kommunikationsresursen, eller om numret i Request-URI inte matchar något konfigurerat Omnichannel-nummer, skickar du anropet till ett Event Grid.
Steg 8 gäller endast om steg 7 misslyckades.
Om Event Grid inte har konfigurerats, eller om det inte finns några regler för att hantera det inkommande samtalet, avbryts samtalet.
Detaljerade krav för Kontakthuvud och Request-URI
Kontaktrubrik
För alla inkommande SIP-meddelanden (ALTERNATIV, BJUD IN) till Microsoft SIP-proxyn måste kontakthuvudet ha det kopplade SBC FQDN i URI-värdnamnet enligt följande:
Syntax: Kontakt: <sip:phone eller sip address@FQDN för SBC; transport=tls>
Enligt RFC 3261, avsnitt 11.1, kan ett kontakthuvudfält finnas i ett ALTERNATIV-meddelande. I direktdirigering krävs kontakthuvudet. När det gäller OPTIONS-meddelanden kan userinfo undantas från SIP-URI:n och endast FQDN kan skickas i följande format:
Syntax: Kontakt: <sip:FQDN för SBC; transport=tls>
Det här namnet (FQDN) måste också finnas i fälten Eget namn eller Alternativt ämnesnamn för det presenterade certifikatet. Microsoft stöder användning av jokerteckenvärden för namn i fälten Eget namn eller Alternativt ämnesnamn i certifikatet. Stöd för jokertecken beskrivs i RFC 2818, avsnitt 3.1. Specifikt:
"Namn kan innehålla jokertecknet *, som anses matcha en enskild domännamnskomponent eller komponentfragment. *.a.com matchar till exempel foo.a.com men inte bar.foo.a.com. f*.com matchar foo.com men inte bar.com."
Om mer än ett värde i kontakthuvudet som visas i ett SIP-meddelande av SBC används endast FQDN-delen av det första värdet i kontakthuvudet. Som tumregel för direkt routning är det viktigt att FQDN används för att fylla i SIP-URI i stället för IP. Ett inkommande INVITE- eller OPTIONS-meddelande till SIP-proxyn med kontakthuvudet där värdnamnet representeras av IP och inte FQDN, anslutningen nekas med 403 Förbjudet.
Request-URI
För alla inkommande samtal används request-URI för att identifiera en anropare. För närvarande måste telefonnumret innehålla ett plustecken (+) som visas i följande exempel.
INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0
Från sidhuvud
För alla inkommande samtal används Från-huvudet för att matcha uppringarens telefonnummer.
Telefonnumret måste innehålla + enligt följande exempel.
From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811
Överväganden för kontakt- och postroutningsrubriker
SIP-proxyn måste beräkna nästa hopp-FQDN för nya klienttransaktioner i dialogrutan (till exempel Bye eller Re-Invite) och när du svarar på SIP-ALTERNATIV. Detta kan göras med antingen Kontakt eller Postväg. Enligt RFC 3261, avsnitt 8.1.1.8, krävs en kontaktrubrik i alla begäranden som kan resultera i en ny dialogruta. Record-Route krävs bara om en proxy vill fortsätta att följa sökvägen för framtida begäranden i en dialogruta.
För att beräkna nästa hopp använder SIP-proxyn:
Prioritet 1. Postväg på högsta nivå. Om den översta postvägen innehåller FQDN-namnet används FQDN-namnet för att göra den utgående anslutningen i dialogrutan.
Prioritet 2. Kontaktrubrik. Om Record-Route inte finns letar SIP-proxyn upp värdet för kontakthuvudet för att upprätta den utgående anslutningen. (Rekommenderad konfiguration.)
Om både Kontakt och Postväg används måste SBC-administratören hålla sina värden identiska, vilket orsakar administrativa omkostnader.
Användning av FQDN-namn i Kontakt eller Postväg
Användning av en IP-adress stöds inte i varken Record-Route eller Contact. Det enda alternativ som stöds är ett FQDN, som måste matcha SBC-certifikatets gemensamma namn eller alternativa namn (jokerteckenvärden i certifikatet stöds).
Om en IP-adress visas i Record-route eller Contact misslyckas certifikatkontrollen och anropet misslyckas.
Om FQDN inte matchar värdet för det alternativa namnet common eller subject i det presenterade certifikatet misslyckas anropet.
Anropa kontextrubriker
Samtalskontextrubriker är för närvarande endast tillgängliga för Call Automation SDK. Anropa Automation SDK har stöd för användar-till-användare-huvudet och upp till fem anpassade SIP-huvuden. Dessa rubriker stöds i metoderna INVITE och REFER.
Användar-till-användare-huvud
SIP-huvud för användare-till-användare (UUI) är en branschstandard för att skicka sammanhangsbaserad information under en samtalskonfigurationsprocess. Den maximala längden på en UUI-huvudnyckel är 64 tecken. Den maximala längden på UUI-huvudvärdet är 256 tecken. UUI-huvudvärdet kan bestå av alfanumeriska tecken och några valda symboler, inklusive =, ;, ., !, %, *, _, +, , ~, -.
Anpassat sidhuvud
Azure Communication Services stöder också upp till fem anpassade SIP-huvuden. Anpassad SIP-huvudnyckel måste börja med ett obligatoriskt X-MS-Custom- prefix. Den maximala längden på en SIP-huvudnyckel är 64 tecken, inklusive prefixet X-MS-Custom- . SIP-huvudnyckeln kan bestå av alfanumeriska tecken och några markerade symboler, inklusive ., !, %, *, _, +, ~, -. Den maximala längden på SIP-huvudvärdet är 256 tecken. SIP-huvudvärdet kan bestå av alfanumeriska tecken och några markerade symboler, inklusive =, ;, ., !, %, *, _, +, ~, . -
Information om implementering finns i Så här skickar du kontextuella data mellan anrop.
Inkommande anrop: BESKRIVNING av SIP-dialogrutan
Här följer information om hur SIP Proxy bearbetar inkommande anrop.
| Parameternamn | Värde |
|---|---|
| Mediekandidater i 183 och 200 meddelanden från | Mediebearbetare |
| Antal 183 meddelanden som SBC kan ta emot | En per session |
| Samtalet kan vara med preliminärt svar (183) | Ja |
| Samtalet kan vara utan preliminärt svar (183) | Ja |
En Azure Communication Services-identitet kan användas i flera slutpunkter (program) samtidigt. Till exempel webbapp, i Telefon-app och Android-app. Varje slutpunkt kan signalera en HTTP-vila på följande sätt:
Samtalsstatus – konverteras av SIP-proxyn till SIP-meddelandet 180. När du tar emot meddelande 180 måste SBC generera lokala ringningar.
Mediasvar – konverteras av SIP-proxyn till meddelande 183 med mediekandidater i Session Description Protocol (SDP). Vid mottagandet av meddelande 183 förväntar sig SBC att ansluta till de mediekandidater som tas emot i SDP-meddelandet.
Kommentar
I vissa fall kanske mediasvaret inte genereras och slutpunkten kan svara med meddelandet "Samtal accepteras".
Samtalet accepterades – konverterat av SIP-proxyn till SIP-meddelande 200 med SDP. Vid mottagandet av meddelande 200 förväntas SBC skicka och ta emot media till och från de angivna SDP-kandidaterna.
Kommentar
Direktdirigering stöder inte inbjudning av fördröjt erbjudande (bjud in utan SDP).
Flera slutpunkter som ringer med preliminärt svar
När du tar emot den första inbjudan från SBC skickar SIP-proxyn meddelandet "SIP SIP/2.0 100 Trying" och meddelar alla slutanvändarslutpunkter om det inkommande samtalet.
Vid aviseringen börjar varje slutpunkt ringa och skicka "Samtalsstatus"-meddelanden till SIP-proxyn. Eftersom Azure Communication Services-identiteten används av flera slutpunkter kan SIP-proxyn ta emot flera samtalsstatusmeddelanden.
För varje samtalsstatusmeddelande som tas emot från slutpunkterna konverterar SIP-proxyn meddelandet Samtalsstatus till SIP-meddelandet "SIP SIP/2.0 180 Ringning". Intervallet för att skicka sådana meddelanden korrelerar med intervallet för de mottagande meddelandena från samtalsstyrenheten. I följande diagram finns det två 180 meddelanden som genereras av SIP-proxyn. Dessa meddelanden kommer från de två SDK-slutpunkterna. Slutpunkterna har var och en ett unikt tagg-ID. Varje meddelande som kommer från en annan slutpunkt är en separat session (parametern "tag" i fältet "Till" är annorlunda). Men en slutpunkt kanske inte genererar meddelande 180 och skickar meddelande 183 direkt enligt följande diagram.
När en slutpunkt genererar ett Media Answer-meddelande med IP-adresserna för slutpunktens mediekandidater konverterar SIP-proxyn det mottagna meddelandet till ett "SIP 183 Sessionsförlopp" med SDP från slutpunkten ersatt av SDP:n från medieprocessorn. I följande diagram svarade slutpunkten från Fork 2 på samtalet. 183 SIP-meddelandet genereras bara en gång. 183 kan komma på en befintlig förgrening eller starta en ny.
Ett meddelande om godkännande av samtal skickas till SIP-proxyn med slutkandidaterna för slutpunkten som accepterade anropet. Meddelandet För godkännande av samtal konverteras till SIP-meddelande 200.
Flera slutpunkter ringer utan preliminärt svar
När du tar emot den första inbjudan från SBC skickar SIP-proxyn meddelandet "SIP SIP/2.0 100 Trying" och meddelar alla slutanvändarslutpunkter om det inkommande samtalet.
Vid meddelandet börjar varje slutpunkt ringa och skicka meddelandet "Samtalsframsteg" till SIP-proxyn. Eftersom samma Azure Communication Services-identitet kan användas i flera program kan SIP-proxyn ta emot flera samtalsstatusmeddelanden.
För varje samtalsstatusmeddelande som tas emot från slutpunkterna konverterar SIP-proxyn meddelandet Samtalsstatus till SIP-meddelandet "SIP SIP/2.0 180 Ringning". Intervallet för att skicka meddelanden korrelerar med intervallet för att ta emot meddelanden från samtalsstyrenheten. På bilden finns det två 180 meddelanden som genereras av SIP-proxyn, vilket innebär att anropet förgrenas till två olika klienter och varje klient skickar anropets förlopp. Varje meddelande är en separat session (parametern "tag" i fältet "Till" skiljer sig)
Ett meddelande om godkännande av samtal skickas till SIP-proxyn med slutkandidaterna för slutpunkten som accepterade anropet. Meddelandet För godkännande av samtal konverteras till SIP-meddelande 200.
Ersätter alternativet
SBC måste ha stöd för INVITE med Replaces.
Storlek på SDP-överväganden
Direktdirigeringsgränssnittet kan skicka ett SIP-meddelande som överstiger 1 500 byte. Storleken på SDP orsakar främst sådant beteende. Men om det finns en UDP-stam bakom SBC kan det avvisa meddelandet om det vidarebefordras från Microsoft SIP-proxyn till trunken oförändrad. Microsoft rekommenderar att du tar bort vissa värden i SDP på SBC när du skickar meddelandet till UDP-stammarna. Till exempel kan ICE-kandidater eller oanvända codecs tas bort.
Samtalsöverföring
Direktdirigering stöder två metoder för anropsöverföring:
Alternativ 1. SIP-proxyprocesser Referera från klienten lokalt och fungerar som domare enligt beskrivningen i avsnitt 7.1 i RFC 3892.
Med det här alternativet avslutar SIP-proxyn överföringen och lägger till en ny inbjudan.
Alternativ 2. SIP-proxyn skickar referensen till SBC och fungerar som en överförare enligt beskrivningen i avsnitt 6 i RFC 5589.
Med det här alternativet skickar SIP-proxyn en Referens till SBC och förväntar sig att SBC hanterar överföringen helt.
SIP-proxyn väljer metoden baserat på de funktioner som rapporteras av SBC. Om SBC anger att den stöder metoden "Refer" använder SIP-proxyn alternativ 2 för samtalsöverföringar. Exemplet på en SBC som skickar meddelandet att metoden Referens stöds:
ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Om SBC inte anger att Referera som en metod som stöds använder direktdirigering alternativ 1 (SIP-proxy fungerar som domare). SBC måste också signalera att den stöder metoden Notify: Exempel på SBC som anger att Referensmetoden inte stöds:
ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS
SIP-proxyprocesser Referera från klienten lokalt och fungerar som domare
Om SBC anger att metoden Refer inte stöds fungerar SIP-proxyn som domare. Referensbegäran som kommer från klienten avslutas på SIP-proxyn. Referensbegäran från klienten visas som "Samtalsöverföring till Dave" i följande diagram. Mer information finns i avsnitt 7.1 i RFC 3892.
SIP-proxyn skickar referensen till SBC och fungerar som en överförare
SIP Proxy som transferor är den föredragna metoden för anropsöverföringar.
Standarden förklaras i avsnitt 6 i RFC 5589. De relaterade RFC:erna är:
Det här alternativet förutsätter att SIP-proxyn fungerar som en överförare och skickar ett referensmeddelande till SBC. SBC fungerar som en överföringsmottagare och hanterar referensen för att generera ett nytt erbjudande för överföring. Det finns två möjliga fall:
- Samtalet överförs till en extern PSTN-deltagare.
- Anropet överförs från en SDK-slutpunkt till en annan SDK-slutpunkt i samma resurs via SBC.
Om anropet överförs från en SDK-slutpunkt till en annan SDK-slutpunkt via SBC förväntas SBC utfärda en ny inbjudan (starta en ny dialogruta) för överföringsmålet med hjälp av informationen som tas emot i referensmeddelandet. För att fylla i fälten Till/Överförare för transaktionen av begäran internt måste SIP-proxyn förmedla den här informationen i REFER-TO/REFERRED-BY-huvudena. SIP-proxyn utgör REFER-TO som en SIP-URI som består av ett SIP-proxy-FQDN i värdnamnet och antingen:
Ett E.164-telefonnummer i användarnamnsdelen av URI:n om överföringsmålet är ett telefonnummer, eller
x-m- och x-t-parametrar som kodar det fullständiga överföringsmålets MRI- respektive kommunikationsresurs-ID.
REFERRED-BY-huvudet har en SIP-URI med överförings-MRI kodad i den och överföringsresurs-ID och andra parametrar för överföringskontext som visas i följande tabell:
| Parameter | Värde | beskrivning |
|---|---|---|
| x-m | MRI | Fullständig MRI för transferor/överföringsmål ifyllt av CC |
| x-t | Klientorganisations-ID | x-t-resurs-ID Valfritt resurs-ID ifyllt av CC |
| x-ti | Överföringskorrelations-ID | Korrelations-ID för anropet till överföraren |
| x-tt | Överföra målanrops-URI | Kodad samtalsersättnings-URI |
Storleken på referensrubriken kan vara upp till 400 symboler i det här fallet. SBC måste ha stöd för hantering Av referentmeddelanden med en storlek på upp till 400 symboler.
Vidarekoppling av samtal
En Azure Communication Services Call Automation SDK kan omdirigera inkommande samtal till ett annat nummer eller SDK/Teams-slutpunkt, ringa andra användare eller användare parallellt (samtidig ring) eller ringa en grupp användare eller nummer. Saker att tänka på:
Request-URI i INVITE-begäran från SIP-proxyn till Användare C innehåller orsaksparametern.
Rubriken Historik-Info fylls i.
När användare A är en annan PSTN-användare genererar SIP-proxyn det provisoriska svaret "SIP SIP/2.0 181 Call is being forwarded" (SIP SIP/2.0 181-samtal vidarebefordras) till användare A.
Om användare A och användare C är PSTN-användare bevarar SIP-proxyn det preliminära svaret "SIP SIP/2.0 181 Call is being forwarded" (SIP SIP/2.0 181-samtal vidarebefordras).
Historik-Info-huvudet ska användas för loopskydd.
Sessionstimer
SIP-proxyn stöder (erbjuder alltid) sessionstimern. Användning av sessionstimern av SBC är inte obligatorisk.
Användning av Request-URI-parametern user=phone
SIP-proxyn analyserar Request-URI och om parametern user=phone finns hanterar tjänsten Request-URI som ett telefonnummer som matchar numret till en användare. Om parametern inte finns tillämpar SIP-proxyn heuristik för att fastställa användartypen Request-URI (telefonnummer eller en SIP-adress).
Microsoft rekommenderar att du alltid använder parametern user=phone för att förenkla samtalskonfigurationsprocessen.
Rubrik för historikinformation
Kommentar
I Azure Communication Services är direktdirigeringsrubriken History-Info aktiverad som standard och kan inte inaktiveras.
Historik-Info-huvudet används för att ommåla SIP-begäranden och "tillhandahålla en standardmekanism för att samla in information om begärandehistorik för att möjliggöra en mängd olika tjänster för nätverk och slutanvändare". Mer information finns i RFC 4244 – Avsnitt 1.1. För direktdirigering används den här rubriken i scenarier med samtidiga ring- och vidarebefordringssamtal.
Historikinformation är aktiverad på följande sätt:
SIP-proxyn infogar en parameter som innehåller det associerade telefonnumret i enskilda historikinformationsposter som utgör rubriken Historik-Info som skickas till PSTN-styrenheten. Med endast poster som har parametern telefonnummer återskapar PSTN-styrenheten ett nytt historikinformationshuvud och skickar det vidare till SIP-stamprovidern via SIP-proxyn.
Rubrik för historikinformation läggs till för samtidiga ring- och vidarekopplingsfall.
Historikinformationsrubriken läggs inte till för samtalsöverföringsärenden.
En post för enskild historik i det rekonstruerade historikinformationshuvudet har den angivna telefonnummerparametern i kombination med det direkta routnings-FQDN (sip.pstnhub.microsoft.com) som anges som värddelen av URI:n. En parameter för "user=phone" som lagts till som en del av SIP-URI:n. Alla andra parametrar som är associerade med det ursprungliga historik-info-huvudet, förutom parametrar för telefonkontext, skickas igenom i det rekonstruerade historikinformationshuvudet.
Kommentar
Poster som är privata (enligt de mekanismer som definieras i avsnitt 3.3 i RFC 4244) vidarebefordras, vilket beror på att SIP-stamprovidern är en betrodd peer.
Inkommande historikinformation bevaras för loopskydd.
Följande är formatet på rubriken Historik-info som skickas av SIP-proxyn:
<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2
Om anropet omdirigerades flera gånger inkluderas information om varje omdirigering med lämplig orsak i kronologisk ordning i en kommaavgränsad lista.
Rubrikexempel:
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
SIP-URI:n i rubriken Historik-Info formateras enligt avsnitt 25 i RFC 3261 (se definitionen av addr-spec). I föregående exempel är den ursprungliga texten i URI-huvudet Reason , som hämtar dess ;, "och = tecken som har undantagit sina ASCII-hexvärden %3B, %22respektive 3D.SIP;cause=496;text="User Busy"
Historikinformationen skyddas av en obligatorisk TLS-mekanism.
SBC-anslutning till direktdirigering och redundansmekanism
Se avsnittet Redundansmekanism för SIP-signalering i infrastrukturkrav för direktdirigering.
Försök igen efter
Om ett direkt routningsdatacenter är upptaget kan tjänsten skicka ett återförsöksmeddelande med ett intervall på en sekund till SBC. När SBC tar emot ett 503-meddelande med ett återförsökshuvud som svar på en INVITE måste SBC avsluta anslutningen och prova nästa tillgängliga Microsoft-datacenter.
Hantera återförsök (603 svar)
Om en slutanvändare observerar flera missade anrop för ett samtal efter att ha avböjt det inkommande samtalet innebär det att SBC- eller PSTN-stamproviderns återförsöksmekanism är felkonfigurerad. SBC måste konfigureras om för att stoppa återförsöken för 603-svaret.